Re: a/@ping discussion (ISSUE-1 and ISSUE-2), was: An HTML language specification vs. a browser specification

On Sat, 22 Nov 2008, Julian Reschke wrote:
> Ian Hickson wrote:
> > ...
> > > I don't care how long ping has been under consideration by WHATWG 
> > > mailing lists, nor do I care how many fanboys have thought in the 
> > > past that it is worth implementing. It represents a change to HTML 
> > > (a harmful one at that). Place it on the block and let it fight for 
> > > itself in terms of implementation. It should be a separate proposal 
> > > until it has been successfully implemented by two independent 
> > > implementations. Likewise for all of the other new additions.
> > 
> > This is certainly an interesting way of writing specifications, but 
> > it's not how the W3C (or the IETF) has worked so far. Why would we 
> > start with
> 
> Sorry? At least for the IETF it's tricky to make broad statements like 
> this. But rest assured that at least in some Working Groups that 
> *revise* a specification, new things do *not* get added; they get 
> separate proposals, and if they succeed, potentially get included into 
> the main spec.

Fair enough. I stand corrected. I have never seen that happen but I am 
quite willing to believe that it does.


> > HTML5? Would it help if you consider HTML5 spec as it stands today to 
> > _be_ the separate proposal?
> 
> Separate to what?

Separate to the specifications it is intended to replace, namely, HTML4, 
XHTML 1.x, and DOM2 HTML.


> > > [It] would never be implemented consistently in practice
> > 
> > Could you elaborate on this? Why would it not? It seems simple to 
> > implement, and the spec is pretty detailed.
> 
> "When the ping attribute is present, user agents should clearly indicate 
> to the user that following the hyperlink will also cause secondary 
> requests to be sent in the background, possibly including listing the 
> actual target URLs." -- 
> <http://www.w3.org/html/wg/html5/#hyperlink-auditing>
> 
> I would expect that for implementations to be consistent, there would 
> need to be a proposal *somewhere* how to implement this particular 
> aspect.

I have discussed such interface proposals with several browser vendors. 
For example, to address the above requirement, at least three proposals 
have been made: appending the hostnames of the ping targets to the status 
bar, as in:

  +--------------------------------------------------------------+
  | http://example.com/ (Notifying example.org)                //|
  +--------------------------------------------------------------+

...or using a special cursor with a tooltip, or appending an inline icon 
next to the link.


> > > [It] is trivial to defeat
> > 
> > That's by design. The whole point is to protect user privacy for users 
> > who desire pings to be disabled.
> 
> Speaking of which: I can easily imagine that in certain countries, laws 
> will require this feature to be turned off by default.

If true, that would be yet another reason to keep it -- it would make 
complying with local laws easier.


> > > [It] is trivial to use for a DoS attack or mass fraud on the 
> > > referral provider
> > 
> > Surely it's easier to use <img> for a DOS attack than ping="".
> 
> img/@src causes GET requests, while a/@ping causes POST requests.

Ok, then use <form>. ping="" is as easy to trigger as a form submission.


> > I don't understand how it would be easier to use for fraud than, say, 
> > redirects, which in practice are what is used today.
> 
> Redirects cause GET requests.

Again, use forms then.


> > > [It] is completely redundant to the current features provided by 
> > > HTTP (cookies and referer) and HTML (any embedded request).
> > 
> > I don't understand how you would implement click tracking with any of 
> > those. Could you provide code examples should how one would translate 
> > the following to an existing mechanism other than redirects? Found on, 
> > say, example.net:
> > 
> >    <a href="http://example.com/" ping="http://example.org/">...</a>
> 
> This introduces an additional party (example.org) to the operation. Why 
> is this needed?

It's a common use case. The ad publisher, the ad provider (and click 
tracker) and the ad target are commonly three different companies.


> > > [I see] an overwhelming number of comments that indicate it isn't 
> > > desirable in HTML.
> > 
> > Volume of comments one way or the other is not a technical argument.
> 
> But volume of comments can be an indicator of whether something has 
> consensus or not.

Sure. Nobody claims that we have consensus on this feature (or, for that 
matter, any feature). What's the relevance of this?


> > Browsers should show that ping="" will cause a side-effect, that's 
> > pretty much the whole point of the attribute. This is in line with 
> > what RFC 2616 says to do for unsafe methods -- tell the user.
> 
> Following a hyperlink needs to *stay* a safe operation.
> 
> Link auditing itself (whether desirable or not) is a safe operation from 
> the p.o.v. of the user, and this is what's relevant here.
>
> > A ping is non-idempotent, too, so we can't use GET.
> 
> I think you misunderstand the concept of idempotence, which could be 
> caused by RFC 2616 being misleading.
> 
> See discussion in 
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/27>.

Well, what method would you propose? GET is unacceptable for a number of 
reasons, such as bad caching behavior with proxies. Not having the feature 
rather fails to address the use cases.

Would the HTTP working group be willing to add a more appropriate method?


> > Also, note that sites vulnerable to ping="" cross-site would already 
> > be vulnerable to numerous CSRF attacks, so that's not an argument 
> > against ping="" using POST.
> 
> Actually, it is. Just because there's already another way to cause harm 
> doesn't mean it's ok to add another one.
> 
> And yes, sites need to handle arbitrary requests anyway; if they don't, 
> they are buggy. But that's not an excuse for adding a way to create POST 
> requests by simply navigating a web site.

We already have a way to create POST requests by simply navigating a Web 
site. This isn't adding anything new as far as that goes.


> > There have been several groups that have said that ping="" is exactly 
> > what they need, including (but not limited to) two groups at Google, 
> > which is a pretty major player in click tracking. I'm sure it doesn't 
> > address everyone's needs, and if there are changes that can be made to 
> > improve the feature so that it covers even more groups, we certainly 
> > should consider them, but saying that the feature doesn't match any 
> > real site's needs is simply not true.
> 
> That may all be true. I can't verify it. That being said, there seems to 
> be disagreement about it, and it would be good if that discussion would 
> occur in the open, and we wouldn't have to take your word for it.

I agree entirely that it would be better for feedback to be public. 
Unfortunately click-tracking companies tend to not want to make public 
comments about this kind of thing.

I can represent Google on this issue, though, and I assure you that at 
least from Google's point of view ping="" addresses a number of needs that 
we have been hoping to see addressed related to improving the user 
experience; primarily exposing click tracking to users more clearly and 
allowing us to move away from obfuscated links as in redirects.


> To summarize:
> 
> - it's not clear that it will be used

A number of groups, including Google, have said they will use it.


> - the way it's implemented over HTTP is problematic

Suggestions on improving it are welcome. I'm trying to do the best I can 
given HTTP's limitations.


> - there's no proposal for a UI that would comply with the requirements 
> in the spec

There are several such proposals.


> So this is a very good example for a part of HTML5 that clearly is not 
> stable

It's as stable as most parts of the document. More stable than many.


> nor has consensus

Nothing will ever have consensus in a group this size.


> and also could *easily* be specified separately.

Not really; it's part of the vocabulary and directly affects link 
navigation, a pretty core part of HTML.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 23 November 2008 05:49:19 UTC