How does this interact with iframes?

WICG / web-preferences-api

The Web Preference API aims to provide a way for sites to override the value for a given user preference (e.g. color-scheme preference) in a way that fully integrates with existing Web APIs.

https://wicg.github.io/web-preferences-api/

Other

41 stars 2 forks source link

How does this interact with iframes? #8

Open lukewarlow opened 10 months ago

lukewarlow commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

[ ] 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 commented 9 months ago

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 commented 9 months ago

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.