Intent to deprecate and remove: `X-Frame-Options` processing inside `<meta>`.

[Mike West]

# Primary eng (and PM) emails

mk...@chromium.org

# Summary

'X-Frame-Options' will be ignored when present inside a `<meta>` tag (e.g. `<meta http-equiv="X-Frame-Options" contents="DENY">`). It will continue to be supported as an HTTP header.

# Motivation

We currently try to support `X-Frame-Options` inside `<meta>` tags  by cancelling the page load when we parse the tag, and navigating to a blank page instead. This is somewhat functional, but not exactly a reliable protection.

In fact, all of our XFO implementation is somewhat unreliable, as it's all implemented in Blink. We're working on migrating it up to the browser process, but that's going to be difficult to do cleanly if we need to support the `<meta>` implementation. We'll either need implementations in both Blink and //content, or we'll need another IPC.

I'd prefer to simply remove the functionality.

# Compatibility Risk

The spec notes that the feature must be sent as an HTTP header, and is ignored inside `<meta>` (https://tools.ietf.org/html/rfc7034#section-4). Both Firefox and IE/Edge follow this advice, ignoring XFO inside `<meta>`.

Safari supports it in a similar way to today's Chrome, with similar caveats.

No page that contains this `<meta>` tag would break outright if we removed support, they would instead lose the marginal clickjacking protection that XFO provides in a page that has already loaded. They still have the option of using the header, or using an imperative anti-clickjacking mechanism (`window.top.location = whatever`). This, of course, is exactly what's happening in IE/Edge and Firefox today.

# Usage Metrics

We don't have UseCounter metrics, but internal tools tell me somewhat reliably that ~20k pages on 154 domains contain a meta tag that we would begin ignoring:

* carsdb.com is responsible for ~5k of those pages, and won't be affected at all, as they serve the X-Frame-Options header.

* www.vivatao.com is responsible for ~4k of those pages, and won't be affected at all, as they have commented out the tag.

# OWP Launch Tracking Bug

https://crbug.com/603002

# Entry on the feature dashboard

I added https://www.chromestatus.com/feature/5760041927835648 for XFO itself. I'm not sure it's worth adding another for this removal, given it's usage, but I'll certainly add one if y'all disagree!

# Requesting approval to remove too?

Yes.

-mike

[Dimitri Glazkov]

LGTM.

[Jochen Eisinger]

lgtm2

[Philip Jägenstedt]

LGTM3. I'll defer to your judgement, but maybe it's worth emitting a
console message when this and other HTTP-only headers are used in
meta, if that isn't already happening?

> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Rick Byers]

Thanks for the great compat impact (and interop) data!  Clearly safe IMHO.

[Mike West]

I added a chromestatus entry at https://www.chromestatus.com/feature/6450843930853376 based on folks' suggestions.

Philip: https://codereview.chromium.org/1889433003 added a warning for the specific case of `X-Frame-Options`. We don't currently have a "We don't understand this <meta> tag." message, though. Perhaps we should?

-mike

-mike

[Philip Jägenstedt]

Thanks Mike! To warn about all unsupported http-equiv names would be annoying when some new header isn't yet supported, and it does happen that people add code to avoid spurious messages, so I think what you landed makes sense :)

[PhistucK]

Did you talk to WebKit folks in order to align WebKit with this new behavior as well?

They really should really be notified about any WebKitism we remove...

☆PhistucK

[Mike West]

Fair enough. Filed https://bugs.webkit.org/show_bug.cgi?id=156625.

-mike