Like the rel=noreferrer (bug 530396) attribute for links and the referrer control offered at a document level in bug 704320 and bug 965727, we should allow web devs to set the referrer "level" for links, iframes and other embedding/navigating loads. This would basically be a special case of the document-level referrer policy offered by CSP or <meta referrer= for an individual element. I propose we use the same syntax as meta/CSP, but scope it to the element via a "referrer" attribute on the tag.

I'd argue that there is a use case for providing a finer-grained referrer. Let's take an example. On Twitter, if someone tweets a link to my blog and people visit my blog via the tweet appearing on their timeline, the referrer I see is very likely the timeline page referrer (https://twitter.com/), more or less because there is no choice. On the side of my blog, I see undifferenciated traffic from twitter.com, but have no idea which tweet specifically brought me traffic (and I'm interested, because I can engage with the people who tweeted about my blog, respond to their critics, etc.) It'd be nice, if Twitter had a mechanism to set the tweet permalink as referrer of a link to a webpage, so I know who's been interested in my blog posts. It looks like this bug is very close to suggesting such a mechanism.

Makes sense, David. For now (since there's no spec I know of on this feature) I'd like to match it up to another feature closer to standardization; but there's no reason we couldn't explore adding a literal/spoofed referrer as an option in the future.

This should be proposed on the WHATWG list first.

Also, if you plan on implementing: https://wiki.mozilla.org/WebAPI/ExposureGuidelines

FYI this has made it's way into the Referrer Policy: http://w3c.github.io/webappsec/specs/referrer-policy/#referrer-policy-delivery-referrer-attribute

Franziskus, could you please address comment 4? Also, I'm not sure this specification is really what we want for referrer: https://github.com/w3c/webappsec/issues/409