(In reply to creesch.r from comment #14)
This comment exactly proves my point. You didn't know what I referred to at first, so if
incognito:"split" were to be supported, you would rely on it and mistakenly believe that your extension is privacy-friendly
No.... I rather have it that split is implemented for those case where tabs are truly containers (as is the case with tab containers and incognito mode) so I don't have to bother with an entire separate API as at least for those tabs I know all data is contained within that tab and the corresponding background page.
As said, it doesn't scale well. With incognito/private browsing mode, there would be at most two instances of the same extension. With more kinds of isolation, there may be many more.
extensions will need to move requests to the background page like recommended by the chrome devs, when doing that the option I have as extension developer for the things we discussed is to either go with the default which means that in the background page content from different containers is freely mixed (resulting in very odd behavior) or I specifically don't allow my extension to load in a private tab to somewhat protect my users and prevent confusion as they are seeing data from sessions in their non private tabs.
The described options are not the only ones. The issue that you've shown in comment 10 is very valid, but the proposed remediation is suboptimal.
incognito:"split" offers good isolation of DOM APIs such as
localStorage, but does little against information leakage through extension APIs (e.g. storage / messaging) (this is what was being referred to in comment 5 of bug 1380812). So while there is some isolation, it is not complete and also has other drawbacks (memory usage, latency due to extension startup).
Regardless of an extension's support, users already have the ability to toggle extensions in private browsing mode (both in Firefox and Chrome). We are also exploring ways to offer even more granular user control, follow bug 1365019 and bug 1497075 if you're interested.
First party isolation is an entirely different principle and doesn't really seem relevant to my concerns.
For this discussion, (dynamic) first-party isolation (FPI) is equally relevant. With (d)FPI, requests from two different tabs can be isolated. Extensions that ignore this characteristic can potentially weaken the privacy of users, for example by (inadvertently) mixing network requests on behalf of those tabs. The idea of
split could bluntly be applied here, but then every unique top-level site will have their own extension instance.
I still rather have a solution that also works with split as that makes cross browser extension development a lot easier. But if a separate API is need I'd work with that as well. As long as there is a solution for this as currently there is none and so far it didn't seem anyone was interested in creating or even discussing a proper solution anyway.
I'm not outright rejecting compatibility with split mode-code, but if the isolation/privacy problem is not addressed by chosing that path, then there would not be much point in implementing it. This problem should be resolved before turning cross-origin requests are turned off. I guess that the latter won't happen this year, so we are not in a rush to make hasty decisions. I do expect to file a new bug to track the identified issue, after discussing this with the rest of my team.