Earlier quoted context omitted.
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 fa…
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 so…
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...