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

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 
(<http://lists.w3.org/Archives/Public/public-html/2010Nov/0195.html>):


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

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

 > ...

Best regards, Julian

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