W3C home > Mailing lists > Public > public-html@w3.org > February 2011

Re: ISSUE-124: rel-limits - Straw Poll for Objections

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 28 Feb 2011 16:43:47 +0100
Message-ID: <4D6BC2B3.7070106@gmx.de>
To: Paul Cotton <Paul.Cotton@microsoft.com>
CC: "public-html@w3.org" <public-html@w3.org>
On 21.02.2011 04:50, Paul Cotton wrote:
> ISSUE-124: rel-limits - Straw Poll for Objections
> The poll is available here, and it will run through Monday Feb 28th:
> http://www.w3.org/2002/09/wbs/40318/issue-124-objection-poll/
> Please read the introductory text before entering your response.
> In particular, keep in mind that you don't *have* to reply. You only
> need to do so if you feel your objection to one of the options is truly
> strong, and has not been adequately addressed by a clearly marked
> objection contained within a Change Proposal or by someone else's
> objection. The Chairs will be looking at strength of objections, and
> will not be counting votes.
> /paulc
> ...

Hi, below are my comments on Ian's counter proposal 

> =======
> Reduce the implementation burden and simplify the platform by limiting the
> scope of features to the use cases that matter.
> =========
> 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.

This seems to be a very artificial argument.

First of all, I'm not aware of any conformance checkers that currently 
*do* validate the rel attribute.

Furthermore, it's not clear why it's required to check for <link>s that 
only specify annotation types. It seems to be a harmless authoring error.

> 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

It will only be untested if we do not write tests for it.

> historically been the hallmark of parts of the platform that become
> unusable due to bugs, so the feature would likely still end up unusable.

Yes, that's why we need a test suite.

> 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.

The same can be said about many other features in the spec.

> 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).

How are images affected?

> By making it trivial to drop such headers, we would be making it much
> harder to protect against such unauthorised content re-use.

This would be more convincing if you gave an example of a site that 
restricts loading of CSS based on the Referrer header.

> 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.
> ...

Apparently we disagree on costs and what a "feature" is. Having 
something work on one element but not on another element means that 
special-casing is needed. One could call that a "feature", and removing 
it could actually simplify implementations.

I just checked current UAs (Opera 11/IE 9/Safari 5.x/Firefox 4/Chrome 
10), and of these, only Safari and Chrome actually implement 
"noreferrer". Maybe this is something that requires more implementer 

 > ...

Best regards, Julian
Received on Monday, 28 February 2011 15:44:32 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:09 UTC