- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 10 Nov 2010 21:09:44 +0000 (UTC)
- To: public-html@w3.org
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 UTC