There has been a recent spike in the number of Announcer badges being awarded on TeX.SE. A query on SEDE highlights this:

enter image description here

The last four months saw the occasional awarding of more than one-a-day, with April 2017 shooting up to 3+ per day.

Similar increases or spikes seem to have occurred on SO, SF and SU.

Can anyone shed some light on this? Was there any changes in the back-end that caused this?

  • 1
    Marking this as [status-completed] since it was a result of the move and a temporary issue overall. Commented Jan 7, 2019 at 19:56

1 Answer 1


This is caused by the switch to HTTPS.

Stack Overflow changed to HTTPS on May 22, and guess what happened. Here are the awarded Announcer badges on Stack Overflow:

announcer badge graph 12017

This has a technical reason. Visitors coming from within the Stack Exchange network didn't count towards the badge as they were filtered out using the HTTP Referer header. The problem is, HTTPS disallows cross-domain Referers1, thus visitors from within the network, even from child metas, can no longer be distinguished from outside visitors.

1: not entirely true, see comments for details.

  • 3
    The default referrer policy for modern browsers is to send the full referrer URL for HTTPS-to-HTTPS links, even across domains. So this effect must be caused by one or more of 1) oddball browsers that deviate from this default behavior, 2) internal links to http: URLs that aren't automatically rewritten to use HTTPS by the SE Markdown parser (was an issue during the transition, but shouldn't happen any more), or 3) possible bugs in the Announcer badge tracking code (e.g. not properly recognizing https: referrer URLs). Commented Jul 16, 2017 at 14:49
  • The specific paragraph @IlmariKaronen is referring to is "The empty string "" corresponds to no referrer policy, causing a fallback to a referrer policy defined elsewhere, or in the case where no such higher-level policy is available, defaulting to "no-referrer-when-downgrade". This defaulting happens in the §8.3 Determine request’s Referrer algorithm." w3c.github.io/webappsec-referrer-policy/…
    – Braiam
    Commented Sep 6, 2017 at 13:59
  • @Braiam: Indeed. It's also easy enough to observe (e.g. using the developer tools built into most browsers nowadays) that Referer (sic) headers are getting sent for links between SE sites, even over HTTPS. Thus, I suspect the real cause is a bug in the SE referral tracking code, perhaps an old regexp getting confused by the extra s in the referrer URLs or something. Commented Sep 6, 2017 at 14:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .