How does this interact with iframes?

[lukewarlow]

Need to work out the exact specifics with regards to iframes both same-origin and cross-origin.

Same-origin iframes should probably be updated with the parent frame's preference overrides but in an opaque manner.

e.g. if the parent frame sets colorScheme to dark then the iframe should see prefers-color-scheme as dark but shouldn't read navigator.preferences.colorScheme as dark.

Whereas, cross-origin iframes should probably not be updated with the parent frame's preference overrides. This is an unfortunate limitation but is probably necessary to prevent new forms of data exfiltration.

[lukewarlow]

Be interesting to hear thoughts on this. The more circumstances we can pass down this information the better but I understand it may just be an inherent limitation with this ability.

[tabatkins]

Instances that cannot communicate with the outside world, like an SVG loaded as an image (which can't run script or invoke external resources) should also be safe to pass the preferences into even when they're cross-origin.

For cross-origin things, we can probably piggyback on another notion of communication. Like, if you can postMessage() you already have an open communication channel, so there's no reason to restrict things. We just don't want to open a new communication channel.

[lukewarlow]

• Does an iframe have some kind of persisted state it can use if the document in the parent frame doesn't override? What about the interactions with Storage partitioning?
• What about the interactions with the planned portals? They are some kind of document in an iframe, but it could become top-level document too.
• What about the interactions with the planned FencedFrame. I know they have some "mode" where they guarantee there are no mean of communications in between the two documents across the boundary.
• There are also iframe credentialless to think about. I don't really have concerns about them.

[ArthurSonzogni]

IMO: Portals and FencedFrame should be considered independant top-level context
shouldn't inherit anything. This is especially important for FencedFrame.

For cross-origin things, we can probably piggyback on another notion of communication. Like, if you can postMessage() you already have an open communication channel, so there's no reason to restrict things. We just don't want to open a new communication channel.

On one side, postMessage is an opt-in. Both side must use the feature, and they can specify/verify the origin they are talking to.
On the other side, with WebPreference the communication happens passively.

They are quite different. Inheriting WebPreference cross-origin would be considered as a new kind of cross-site leak.

[lukewarlow]

Idk that I agree cross origin iframes would be a leak. It's the user's data not the sites, and from that perspective the site can already send it cross origin. So why would this API be any different?

I agree that fencedframes should be completely separate. I think the portals discussion is rather academic given their development seems to have stalled, having said that I'm not overly familiar with them so unsure whether it should behave like a cross origin iframe or a fenced frame.

[josephrocca]

I have two use cases, in case it helps with thinking about this issue:

1. I have a JSBin/CodePen/Scratch-like platform, where the dev's code runs within a sandboxed cross-origin iframe. I'm trying to encourage devs to make their applications support dark mode. I'd like to have a dark mode toggle within the top-level document so the dev can very easily test their application's dark and light mode as they modify their CSS (i.e. instant switch/toggle which controls the cross-origin child, rather than e.g. full reload required, or having to change their OS-level settings).
2. However, for the dev to be able to add an easy dark mode toggle for users of their site/application, they'd have their own toggle in their application. But a key point here is that the application runs inside a sandboxed cross-origin iframe even when users are viewing it. This is needed for security of top-level user accounts. So, independent of the parent iframe, the sandboxed, cross-origin, child iframe should be able to use the Web Preferences API (i.e. it ideally should not have to "ask" the parent to change it, though it wouldn't be a dealbreaker for me if it did need to ask the parent, since I could implement a "hack" on top of the API in the child frame, which uses postMessage to the parent behind the scenes).

I'm not sure if these examples do touch upon any important questions here, but I figured I'd add them just in case. Thanks for your work on this proposal!

Edit: Ah, related issue for point 2 above:

• Can an iframe provide its own override #20