Intent to Implement & Ship: Referrer Policy header for CSS

[Jochen Eisinger]

Contact emails

est...@chromium.org, joc...@chromium.org

Spec

https://www.w3.org/TR/referrer-policy/#integration-with-css 

https://github.com/w3ctag/spec-reviews/issues/36 

Summary

Stylesheets loaded from the network will get their own referrer policy instead of inheriting it from the owner document. The policy can be set via the referrer policy header.

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

Yes

Debuggability

Referrer policies are exposed in the network panel of devtools.

Interoperability and Compatibility Risk

If a site relies on setting the referrer policy for stylesheets via inheritance from a document, they'll have to send a header instead. Also, they relied on previously unspec'ed behavior...

Edge: No signals

Firefox: Public support: working with +Boris Zbarsky to get the wording right here: https://github.com/w3c/webappsec-referrer-policy/pull/92 - I'll just count that as public support of the general idea

Safari: No signals

Web developers: No signals

OWP launch tracking bug

https://crbug.com/676645 

Entry on the feature dashboard

https://www.chromestatus.com/features/5639972996513792 (reusing existing entry for Referrer Policy header support)

[Dimitri Glazkov]

LGTM1

[Chris Harrelson]

LGTM2

LGTM1

--
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+unsubscribe@chromium.org.

[PhistucK]

Are you going to send an intent to remove for the inheritance part (and a dashboard entry for it)?

I think you should.

☆PhistucK

[Rick Byers]

LGTM3

On Wed, Feb 8, 2017 at 1:19 PM, PhistucK <phis...@gmail.com> wrote:

Are you going to send an intent to remove for the inheritance part (and a dashboard entry for it)?

I think you should.

☆PhistucK

On Wed, Feb 8, 2017 at 7:20 PM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM2

On Mon, Feb 6, 2017 at 7:22 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:

LGTM1

On Mon, Feb 6, 2017 at 2:14 AM Jochen Eisinger <joc...@chromium.org> wrote:

Contact emails

est...@chromium.org, joc...@chromium.org

Spec

https://www.w3.org/TR/referrer-policy/#integration-with-css 

https://github.com/w3ctag/spec-reviews/issues/36 

Was there some follow-up somewhere else?  There's not actually any review response about referrer policy there as far as I can see.

Summary

Stylesheets loaded from the network will get their own referrer policy instead of inheriting it from the owner document. The policy can be set via the referrer policy header.

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

Yes

Debuggability

Referrer policies are exposed in the network panel of devtools.

Interoperability and Compatibility Risk

If a site relies on setting the referrer policy for stylesheets via inheritance from a document, they'll have to send a header instead. Also, they relied on previously unspec'ed behavior...

I guess there's some potential compat risk here, but it's hard to quantify (since it depends almost entirely on server behavior) - right?  It seems reasonable to expect that the risk is low, but we should be prepared to re-evaluate if we get reports of real breakage.

Please make sure this gets mentioned in the deprecations blog post.  IMHO that's what's important about the "deprecations" process (otherwise this seems small / low-risk enough that I don't see a need for a separate intent / dashboard entry).

 

Edge: No signals

Firefox: Public support: working with +Boris Zbarsky to get the wording right here: https://github.com/w3c/webappsec-referrer-policy/pull/92 - I'll just count that as public support of the general idea

Safari: No signals

Web developers: No signals

OWP launch tracking bug

https://crbug.com/676645 

I marked this as a "OWP-Type-ChangeBehavior" bug.  Please add the correct milestone once it's landed and known to be shipping (so it shows up in searches for OWP changes in that milestone).

[Jochen Eisinger]

On Wed, Feb 8, 2017 at 7:53 PM Rick Byers <rby...@chromium.org> wrote:

LGTM3

On Wed, Feb 8, 2017 at 1:19 PM, PhistucK <phis...@gmail.com> wrote:

Are you going to send an intent to remove for the inheritance part (and a dashboard entry for it)?

I think you should.

☆PhistucK

On Wed, Feb 8, 2017 at 7:20 PM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM2

On Mon, Feb 6, 2017 at 7:22 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:

LGTM1

On Mon, Feb 6, 2017 at 2:14 AM Jochen Eisinger <joc...@chromium.org> wrote:

Contact emails

est...@chromium.org, joc...@chromium.org

Spec

https://www.w3.org/TR/referrer-policy/#integration-with-css 

https://github.com/w3ctag/spec-reviews/issues/36 

Was there some follow-up somewhere else?  There's not actually any review response about referrer policy there as far as I can see.

I actually don't know whether there's something on record. The tl;dr version is that relaxing referrer restrictions is considered to be helping websites move to https without running the risk of losing attribution.

With that in mind, referrer controls were removed from CSP as CSP is supposed to always restrict things, and we now have a separate header to control referrer policies.

 

Summary

Stylesheets loaded from the network will get their own referrer policy instead of inheriting it from the owner document. The policy can be set via the referrer policy header.

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

Yes

Debuggability

Referrer policies are exposed in the network panel of devtools.

Interoperability and Compatibility Risk

If a site relies on setting the referrer policy for stylesheets via inheritance from a document, they'll have to send a header instead. Also, they relied on previously unspec'ed behavior...

I guess there's some potential compat risk here, but it's hard to quantify (since it depends almost entirely on server behavior) - right?  It seems reasonable to expect that the risk is low, but we should be prepared to re-evaluate if we get reports of real breakage.

Please make sure this gets mentioned in the deprecations blog post.  IMHO that's what's important about the "deprecations" process (otherwise this seems small / low-risk enough that I don't see a need for a separate intent / dashboard entry).

Sure, I'll make sure that this gets covered.

 

 

Edge: No signals

Firefox: Public support: working with +Boris Zbarsky to get the wording right here: https://github.com/w3c/webappsec-referrer-policy/pull/92 - I'll just count that as public support of the general idea

Safari: No signals

Web developers: No signals

OWP launch tracking bug

https://crbug.com/676645 

I marked this as a "OWP-Type-ChangeBehavior" bug.  Please add the correct milestone once it's landed and known to be shipping (so it shows up in searches for OWP changes in that milestone).

Will do

 

Entry on the feature dashboard

https://www.chromestatus.com/features/5639972996513792 (reusing existing entry for Referrer Policy header support)

--
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.

--
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.

[Jochen Eisinger]

fyi, this has landed now (including web platform tests)