Intent to Ship: `referrerpolicy` attribute

[Emily Stark]

Contact emails

est...@chromium.org

Spec

https://w3c.github.io/webappsec/specs/referrer-policy/

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

Summary

The `referrerpolicy` attribute allows a developer to set a referrer policy for certain HTML elements, which determines how the Referer header is set for requests issued while loading these elements. The attribute applies to <a>, <area>, <img>, and <iframe> elements.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/tBn5cU26N9Q/R9vtH0XaBQAJ

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/unaEzikvU1g

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

Yes.

Interoperability and Compatibility Risk

Firefox 45 is shipping a compatible implementation: https://groups.google.com/forum/#!msg/mozilla.dev.platform/TXFImc_r9Jo/iW_5u0ICCwAJ

Mozilla has been very active in driving the specification of this attribute: https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0282.html

I recently updated the web platform tests for this attribute to help us make sure that our implementations are compatible: https://github.com/w3c/web-platform-tests/pull/2550

OWP launch tracking bug

crbug.com/490608

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5743723954569216

[Mike West]

Non-owner's LGTM from me. Thanks for doing the work to implement this interoperably with Firefox. It's a good step forward from the status-quo global policy flag for a page, and should give folks the opportunity to curtail leakage from their sites.

-mike

-mike

[Jochen Eisinger]

lgtm1

the attribute also allows for feature detection, as it reflects only valid referrer policy values.

[TAMURA, Kent]

LGTM2.

--

TAMURA Kent
Software Engineer, Google

[Chris Harrelson]

LGTM3

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

[Philip Jägenstedt]

Is https://w3c.github.io/webappsec-referrer-policy/#authoring wrong?

It says that "unknown policy values will be ignored, and when multiple sources specify a referrer policy, the value of the latest one will be used" but AFAICT that isn't what the spec says, nor is it what is SecurityPolicy::referrerPolicyFromString does.

[Jochen Eisinger]

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Document.cpp&rcl=1456288560&l=3171 implements that logic. Is that what you're referring to?

[Philip Jägenstedt]

Oh, I didn't read very carefully. One can use multiple meta elements, and the last recognized one will be used. I was thinking something like <a href="..." referrerpolicy="no-referrer new-policy"> but that's not what this section is talking about, and that wouldn't work.

LGTM4

[Yutaka Hirano]

Currently the Fetch API implementation relies on an assumption that the referrer policy of a request is always default (See https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/fetch/FetchManager.cpp&l=550). This change breaks the assumption with a service worker, right?

[Emily Stark]

On Wed, Feb 24, 2016 at 1:11 PM, Yutaka Hirano <yhi...@chromium.org> wrote:

Currently the Fetch API implementation relies on an assumption that the referrer policy of a request is always default (See https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/fetch/FetchManager.cpp&l=550). This change breaks the assumption with a service worker, right?

Hi Yutaka -- I'm sorry, I don't understand, could you explain bit more? How does this change break that assumption?

Thanks,

Emily

[Yutaka Hirano]

+falken@

Sorry for not being clear.

What happens when you trap a <img referrerpolicy=...> request in the following service worker?

self.addEventListener('fetch', e => {

  e.respondWith(fetch(e.request))

});

IIUC the fetch spec requires us to transfer request's referrer policy (in this case, the referrer policy set via the attribute) to service workers. Currently we don't implement it because no one sets request's referrer policy.

[Yutaka Hirano]

Talked offline.

The current implementation doesn't give request's referrer policy to the service worker. That means the referrer policy will be cleared in the service worker and the assumption in modules/fetch is still valid. This feature may heighten the priority of the referrer policy handling implementation in modules/fetch a bit.

[Jochen Eisinger]

yeah, referrer policies have shipped since three years or so. Maybe not breaking them in SW would be nice :(

[Yoav Weiss]

While the attribute was implemented, it wasn't implemented on `<link>`.

I have an in-progress CL adding support for that attribute on `<link rel=preload>`, and I'm likely to follow up on it with stylesheet, prefetch and icon.

Would those require a separate "intent to ship" or just notifying this thread enough?

Also, the current attribute is shipped with legacy values as well as the current spec ones. I intend to break that tradition with `<link>` and only ship the current spec values, as no content depends on the legacy values.

Does all that make sense?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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+unsubscribe@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+unsubscribe@chromium.org.

[Jochen Eisinger]

Let's do an intent to ship - that's easier to track for those who write blog posts about releases etc..

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.

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

[Joe Medley]

+1

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@chromium.org.