Note: added the Analytics project since we might well need more data to prioritize this correctly. Please remove if it's not pertinent! :) Many thanks!!!

Whenever a user clicks on a banner's close button, we trigger background requests to Special:HideBanners to set "close" cookies on a bunch of domains.

How many?

Looks like 10, as currently listed in wgNoticeHideUrls.

// T18821
// Updates made here also need to be reflected in
// wikimediafoundation.org/wiki/Template:HideBanners
$wgNoticeHideUrls = array(
        '//en.wikipedia.org/wiki/Special:HideBanners',
        '//meta.wikimedia.org/wiki/Special:HideBanners',
        '//commons.wikimedia.org/wiki/Special:HideBanners',
        '//species.wikimedia.org/wiki/Special:HideBanners',
        '//en.wikibooks.org/wiki/Special:HideBanners',
        '//en.wikiquote.org/wiki/Special:HideBanners',
        '//en.wikisource.org/wiki/Special:HideBanners',
        '//en.wikinews.org/wiki/Special:HideBanners',
        '//en.wikiversity.org/wiki/Special:HideBanners',
        '//www.mediawiki.org/wiki/Special:HideBanners',
);

How many?

In theory might be ten but seeing numbers for wikinews I would postulate there might be a bug that is making more requests that we might want, as on that domain for the 10th of april of 2015 we have about 7 millions of requests for HideBanner and about 100.000 real pageviews.

Please see: https://phabricator.wikimedia.org/T116609

We're hiding banners across all projects when you click a banner close button, so each close click from any project makes requests to all 10 of those URLs. Most of those 7 million wikinews HideBanner requests probably have a *.wikipedia.org referrer.

In T117433#1774512, @Nuria wrote:

How many?

In theory might be ten but seeing numbers for wikinews I would postulate there might be a bug that is making more requests that we might want, as on that domain for the 10th of april of 2015 we have about 7 millions of requests for HideBanner and about 100.000 real pageviews.

Possible explanation: calls to Special:HideBanners can be caused by user actions on any wiki, so if 1 million people close a banner on Wikipedia, we'd get that number of Special:HideBanners requests on all wikis configured to set close cookies. I have no idea if the numbers bear this out, however. ;p

Why are there 3 .wikimedia.org domains in the list?

In T117433#1774574, @ori wrote:

Why are there 3 .wikimedia.org domains in the list?

Hmm, not sure... Let's ask @faidon? BTW, there's a task about tweaking this existing cross-wiki hide mechanism: T117435. (It also seems some minorish changes could be useful in JS and other places.) I thought maybe the present task could be about designing a better way... Thanks!!

I don't know for sure why there are 3 wikimedia.org domains in the list (I'd expect you as the Special:HideBanners maintainer(s) to know?) but I have a theory: we don't generally use *.wikimedia.org cookies for security reasons. We host far more than the wiki platform on wikimedia.org (anything from Icinga to Ganglia and those kinds of tools) and we don't generally trust them to be secure enough, so we wouldn't want e.g. session cookies to be leaked to them.

Just to note there's another place we call Special:HideBanners, on the Thank You page via Template:Hide banners (so that we don't keep bothering people after they give). That's probably far fewer requests than from the close button though.

One (maybe hokey) idea would be to replace the images with tiny iframes. Those could be served from a static cache, and contain inline JavaScript to set cookies (eventually localstorage) on their respective domains based on querystring or fragment parameters.

In T117433#1776028, @Ejegg wrote:

One (maybe hokey) idea would be to replace the images with tiny iframes. Those could be served from a static cache, and contain inline JavaScript to set cookies (eventually localstorage) on their respective domains based on querystring or fragment parameters.

Images are more lightweight than iframes, so this would regress client-side performance. It also increases security risk if we involve HTML and JavaScript, and doesn't reduce the request/response/cookie noise (which this task tries to resolve) as it would still require the same number of requests to be send, received and parsed from each domain.

Cachability is a good point. However, aren't our SpecialHideBanner responses cacheable already? It seems to output a 24h public cache max-age, which would mean this isn't a burden for our serves (mainly served statically from Varnish already). It makes an exception for logged-in users. This shouldn't be a problem traffic-wise (as logged-in users already have all page views go to app servers), but maybe we can remove that exception?

There shouldn't be a need for SpecialHideBanner responses to vary by anything other than the query string.

PS: T117435: Spike: CentralNotice: Verify that our Special:HideBanners cookie storm works as efficiently as possible

A word of caution from my experience with CORS when working on cross-wiki notifications in Echo: they don't always work. Some clients are configured to disallow 3rd-party cookies, and privacy extensions like AdBlock and especially Privacy Badger deliberately break CORS requests in ways that can sometimes seem arbitrary. The PB developer has expressed interest in creating a list of domain groups that are known to be the same organization (so wikipedia.org and wikimedia.org and wikibooks.org etc for us, but also google.com and gmail.com) so that they're not misinterpreted as attempts to spy on people, but that's a maybe-some-day kind of thing.

We originally used CORS requests to fetch cross-wiki notifications, but during the beta feature stage we got so many reports of Privacy Badger and other browser plugins breaking that feature that we switched to proxying these requests through the local domain. We still use CORS for cross-wiki mark-as-read requests (which are also a kind of dismissal, just like banner close button clicks), and we still get complaints about them failing for some people, especially the ones across wiki families (going from en.wikipedia.org to fr.wikipedia.org will often work, but going from en.wikipedia.org to en.wikibooks.org often won't), to the point where I'm probably going to implement proxying for mark-as-read requests the next time I'm on an airplane with no wifi.

That said, CentralAuth login relies on cross-domain techniques as well AFIAK, although they've now centralized some things via loginwiki. Perhaps the people who redesigned CentralAuth to work with loginwiki (I forget who did this) are good people to ask about how to get your cookies to be everywhere.

Is this really "normal" priority?

Removed analytics.

Please be aware that 3rd-party cookie support will go away in all browsers, and we'll need to find an alternative to that if we still want to support fundraising sites outside the wikipedia.org / wikimedia.org domains to hide banners. See https://phabricator.wikimedia.org/T244699