Timeline for Announcer badge spike
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 12, 2017 at 19:31 | history | edited | Floern | CC BY-SA 3.0 |
footnote
|
| Sep 10, 2017 at 6:34 | history | bounty ended | Shadow Wizard | ||
| Sep 6, 2017 at 14:19 | comment | added | Ilmari Karonen |
@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.
|
|
| Sep 6, 2017 at 13:59 | comment | added | Braiam | 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/… | |
| Jul 16, 2017 at 14:49 | comment | added | Ilmari Karonen |
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).
|
|
| Jul 16, 2017 at 5:41 | vote | accept | Werner | ||
| Jul 15, 2017 at 22:16 | history | answered | Floern | CC BY-SA 3.0 |