Embedded Extension iframes in incognito tabs with site per process |
|||||||||||||||
Issue descriptionWhat steps will reproduce the problem? 1. Load the attached extensions. They inject a script that adds a web iframe on the active page. 2. Enable the extensions in incognito mode. 3. Load up example.com in regular, incognito 4. Inject the extensions (probably only one), but both would work too 5. Check out task manager's processes 6. Wonder to yourself what the right answer is What is the expected result? Be able to come up with a right answer What happens instead of that? Continue to scratch your head So, here's the thing: with site per process/isolate extensions, we try to shove extension iframes in web pages into the extension process. This works easily with on-the-record windows. However, with incognito windows, it gets trickier. If the extension runs in spanning mode (which is the default and most common), the extension has one process shared between incognito and regular profiles - this means that the extension process is on the record. Because of this, an extension iframe can't share the extension process for a spanning-mode extension in an incognito window (it sounds like a crazy edge case - it's not entirely crazy). In a regular profile, your processes would look like: * Example.com * Extension Subframe Extension With an incognito profile, your processes are: * Incognito Example.com * Incognito Extension Subframe * Extension With a split mode extension, this works fine, because the extension has its own incognito process. The implications of this are that we won't necessarily get rid of unblessed extension contexts - because a spanning-mode extension subframe in an incognito window still meets that criteria... perhaps. Attached are split/spanning extensions and screenshots of the task manager with them.
,
Feb 16 2017
I'm guessing step 1 of the repro steps meant to say "adds an extension iframe" rather than "adds a web iframe"? Can you explain how the incognito extension subframe meets the unblessed criteria? I don't see the problem with treating it as a blessed extension page, since it lives in its own incognito process. Is it just a question of whether it can script the background page? I suppose the alternative is to put the incognito extension subframe in the normal extension's process, since it's already part of that extension and could log every thing the user does in incognito whether it's in that process or not. Does this pose a greater risk to incognito behavior than we already have today? Then again, maybe that's infeasible because we can't really support a subframe being in a different Profile than its parent frame. Personally, I'd be happy with having an incognito extension subframe process (similar to existing behavior but with extension bindings), with the caveat that it won't be sharing a process with the background page and thus can't script it. It's not like such frames are able to script the background page of a spanning mode extension today anyway.
,
Feb 17 2017
Right now, it meets the unblessed criteria because "unblessed" just means "not running in the same process as the extension". It wouldn't be unreasonable to make this blessed, but it does pose some interesting questions about interaction with the background page (or lack thereof). I still think it's reasonable, but it's something we'd need to decide, test, and document. I think that having a web frame in a separate profile than its parent is very...weird. And breaks some of the promises of incognito. So if we can, I'd say we should definitely avoid that. I also didn't test, but should have, whether or not multiple frames in incognito pages get embedded into the same process, or if they're each separate.
,
Mar 17 2017
What do you all think here, from a site isolation and security perspective? Is it WAI to have two extension processes, even for a 'spanning' mode extension? Should we consider the second unexpected process blessed?
,
May 26 2017
RE: whether or not multiple frames in incognito pages get embedded into the same process Yes - same process.
,
Apr 20 2018
,
Nov 9
I think we've all come to accept the current behavior as WAI. |
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by rdevlin....@chromium.org
, Feb 11 2017