Intent to Ship: `Sec-Fetch-{Mode,Site,User}` request headers.

785 views
Skip to first unread message

Mike West

unread,
Apr 1, 2019, 3:10:39 AM4/1/19
to blink-dev
# Contact emails

# Explainer

# Spec
https://mikewest.github.io/sec-metadata/ (I should have moved this to WICG quite some time ago; as it stands, I've started a CfC to transition it directly to WebAppSec (though I'm sure that reasonable portions of it will end up living in Fetch and HTML)

# Summary
Fetch Metadata introduces 4 new HTTP request headers that send additional metadata about a request's provenance (is it cross-site, is it `no-cors`, etc) to the server in order to allow it to make security decisions which might mitigate some kinds of attacks based on timing the server's response (xsleaks and others).

This intent aims to ship 3 of those headers: `Sec-Fetch-Mode`, `Sec-Fetch-Site`, and `Sec-Fetch-User`. The fourth, `Sec-Fetch-Dist` needs a little more discussion, so I'd like to leave our implementation behind a flag for the time being. 

# Link to “Intent to Implement” blink-dev discussion https://groups.google.com/a/chromium.org/d/msg/blink-dev/tNwA_l_o9lc/5wug6BcmCQAJ

# Risks

## Interoperability and Compatibility
The biggest risk for deployment is that different browsers send different header values for the same kind of request. We're attempting to mitigate this risk with a reasonably robust test suite, and with recommendations in the spec for browser-specific features that are difficult to test via WPT (e.g. distinguishing users' typed navigation from page-controlled navigation).

Firefox: Mixed public signals (https://github.com/whatwg/fetch/issues/700, https://github.com/mozilla/standards-positions/issues/88 is ongoing, but I've heard positive things from individuals).

Edge: No public signals
Safari: No public signals
Web developers: Positive Dropbox wants to deploy this https://github.com/w3ctag/design-reviews/issues/280#issuecomment-440896562. Google wants to deploy this. I've heard positive comments from GitHub as well.

## Ergonomics
I expect developers will use these metadata headers on the server side as another layer of defense in combination with client-side mechanisms like Cross-Origin-Resource-Policy, Cross-Origin-Opener-Policy, and whichever headers we define next to provide more robust isolation. These are all shipping at different times in different browsers, but that seems fine, as each provides an independent layer which can be useful independently.

## Security
The feature exposes additional metadata about a given request, enabling servers to make informed decisions about the ways in which they respond. We believe it's security-positive in impact.

# Debuggability
These headers are discoverable in devtools, just like any other header.

# Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes 

Yoav Weiss

unread,
Apr 4, 2019, 2:42:29 PM4/4/19
to Mike West, blink-dev
This change seems like a significant improvement from a security perspective. I'd have loved to see more positive signals from other vendors, but at the same time, it seems we'd be able to change course if required later on.  

LGTM1

On Mon, Apr 1, 2019 at 9:10 AM Mike West <mk...@chromium.org> wrote:
# Contact emails

# Explainer

# Spec
https://mikewest.github.io/sec-metadata/ (I should have moved this to WICG quite some time ago; as it stands, I've started a CfC to transition it directly to WebAppSec (though I'm sure that reasonable portions of it will end up living in Fetch and HTML)

TAG review?
I'd hate to block on it, but might be worthwhile to kick one off
 
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DevhGO0QbcJA%3Dt%3D2mkHJTzetr%3D4T0prKVryRLBJN1HqYA%40mail.gmail.com.

Mike West

unread,
Apr 5, 2019, 2:49:43 AM4/5/19
to Yoav Weiss, blink-dev
On Thu, Apr 4, 2019 at 8:42 PM Yoav Weiss <yo...@yoav.ws> wrote:
This change seems like a significant improvement from a security perspective. I'd have loved to see more positive signals from other vendors, but at the same time, it seems we'd be able to change course if required later on.  

LGTM1

On Mon, Apr 1, 2019 at 9:10 AM Mike West <mk...@chromium.org> wrote:
# Contact emails

# Explainer

# Spec
https://mikewest.github.io/sec-metadata/ (I should have moved this to WICG quite some time ago; as it stands, I've started a CfC to transition it directly to WebAppSec (though I'm sure that reasonable portions of it will end up living in Fetch and HTML)

TAG review?
I'd hate to block on it, but might be worthwhile to kick one off

The TAG finished up their review in December: https://github.com/w3ctag/design-reviews/issues/280.

Thanks!

-mike

Chris Harrelson

unread,
Apr 6, 2019, 5:25:12 PM4/6/19
to Mike West, Yoav Weiss, blink-dev
LGTM2

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcOy3efo9QWJwZes0drxY7z7DiFm2%2B%3DJNo28rowZpiZbQ%40mail.gmail.com.

Alex Russell

unread,
Apr 11, 2019, 3:16:59 PM4/11/19
to blink-dev, mk...@chromium.org, yo...@yoav.ws
LGTM3


On Saturday, April 6, 2019 at 5:25:12 PM UTC-4, Chris Harrelson wrote:
LGTM2

On Thu, Apr 4, 2019 at 11:49 PM Mike West <mk...@chromium.org> wrote:
On Thu, Apr 4, 2019 at 8:42 PM Yoav Weiss <yo...@yoav.ws> wrote:
This change seems like a significant improvement from a security perspective. I'd have loved to see more positive signals from other vendors, but at the same time, it seems we'd be able to change course if required later on.  

LGTM1

On Mon, Apr 1, 2019 at 9:10 AM Mike West <mk...@chromium.org> wrote:
# Contact emails

# Explainer

# Spec
https://mikewest.github.io/sec-metadata/ (I should have moved this to WICG quite some time ago; as it stands, I've started a CfC to transition it directly to WebAppSec (though I'm sure that reasonable portions of it will end up living in Fetch and HTML)

TAG review?
I'd hate to block on it, but might be worthwhile to kick one off

The TAG finished up their review in December: https://github.com/w3ctag/design-reviews/issues/280.

Thanks!

-mike

--
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 blin...@chromium.org.
Reply all
Reply to author
Forward
0 new messages