#578: Require embedees to opt-in.

Visit on Github.

Opened Nov 25, 2020

Guten TAG!

I'm requesting a TAG review of requiring embedees to opt-into (rather than -out of) being embedded in cross-origin documents.

Documents can embed anything they like via <frame>, <iframe>, etc., exposing those embedded resources to a number of attacks, ranging from the well-known risks of clickjacking to the less-understood side-channel risks of XSLeaks and Spectre. Developers can mitigate these risks by choosing to limit the ways in which particular resources can be embedded. The X-Frame-Options header and CSP's more-granular frame-ancestors directive both provide developers with a measure of defense, but developers must choose to use them.

We should change the web's defaults such that an explicit declaration is necessary to enable cross-origin embedding a given document. That is, we'd treat the absence of an explicit X-Frame-Options or frame-ancestors declaration as having more or less the same behavior as X-Frame-Options: SAMEORIGIN.

  • Explainer¹ (minimally containing user needs and example code): https://github.com/mikewest/embedding-requires-opt-in
  • Security and Privacy self-review²: This is a strict reduction in the ability to embed documents, with direct (positive) effect on attackers' ability to exploit side-channels to gain access to other origins' data.
  • GitHub repo (if you prefer feedback filed there): https://github.com/mikewest/embedding-requires-opt-in
  • Primary contacts (and their relationship to the specification):
    • Mike West (@mikewest, Google)
  • Organization/project driving the design: Google
  • External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): None yet. You're my first stop.

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG (or just an issue against HTML)
  • The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
  • Existing major pieces of multi-stakeholder review or discussion of this design: None.
  • Major unresolved issues with or opposition to this design: None known.
  • This work is being funded by: Google.

We'd prefer the TAG provide feedback as leave review feedback as a comment in this issue and @-notify @mikewest.

Thanks for your work!

Discussions

Comment by @lknik Nov 26, 2020 (See Github)

From a personal perspective this is a very interesting proposal security-wise, so I would simply support it as is. The catchy issue is indeed rollout - so the potential for breaking how stuff works today. It is addressed in your explainer, but I wonder how to reach the smaller sites? Maybe at first stage a site should be marked as unsafe (url-bar)?

Comment by @mikewest Dec 1, 2020 (See Github)

Thanks, @lknik! Reaching the long tail of sites is, indeed, important. I hope we'll be able to do so effectively via mechanisms like blog posts and tooling (devtools, lighthouse/observatory, deprecation reports, securityheaders.io and similar, etc). I don't think marking sites as unsafe because they embedded a page that didn't opt-in will be terribly effective, as the warning would seem to accrue to the wrong entity (embedder rather than embedee), but I'm open to additional ideas!

Discussed Jan 1, 2021 (See Github)

No issues except compat concerns.

Comment by @hober Jan 26, 2021 (See Github)

#76 seems relevant...

Comment by @hober Jan 27, 2021 (See Github)

Hi @mikewest!

@cynthia, @plinss and I looked at this today during our vF2F. We recognize the value in moving the web in this direction, and also that it's risky from a compat standpoint. If you decide to try it, let us know how it goes & if it turns out to be doable.