SUMMARY
=======
Reduce the implementation burden and simplify the platform by limiting the
scope of features to the use cases that matter.
RATIONALE
=========
Implementation burden
---------------------
Allow the "nofollow" and "noreferrer" keywords to be specified on <link>
would increase the implementation burden for implementations:
CONFORMANCE CHECKERS: Conformance checkers would have to add additional
code to special-case "annotation" keywords on <link> to make sure they are
never specified alone but always with another keyword that isn't itself an
"annotation" keyword. Currently this is not required since on <a> the
element itself creates a link and thus the "annotation" keywords can be
specified alone.
USER AGENTS: Implementing "noreferrer" is non-trivial, due to the
subtlties of its effect on cross-browsing-context page navigation. While
it's likely we can get the bugs out in the <a> case, since that will be
often used, the <link> case will be rarely used (as discussed below, there
are no major use cases) and thus untested. This kind of situation has
historically been the hallmark of parts of the platform that become
unusable due to bugs, so the feature would likely still end up unusable.
EDITING TOOLS: Exposing this in a conforming manner would have many of the
same difficulties as impacts conformance checkers as listed above, but in
addition there is the difficulty of creating a good user interface for
this feature. The likelihood of this being a low-priority feature also
means that editing tools might just not expose it at all, or might expose
it without properly checking for conformance.
Security
--------
The "noreferrer" feature is primarily intended for Web mail applications;
without some mechanism to remove the Referer: header from requests, a
third party could find out any information that is contained in the URL of
the mail app, such as in some cases the user's e-mail address, or at a
minimum the identity of their mail provider. (Without "noreferrer", such
sites have to use a variety of hacks that essentially depend on bugs in
browsers.) However, this use case doesn't apply to content that is made
available using the <link> element. In fact, the Referer: header included
in requests made from <link> elements (and other elements like <img> that
are out of scope for this issue) is used _as_ a security feature to
prevent unauthorised reuse of content such as style sheets (and images).
By making it trivial to drop such headers, we would be making it much
harder to protect against such unauthorised content re-use.
Conclusion
----------
Given the existence of these costs, one must consider the value of adding
the feature. There does not appear to be any. The primary users of
"nofollow" are search engines, and none have asked for this feature to be
provided in <link>; the primary users of "noreferrer" are Web app
developers and none have asked for this feature to be provided in <link>
either. Given a dearth of use cases, and a cost to having the feature, one
can only conclude that adding the feature is a bad idea.
DETAILS
=======
No changes.
POSITIVE EFFECTS
================
Simplifies the platform, lowers the implementation burden, and keeps the
platform tightly focused on use cases that matter.
NEGATIVE EFFECTS
================
None.
CONFORMANCE CLASS CHANGES
=========================
None.
RISKS
=====
None. We can always make this change later if use cases are introduced;
implementations that wish to experiment with supporting these features can
already do so without harming the platform.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'