W3C home > Mailing lists > Public > public-html@w3.org > November 2007

Re: Feedback on the ping="" attribute (ISSUE-1)

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 6 Nov 2007 19:53:34 -0800
Message-Id: <A5356AD0-3EC7-432E-8512-B9CA08DE2038@gbiv.com>
Cc: Mark Baker <distobj@acm.org>, Julian Reschke <julian.reschke@gmx.de>, HTML WG List <public-html@w3.org>
To: Ian Hickson <ian@hixie.ch>

On Nov 6, 2007, at 2:11 PM, Ian Hickson wrote:
> On Tue, 6 Nov 2007, Mark Baker wrote:
>> On 11/6/07, Ian Hickson <ian@hixie.ch> wrote:
>>> On Tue, 6 Nov 2007, Mark Baker wrote:
>>>>>
>>>>> In that case I don't understand what we are discussing. Could you
>>>>> define the terms in more detail?
>>>>
>>>> Are there any specific terms you had in mind?  I think we all  
>>>> understand
>>>> what "safe" means.
>>>
>>> I don't think I do, since the way you are using it doesn't match  
>>> what I
>>> understand of the term.
>>
>> Ok.  The closest thing to a definition that Roy's cited, AFAIK,  
>> can be
>> found here;
>>
>> http://lists.w3.org/Archives/Public/www-tag/2002Apr/0207.html
>>
>> But again, the word can be used in many contexts, including both the
>> contexts that are of importance here: message and implementation.  So
>> I'm not sure that will help.
>
> The above e-mail seems to imply that a message in HTTP is "safe" if it
> causes no loss of property for the user (with a loose definition of
> property here).
>
> By that definition, any method would be safe for the purposes of
> processing ping="", because the semantics of the message are simply  
> that
> the user agent is notifying the server of an action.
>
> Note, though, that it seems that the danger is not in doing "safe"  
> things
> with "unsafe" methods, but with doing "unsafe" things with "safe"  
> methods.
> That is, doing "unsafe" work (work which can cause loss of  
> property) is
> bad when you're using GET or HEAD -- but doing "safe" work as part  
> of a
> message with "POST" is harmless. As far as I can tell.
>
> On the other hand, if we agree that "idempotent" means "has no  
> important
> side-effects" (for anyone), then clearly ping="" is not idempotent,  
> and
> so we have to have a non-idempotent method.
>
> Does that make sense?

Not really.  The actions generated by a user agent should be consistent
with the actions selected by the user.  That is why TimBL had an axiom
about GET being safe -- clicking on a link (or a spider wandering
around) must be translated into a safe network action because to do
otherwise would require every user to know the purpose of every
resource before the GET.  It follows, therefore, that the UI for a
user action that is safe (a link) must be rendered differently from
all other actions that might be unsafe.

In short, if the UI is being presented as a normal link, then the
HTTP methods resulting from the user's selection must all be safe
(GET/HEAD/OPTIONS).  You can argue this one for the next few years
if you like, but I'd be shocked if the TAG let anything else
progress past the WD stage.

I don't care how many user agents already get it wrong today. They
are responsible for their own implementations.  We are responsible
for the standards by which those implementations will be judged
broken and liable for that broken behavior.

The discussion on ping assumes that the ping target is expecting
to receive empty-body POST requests (i.e., that the target has
not been deliberately supplied to fool an unsuspecting user into
triggering a non-safe action when they select the link).  But that
is an invalid assumption -- the target of the ping could be any
URI, including those that do fun things like delete wiki pages
or print documents or send mail ... we've been through this all
before and not all of them require bodies.  That's why HTTP and
HTML both have requirements on use of safe methods.

In any case, I still see no reason for this attribute to exist.
I am well aware of how link tracking works and the entire
history of the user tracking industry in Web protocols (due to
a recent patent case), and you haven't even reached the most
minimal requirements that a real site would need for tracking
referrals, and would never be capable of proving undercounts
[the sole apparent reason for this new feature] because there
is no guarantee that the two DNS requests will deliver equally
reachable servers for the ping and href, nor that the href
request will succeed before the ping succeeds, nor that the
href URI corresponds to the ping-per-referral URI.  It is for
all of those reasons that people use redirects, referer, and
cookies today and those will never be solved by ping.

A solution to that problem, if one exists, needs to be vetted
by people at companies that do referral tracking and payments in
real life, not as a hacking exercise in cool features, and for
that you will need to talk directly to the right people at
Google, Amazon, Linkshare, and at least a few of the retailers
that are aware of all the ways in which tracking can be abused.

Even if such a ping was standardized, it would be years
before a sufficient number of deployed browsers were out there
to make it work, and during that time the content providers
would have to do both redirects and pings to get their numbers.
It is, from all perspectives, just a bad idea and not ready
for anything that calls itself an HTML standard.

....Roy
Received on Wednesday, 7 November 2007 03:53:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:50 UTC