Intent to Implement: The `Sec-Metadata` HTTP request header.
Mike West
Contact emails
mk...@chromium.org, a...@google.com
Explainer
https://github.com/mikewest/sec-metadata
TAG Review
Summary
`Sec-Metadata` (which I expect we'll rename at some point) is an HTTP request header that informs the server about otherwise opaque characteristics of the request. For example, it allows the server to distinguish requests based on the way they'll be used (e.g. `<img>` vs `<script>` vs `fetch()` vs navigation), and the relationship between the requesting origin and the requested origin (same-origin, same-site, cross-site).
Motivation
A number of attacks rely on the fact that servers don't really understand the context of incoming requests. They can evaluate the presence or absence of credential information, they can sometimes evaluate an incoming referrer, but they often don't have enough information to make an a priori decision about whether or not to respond to a given request.
This means that they'll generally do the work of generating a response, and sending it across the network to the client, relying then on client-side checks of `X-Content-Type-Options` and `X-Frame-Options` to prevent abuse. Unfortunately, this means that CSRF attacks will still reach the application and do damage. Timing attacks based both on the work the server does when responding to requests, and on the length of the delivered content itself, will still be possible client-side and through passive network observation.
If we give the servers more context about an incoming request, they can make snap decisions before doing heavy lifting in application logic, creating side-channels and potentially exposing interesting data to a cross-origin renderer.
https://www.arturjanc.com/cross-origin-infoleaks.pdf spells out the threat models we're considering in a little more detail.
Risks
Interoperability and Compatibility
As this mechanism is simply an additional HTTP header, there's little risk created by shipping it. Other vendors can pick it up over time, or, if it turns out to be a bad idea, we can drop it without much fanfare.
Edge: No signals
Firefox: Vaguely positive (annevk@'s been engaged on GitHub and IRC, dveditz@ had positive suggestions on GitHub)
Safari: Public quasi-skepticism (WebKittens are actively working on a client-side proposal that attempts to address some of the same questions from a different angle. They've engaged in the conversation around this proposal, but haven't actively invested in it. Happily, I believe these proposals can coexist cleanly, one on the client-side and one on the server-side, providing layers of defense in depth.)
Web developers: Google's internal application security team wants this yesterday.
Ergonomics
Are there any other platform APIs this feature will frequently be used in tandem with?
Not directly, but this feature would form part of an application's defenses, along with some of the client-side mechanisms I noted above.
Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?
As it's currently defined, no: we're already associating all of the information we'd like to expose with outgoing requests (and we're even exposing some of the data to JavaScript in Service Workers already). I don't foresee any specific implementation issues that would cause performance problems in the long term.
Activation
Will it be challenging for developers to take advantage of this feature immediately, as-is?
No. Google's application security team assures me that deploying this to protect various API endpoints is not difficult.
Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?
This API is partially polyfillable by leaning on Service Workers to inject a request's `destination` into the outgoing request headers. That has some impact on CORS and etc, so it wouldn't be a drop-in solution.
Debuggability
The outgoing header will show up in devtools.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5155867204780032
Requesting approval to ship?
Nope.
David Benjamin
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dd88oLXp_%2BO0eZLBaSBJiNydODZeLBboOyTcyW%2BrknROQ%40mail.gmail.com.