Change 609810 had a related patch set uploaded (by Mepps; owner: Mepps):
[mediawiki/extensions/CentralNotice@master] Allow redirect on Special:HideBanners on limited redirectUrl

https://gerrit.wikimedia.org/r/609810

The next step will be adding the redirect to paymentswiki, right?

So I'm looking at how we currently do this and we set this cookie for all wiki projects by pulling in the hidebanner page in an img tag. I assume this way we'll only do it for Wikipedia?

Also I assumed we'd only want to whitelist one domain at any given time, given the use case, but I might want to change it to an array.

This is currently waiting on a consult with Traffic per @AndyRussG's comment on the Phabricator ticket:

Woohooo thanks so so much!!! Hmmm locally? Weird...
BTW I think we need to consult with Traffic about how this will interact with the front-end cache. I saw a ticked related to the existing mechanism, actually: T256447.
So, just to say, let's not merge until we've done that, and not at all as a reflection of the state of the code itself, I'm setting a -1 code review for now.
Thanks again!!!

We also need to ensure we can properly escape the url parameters on the thank you url in DI.

Adding Traffic and Operations tags to ask for input about how Varnish caching for this new redirecting special page. Please see the attached patch.

General explanation:

• After donating, users currently are sent to a "thank-you" page on Donate Wiki which sets cross-site cookies to hide fundraising banners for a year.
• Browsers are ending support for cross-site cookies.
• The proposed solution is to send donors through Wikipedia to set the cookie there, then redirect them to the thank-you page on Donate Wiki.
• This should be fine since we only show fundraising banners on Wikipedia anyway.
• Special:HideBanners will perform the redirect and set the cookie, as in the attached patch. It'll have a redirect URL parameter with the specific URL the user should be redirected to. Probably only non-logged-in will ever hit this page, and the amount traffic may be reasonable (though not huge, by production cluster standards, I think) during some fundraising campaign times.

Many thanks in advance for any suggestions--especially on the last point!

Thanks to everyone working on this. I'd like to suggest this task be considered High priority, as we have banners up in Netherlands currently, and donors will continue to see banners after donating.

@MBeat33 I just emailed Peter to ask what he thinks about the complexity of this; I could have just pinged him here too, sorry :)

@MBeat33 You can just point them directly to the following link, it will appear blank but does set the cookies. Despite being at en.wikipedia.org the cookie will apply to all wikipedia.org language subdomains.

https://en.wikipedia.org/w/index.php?title=Special:HideBanners&category=fundraising&reason=donate

Thank you @Pcoombe this is great. Does the error message that I saw when testing affect the setting of the cookie?

If that's normal we can tell donors to expect that and assure them that it will suppress the banners.

Also, is that message what logged in users will see? When I tested the link in other browsers (not logged in) the page was indeed blank.

@MBeat33 That's normal for Firefox. Some other browsers will also show a broken image symbol. However the cookie setting still works: I tested in Chrome, Firefox, Safari, IE11 and Edge

Great, thank you for confirming @Peter Coombe <pcoombe@wikimedia.org>

@Krinkle explained in IRC that this approach will probably not work long term, and risks Wikipedia being classified as a bounce-tracker by WebKit browsers. More context here:
https://webkit.org/tracking-prevention/ (under the ITP section)

He suggested we put the thank you page on a *.wikipedia.org domain rather than *.wikimedia.org, so it can set the cookie itself.

He suggested we put the thank you page on a *.wikipedia.org domain rather than *.wikimedia.org, so it can set the cookie itself.

Just more follow-up, a couple other super-short-term solutions that I think we could implement tomorrow:

• Set hide cookies from within banners, as soon as the user clicks to donate. Disadvantage is that users who don't complete the donation process will still have banners hidden.
• Put a link in the thank-you page and/or thank-you e-mail for users to click to hide fundraising banners.

Thanks so much @Ejegg, @MBeat33, @Pcoombe, @mepps, everyone else, for working on this tough problem, btw!!

Just another idea for the shortest-term solution: in the banner, we could try to determine the user's browser version, and based on that, only set the hide cookie from within the banner if we think the browser won't tolerate the hide cookie being set in the background on the thank-you page.

Browser sniffing could also be used to determine whether or not to show a hide-banners manual link on the thank-you page.

@Ejegg what about this option? We set a special cookie on donate.wikimedia.org when people go to the thank-you page, then include code in the banners to check it in the background before actually displaying the banner? I think that's in line with sort of flow for cross-site interactions that will still be allowed?

@AndyRussG Hmm, that cross-site cookie check would require at least one more web request to complete before we decide whether or not to show the banner. Wouldn't that lead to more 'banner bump' issues where we redraw the page?

I like that last idea (special cookie on donate wiki that we check in banners), @AndyRussG! I would be reluctant to set a hide cookie in the banner for any user who clicks donate, because our best conversion rate is around 75%. I'm sure there's some portion of that missing 25% who get interrupted in the donor flow and end up giving later on a subsequent banner impression.

Some quick thoughts on proposed solutions

TY page on *.wikipedia.org
- need a new restricted access site to do it on
- need to completely rewrite TY page, since we won't have RawHTML

Set hide cookie when someone clicks in banner
+ easy
- some false positives for people who don't complete donation
- does nothing for email (or sidebar etc) donors

Link on TY page or in TY email
+ easy
- not a great experience for donors

Cross-site cookie check in banners
? sounds promising but I'm not 100% sure how this is done

Put a link in the thank-you page and/or thank-you e-mail for users to click

I'd like to advocate generally for the process to be automated as much as possible, rather than one that requires the donor to take actions like reading and clicking something on the Thank You page. Persistent banner complaints are a sizable portion of our Zendesk tickets, so automating the hide cookie would help keep these complaints from increasing.

Here is another option. We make a subdomain with a name similar to fundraising.wikipedia.org or donate.wikipedia.org and we either move all of donate wiki there or we only move the TY pages. this resolves the negatives @Pcoombe brings up in his pros and cons list. I will also reiterate this on the email thread.

One more option (thanks to @Jgreen for this idea): we could create a thank-you banner on Wikipedia. So, instead of going to the thank-you page on Donate Wiki, donors could be sent to Wikipedia with a banner= parameter in the URL to force the banner to appear. It could have the same content as the thank-you page and set the cookie to suppress further FR banners.

That might be the easiest automated solution, in that it could be done right away, with no deployments or server config changes needed.

I don't know if it'd be a problem in that it might invalidate previous t-y page tests? This is a concern @DStrine mentioned. Just to note also, banners can do basically anything to a page.

Regarding the option of setting a cookie on donate wiki and checking it before we display the banner:

In T251780#6296963, @Pcoombe wrote:

Cross-site cookie check in banners
? sounds promising but I'm not 100% sure how this is done

I'm not sure either, I'm afraid... From what I understand, browsers may still give some allowances for third-party cookies to be sent back to servers (though not set) in background requests. I'm guessing we might have to do some server-side engineering to create a page on donate wiki that reads the cookie and returns something different based on its value. We could hit that page in a background request from Wikipedia, and then in Javascript see in the result that was returned? In any case, maybe it's worth looking into?

In T251780#6296790, @Ejegg wrote:

@AndyRussG Hmm, that cross-site cookie check would require at least one more web request to complete before we decide whether or not to show the banner. Wouldn't that lead to more 'banner bump' issues where we redraw the page?

Yeah, it'd be an additional request... Though we could also potentially add a feature to CentralNotice to make the request early, before or while we fetch the banner... Like that, I think we could keep the impact on user experience to little or none.

Thank you banner
This certainly seems like it could solve the problem, but it would need a not insignificant amount of work from fr-creative. We have a lot of content on the TY page that would need porting over, and a lot of stakeholders on that content. I'm not sure how quickly we could turn this around.

If there's a possibility of being able to return donors to their original article (T60506) this becomes more interesting as it's a very common request.

Setting a cookie on donate wiki and checking it before we display the banner

@AndyRussG Can we set a .wikimedia.org cookie (i.e. without the donate subdomain) on the TY page, and then access that in the banner without an additional request? Since the banner is loading from meta.wikimedia.org

In T251780#6297530, @Pcoombe wrote:

Thank you banner
This certainly seems like it could solve the problem, but it would need a not insignificant amount of work from fr-creative. We have a lot of content on the TY page that would need porting over, and a lot of stakeholders on that content. I'm not sure how quickly we could turn this around.

If there's a possibility of being able to return donors to their original article (T60506) this becomes more interesting as it's a very common request.

Setting a cookie on donate wiki and checking it before we display the banner

@AndyRussG Can we set a .wikimedia.org cookie (i.e. without the donate subdomain) on the TY page, and then access that in the banner without an additional request? Since the banner is loading from meta.wikimedia.org

Oooh yes! Fantastic idea. It'd just be a bit of extra code server-side for Special:BannerLoader!!

It's great we are considering alternatives. I really want to highlight the effort needed to set this up. It would also require us to rely on CN as a critical piece of our donation pipeline. Finally, we need to be prepared for this to be part of our process at least through Q2 and maybe for the foreseeable future.

Some things that come to mind:

• endowment still needs its own TY page on donate wiki
• we need to run through other donation flows where we might not want to direct the user back to wikipedia (i.e. maybe some emails don't make sense going to wikipedia). In these cases we still need to have donate wiki TY pages.
• are we going to lose any analytics currently gathered on the TY page if this is in a banner?

In T251780#6297599, @AndyRussG wrote:

In T251780#6297530, @Pcoombe wrote:

Thank you banner
This certainly seems like it could solve the problem, but it would need a not insignificant amount of work from fr-creative. We have a lot of content on the TY page that would need porting over, and a lot of stakeholders on that content. I'm not sure how quickly we could turn this around.

If there's a possibility of being able to return donors to their original article (T60506) this becomes more interesting as it's a very common request.

Setting a cookie on donate wiki and checking it before we display the banner

@AndyRussG Can we set a .wikimedia.org cookie (i.e. without the donate subdomain) on the TY page, and then access that in the banner without an additional request? Since the banner is loading from meta.wikimedia.org

Oooh yes! Fantastic idea. It'd just be a bit of extra code server-side for Special:BannerLoader!!

@Pcoombe We started diving into this solution, and then realized that the Special:BannerLoader page is heavily cached.

We vary the response based on the specific querystring parameters that are sent in, but it looks like varying based on cookie value would really explode the cache. We're asking in the ops and traffic channels if they have any suggestions to get around this, but it may not be possible, so let's keep thinking of alternatives.

For the record: we are moving ahead with the TY page that is accessible from a wikipedi.org subdomain. I have edited the title and description of this task.

As I understand this:

• Confirm img tag is working as expected
• Create new subdomain donate.wikipedia.org and point to donate.wikimedia.org
• Confirm whether img tag works without additional javascript
• Send additional javascript to Peter if needed
• Change ThankYouPage config setting

It appears to already load at https://donate.wikipedia.org/w/index.php?title=Thank_You&country=US , no changes needed!

@AndyRussG and I have tested this snippet to set the hide cookie in Firefox 68.10.0esr and Chrome 80 (both on Linux): P11883

To test this on other browsers, open a console at the donate.wP.org link above and paste in the contents of that snippet. Then navigate to a page on enwiki and paste the following in a console:

mw.centralNotice.internal.hide.setCategory( 'fundraising' );
mw.centralNotice.internal.hide.processCookie();
mw.centralNotice.internal.hide.shouldHide();

The last of those should return true.

It would be nice to understand exactly HOW the page is available at donate.wikiPedia.org before we go full steam ahead with this. Below are what we know so far

• Andrew and I looked over the mediawiki config repo and found that the MultiWiki function which maps server name to db name loads 'donatewiki' for either 'donate.wikimedia.org' or 'donate.wikipedia.org'.
• The SSL cert that is served up is valid for *.wikimedia.org and *.wikipedia.org.
• donate.wikiMedia.org has its own A record which for me resolves to 208.80.154.224. donate.wikiPedia.org has a CNAME record pointing to dyna.wikimedia.org, and that resolves to the same IP address.
• Stylesheets and other resources are loaded from relative URLs (without the domain) so don't end up being cross-domain
• @Pcoombe, do you know how the root donatewiki url is configured to redirect to Special:FundraiserRedirector? I don't see that page mentioned anywhere in the cluster settings.

Thanks so much, @Ejegg!

So, just one more point to note: all of donate wiki was already available on donate.wikipedia.org. And it seems this has been the case for a while.

We could still implement measures to prevent anything besides the thank-you page from being accessible at donate.wikipedia.org. So, please let us know if that's needed? Thanks!!

Oh, well that's neat! Let's just hope Traffic don't come back and tell us it's a problem. I'm keeping all my fingers crossed!

Do we actually need the javascript snippet? I tested Chrome, Firefox and Safari with third-party cookies disabled and the current <img> technique seems to work fine for .wikipedia.org. (Sidenote: We could probably remove all the non-Wikipedia <img>s assuming there's no intention to run fundraising banners on those sites, I'll double check this with the rest of the banner team.)

@Pcoombe, do you know how the root donatewiki url is configured to redirect to Special:FundraiserRedirector? I don't see that page mentioned anywhere in the cluster settings.

I have no clue. Cluster configuration is waaaaay outside my expertise.

We could still implement measures to prevent anything besides the thank-you page from being accessible at donate.wikipedia.org. So, please let us know if that's needed? Thanks!!

Not needed from my point of view.

OK, the redirect is at the Apache site configuration level, and has only ever applied to the root URL. The server has answered to the donate.wikiPedia.org alias since at least July 2014 when this patch was merged.

OK, the settings change is deployed and tested to work (at least on Firefox). As @Pcoombe points out, the new snippet isn't needed as the existing <img> tag sets the cookie just fine now that it's on the same second-level domain.

Thank you @Ejegg! One question, for donors who don't enable cookies in their browsers we have a macro that tells them how they can suppress banners. Is it ok to modify this link and put into the macro? I just want to make sure it's usable across different countries. Something like:

https://donate.wikipedia.org/w/index.php?title=Thank_You

Yep, that link should work @MBeat33 . You can append a language code after a slash if you want to: https://donate.wikipedia.org/w/index.php?title=Thank_You/es

Awesome, thanks for confirming that.

Serving the same wiki through multiple hostnames is wholly unsupported in MediaWiki and may stop working any moment. With caching and URL normalisation and other validation mechanisms, these urls may end up redirecting, or stuck in a loop, or serve 404 or other damage any time, unannounced with no support other than to help you restore the previous status quo. I suggest that for the time this approach needs to exist, that you have a runbook written up that details how to roll this back if/when needed, and what risks that carries (e.g. what happens to existing URLs). You'll also want to include how to make it redirect to the canonical hostname and how to clear the Varnish+ATS caches for that domain if/when needed.

Thanks so much @Krinkle for the information on this!

Please see T259002: New wiki for fundraising Thank You pages with similar config as donatewiki.

Hi all, I've copied across the Thank You pages content to the new wiki. The pages are listed at https://thankyou.wikipedia.org/wiki/Main_Page. It should all work exactly the same as the donatewiki pages, all that needs changing in the settings is the domain name. And I remembered to test on mobile, there's no .m. redirect like what caught us out last time!

I think we're ready to switch to the new domain whenever it is convenient for fr-tech.

Thanks @Pcoombe for all your help!!!one!1 I want to over-communicate this with all of advancement. I'll update the email thread and we can discuss timing there.

Just out of curiosity, why was this declined @DStrine?

In T251780#6425547, @DStrine wrote:

This is done from my perspective. I'll open it if others are still using it. We are actively sending traffic to the new TY pages on the new wiki. What else needs to be done?

I interpret "declined" as "we're not going in this direction anymore", so I thought the wiki will not be used for some reason. That was my question.