Intent to ship: referrerpolicy attribute

[Franziskus Kiefer]

As of Firefox 45 we intend to turn referrerpolicy attribute on by default
on all platforms. It has been developed behind the
network.http.enablePerElementReferrer preference. Other UAs shipping this
or intending to ship it are Chrome and Opera [1].

The referrerpolicy attribute as specified in the referrer policy spec
allows per element referrer policies for <a>, <area>, <img>, and <iframe>
tags. Referrer policies allow to specify
which referer [sic] header is sent when performing the request. The
referrerpolicy attribute allows
developers to override the document's referrer policy (set in meta tag or
via CSP) on a per element basis.

This feature was previously discussed in this "intent to implement" thread:
https://groups.google.com/d/topic/mozilla.dev.platform/g-YY5rWFCLM/discussion.


*Bug to turn on by default*:
https://bugzilla.mozilla.org/show_bug.cgi?id=1223838
*Link to standard*: https://w3c.github.io/webappsec-referrer-policy/
[1] https://www.chromestatus.com/feature/5743723954569216

[Ms2ger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Do we have tests in web-platform-tests that show our implementation is
interoperable with Blink?

I believe there was a capitalization issue with this feature; has it
been solved and the solution implemented everywhere?

Thanks
Ms2ger
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJWXsPnAAoJEOXgvIL+s8n2FIkH/2jkW3tYftCwNnTNScSCBvrq
UQTsPruJJPzTQL1lVfMV3Nl+JoieFLvpgPlZc2HG4AY0m5c95A+lAwHAbt6bu/GY
nYmctz+e0Mktau2IGvTon6G4QO5kRy/boXX4N2m7E/cAzkC7H8dfFC5AD5jtsqo7
F8FqmQah1RrcvtUrrqvfGi5Va5bLdKVD2WEkbR7vlWr7ubSzNsCtJSe2P6oKOeet
Ys9f6n+RLOoWLI9CUqNBt2WqLSxJDf+gIgXEm3p+3D718BZg+zLe2d6u5SV3NuEw
zljxSHADse/zobwgCPvXLL6hpaDVFBLC45TccGRIVIPBcyeT0tHngGO/EYZpejI=
=rHo4
-----END PGP SIGNATURE-----

[Franziskus Kiefer]

There are web-platform-tests [1], though they're not up to date with the
spec. In particular, they still use |referrer| as attribute name instead of
|referrerpolicy|. The idl name is referrerPolicy, is that the
capitalisation issue you mean?

So there are no tests for interoperability at the moment.

[1] https://github.com/w3c/web-platform-tests/tree/master/referrer-policy

Cheers

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Gijs Kruitbosch]

On 02/12/2015 11:16, Franziskus Kiefer wrote:
> they still use |referrer| as attribute name instead of
> |referrerpolicy|.

I randomly ran into this today while looking at something completely
different...

Where was the name changed? There is browser frontend code that still
uses the old name:

https://dxr.mozilla.org/mozilla-central/rev/470f4f8c2b2d6f82e56e161a4b05262c85f55b59/browser/base/content/browser.js#5779-5786

and there might be more. Can you file a bug to go over the rename and
fix up this and any other cases that were left out?

~ Gijs

[James Graham]

On 02/12/15 11:16, Franziskus Kiefer wrote:
> There are web-platform-tests [1], though they're not up to date with the
> spec. In particular, they still use |referrer| as attribute name instead of
> |referrerpolicy|. The idl name is referrerPolicy, is that the
> capitalisation issue you mean?
>
> So there are no tests for interoperability at the moment.

It sounds like we need to fix these tests as part of this implementation
work.

[Franziskus Kiefer]

Thanks again Gijs for pointing this out and the quick review. The frontend
code is fixed (see bug 1187357).

The web-platform tests are tracked in bug 1168540. But there seems very
little work on them recently (in the last 5 month). But we will follow up
on this.

[Ehsan Akhgari]

On 2015-12-02 3:16 PM, Franziskus Kiefer wrote:
> The web-platform tests are tracked in bug 1168540. But there seems very
> little work on them recently (in the last 5 month). But we will follow up
> on this.

We have recently been working on fixing up web-platform-tests in order
to keep up with spec changes (among other things) and with James
Graham's help we came up with a plan to fix the tests in mozilla-central
and upstream later. I hope we can do more of this in general, but in
this specific case I suggest asking for help from jgraham. :-)

[Jonas Sicking]

I think our implementation still has the problem that specifying
referrerpolicy="none-when-downgrade" on an element has no effect. This
is because the ReferrerPolicy enum uses the same value for RP_Unset,
RP_Default and RP_No_Referrer_When_Downgrade.

In general, that enum is a mess :(

Would be good to get our implementation into a better state before we ship.

/ Jonas

On Wed, Dec 2, 2015 at 1:58 AM, Franziskus Kiefer <fki...@mozilla.com> wrote:
> As of Firefox 45 we intend to turn referrerpolicy attribute on by default
> on all platforms. It has been developed behind the
> network.http.enablePerElementReferrer preference. Other UAs shipping this
> or intending to ship it are Chrome and Opera [1].
>
> The referrerpolicy attribute as specified in the referrer policy spec
> allows per element referrer policies for <a>, <area>, <img>, and <iframe>
> tags. Referrer policies allow to specify
> which referer [sic] header is sent when performing the request. The
> referrerpolicy attribute allows
> developers to override the document's referrer policy (set in meta tag or
> via CSP) on a per element basis.
>
> This feature was previously discussed in this "intent to implement" thread:
> https://groups.google.com/d/topic/mozilla.dev.platform/g-YY5rWFCLM/discussion.
>
>
> *Bug to turn on by default*:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1223838
> *Link to standard*: https://w3c.github.io/webappsec-referrer-policy/
> [1] https://www.chromestatus.com/feature/5743723954569216

[Franziskus Kiefer]

On Fri, Dec 4, 2015 at 8:57 AM, Jonas Sicking <jo...@sicking.cc> wrote:

> I think our implementation still has the problem that specifying
> referrerpolicy="none-when-downgrade" on an element has no effect. This
> is because the ReferrerPolicy enum uses the same value for RP_Unset,
> RP_Default and RP_No_Referrer_When_Downgrade.
>

well, that might be the case, but "no-referrer-when-downgrade" is also not
a valid value for referrerpolicy attributes yet. This is a recent spec
change that should be implemented in bug 1178337.

[Franziskus Kiefer]

we're working on fixing the web-platform tests but those aren't blocker for
shipping this. Neither are the additional valid attribute values, which
will be added soon in bug 1178337.
So if there are no other concerns we will enable the referrerpolicy
attribute in 46.

On Fri, Dec 4, 2015 at 10:15 AM, Franziskus Kiefer <fki...@mozilla.com>
wrote:

>

[Josh Matthews]

On 2015-12-29 10:42 AM, Franziskus Kiefer wrote:
> we're working on fixing the web-platform tests but those aren't blocker for
> shipping this. Neither are the additional valid attribute values, which
> will be added soon in bug 1178337.
> So if there are no other concerns we will enable the referrerpolicy
> attribute in 46.

Why are cross-browser tests for the feature not considered a blocker to
it shipping?

[Josh Matthews]

To elaborate on this - it is now easier than ever to write tests that
verify an implementation's conformance against the specification. These
tests are also run by other browser vendors. Given that we want to be
shipping features that are interoperable with other browsers and match
the specification, why should ensuring that the relevant web-platform
tests are up to date and passing not block shipping new features?

Cheers,
Josh

[Ehsan Akhgari]

On 2015-12-29 10:42 AM, Franziskus Kiefer wrote:
> we're working on fixing the web-platform tests but those aren't blocker for
> shipping this. Neither are the additional valid attribute values, which
> will be added soon in bug 1178337.
> So if there are no other concerns we will enable the referrerpolicy
> attribute in 46.

Is it possible to feature detect which attribute values our
implementation supports?

[Franziskus Kiefer]

currently there is no nice way to check which attribute values are
implemented afaik.

So far web platform tests haven't been a blocker (so I was told) but if
that's something we want to change that's fine with me.

On Tue, Dec 29, 2015 at 7:27 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

[Anne van Kesteren]

On Mon, Jan 4, 2016 at 7:46 AM, Franziskus Kiefer <fki...@mozilla.com> wrote:
> currently there is no nice way to check which attribute values are
> implemented afaik.

There should be, per the specification discussion. E.g.,

function isSupported(token) {
var ele = document.createElement("a")
ele.referrerPolicy = token
return ele.referrerPolicy === token
}


--
https://annevankesteren.nl/

[Masatoshi Kimura]

On 2016/01/04 16:54, Anne van Kesteren wrote:
> There should be, per the specification discussion. E.g.,
>
> function isSupported(token) {
> var ele = document.createElement("a")
> ele.referrerPolicy = token
> return ele.referrerPolicy === token
> }

It didn't work because |ele.referrerPolicy = token| created the
"referrerPolicy" property on ele. This function will return true even if
the browser does not support referrerPolicy.

--
VYV0...@nifty.ne.jp

[Anne van Kesteren]

Well, yes, this function assumes

"referrerPolicy" in ele

to be true. If that is not true it does not matter much whether the
token is supported or not, since it won't work anyway.


--
https://annevankesteren.nl/