Firefox identities/containers are a near gold standard in terms of the combination of ease of use and siloing of data. Brave has some great features and without a doubt there is some overlap in terms of things brave can do automatically and what you might use containers for. The features I see in containers beyond what Brave provides include:
- A strong wall separating sensitive authenticated session data from the rest of your browsing actions, greatly reducing the chance for some sort of CSRF or CSS/XSS exploit
- Phishing protection, if containers have only approved urls it can make it much harder to confuse sites even if password managers do their jobs
- Locked containers can force external links to open in a completely different session, quickly separating say email links from your authenticated email account, or search results from the pages they link to
- Low barrier to new containers vs profiles. Creating profiles manually means all extensions, preferences, etc are lost.
Brave does some amazing things for privacy, just how well ‘forget me when I close this site’ being on by default works is great. The task of supporting this in chrome itself already involved some advanced tagging for cookies and storage (as the docs cover).
This is a major lift for Brave but is something we can realistically expect chromium to never adopt. As Brave themselves have pointed out, Google has no problem using their 800lb gorilla in the room to reduce privacy options rather than extend them.
Firefox’s contextualIdentities while somewhat simple sounding is quite the daunting task to implement. The idea of cookieStoreId per tab is something of the core feature there (and by cookie store it really means cookie or local storage id assume). Being able to manually control a tabs context would likely allow even a 3rd party to develop an extension along the line of ff’s container extension.
I have implemented (and use) profiles/cache contexts for containers for quite some time. With recent chromium changes and backend chrome runtime making profiles heavier in resources this has become more disk and speed intensive. Even if throw away / in memory sessions are used for most sites and password managers for login with so many sites moving to 2FA it can still be cumbersome to authenticate every visit (especially for ‘remember my device’ sites). That isn’t to say multiple ‘ghost’ profiles as @kdenhartog isn’t potentially the solution. Automating preference and extension duplication across profiles may not be super complex although data synchronization might be more tricky. I assume the idea here would be to extract the key session data (cookies/local storage) out of the profile when the container is done thus requiring only however many profiles equal to the number of simultaneously running containers.
Still Brave’s work with ephemeral storage and partitioning may give glimpses into potential container / cookieStoreId possible options. Right now much of the 3rd party storage is already partitioned by top level domain in a very cleaver approach even within a shared context. This is certainly abstracting that out more to partitioning by an arbitrary ID instead and applying beyond 3rd party storage.
Of course many people here request two things a bit more basic:
- Tabs in one window from different profiles
- Multi-account authentication
As for 1) While chrome has a tight binding between the window and the profile, and there are many profile related things that are far more global than a tab, it likely could be emulated. A hypothetical here would be to maintain chromes idea of each session’s window with only the active tab’s true window shown, the other ‘tabs’ would simply be fake that when clicked would switch to that sessions window. Things like window resizing etc would need to be bound together although simple content hosting might also be able to solve showing one tab within another. It is by no means a clean or complete solution but might be easier than container support.
As for 2) this is likely more about trying to isolate the cookie/storage used for authentication to be able to extract it out and insert it back in. This is why these sorts of extensions are likely more vulnerable to failure as well, both the extraction and re-insertion of select data instead of complete state is lossy and would likely cause issues for some services behaving in ways not accounted for.