Re: ISSUE-124 CP 2

On 10.11.2010 22:09, Ian Hickson wrote:
> ...
> 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.
> ...

First of all, I don't think that implications on conformance checkers 
should rule the design of the language.

Second, validator.nu currently does not check link relations *at all*; 
implementing this apparently is a big issue in itself (as it requires 
access to a machine-readable registry we haven't decided about yet).

Third, the spec already requires the checker to distinguish between 
<a>/<area> and <link>, so claiming that checking for "annotation" type 
links is a real burden seems... unsubstantiated.

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

The complexity depends on the special cases; treating the link relations 
the same way *everywhere* actually reduces the probability of errors.

Also, we're going to test this, right?

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

Doesn't compute. Why is this different from <a>/<area>?

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

How so? Page author adds "noreferrer", linked resource stops to work. 
This is by design. If it hurts, don't do it.

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

Just because "nobody has asked" for a consistent treatment doesn't mean 
that these people wouldn't *like* it to be consistent.

As far as I can tell, the additional cost of special-casing those is 
much bigger than the cost of fixing the bug, and have Webkit (the only 
current impl of "noreferrer") just follow.

 > ...

Best reagrds, Julian

Received on Thursday, 11 November 2010 11:16:43 UTC