Firefox 85 will improve privacy with network partitioning feature
Next month's stable release of Firefox 85 will include the anti-tracking feature networking partitioning to improve user privacy on the Internet. While Firefox is not the first web browser to support network partitioning, that honor goes to Apple and the company's Safari web browser, it is a major improvement as it eliminates tracking techniques that rely on shared cache functionality.
Most Internet users are aware of cookies by now and how they may be used to track users across sites. Less known is that other data that is stored locally may also be used to track users. Browsers store all sorts of data besides cookies including HTTP and image files, favicons, fonts and more.
Up until now, these caches were set to share files, and it makes sense from a performance point of view. Instead of having to download files such as fonts for each site, the browser could simply load it from the cache if the file had been downloaded from another site in the past. Sites could use the information to determine if a user visited another site in the past.
Starting in Firefox 85, Firefox will partition network resources to eliminate this form of tracking and probing.
Google introduced support for partitioning the HTTP cache in Chrome 86 stable to prevent snooping and improve security at the same time.
Performance may be impacted as it is no longer possible to share resources, e.g. the same font. The browser needs to download the file for each top-level domain separately and that takes longer than loading it from cache. The performance impact depends largely on the sites that are visited; if none use the same resources, then no performance hit should be observed when loading sites.
Firefox users who are interested in the feature's development can check out the Meta Bug on the Bugzilla website. Firefox 85 is scheduled to be released on January 26, 2021.
Closing Words
Network partitioning improves a browser's tracking protection by separating the caches that sites may use when they are accessed in the browser. It is a welcome feature, and it appears to be supported by all modern web browsers that are based on Chromium and Firefox. (via ZDNet)
This extension conflicts with other gesture extensions (those that support real gestures). For example, if you configured its context menu to open by right click, you will definitely have issues with mouse drag gestures bound to the right button. Dragging mouse will trigger actions from the context menu as this extensions does not detect the fact that the button was not released.
This extension does not allow to use custom items (those from other extensions) available in the standard context menu.
This extension has confusing icons for some actions and does not provide a way to change them.
Cache partitioning which is introduced since Firefox 70 can be disabled in about:config by setting these privacy.partition.network_state to false. Also to improve use of cache set network.http.rcwn.enabled to false. This reduces network data usage (wasting). Then extensions like Save Page WE and SingleFile will save much faster, and won’t make double downloads. See bug 1687569 in bugzilla. Cache partitioning can be noticed in about:cache in Firefox, and you will see small key under each url. Disabling it improves speed both of browsing and of extensions which download stuff.
This is not new and I think there is confusion. Network partitioning and Cache partitioning? Firefox has cache partitioning since version 70, see https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/70 under HTTP: “The HTTP cache is now partitioned per the top-level document’s origin (bug 1536058).”. Chrome has it since version 86, meaning since 2 months ago. Extensions that download files or save pages like Save Page WE or SingleFile or SingleFileZ will be slower and waste more data. Well, Save Page WE will be actually faster than before because it has now remove no-store header of cache-control, but will be slower than without partitioning. I reported bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1687569
When will they cut down on ram usage?
Step 1: the Google/Apple/Mozilla/… browser gang introduce tons of “features” that totally carelessly allow tracking
Step 2: they ignore all the careful criticism of their design that came every time, because the web is their property anyway and fuck the users
Step 3: after many years they start mitigating a tiny bit the damage they created themselves
Result: Your favorite browser company is now a privacy company ! Celebrate.
Been waiting for this, helps strengthen my browser even more, so that I can rest assured that some hidden tracker don’t sneak under my browser’s skin, about performance, no I do not so sad about that!
I’ve haven’t had good results with FPI, with which apparently this shares some features or decentralize. Great in theory but sites are so tangled with others, many times portions of pages, whatever, just disappear.
Same with anti-fingerprinting, great idea but seems to shut down too much functionality.
Our main concern is ads, so many ads and we rarely see any with our system level blockers, so that’s where we’ll remain for now.
it is easier to immediately go to the utopia ecosystem…
Even better is when you don’t download shared resources at all. Most sites use Google fonts, LocalCDN caches them so they don’t have to be downloaded each time and they can’t be tracked by other sites.
https://addons.mozilla.org/en-US/firefox/addon/localcdn-fork-of-decentraleyes/
LocalCDN doesn’t cache resources, if it’s not supported, the connection is either blocked or allowed depending on your settings. Normal fonts aren’t included because if blocked your browser just displays the default ones, from the Google Fonts CDN only material icons are replaced at the moment, hence the dedicated toggle in advanced settings.
To improve speed a solution might be to use the Decentraleyes addon: https://addons.mozilla.org/firefox/addon/decentraleyes/
@hehep
See my reply to @Maarten, Decentraleyes is worse than LocalCDN by now:
https://www.ghacks.net/2020/12/20/firefox-85-will-improve-privacy-with-network-partitioning-feature/#comment-4481115
Just a hint.
What is the difference between network partitioning and privacy.firstparty.isolate?
Thanks, Pants, good to see you again.
@some1
Have a good time with stuff that doesn’t work with FPI enabled:
https://www.ctrl.blog/entry/firefox-fpi.html
Web devs do not care to fix bugs for Firefox (3% market share) even now (i.e., without isolation), when Firefox does add more stuff like this, they will be even less willing to, driving further users away because the websites they browse don’t work as expected / with higher failure rates.
Tor will be moving to Chromium some day because more and more websites won’t work with Gecko in the not so distant future. Ignore this problem-causing stuff – in time, Chromium will also isolate more things than the cache, which it does partition now. Wait and see.
> What is the difference between network partitioning and privacy.firstparty.isolate?
I’m simplifying here
– FPI was built for Tor Browser (FF52+): and covers not just what we’ll call “networking” but other areas such as “persistent storage”. It was an all-in-one solution: and they added everything to it they could
– This new pref is basically the “networking” side of FPI, rebuilt, re-imagined and refactored from the ground up to handle future and other changes such as adding scheme to the partyness, docgroup etc
– What network partition covers is listed here: https://groups.google.com/g/mozilla.dev.platform/c/uDYrtq1Ne3A . There may be some things it does that FPI doesn’t
– If you use FPI, then network partitioning is ignored and you use the FPI code: i.e FPI overrides
– dFPI (d for dynamic) is a cookie setting (and been enabled in nightly for three or four releases) and is basically the “persistent storage” side of FPI: again, rebuilt, re-imagined etc to handle scheme and so on: it will allow more flexibility with exceptions and more: not just user choices, but dynamic ones (which you could enable/disable) such as if you interact with a facebook widget then it would relax facebook in this session on that domain in order to allow a cross domain login cookie-flow structure. This could apply to more than just login flows: look at https://bugzilla.mozilla.org/show_bug.cgi?id=1683165
So basically: one day you will have “partitioning” and dFPI – by default and basically be just like Tor Browser’s isolation, but with tweakability (e.g. you could flip off the dynamic part, or parts of it). And I imagine that Tor Browser will also move to it (and set some hardened prefs to suit them) and FPI code eventually stripped out: that’s how I see it, I do not see engineers trying to maintain two versions of basically the same thing
Pants, I will like to ask you something about containers in Firefox, your message just reminded me about it. Maybe you will know more about it and explain me whats going on. I think I have found some logic issue in containers handling.
I have google container, with google domain assigned to it, to open automatically. Also I have pref set to open all other domains outside this container (handy on gmail).
When I am on YT (not assigned to container), and I accidentally click on “sign in” (or when I forget about containers and want to sing in to another YT-related account), Firefox will redirect YT-no container to account.google.com google container, and back to YT-no container.
I’m pretty sure this should just fail, and I’m pretty sure this was failing before, but for some reason I’m now logged-in into my google account on YT. This is completely unexpected to me. Any page can just redirect me through other container to snoop for my data? WTH?!
Thanks for the detailed reply!
@Iron Heart
I have enabled privacy.firstparty.isolate for a long time and don’t see a lot of important things breaking.
I agree. If you stick to 1st-party logins most stuff works. However, I see a lot more and more aggressive Captchas. That is indeed annoying (at times I had to go through 5-10 tests until the captcha god was happy).
@some1
Your workflow ≠everybody’s workflow.
OK, to be fair, there are common workflows but one of them would also be using cross-site login forms. It happens all the time because people are literally too lazy to create an account for each website and resort to using “Login with Facebook / Google / Apple” when it’s offered. Those are called cross-site login forms. They are buggy with first party isolation, which is also why this feature will never be mainstream. Now I hear you say: “Why can’t web devs fix this / adapt to this for Firefox?” to which I reply “3% market share, nobody cares.”
TL;DR: It breaks a workflow that is fairly common out there. Good if it works for you.
“Login with Facebook / Google / etc…” is the opposite of privacy.firstparty.isolate. You can’t have your cake and eat it too!
@some1
I am just trying to explain that there are things that break on a technical level when you enable FPI. That it is not exactly advantageous for privacy when you use Google or Facebook as login methods should be self-evident… But normies out there actually do that, which is why FPI will never, ever be mainstream. If any website breaks in Firefox because this is enabled, I’d also consider a fix unlikely because so few people use FPI, it’s not worth it.
There are people here on gHacks who seriously give recommendations, which – if followed – will break fairly mainstream use cases. Just saying.
@Iron Heart
Some websites and services even force you to sign up and log in with a Google/FB authentication method, without giving you the option to sign up separately using email/pw…
What does it matter when they sell their users’ data to Google anyways?
Lol what?
@Allwynd
Occasionally, anyway:
https://www.zdnet.com/article/firefox-tests-cliqz-engine-which-slurps-user-browsing-data/
How to know if cache partitioning is on and working in Chrome 87? Is it rolled out to everyone now and always on?
@Jeff
It’s in the FAQ section here:
https://developers.google.com/web/updates/2020/10/http-cache-partitioning
You need a command line flag in order to make 100% sure that it’s enabled, but it should be enabled by default now.
Thank you
MAybe decentraleyes can help with that, as the goal of this browser add-on is to provide those common libraries (jquery, google fonts, etc.) locally (to prevent tracking).
If decentraleyes is able to look beyond the partitions, this should be possible, I guess.
Link: https://decentraleyes.org/
(regarding the
“Performance may be impacted as it is no longer possible to share resources, e.g. the same font.”
)
@Maarten
LocalCDN (fork of Decentraleyes) is objectively better than Decentraleyes as it supports way more libraries, and because its development is way more active… Just compare the recent releases:
https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/versions/
https://addons.mozilla.org/en-US/firefox/addon/localcdn-fork-of-decentraleyes/versions/
Just saying.
Thanks, @Iron Heart, that will help people
(I use neither of those; it was more about the concept of addons like Decentraleyes and Local CDN to prevent performance loss)
It’s not verified by mozilla, while Decentraleyes is.
@user
It’s open source, though: https://codeberg.org/nobody/LocalCDN
You can look for any malicious code there.
Mozilla doesn’t “verify” (= manually review) small extensions unless they specifically pay for it, unfortunately. So that situation won’t change quickly. :(