- A plain explanation of the HSTS protocol and the cache behind it
- How that cache can encode a simple pattern that follows you between sites
- Why clearing history often leaves this cache untouched
- How state partitioning addresses the issue without weakening security
A Security Rule That Doubles as Long-Term Memory
HSTS was designed to solve a real connection problem. When you type a web address, your browser once tried an unencrypted connection first, then switched to the secure version. HSTS lets a site tell your browser to skip that step and always use the encrypted connection from the start. To follow this instruction later, your browser writes the rule into a dedicated HSTS cache and keeps it. That storage behavior is the useful part for security. It is also the part that makes the cache interesting for identification. Any place a browser reliably remembers something can, in principle, hold a value that describes it. The HSTS cache fits that description, which is why it sometimes appears in discussions about stateless tracking methods.
A feature built to remember a safety preference can also remember a pattern that is specific to your browser.
How a Pattern Gets Written Into the Cache
The method relies on a set of subdomains rather than a single site. Picture a tracking service that controls many addresses, such as a.example, b.example, c.example, and so on. A script can quietly ask your browser to load a small resource from each one. The sequence generally looks like this:
The service applies the HSTS rule to some of those subdomains and leaves others without it.
Your browser records the rule for the subdomains that set it, and records nothing for the rest.
The pattern of "has a rule" and "has no rule" across the group forms a string of ones and zeros.
That binary string works like a number, and a long enough string can be close to unique for a given browser.
On a later visit to a different site using the same service, the script checks which subdomains your browser already forces to the secure version, reproducing the same value.
Because the value lives in the security cache rather than in a cookie file, it can persist through routines that only target cookies and history.
Why Clearing History Often Leaves It Behind
This is where the behavior surprises people. Several factors keep the pattern in place. The cache is usually preserved on purpose: when you clear browsing data, many browsers keep the HSTS cache intact, because removing it would send you back to the older, less secure connection behavior on your next visit. It also operates below scripts: HSTS is handled at the network layer, so script-blocking tools do not always reach that layer. And the rules are built to last: an HSTS instruction can remain valid for a long stretch, so the encoded pattern can stay well beyond a single session. The point to remember is that persistence here is a side effect of a safety design, not a sign that anything unusual is happening on your device.
Separating the Cache by Site With State Partitioning
You cannot simply switch HSTS off, because that would return your connections to the weaker default. A more measured answer is to isolate the memory so that one site cannot read what another site wrote. Total Adblock takes this route with Network State Partitioning. Instead of altering the HSTS protocol itself, it groups the security cache according to the top-level site you are currently on. A pattern written while you read one site is kept in its own compartment. When you move to a different site later, a script that tries to read the HSTS cache sees only the entries tied to that new context. The earlier pattern is not available to it, so the values cannot be stitched together across sites. The security benefit of HSTS stays fully in place for each site you visit, while the shared identifier loses its meaning.
A Measured Way to Think About Browser Storage
The HSTS example is a good reminder that identification does not always depend on obvious files. A quiet security cache can hold a pattern just as well. That does not call for alarm — it calls for a clear understanding of how browser storage behaves and what your options are. Partitioning that storage gives you more say over which contexts can share information and which stay separate. It sits alongside familiar habits, such as keeping your browser current and paying attention to the sites you use most.
