Consider separating opaque-origin iframes from subresource loading

[littledan]

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:

• Blobs can achieve the same semantics, but require that all of the HTML be downloaded, and then put in a blob, and then in an iframe. This blocks important browser optimizations like starting the render before the whole network fetch is done.
• <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:

• It seems like opaque-origin iframes are useful outside of bundles (and in omit-credentials contexts), even if there are some use cases where it is useful to load their HTML from a bundle.
• There are some annoying edge cases that would have to be defined one way or another, e.g., if multiple bundles define the same UUID.
• There is a kind of "semantics" that the URL has--e.g., you can see which origin it comes from--which is more visible if it's not mapped through a UUID.
• There's no way to map loading these opaque URLs to an "underlying" URL for potential verification, as suggested in Correct / real URLs should be enforced, to avoid breaking adblockers #551

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 src is. For example, we could call it <iframe opaque>. This example could instead be written as:

<link rel="webbundle"
  href="https://example.com/dir/subresources.wbn"
  resources="https://example.com/dir/a.js
             https://example.com/dir/b.js
             https://example.com/dir/c.png
             https://example.com/dir/page.html"
/>

<script type=”module” src=”https://example.com/dir/a.js”></script>
<img src=https://example.com/dir/c.png>
<iframe src="https://example.com/dir/page.html" opaque>

[littledan]

In a discussion with @jeffkaufman, @yoavweiss, @WebReflection and others, it was pointed out that this <iframe opaque> idea would need some additional protections to maintain the integrity of this opacity, that various parties don't make it ineffective:

• Once an opaque attribute is added, it cannot be removed.
• The HTML needs to be required to have a matching header indicating the opacity. If you have just the header, or just opaque, but not the other, then it is some kind of error.

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.

[clelland]

• <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.

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 <iframe> element, it doesn't necessarily apply to any and all content within the frame.

[jeffkaufman]

WebPackage UUIDs would allow an opaque-origined frame to have same-origin children

This is also how data: and blob: URLs are handled today.

[jeffkaufman]

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
A - C: xorigin
B - C: same origin

Today this is handled with having B be a safeframe. UUIDs allow this model (B is urn:uuid), while sandbox does not (C inherits the sandbox). I was hoping that <iframe opaque> would allow this model?