Firefox 85 crumbles cache-abusing supercookies with potent partitioning powers
(2021/01/27)
- Reference: 1611727265
- News link: https://www.theregister.co.uk/2021/01/27/firefox_85_crumbles_supercookies/
- Source link:
The Mozilla Foundation has scorched a pair of monstrosities in the new version 85 of its Firefox browser.
The big target is supercookies which, as [1]explained by Mozilla privacy engineer Steven Englehardt and senior product manager for Firefox privacy and security Arthur Edelstein, are very nasty trackers indeed because they exploit best-practice browser behaviour to offer tracking that goes beyond both that allowed by “official” Cookies and privacy laws.
[2]
“Like all web browsers, Firefox shares some internal resources between websites to reduce overhead,” the pair explain, before offering up the Firefox cache as an example of this approach at work. “If the same image is embedded on multiple websites, Firefox will load the image from the network during a visit to the first website and on subsequent websites would traditionally load the image from the browser’s local image cache (rather than reloading from the network).”
Trackers have found ways to abuse these shared resources to follow users around the web
[3]
So far, so sensible. But also, so exploitable by the cynical.
“Unfortunately, some trackers have found ways to abuse these shared resources to follow users around the web. In the case of Firefox’s image cache, a tracker can create a supercookie by ‘encoding’ an identifier for the user in a cached image on one website, and then ‘retrieving’ that identifier on a different website by embedding the same image,” the pair write.
Firefox 85 fights back by using “a different image cache for every website a user visits.”
This approach preserves the benefit of caching because files are still stored locally. But critically Firefox no longer shares caches across sites.
Englehard and Edelstein identify eleven caches - HTTP cache, image cache, favicon cache, HSTS cache, OCSP cache, style sheet cache, font cache, DNS cache, HTTP Authentication cache, Alt-Svc cache, and TLS certificate cache – that they needed to address.
But that’s not all they needed to change. “Firefox would reuse a single network connection when loading resources from the same party embedded on multiple websites,” the pair wrote. While this approach would avoid the need for extra TCP handshakes as browsers reach for different resources, sustaining a single network session enabled user tracking.
Verizon fined just $1.4m for stalker supercookies [4]READ MORE
Firefox 85 therefore “partitions pooled connections, prefetch connections, preconnect connections, speculative connections, and TLS session identifiers.”
The two Mozillans admit that this new approach does impact page load time but rate the hit as “very modest” as it delivers “between a 0.09% and 0.75% increase at the 80th percentile and below, and a maximum increase of 1.32% at the 85th percentile.” The pair say that’s about the same as similar protections coming real soon now to Chrome.
Indeed, the two authors sign off by thanking “colleagues in the Brave, Chrome, Safari and Tor Browser teams” for their own supercookie-crumbling efforts.
The second nasty killed in Firefox 85 is Adobe Flash, which [5]release notes state has been so thoroughly dispelled that “There is no setting available to re-enable Flash support.”
[6]
Which is a fine idea because on top of Flash being a security nightmare, it was one more tool that supercookie-bakers used to create their evil trackers. ®
Get our [7]Tech Resources
[1] https://blog.mozilla.org/security/2021/01/26/supercookie-protections/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YBFHxrq7GwunDJ69CCRa7wAAAFM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YBFHxrq7GwunDJ69CCRa7wAAAFM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://www.theregister.com/2016/03/07/verizon_fined_135m_for_stalker_supercookies/
[5] https://www.mozilla.org/en-US/firefox/85.0/releasenotes/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YBFHxrq7GwunDJ69CCRa7wAAAFM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://whitepapers.theregister.com/
The big target is supercookies which, as [1]explained by Mozilla privacy engineer Steven Englehardt and senior product manager for Firefox privacy and security Arthur Edelstein, are very nasty trackers indeed because they exploit best-practice browser behaviour to offer tracking that goes beyond both that allowed by “official” Cookies and privacy laws.
[2]
“Like all web browsers, Firefox shares some internal resources between websites to reduce overhead,” the pair explain, before offering up the Firefox cache as an example of this approach at work. “If the same image is embedded on multiple websites, Firefox will load the image from the network during a visit to the first website and on subsequent websites would traditionally load the image from the browser’s local image cache (rather than reloading from the network).”
Trackers have found ways to abuse these shared resources to follow users around the web
[3]
So far, so sensible. But also, so exploitable by the cynical.
“Unfortunately, some trackers have found ways to abuse these shared resources to follow users around the web. In the case of Firefox’s image cache, a tracker can create a supercookie by ‘encoding’ an identifier for the user in a cached image on one website, and then ‘retrieving’ that identifier on a different website by embedding the same image,” the pair write.
Firefox 85 fights back by using “a different image cache for every website a user visits.”
This approach preserves the benefit of caching because files are still stored locally. But critically Firefox no longer shares caches across sites.
Englehard and Edelstein identify eleven caches - HTTP cache, image cache, favicon cache, HSTS cache, OCSP cache, style sheet cache, font cache, DNS cache, HTTP Authentication cache, Alt-Svc cache, and TLS certificate cache – that they needed to address.
But that’s not all they needed to change. “Firefox would reuse a single network connection when loading resources from the same party embedded on multiple websites,” the pair wrote. While this approach would avoid the need for extra TCP handshakes as browsers reach for different resources, sustaining a single network session enabled user tracking.
Verizon fined just $1.4m for stalker supercookies [4]READ MORE
Firefox 85 therefore “partitions pooled connections, prefetch connections, preconnect connections, speculative connections, and TLS session identifiers.”
The two Mozillans admit that this new approach does impact page load time but rate the hit as “very modest” as it delivers “between a 0.09% and 0.75% increase at the 80th percentile and below, and a maximum increase of 1.32% at the 85th percentile.” The pair say that’s about the same as similar protections coming real soon now to Chrome.
Indeed, the two authors sign off by thanking “colleagues in the Brave, Chrome, Safari and Tor Browser teams” for their own supercookie-crumbling efforts.
The second nasty killed in Firefox 85 is Adobe Flash, which [5]release notes state has been so thoroughly dispelled that “There is no setting available to re-enable Flash support.”
[6]
Which is a fine idea because on top of Flash being a security nightmare, it was one more tool that supercookie-bakers used to create their evil trackers. ®
Get our [7]Tech Resources
[1] https://blog.mozilla.org/security/2021/01/26/supercookie-protections/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YBFHxrq7GwunDJ69CCRa7wAAAFM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YBFHxrq7GwunDJ69CCRa7wAAAFM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://www.theregister.com/2016/03/07/verizon_fined_135m_for_stalker_supercookies/
[5] https://www.mozilla.org/en-US/firefox/85.0/releasenotes/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YBFHxrq7GwunDJ69CCRa7wAAAFM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://whitepapers.theregister.com/
Crypto Monad
This issue is not so much about caching of HTML pages themselves, but of the assets referenced within them - images, CSS stylesheets, Javascript etc.
Even when fetching over HTTPS, I doubt your browser refetches *all* the assets for a page for every page view. For many sites that would be multiple megabytes per view; you'd certainly notice it.
The problem described in the article is when two separate websites (site1 and site2) both reference an asset at the same URL, e.g. img src="https://example.com/foo.png". Colluding sites could generate an image (or stylesheet etc) dynamically, and then check its content. The solution in Firefox is to have separate caches when browsing site1 and site2.
Good stuff. However, I have caching of HTTPS pages disabled (which makes no discernible difference to page load times on my modest 36Mbit broadband), and I also enforce HTTPS (only occasionally making an exception when absolutely necessary), so this won't make too much difference to me. I re-iterate my call for HTTPS on every website, and I await the inexplicable downvoting from those who seem to think it's a bad idea because its hard work* or something.
*Before anyone says LetsEncrypt is difficult to understand etc., I will note that I find it utterly seamless with my hosting provider. In any case, that's not an argument against HTTPS, it's an argument for simpler implementation of HTTPS certificate management.