Intent to Ship: Add referrerpolicy attribute support to <script> elements

[Dominic Farolino]

Contact emails

domfa...@gmail.com

Spec

HTML Standard PR https://github.com/whatwg/html/pull/3678, whose changes will be present at https://html.spec.whatwg.org/multipage/scripting.html#attr-script-referrerpolicy and https://html.spec.whatwg.org/multipage/scripting.html#dom-script-referrerpolicy when the PR is merged.

There is no TAG review for this since:

• It is a relatively small addition to the <script> element

• It already exists on various other resource-fetching elements such as <link> and <img>

• It is already possible to fetch a script with a developer-set referrer policy via <link rel=preload as=script referrerpolicy=... href=...>

Summary

I intend to add referrerpolicy attribute support to script elements. With this, the fetching of a <script src=... referrerpolicy=...> can utilize the value of the referrerpolicy attribute to influence the `Referer` header in ways outlined in the Referrer Policy specification. See https://github.com/w3c/webappsec-referrer-policy/issues/96.

Link to “Intent to Implement” blink-dev discussion

N/A

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

Yes

Demo link

https://script-referrerpolicy.glitch.me/

Risks

Interoperability and Compatibility

There is some interoperability risk here. Not all browsers, notably Safari, support the notion of the `referrerpolicy` attribute on already-spec’ed elements. Supporting this on <script> would widen the gap between implementations that support `referrerpolicy` and ones that don’t. The effect on developers is relatively small, but would be nice to have this privacy attribute available everywhere.

The compatibility risk here is relatively low. Only servers will see the result of the referrerpolicy attribute reflected in probably more general `Referer` headers. Even then, servers should be unable to detect that `Referer` was influenced by a policy, and it seems highly unlikely that they discriminate amongst `Referer`’s when serving responses for the same resources.

Furthermore, the addition of a referrerpolicy attribute to script has no effect in browsers that do not support this attribute, so this cannot break sites rendered in non-conforming browsers.

Edge: No signals

Firefox: Public support

Safari: No signals

Web developers: No signals

Ergonomics

It will only fall in line with other uses of the referrerpolicy attribute, and has no perceivable performance impact.

Activation

Developers can use this feature immediately in all browsers, and the computation of the `Referer` header may only be affected in conforming-browsers.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to issues, e.g.:

This is completely testable. The current referrer policy WPT suite is thoroughly tested. Before the Chromium implementation is done I will be contributing <script> tests to it for completeness.

Entry on the feature dashboard

https://www.chromestatus.com/feature/5227651627220992

[Yoav Weiss]

LGTM1

TBH, I'm surprised this isn't already supported. Thanks for tackling it! :)

Can you link to Firefox's public support as well as to the issues filed against the other implementations?

(Saw bz's comment on the PR as well as the issues you filed. I just think it'd be clearer for other reviewers if they were linked directly)

Ergonomics

It will only fall in line with other uses of the referrerpolicy attribute, and has no perceivable performance impact.

Activation

Developers can use this feature immediately in all browsers, and the computation of the `Referer` header may only be affected in conforming-browsers.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to issues, e.g.:

This is completely testable. The current referrer policy WPT suite is thoroughly tested. Before the Chromium implementation is done I will be contributing <script> tests to it for completeness.

Entry on the feature dashboard

https://www.chromestatus.com/feature/5227651627220992

--
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/9237ec0c-0ec2-420f-93ad-3dee3b3bbaff%40chromium.org.

[Dominic Farolino]

Sure thing! Here's Boris's comment on the HTML Standard discussing what (relatively minor) changes to their implementation will need made to support this. The Firefox issue is here, where the issue has been triaged, assigned a priority (P2), and a probable implementer has been CC'd.

[TAMURA, Kent]

LGTM2.  Looks a small straight-forward addition.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e1b2c886-8bd2-4981-87c9-3c02cebf9b85%40chromium.org.

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

LGTM3, and thanks for adding to the tests for this!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqEM4CsVLu2gY2J1PSrSdK3GA0TiG_-20%3DfbxPO96-KGRQ%40mail.gmail.com.