Interaction with sandbox attribute

[annevk]

Looking at this again for WebKit/standards-positions#45 it occurred to us with everyone aligning on cross-site cookies, repurposing the sandbox attribute in some manner might be within grasp?

I realize this was discussed to some extent before in mozilla/standards-positions#628 (comment) but it would be nice to have this flushed out a bit more. And also discussed in a place that's a bit more appropriate.

[ArthurSonzogni]

+CC @camillelamy and @mikewest who might want to bring more informations.

Some data we have: ~94% of <iframe credentialless> are not sandboxed.

About repurposing sandbox to implement <iframe credentialless>. This was documented here:

• #alternatives-sandbox
• mozilla-sandbox-proposal.md

---

Main reasons

Fully sandboxed iframe are not strict enough. The navigation response in an <iframe credentialless> is requested without credentials ¹. This is key to the security story to avoid embedding a personalized response inside a cross-origin-isolated page. With sandbox flags, it means we would need a new way to "disallow" some feature as opposed to the existing "allow-xxx" flags. This would set a precedent to the sandbox feature.

Ignoring this, We could imagine <iframe credentialless> to be:

<iframe sandbox="
  allow-same-origin
  disallow-unscoped-origin  # new flag
  disallow-autofill         # new flag
  allow-popups-no-opener    # new flag
  ...
">

(+ all of the possible allow-xxx to "undo" most sandbox flags, because developers currently don't want them).

Problem with inheritance: Sandbox flags are inherited by popups. For instance, in the case of ads, this means that every time someone clicks on an ad, the disallow-unscoped-origin flag would be inherited. The targeted website likely does not want users without credentials, and the user would be "stuck" in a credentialless tab forever. Users would not be able to understand why every website forgot who they are. This sounds unacceptable.

Problem with CSP:sandbox: The sandbox falgs are known too late, after the navigation request was made. It means the response cannot be considered unpersonalized and it wouldn't be safe loading the document in COOP/COEP environments.

Footnotes

1. To be more specific, I should say: "requested with a cookie partition scoped to the current top-level document"._ ↩

[annevk]

Thank you for reiterating those. Here's how I was thinking about them:

• I think that perhaps disallow-unscoped-origin could be a feature of sandboxing generally and perhaps not need to be opt-in. As all browsers transition towards blocking cross-site cookies, that should be easier.
• Not sure about disallow-autofill, but maybe that's possible to do by default as well. We'd have to measure how many logins happen in sandboxed documents.
• If you don't want your popups to be sandboxed, there's a flag for that.
• CSP: that indeed seems unfortunate for disallow-unscoped-origin. The server with the CSP policy would have to know not to react to cookies. As for COOP+COEP, are we sure it won't work? We could consider this declaration to be equivalent to COEP: require-corp/credentialless or some such, maybe?