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.