Re: [whatwg/fetch] Split 'document' destination into 'frame' and 'iframe'. (#948)

> Honoring `X-Frame-Options` (and friend) consistently for embed and object seems good. Could Chrome start doing that for plugins? I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1595491 to consider this on Mozilla's side.

(Lack of) specs to the side, it appears that there's already reasonable interop when creating a browsing context under `<embed>`: compare `data:text/html,<embed src="https://avatars3.githubusercontent.com/u/665379?s=88&v=4" type="image/jpeg">`, which loads @arturjanc's pixelated head as an image, to `data:text/html,<embed src="https://paypal.com/">`, which doesn't load `https://paypal.com/` because of its `frame-ancestors` assertions, and `data:text/html,<embed src="https://avatars3.githubusercontent.com/u/665379?s=88&v=4">`, which doesn't load @arturjanc's pixelated head because of XFO.

We can try do the same for plugin content. I wouldn't be surprised if we found breakage for PDF, but I'm happy to add metrics.

> If a site prevents cross-site loading of images but allows cross-site navigations, and sets X-Frame-Options to protect from embedding, an attacker will still be able to load images cross-site via `<embed>` and e.g. exflitrate them via Spectre.

It seems like the way we're recommending that folks deal with this would be to examine `Sec-Fetch-Dest`, and make a decision based on `img` vs `embed` vs `iframe`?  I mean, it is an additional check, and that does create some complexity, but it's not actually _complicated_. It seems to me that sites are either going to accept the risk associated with a given resource being loaded via `<embed>` or not, and that there's not actually a decision we expect anyone to make about the qualities of that load.

I'd also suggest that `Cross-Origin-Resource-Policy` (and the nascent COEP mechanism) should more or less resolve this concern by requiring explicit permission from a site to embed its bits and pieces iff those pieces would be embedded in a powerful-enough context. Does that mitigate some of your concerns? Or do you see it as tangential?

---

Bottom line, I think there's a reasonable philosophical argument for `no-cors/embed` followed by `navigate/embed` if we create a context and then navigate it. My mental model matches Artur's on this point. That said, I have a hard time getting worked up about it practically. I don't have the impression that sending `navigate/embed` for both actually changes the risk analysis that we'd ask developers to perform, and it seems straightforward to modify the policy recommendations put forth on sites like https://secmetadata.appspot.com/ to match.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/948#issuecomment-552469197