Firefox 85 Cracks Down on Supercookies

Imatge
Àmbits Temàtics
Àmbits de Treball

Trac­kers and adtech compa­nies have long abused brow­ser featu­res to follow people around the web. Since 2018, we have been dedi­ca­ted to redu­cing the number of ways our users can be trac­ked. As a first line of defense, we’ve bloc­ked cookies from known trac­kers and scripts from known finger­prin­ting compa­nies.

In Fire­fox 85, we’re intro­du­cing a funda­men­tal change in the brow­ser’s network archi­tec­ture to make all of our users safer: we now parti­tion network connec­ti­ons and caches by the website being visi­ted. Trac­kers can abuse caches to create super­co­o­kies and can use connec­tion iden­ti­fi­ers to track users. But by isola­ting caches and network connec­ti­ons to the website they were crea­ted on, we make them useless for cross-site trac­king.

What are super­co­o­kies?

In short, super­co­o­kies can be used in place of ordi­nary cookies to store user iden­ti­fi­ers, but  they are much more diffi­cult to delete and block. This makes it nearly impos­si­ble for users to protect their privacy as they browse the web. Over the years, trac­kers have been found storing user iden­ti­fi­ers as super­co­o­kies in incre­a­singly obscure parts of the brow­ser, inclu­ding in Flash storage, ETags, and HSTS flags.

The chan­ges we’re making in Fire­fox 85 greatly reduce the effec­ti­ve­ness of cache-based super­co­o­kies by elimi­na­ting a trac­ker’s ability to use them across websi­tes.

How does parti­ti­o­ning network state prevent cross-site trac­king?

Like all web brow­sers, Fire­fox shares some inter­nal resour­ces between websi­tes to reduce over­head. Fire­fox’s image cache is a good exam­ple: if the same image is embed­ded on multi­ple websi­tes, Fire­fox will load the image from the network during a visit to the first website and on subse­quent websi­tes would tradi­ti­o­nally load the image from the brow­ser’s local image cache (rather than relo­a­ding from the network). Simi­larly, Fire­fox would reuse a single network connec­tion when loading resour­ces from the same party embed­ded on multi­ple websi­tes. These tech­ni­ques are inten­ded to save a user band­width and time.

Unfor­tu­na­tely, some trac­kers have found ways to abuse these shared resour­ces to follow users around the web. In the case of Fire­fox’s image cache, a trac­ker can create a super­co­o­kie by  “enco­ding” an iden­ti­fier for the user in a cached image on one website, and then “retri­e­ving” that iden­ti­fier on a diffe­rent website by embed­ding the same image. To prevent this possi­bi­lity, Fire­fox 85 uses a diffe­rent image cache for every website a user visits. That means we still load cached images when a user revi­sits the same site, but we don’t share those caches across sites.

In fact, there are many diffe­rent caches trac­kers can abuse to build super­co­o­kies. Fire­fox 85 parti­ti­ons all of the follo­wing caches by the top-level site being visi­ted: HTTP cache, image cache, favi­con cache, HSTS cache, OCSP cache, style sheet cache, font cache, DNS cache, HTTP Authen­ti­ca­tion cache, Alt-Svc cache, and TLS certi­fi­cate cache.

To further protect users from connec­tion-based trac­king, Fire­fox 85 also parti­ti­ons pooled connec­ti­ons, prefetch connec­ti­ons, precon­nect connec­ti­ons, specu­la­tive connec­ti­ons, and TLS session iden­ti­fi­ers.

This parti­ti­o­ning applies to all third-party resour­ces embed­ded on a website, regard­less of whet­her Fire­fox consi­ders that resource to have loaded from a trac­king domain. Our metrics show a very modest impact on page load time: between a 0.09% and 0.75% incre­ase at the 80th percen­tile and below, and a maxi­mum incre­ase of 1.32% at the 85th percen­tile. These impacts are simi­lar to those repor­ted by the Chrome team for simi­lar cache protec­ti­ons they are plan­ning to roll out.

Syste­ma­tic network parti­ti­o­ning makes it harder for trac­kers to circum­vent Fire­fox’s anti-trac­king featu­res, but we still have more work to do to conti­nue to strengt­hen our protec­ti­ons. Stay tuned for more privacy protec­ti­ons in the coming months!

Thank you

Re-archi­tec­ting how Fire­fox hand­les network connec­ti­ons and caches was no small task, and would not have been possi­ble without the tire­less work of our engi­ne­e­ring team: Andrea Marche­sini, Tim Huang, Gary Chen, Johann Hofmann, Tanvi Vyas, Anne van Keste­ren, Ethan Tseng, Prangya Basu, Wennie Leung, Ehsan Akhgari, and Dimi Lee.

We wish to express our grati­tude to the many Mozi­lli­ans who contri­bu­ted to and suppor­ted this work, inclu­ding: Selena Deckel­mann, Mikal Lewis, Tom Ritter, Eric Rescorla, Olli Pettay, Kim Moir, Gregory Mierz­winski, Doug Thayer, and Vicky Chin.

We also want to acknow­ledge past and ongoing efforts carried out by colle­a­gues in the Brave, Chrome, Safari and Tor Brow­ser teams to combat super­co­o­kies in their own brow­sers.

 

 

+ The latest Fire­fox is here