Consider separating opaque-origin iframes from subresource loading #623
Comments
|
In a discussion with @jeffkaufman, @yoavweiss, @WebReflection and others, it was pointed out that this
If people are interested in moving this idea forward, I guess it's a bit outside the scope of this repository, and it might make sense to develop further in an HTML PR or even a separate WICG effort preceding that. |
You could get just an opaque subframe with <iframe sandbox="allow-top-navigation allow-forms allow-scripts allow-popups allow-pointer-lock allow-modals
allow-popups-to-escape-sandbox allow-orientation-lock allow-presentation
allow-top-navigation-by-user-activation allow-storage-access-by-user-activation">But of course you'd have to update that if a new sandbox feature is added. I've proposed a couple of different measures for controlling sandbox flags individually, so that just the opaque origin bit could be controlled independently, but none of them have been satisfying. Something of the flavour <iframe policy="same-origin=?0">would use Document Policy to that effect, for instance. I think that the biggest semantic difference between that and the WebPackage proposal, though, and the biggest question I would have about your proposal, is what happens in further nested frames: The sandbox mechanism ensures that any nested frames have their own unique opaque origins, regardless of the original URLs of their contents, and even get new origins on navigation. In contrast, WebPackage UUIDs would allow an opaque-origined frame to have same-origin children, allowing composite documents to be embedded in an opaque frame and stilll work as originally intended. I suspect (though I haven't checked) that they would also be able to further nest or navigate to URLs which don't have an opaque origin, which sandboxing doesn't allow. By making the opaque-ness part of the URL, rather than the containing |
This is also how |
|
A common scenario for ads on the web today is that a page A creates an iframe B which creates an iframe C, where the desired origins are: A - B: xorigin Today this is handled with having B be a safeframe. UUIDs allow this model (B is |
…tension part (WICG#623 WICG#641) This is the almost mechanical *refactoring*, splitting the subresource-loading explainer into the core part and the extension part. The related issues are WICG#624 and WICG#641. In a follow-up PR, we might want to refine the core part so that we can write extension parts more easily, such as having well-defined terminologies and hook points.
#645) * Split the subresource-loading explainer into the core part and the extension part (#623 #641) This is the almost mechanical *refactoring*, splitting the subresource-loading explainer into the core part and the extension part. The related issues are #624 and #641. In a follow-up PR, we might want to refine the core part so that we can write extension parts more easily, such as having well-defined terminologies and hook points.
In https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md#link-based-api , there is an idea of
urn:uuid:URLs which can be present in the bundle, which will be treated as a new opaque origin.I really like the idea of adding a new web platform feature that makes it easier to create an opaque-origin iframe. This seems genuinely useful for increasing isolation (potentially helping privacy), where there are often multiple units of code that need to be treated with different trust levels. Existing solutions do have problems:
<iframe sandbox>can be used declaratively, without this overhead of indirection of storing to and loading from blobs, but its semantics are quite different. Sometimes you don't want these additional restrictions, and you just want an opaque-origin iframe.At the same time, I'm skeptical of the API surface here being linked to URLs inside bundles, for a couple reasons:
I want to suggest that, rather than defining UUID URLs to make opaque-origin iframes, a separate attribute is used in the iframe tag, to make the origin opaque, regardless of what the
srcis. For example, we could call it<iframe opaque>. This example could instead be written as:The text was updated successfully, but these errors were encountered: