Site Isolation in Firefox
blog.mozilla.org
blog.mozilla.org
In particular, it seems that "site" isn't precisely defined. It seems to be based on domains, but backed by a human-curated list of "sites": <https://github.com/publicsuffix/list>.
So it's different than Chrome's "every webpage gets a separate process".
Do you actually want it to? Or are you just experimenting? FWIW There's a flag related to isolation in your chrome://flags that will do per-origin.
> There's a flag related to isolation in your chrome://flags that will do per-origin.
What flag is that?
I even tried setting --process-per-site-instance and it had no effect.
Does this also happen when you type the Twitch URL in a new tab?
That list is the reason why CORS behaves differently e.g. across two subdomains like [subdomain].herokuapp.com (requests are considered cross origin) in comparison with two subdomains of the type [subdomain].[myowndomain.ext] (requests are considered same origin)[1] - the reason for this difference is that herokuapps.com is part of that list.
[1] unless you added your own domain to the public suffix list.
It's a nasty hack, the successor to even worse proprietary hacks but still something we ought to strive to get rid of.
I can see exactly why it was the choice here, and I don't blame Mozilla for choosing it, but we're not going to make things better if nobody gets out and pushes.
That said, since we're stuck with the PSL for the foreseeable, I sure would like it if Mozilla shipped a way for extensions to just consult Firefox's built-in copy of the PSL, rather than needing to either build yet another awful hack or ship the entire PSL again in an extension.
> I sure would like it if Mozilla shipped a way for extensions to just consult Firefox's built-in copy of the PSL
the PSL is available at https://publicsuffix.org/list/public_suffix_list.dat - as noted elsewhere in this tread it is also used by other browsers. I guess the one built into Firefox is just downloaded from there and cached? If so why would you want that over the other?
> I guess the one built into Firefox is just downloaded from there and cached? If so why would you want that over the other?
If your extension is 10kB of Javascript and you typically update it once or twice a year to tweak things, it's crazy that now the total extension size is over twenty times bigger and you need updates every month or so at least because otherwise things might not work for some users.
If your extension wraps, say, the New York transit map, or Wikipedia's list of English monarchs then fine, there's no reason Firefox would know those, you need to ship or fetch the data. But the PSL is necessarily built-in to Firefox, they do have the data, you just can't access their copy.
[1] https://hacks.mozilla.org/2021/05/introducing-firefox-new-si...
This is a common misconception. Chrome doesn't technically do process-per-tab.
Chrome's model can most succinctly be described as process-per-domain, although even then, there are rare instances where two tabs opened on different domains will actually share the same process.
They did advertise Chrome as process-per-tab: https://www.google.com/googlebooks/chrome/big_04.html, pages 6 and 7 also definitely agree. (I haven’t read all through it again now, but I should also note that the process in the very centre of https://www.google.com/googlebooks/chrome/big_38.html shows what appears to be two tabs under it, which supports it not necessarily being process-per-tab.)
But either it never actually was, or they abandoned it as impractical even before release (https://stackoverflow.com/q/42804 has answers agreeing it isn’t process-per-tab on the day after the first release). So either Google lied, or they released the comic including a glaring and rather significant factual error (even if it had been true when Scott first drew the pages).
It’s frustrating when parties pull these shenanigans, making big claims around things like security and performance predicated on points that are simply not true, but never retracting those points properly or repudiating them, so that the misconception persists.
It's ridiculous to think that a budget laptop with 4 GB of RAM suddenly isn't enough to browse the Web comfortably. All thanks to Meltdown and Spectre.
Let's buy all the toilet paper, it will slow others from buying toilet paper.
I like the idea of containers, and will probably revisit periodically to see if whatever was fubar on my account is resolved (theres none/if any logging, so its hard to really dig in)
I'm using Temporary Containers, but if I visit `somedomain.com`, close it, and come back later, I get a new temporary container.
I do use a lot of tabs, so I fear I'm going to find myself facing the same problem I faced with Chrome: a site misbehaves and locks things up, crap, which process do I kill? A way of tracking which tab maps to which process would be nice, so the next time I trip over a badly-coded page, I don't have to kill everything just to get my browser to respond again. Lazyweb question to y'all: is there a feature in Chrome or Firefox that can do this (mapping tab/page -> process), or have I just stumbled upon a side-project idea?
Scrolling down I found a section starting with
> web (pid 1036080)
> Explicit Allocations
> 108.27 MB (100.0%) -- explicit
> ├───45.04 MB (41.60%) -- window-objects/top(https://www.that-random.site/, id=175)
I try to kill that process now, but I post this message first in case I kill the whole browser.
Result: the tab crashed, the browser survived.
> Gah. Your tab just crashed.
> We can help!
> Choose Restore This Tab to reload the page.
Restore did work.
I also like to occasionally sort by memory usage and kill the biggest Chrome processes. Chrome is nice in that it will show you when a process crashed, so what I do is kill the biggest memory hog, and then see what tab crashed. Then I do it again a few times.
This at least tells me which processes use the most RAM over time and should be recycled (Spoiler alert, it's always GMail and then GCal.)
I suspected gmail was the heaviest thing I regularly had open, but it's good to see the stats.
It lists tabs by process, and includes the PID (on Linux; no idea about other platforms). You can also directly kill tabs and processes from there.
For example, about:compat lists sites they added hard coded work arounds for.
https://addons.mozilla.org/en-US/firefox/addon/onetab/
to offload idle tabs. Downside is that it doesnt sync with firefox so anyhing i may need I may need to open in another firefox instance, I just bookmark.
The grouping is nice because it gives me a reference of a time i was doing x research/reading. And what i find is that there really isnt too much that i need to crossover, work stuff stays on my work computer, personal to personal etc.
If Firefox is still somehow responsive, open about:performance and identify the CPU-hungry tab(s), then close them.
Why/how can this happen? That sounds like a bad failure of the browser.
They really allow you to scroll through the post quickly and see if it is interesting to read in detail.
[0] https://hacks.mozilla.org/2019/08/webassembly-interface-type...
Thanks for the browser work as well!
I'm not sure what gave me the impression but, in my mind "process-per-tab" and "Electrolysis" were linked, but that was a misconception:
>In great detail, (as of April 2021) Firefox’s parent process launches a fixed number of processes: eight web content processes, up to two additional semi-privileged web content processes, and four utility processes for web extensions, GPU operations, networking, and media decoding.
>While separating content into currently eight web content processes already provides a solid foundation, it does not meet the security standards of Mozilla because it allows two completely different sites to end up in the same operating system process and, therefore, share process memory. To counter this, we are targeting a Site Isolation architecture that loads every single site into its own process.
Your impression was mostly correct. Electrolysis is basically process-per-tab until you reach eight tabs, but after that, tabs start sharing those eight content processes.
This always was a long term goal I think. It's per site not per tab though.
Was this goal reached in the end, or perhaps even surpassed, or missed after all?
I guess this also makes adblockers even more valuable in terms of saving memory, since each blocked third party-iframe that doesn't load is potentially one additional process that doesn't have to be created…
It really depends on what web sites you have open. If you have a single tab with an ad-laden news site, the overhead will be high, but if you have a bunch of Google Docs tabs open, there's no overhead.
On the other hand I guess you're right about "people usually don't have that many unique sites open", so the original design value of 100 separate origins was probably purposely chosen to be on the large side, and thinking about it, I guess not having that many unique sites open usually fits my usage patterns, too. The unknown factor I can't really judge is how many iframes with potentially separate origins the pages I normally visit use, though.
Looking at it positively, one additional potential benefit could be that I have a few long-lived tabs that I always keep open – under the current model, this means that the content processes associated with those tabs never die and possibly slowly accumulate cruft and memory fragmentation from additional tabs that happen to be loaded in them (and later closed again).
Under the new model on the other hand, closing all tabs associated with a domain should be enough to get the associated content process to exit and free up really all memory used by those now closed tabs.
Can you explain this in more detail?
Putting sites in their own process mitigates against Spectre–like attacks, but it doesn’t do anything for higher–level problems like third–party cookies.
I'd love to drop https://addons.mozilla.org/en-US/firefox/addon/temporary-con..., which automatically assigns a temporary container to any new tab, which plays nicely with the https://addons.mozilla.org/en-US/firefox/addon/multi-account... but uses too much memory (at least from my experience).
Using temporary containers, multi-account containers, site isolation, along with a number of other privacy/security addons such as Umatrix, LocalCDN, and many others, I have not noticed any slowdown.
This on an older broadwell i7 with 32GB of ram.
AdNauseam
Archive Page
ClearURLs
Cookie AutoDelete
Cookie Remover
Decentraleyes
DoH Roll-Out
Don't track me Google
DuckDuckGo
Facebook Container
Firefox Multi-Account Containers
Firefox Private Network
Firefox Relay
Firefox Screenshots
First Party Isolation
Google Container
Google search link fix
Greasemonkey
HistoryBlock
HTTPS Everywhere
I don't care about cookies
Laboratory
Link Cleaner
LocalCDN
PinPatrol
Privacy Badger
Privacy Pass
Redirect AMP to HTML
Skip Redirect
Tampermonkey
Temporary Containers
Trocker
Twitter Container
uBlock Origin
Ugly Email
uMatrix
Wappalyzer
Zoom Redirector
So they do different things, and interaction between the features appears to work without issues.
One of the primary reasons I use Firefox is that it uses significantly less memory than Chrome, and the entire OS seems to function better as a result (I've seen the most stark difference on macOS). I had been under the impression that most of the reason Chrome uses so much memory is its multiprocess model.
I understand that maybe we need to give that up for better security, but it would be nice to know if that's indeed the tradeoff being made here.
Do you need more data? If so, what's the best way for me to add to it? Would that be installing Nightly, setting fission.autostart to true, and enabling some telemetry?
Looking at the navbar, the horizontal and vertical alignment is all over the place, the search input has no placeholder or label, background colors are inconsistent, and paddings are just bizarre.
Not to mention the fact the extension ecosystem is still crippled. There's still no user-agent switcher, meaning there are sites I literally cannot access from my phone without installing an old version of Firefox Mobile or go back to using Dolphin Browser. "View Desktop Version" perversely still tells sites you're on a mobile browser.
It would be sad if one day Chromium removed Manifest v2 and there was no alternative.
https://www.chromium.org/Home/chromium-security/site-isolati...
http://www.scottmccloud.com/googlechrome/
In early-mid 2008, I created a comic book for Google explaining the inner workings of their new open source browser Google Chrome.
If I'm mixing this up with https://wiki.mozilla.org/Electrolysis, that's still 10 years.
https://chromium.googlesource.com/chromium/src/+/c6f2e67ab40...
Site isolation proved to be the biggest refactor in Chrome's history, and was one of the motivating reasons for the webkit/blink fork. Making site isolation work touched a huge host of features, since handling iframes out of process has a way of making simple things incredibly complicated.
The example I always gave was: imagine how the "find text in page" browser feature would be implemented. With the entire document in-process, it was a simple for loop. With the document and its subframes sharded across multiple processes, it is now a distributed search problem that requires handling of out-of-order results and stitching them into a traversal order. What's more, to achieve Chrome's security goals, you want to avoid introducing functionality that would allow the [presumed-compromised] process of the outer document to query the contents of the inner document via the find in page feature. So you can't simply do this as a peer-to-peer query between the renderer processes; it needs to be coordinated by the main browser process.
Congrats to the Firefox team on this milestone.
And not so related to this, but from what I've heard about cracking competitions a few while ago, Firefox was not even included, it was considered too easy. Maybe my sources were just bad.
And I say this as a Firefox user for the last decade or more.
But yes Electrolysis is the initiative that you should have referred to in the original comment.
How is this bashing? :-)
It literally starts with "Software is hard."
...
As engineers, we should not accept this status quo; we should replace it. We need a new web and new software.
Seems pretty cool tbh
So people imagine splitting off a simpler web, where the main focus is on reading documents, rather than interactive applications, and browsers could be much simpler. But it's pretty hard to see how this could actually work in practice.
So probably the most you can hope for is that we split the document part of the web from the application part, so that it's easier to make a viable document browser. But it's not clear what advantage this offers for anyone who's not trying to make their own browser. Security is probably much simpler for the document browser, but the logins and sensitive data you care about securing are probably in the application browser anyway. And we've spent the last 20 years blurring the lines between documents and applications (think of a Github issue page, for instance), so even if it was possible to access information as a pure document, there would be advantages to looking at it in an application browser.
> it's not an alternative to the web
Right. You can't have a lightweight drop-in alternative to the web, pretty much by definition. Any platform capable of everything modern browsers are capable of, is by definition enormously complex.
> it is a very very small subset
That's not a flaw, it's a design goal. It isn't meant to be a half-baked portable GUI toolkit the way the modern web platform is, it's meant to be a simple and minimal format, stable and easy to implement. There are other formats somewhat like this in common usage, like man pages and, of course markdown.
https://dustri.org/b/the-web-browser-im-dreaming-of.html
Gemini might be a good replacement for the web: