Re: spec review: ping attribute

Charles McCathieNevile wrote:
> ...
> Indeed. What we are being asked to implement is a platform for people to 
> make money or to keep a closer watch than ever on users.
> 
> Fundamentally, the ping being sent is not a user request of any kind at 
> all, it is a third-party request for information about what the user is 
> doing. This is not a transaction between a server and a client in the 
> sense that HTTP usually offers, it is a one-way message from the client 
> to a third party. So we are just using HTTP as a transport method of 
> convenience since it is there. This is probably reasonable in the 
> circumstances, but I don't yet understand how it matters which method we 
> decide to turn into a one-way message in the absence of a mechanism for 
> such.
> ...

It's bad because

- RFC2616 clearly states that the UA should not invoke an unsafe method 
without the consent of the user, and

- a unsafe method is not needed here.

 > ...
> Actually, much as I care about security and privacy, I think that in 
> both these areas we ought to use "should" or similar language. If a 
> browser decides to violate some policy, there is generally a reason for 
> it (offer functionality to the user, or satisfy some corporate desire, 
> implement something better, ...) and I don't think that *this* 
> specification is the appropriate place to set security and privacy 
> policy for all users for the web. HTML 5 might describe the behaviour 
> that this ping should have. But browsers should be free to turn it off 
> and on, or leave it off, or leave it on, or leave it up to the user...
> ...

Understood. But right now we have one UA (FF3) approaching release, and 
the FF developers decided to ignore the "should". This means that they 
are either incompetent (I don't believe that), that they implemented 
something better (they didn't AFAIK) or that the spec can't be 
implemented. That is a problem.

So how is Opera going to do it?

Best regards, Julian

Received on Sunday, 28 October 2007 12:45:59 UTC