Getting some semblance of control over my browsing habits and enabling the implementation of multiple-proxy-based browsing strategies is one reason why I wrote chrome-private.sh [1].
I go through hundreds of disposable browsing profiles every day.
Firefox containers does the same thing with a lot less work. If you get the multi-account-containers extension and the temporary containers extension, you won't have to log back into everything all the time but will still get isolation.
Make sure to disable container sync when using this combination. It's easy to accumulate hundreds of temporary containers which somehow hoses your Firefox profile on Mozilla's sync server (and can also produce gigabytes of logs in your local profile directory).
It seems it's currently impossible to recover your profile once you reach "Maximum bytes per object exceeded" - the remote end won't even let you delete the offending data.
Not only that, you can effortlessly launch Firefox with temporary profiles to emulate what the script in the OP is doing. I think that Firefox's strict privacy setting + containers are all that are needed, though.
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.
There is no hope of privacy on the internet today without some sort of "tumbling" strategy. It is wholely impossible for anyone to prevent all sources of their information from leaking, and once your data from one source is out there, the rest of your precautions are potentially useless. So the only viable strategy is to muddy the waters by creating enough spurious data that an attacker can't know what is real and what is fake.
Different concerns. Ungoogled Chromium removes Google-specific features from Chrome. That is unrelated to non-Google-specific browsing features such as providing cookies back to hosts on repeat requests in the same profile.
I'm doing something similar but less ephemeral. I have many web profiles, but they are dedicated, for example I have a Google profile where I open Gmail, drive, photos, etc. I have an FB one, a reddit one, an HN one, etc. About 15. Then Firefox for my regular browsing.
That's pretty cool ... I'm left wondering what a visualization of the state accumulated by visiting different websites would look like, e.g. google, twitter, nytimes, etc.
It's also used for fingerprinting, because there are a lot of different GPU configurations with slightly different reported features and slightly different e.g. rounding, dithering, antialiasing, and other rendering behaviors.
Mostly for security, rather than fingerprinting, concerns.
Fingerprinting avoidance is a complex issue and it's reached the point where you can't simply disable JavaScript / WebGL and assume you're ok. One needs to run additional extensions to project a browser-view that blends in. You can use chrome-private.sh as a base layer you can build on to get there, but you are not going to get it by default (which is why I'm not making any anti-fingerprinting claims in the README).
I go through hundreds of disposable browsing profiles every day.
[1] https://github.com/atomontage/chrome-private