Hacker News Reader

Comment by metroholografix | Hacker News Reader

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.

[1] https://github.com/atomontage/chrome-private

View on HN

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.

https://addons.mozilla.org/en-US/firefox/addon/temporary-con...

https://addons.mozilla.org/en-US/firefox/addon/multi-account...

Edit: See below with a warning about using this with profile sync.

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.

[1] https://github.com/stoically/temporary-containers/wiki/Isola...

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.

What is OSA? Google fails me.

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.

https://developer.apple.com/library/archive/documentation/La...

Fascinating, thanks! I can see why you'd be reluctant to switch to Firefox if you depend on this.

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.

[1]: https://addons.mozilla.org/en-US/firefox/addon/multi-account... [2]: https://blog.torproject.org/tor-heart-firefox

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.

[1] https://github.com/stoically/temporary-containers/wiki/Isola...

You are being disingenuous.

The issue you are quoting is about opening new containers while following links. That's something your solution doesn't support at all.

Your solution is akin to manually opening a new container. That will always work in Firefox.

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.

[1] https://github.com/stoically/temporary-containers/issues/371

[2] https://github.com/mozilla/multi-account-containers/issues/1...

Good tip! I don't use sync so I didn't know about this one.

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.

Containers don’t stop finger printing though.

I.e if you use the same container to read news, google knows your news preferences.

But neither would changing Chrome profiles.

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.

Why not use ungoogled-chromium?

https://github.com/Eloston/ungoogled-chromium

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.

Interesting. Why disable gpu?

> Disables 3D APIs / WebGL, GPU acceleration by default while allowing them to be re-enabled through command-line switches.

Not OP,

WebGL is a fast path to direct hardware execution and kernel space execution.

It’s difficult to patch when things go wrong often requiring driver or kernel coordination.

There might be issues with cross site memory leaking, but I’ve only seen white papers on how this might be an issue.

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.

WebGL: getParameter: enum 0x9246 - fingerprinting 3d hardware. Personally I run a shim that rotates a list of most popular gpus.

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).

Unfortunately chrome itself makes far too many calls home.

So you're the one messing up my sessions analysis :p

Reply on news.ycombinator.com