Well, there are definite benefits to being in full control of profile segmentation.
You have no idea what the extension is doing unless you audit it. And even then, there are second-order effects that could surprise you [1]. Plus, the extension writer has to maximally cover the set of possibilities where a site can store/retrieve data. These are a lot of unknowns you're trusting and assumptions you're making.
It's far simpler to treat the profile directory as contaminated waste and nuke it at will.
The only assumption you're making is that the browser implements a profile in a given directory properly.
Sure, there's probably less exposure from nuking the profiles directory, but I don't think you're being fair to containers:
- Containers are a feature built into Firefox, these extensions just expose a UI for it. The Multi-Account Containers plugin [1] is published by Mozilla. You don't need to trust anyone but Mozilla to use that base set of functionality.
- The container functionality in Firefox is the result of some work from the Tor Browser being upstreamed into Firefox [2]. It seems reasonable to assume that it's well-implemented.
- The limitations of the extension that you linked to don't seem any worse than your profile-segmentation approach. It's just saying that it's possible for multiple websites to get opened in the same container, which is similar to how you could end up opening multiple websites in the same profile.
I reworded my comment. My point remains in that a lot of possible issues disappear if I just choose to destroy the entire directory. There is a clear difference between one Chrome instance (and all its associated windows/tabs) segmented into one profile directory and in-process segmentation. The issues at [1] seem to invoke unexpected behavior in that you're asking for a new temporary container but you can't know ahead of time if that's what you will get. I'm writing "seem" because it's not clear from the description how that interaction works. They could be better worded.
With segmentation enforced at instance boundary (rather than in-instance), there is no unexpected behavior of this sort. All links open in the segmented instance that the browser window/tab you're using belongs to. If you want a new container, you start a new instance and you know that's exactly what you will get. There is no possible "fail open" result. Note that I'm not saying the Firefox behavior you described is a major issue, just that it proves you can have unexpected scenarios.
Moreover, jedberg is correct in that cross-profile data leaking is possible (partly what I meant by "implementing profiles" properly), except that it's very easy to see if that's happening without auditing Chrome. Use a tool that records all filesystem operations (e.g. dtrace on macOS).
At the end of the day, I choose one set of trade-offs over another.
Of course, all security is a trade off between convenience and privacy. But the hassle of a new profile all the time seems like a lot of extra inconvenience for little extra privacy.
So far in practice I've never seen the isolation fail. The combination of the two plugins seems to counteract each one's failures.
And Mozilla makes the multi-account-container plugin. I trust them a lot more than I trust Google to make Chrome not leak information across profiles.
I can say that I would prefer to use Firefox instead of Chrome, except that Firefox has no OSA scripting endpoints on macOS (a real shame) and I've written a lot of code that depends on Chrome APIs over the years.
Even if I did move to Firefox however, I would still implement a directory-based profile segmentation strategy.
It's an OS-wide scripting framework, that a lot of (most) applications running on macOS support. The beauty of it is that it works on top of Apple Events and is layered. An application may inherit a standard set of exposed scripting endpoints and may also implement its own specific set of behaviors.
Even the standard inherited set of endpoints can be extremely powerful due to accessibility functions that are baked into the entire operating system.
Chrome offers both. Firefox offers nothing. Of course applications can additionally offer their own scripting APIs (Chrome has DevTools, I'm sure Firefox has something equivalent) but a major advantage of OSA is its stability and uniformity. It's a hidden treasure for power users and obsessive feedback loop minimizers. Alas, when it comes to regular users, the most Apple managed to do with it was Automator.app, a very constrained experience that did not really take advantage of the underlying power.
It's far simpler to treat the profile directory as contaminated waste and nuke it at will. The only assumption you're making is that the browser implements a profile in a given directory properly.
[1] https://github.com/stoically/temporary-containers/wiki/Isola...