potential abuse

From a product perspective, unregistered users reliably receive talk page notification banners during their anonymous edit session (a.k.a. orange bar of doom), which starts from their first edit and lasts as long as their browser keeps a session cookie (typically 2-3 weeks I believe, but depends on browsing habbits, and browser's privacy settings).

When someone is browsing the site without any session, they generally get their page views from the Varnish cache, and this happens correctly regardless of whether there happen to be unread talkpage notifications.

However, by accident there exists a set of conditions today under which an unregistered user can see the "new talk page notification" banner, even if they don't have a session cookie:

1. You are logged-out and don't have an edit session or other session cookie.
2. There exists a User_talk page for your IP.
3. There are unread messages on said user talk page (i.e. when you last had a session cookie, you didn't click the banner or otherwise visit your own talk page after the message was sent; noting that "visiting" the talk page is what marks it as read).
4. You are the first to view an article after it expires from the CDN cache.

By all odds, even when this does happen, the very next article you navigate to, or even if you merely refresh the page, the banner may be gone again since you're likeky to hit the CDN cache generally.

In summary: Despite not having seen the orange notification banner for several days between when your session expired and the random CDN-cache-miss response you received when reading an article, you can sometimes get random pageviews with a banner on it. Those intermittent responses are (gladly) correclty marked uncacheable, and do not poison the cache with a personalised response for the world to see. But, as per the task description, it does "teach" Varnish that this URL is sometimes uncacheable even without a session cookie, which is an open attack vector.

Conceptually, this feature is similar to other personalisation features in MediaWiki, and we generally only apply those when there is a session cookie. The user talk page notification is an exception to that principle.

I estimate it as low-risk to fix, and generally meet user expectations to do so. If anything, it seems not unlikely that serving this to users who don't have a session may be unrelated visitors on the same IP (e.g. imagine a school or office, where you get a banner for someone else on the same connection). Or for example when a floating IP is re-assigned after many months you might get "notified" about something that happened a long time ago and may have been addressed to someone else.

It also matches the future in terms of Temp users, in that with that model, there literally isn't a way to show notifications to non-session pages as we wouldn't know which Temp user they are, since the cookie is what assigns the user ID.

Patch was made a couple days ago but somehow the phab ticket wasn't labelled. Adding a label manually.

but somehow the phab ticket wasn't labelled

This ticket is not public so @gerritbot cannot access it.

@Aklapper good point. Thanks - I didn't know that.

Could we make this task public, or do the IP addresses etc. posted here make it PermanentlyPrivate? (it seems that they're our own IPs)

In T350861#9409634, @matmarex wrote:

Could we make this task public, or do the IP addresses etc. posted here make it PermanentlyPrivate? (it seems that they're our own IPs)

I'm fine with this task being public now, unless other folks have concerns about potentially (still) sensitive data within this task.

In T350861#9394457, @Aklapper wrote:

This ticket is not public so @gerritbot cannot access it.

One can always add @gerritbot as a subscriber to protected tasks like these. Of course, if a public patch is being created within gerrit, then there often isn't much additional value in keeping the relevant task protected.