Re: spec review: ping attribute

Aside from all of the other issues, my vote would be to remove the
ping attribute from the specification.  It is not a desirable feature.
It is not sufficient for accurate user tracking (mandatory in the
realm of referral payments), would never be implemented consistently
in practice, is trivial to defeat, is trivial to use for a DoS attack
or mass fraud on the referral provider, and is completely redundant
to the current features provided by HTTP (cookies and referer) and
HTML (any embedded request).  In short, it doesn't even come close
to something that should be standardized.

....Roy

On Oct 26, 2007, at 1:51 PM, Ian Hickson wrote:

> On Fri, 26 Oct 2007, Julian Reschke wrote:
>>
>> "For URIs that are HTTP URIs, the requests must be performed using  
>> the
>> POST method (with an empty entity body in the request). User  
>> agents must
>> ignore any entity bodies returned in the responses, but must, unless
>> otherwise specified by the user, honour the HTTP headers — in
>> particular, HTTP cookie headers. [RFC2965]"
>>
>> I'd like to understand why POST was selected for that. POST is an  
>> unsafe
>> method, and it shouldn't be sent without the consent of the user  
>> -- in
>> particular not if the target is on a different server.
>
> POST is "unsafe" because invoking the method is allowed to have
> side-effects, like charging money, whereas GET requests are safe  
> because
> they are supposed to be idempotent, meaning that no side-effects are
> supposed to happen.
>
> In the case of ping="", a major use case is informing a site when a
> sponsored link is followed, to enable the site to transfer money  
> with a
> third party. This is a side-effect, and can only happen if the  
> request is
> not an idempotent (GET, HEAD) request. POST is the most appropriate  
> method
> for this use case.
>
> What do you think are the risks of using POST?
>
>
>> The spec continues with:
>>
>> "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 URIs."
>>
>> This is good, but it's probably not clear enough -- at least FF3 is
>> ignoring this.
>
> It's not clear to me how to make it clearer.
>
> In the case of Firefox 3, the developers were very aware of the above
> requirement, as well as its implications, and intentionally decided to
> violate the SHOULD for the time being. It isn't clear to me that  
> there is
> anything I could do to the _spec_ to change their mind. (It's not like
> they just missed the above paragraph or didn't understand it.)
>
> -- 
> Ian Hickson               U+1047E                ) 
> \._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
> \  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'-- 
> (,_..'`-.;.'

Received on Sunday, 28 October 2007 17:47:40 UTC