Re: spec review: ping attribute

Ian Hickson wrote:
> On Fri, 26 Oct 2007, Julian Reschke wrote:
>> Ian Hickson wrote:
>>> 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.
>> And thus the UA never ever should invoke POST without the consent of the 
>> user.
> 
> We're long past that. It's trivial for a page to trigger a POST without 
> the user knowing.

I consider that a bug in User Agents. Please do not add more of this.

>>> 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.
>> That's incorrect. GET and HEAD can have any side effects you want, as long as
>> they do not affect the party issuing the POST. Citing
>> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>:
>>
>> "The important distinction here is that the user did not request the
>> side-effects, so therefore cannot be held accountable for them."
> 
> You omitted the earlier paragraph:
> 
> # In particular, the convention has been established that the GET and
> # HEAD methods SHOULD NOT have the significance of taking an action
> # other than retrieval.
>  -- RFC2616:9.1.1:2

OK, so let's cite it completely:

"9.1.1 Safe Methods

Implementors should be aware that the software represents the user in 
their interactions over the Internet, and should be careful to allow the 
user to be aware of any actions they might take which may have an 
unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD 
methods SHOULD NOT have the significance of taking an action other than 
retrieval. These methods ought to be considered "safe". This allows user 
agents to represent other methods, such as POST, PUT and DELETE, in a 
special way, so that the user is made aware of the fact that a possibly 
unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not 
generate side-effects as a result of performing a GET request; in fact, 
some dynamic resources consider that a feature. The important 
distinction here is that the user did not request the side-effects, so 
therefore cannot be held accountable for them."

>>> What do you think are the risks of using POST?
>> There are some, as with GET/HEAD. Due to the nature of POST, the effects 
>> may be more grave -- as you just cited ("charging money").
> 
> You are suggesting using GET to make money change hands. If we go that 
> route, then what's the difference between GET and POST? You can't 
> simultaneously say that POST is dangerous because it lets X happen and 
> then say we should therefore use GET to let X happen. That's inconsistent.

No, I'm not suggesting that.

In this scenario, there are three parties involved:

A: the user
B: the visited site
C: the site being linked to

If the link from B to C needs to be audited for the purpose of paying 
ads, money will be exchanged between the owners of B and C. A is not 
involved in that transaction.

How the contract between B and C is implemented should be outside the 
scope of the stuff sent to A.

Again:

"The important distinction here is that the user did not request the 
side-effects, so therefore cannot be held accountable for them."

When A follows the link, he is *not* accountable for the cost of the ad, 
  being transferred from C and B.

>> I personally think that the attribute in itself is a Very Bad Idea, but 
>> if it stays in, by all means do not use POST for it.
> 
> We can't use GET... what other method would be appropriate?

You shouldn't do it at all. If you insist in doing it, use a safe 
method. Everything else is in conflict with RFC2616. And yes, you can 
use GET.

>> BTW: I just checked, and the Google Ads on www.google.de work with GET 
>> and a Redirect (302). Only safe methods from the user's point of view. 
>> Are you saying this is a problem?
> 
> Yes.

Interesting -- good that I asked. It seems we'll not be able to make 
progress on this unless we clarify this issue first.


>>>> 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.
>> You could say "must" instead of "should", for a start. You could also 
>> propose one acceptable way to fulfill that requirement.
> 
> We shouldn't use "MUST" for issues that don't result in interoperability 
> problems, that just weakens the other "MUST"s.

I think we should use "must" for things that affect privacy.

>>> 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.)
>> Well, they ignored it, yet made the functionality the default. It's a 
>> very clear signal that we have a problem here.
> 
> We could remove the paragraph.

Which makes things even worse. If you can't make this work correctly, 
please consider removing it.

Best regards, Julian

Received on Saturday, 27 October 2007 08:52:38 UTC