W3C home > Mailing lists > Public > public-html@w3.org > November 2010

ISSUE-124 CP 2

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 10 Nov 2010 21:09:44 +0000 (UTC)
To: public-html@w3.org
Message-ID: <Pine.LNX.4.64.1011102025040.11018@ps20323.dreamhostps.com>

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.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 10 November 2010 21:10:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:16 GMT