Why are you providing "none" in the content attribute instead of "no-referrer"? Is there documentation somewhere that says that should work? If you change it to "no-referrer", then your example works as expected: https://jsfiddle.net/mer054hc/

Ah yes no-referrer works as expected. However using "None" is pretty widely documented and should be supported. It's supported in Firefox, iOS Chrome, iOS Safari, and desktop Safari (IE doesn't support either). Linked is the documentation (and attached are screenshots) that gives the false impression of it being supported.


https://moz.com/blog/meta-referrer-tag
https://www.w3.org/TR/referrer-policy/#referrer-policy-state-none

Not official by any means, but it's just a note to show this is a common mistake (http://stackoverflow.com/a/32803924/5865423)

Deleted: mozDocumentation.PNG 25.2 KB

	mozDocumentation.PNG 25.2 KB View Download

Deleted: w3Documentation.PNG 44.4 KB

	w3Documentation.PNG 44.4 KB View Download

Thank you for providing more feedback. Adding requester "estark@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

It looks like there isn't a security vulnerability here, as the correct value (no-referrer) works.

estark: Should this be a feature request instead, to allow "None" as a valid value?

I’m not sure how this isn’t a security issue. I agree, I mis-titled the thread causing some confusion. However, there is quite a bit of documentation regarding this (even w3 written by Google), and claiming that this is indeed a valid value for that field. Every other major browser supports it including Chrome on iOS, however it’s ignored on Chrome desktop. If desktop Chrome never supported this value I’m not sure why there’s misleading w3 spec written on it. If they did support it at one point, I’m not sure why it was removed after wide adoption. Thanks,

- Tanner

If it's in the spec, then sure, it makes sense to treat is as a security bug. I'll leave it to estark to decide.

Huh, that's weird that 'none' is in the working draft of the spec as a valid policy. At some point it disappeared from the editor's draft (https://w3c.github.io/webappsec-referrer-policy/) and I'm not sure why. Maybe there's some mention of it in the public-webappsec archives, I'll go searching...

In the meantime I think we should perhaps leave this open as a low severity security bug.

this was removed in https://github.com/w3c/webappsec-referrer-policy/commit/d99bd4a72fec089aa5e4c81922aa2e9cb640fa96 - looks like an accident indeed.

filed https://github.com/w3c/webappsec-referrer-policy/issues/112 to track

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e6e49f4b3376d278aa09186ad5200732f0cd8365

commit e6e49f4b3376d278aa09186ad5200732f0cd8365
Author: Jochen Eisinger <jochen@chromium.org>
Date: Thu Nov 16 17:29:09 2017

Add back support for "none" referrer policy

It's a legacy keyword that was accidentially removed

BUG= 615608 
R=estark@chromium.org

Change-Id: I1bf4d87d999f35b30beca644b4dec6712ac2d388
Reviewed-on: https://chromium-review.googlesource.com/772234
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517114}
[modify] https://crrev.com/e6e49f4b3376d278aa09186ad5200732f0cd8365/third_party/WebKit/Source/platform/weborigin/SecurityPolicy.cpp
[modify] https://crrev.com/e6e49f4b3376d278aa09186ad5200732f0cd8365/third_party/WebKit/Source/platform/weborigin/SecurityPolicyTest.cpp

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot