What actually triggered the real "state was purged" warning on osztromok.com, and how to diagnose it properly
This chapter exists because of a real warning seen while using this site: "The state of 'osztromok.com' was recently purged because it was detected as a bounce tracker." Chapter 3 covered the browser-side crackdown on third-party tracking in general terms — this chapter goes specifically into bounce tracking, the exact heuristic responsible for that message, and a practical way to investigate whether osztromok.com is actually doing anything tracking-like, or just incidentally resembling the pattern.
The actual warning, and what we know so far
The message appeared when navigating to osztromok.com/linux in a Safari/WebKit-based browser. Crucially: this is a storage purge notice, not a connection error — it means the browser cleared cookies/localStorage for the domain, not that the page failed to load. It's a separate issue from the ECONNREFUSED routing problem investigated earlier (port-forwarding/DNS) — that one is about reachability; this one is about what the browser does once it CAN reach the site.
What Bounce Tracking Actually Is
Bounce tracking (sometimes called "redirect tracking") is a workaround trackers developed specifically to get around third-party cookie restrictions (Chapter 3) — instead of embedding a tracker as a third party, the user is very briefly, almost invisibly, redirected through the tracker's own domain as a first party, which lets that domain set cookies as if the user had genuinely visited it directly, before bouncing them straight back to where they were going.
The visit to tracker.com is real and brief, but happens so fast and invisibly the user never notices — it's just a stop on the way to the actual destination
Why Browsers Flag This Pattern
Because the redirect through the tracking domain is genuinely a first-party visit (just extremely brief), the SameSite restrictions from Chapter 2 don't stop it — the tracker's cookie is legitimately first-party for that split second. WebKit's response (the mechanism behind Safari's ITP, mentioned in Chapter 3) is behavioural: detect domains that are visited only as quick intermediate redirect hops, never as actual destinations users stay on, and purge their storage shortly after.
This is exactly the heuristic false-positive risk flagged in Chapter 3
The detection is pattern-based, not based on a list of known trackers — it's looking at behaviour (redirect-then-bounce, short visit duration, no genuine user engagement) rather than confirmed tracking intent. A legitimate site that happens to redirect through itself quickly, or gets visited briefly as an intermediate step in some navigation flow, can trigger the same detection with zero actual tracking happening.
Plausible Causes on osztromok.com — A Diagnostic Checklist
Without inspecting the live site's actual navigation flow, these are the most common legitimate (non-tracking) causes of this exact warning, ranked by how often they actually turn out to be the culprit:
🔁 A redirect chain on load
HTTP → HTTPS redirect, or a www/non-www redirect, or an old URL structure redirecting to a new one — if any of these happen in quick succession, especially combined with setting a cookie at each hop, it resembles the bounce pattern closely.
Most likely cause
🍪 A cookie set immediately, then the page navigates away quickly
If /linux itself (or a page it loads through) sets a cookie and then immediately redirects somewhere else — even for a legitimate reason like a login check or an old-URL redirect — that's structurally identical to the bounce pattern from WebKit's perspective.
Most likely cause
🔗 Arriving via a link/embed from another domain
If the warning appeared after following a link from search results, social media, or an embedded reference elsewhere, the "bounce" might be the click-through itself, especially if osztromok.com briefly redirects before settling on the final page.
Possible
📊 An embedded third-party analytics/widget script
If any analytics tool, ad, or embedded widget on the page itself performs its own redirect-based tracking technique, WebKit may be flagging the embedded tracker's behaviour rather than anything osztromok.com is doing directly.
Less likely, but worth ruling out
How to Actually Diagnose It
1
Open Safari's Web Inspector → Network tab, then navigate to the affected page fresh
Look specifically for a chain of 3xx redirect responses before the final 200 — that chain, if it exists, is the prime suspect.
2
Check the Application/Storage tab for what cookies osztromok.com actually sets, and when
If a cookie gets set during one of those redirect hops rather than on the final settled page, that's very likely the exact trigger.
3
Check the server config (Apache/nginx) for the actual redirect rules in play
HTTP→HTTPS redirects, trailing-slash redirects, and old-URL redirects are all extremely common and entirely legitimate — the fix usually isn't removing the redirect, just not setting cookies during it (set cookies only on the final destination response).
4
If a third-party script is implicated, check its documentation for known ITP-related guidance
Major analytics and ad platforms have published guidance for ITP compliance specifically — often a configuration flag rather than removing the integration outright.
The practical fix, once diagnosed, is usually small
In the most common case (a redirect chain that also sets a cookie), the fix is simply moving the cookie-setting logic to happen on the final destination page rather than during an intermediate redirect — the redirect itself can stay exactly as it is. This is a configuration/code change, not something that requires removing legitimate functionality.
Chapter 4 Quick Reference
Bounce tracking — briefly redirecting through a domain as a first-party visit specifically to set tracking cookies, then bouncing back
The warning is a storage purge, not a connection error — separate from the ECONNREFUSED routing issue investigated earlier
Detection is heuristic/behavioural, not list-based — legitimate sites can trigger false positives
Most likely cause on osztromok.com: a redirect chain (HTTP→HTTPS, www, old-URL) that also sets a cookie during one of the hops
Diagnose with: Web Inspector Network tab (look for a 3xx chain) + Storage tab (check when cookies actually get set)
Likely fix: set cookies only on the final destination response, not during intermediate redirects — the redirect itself is fine to keep
Next chapter: CORS — Same-Origin Policy, preflight requests, and reading real CORS error messages