Re: CHANGE PROPOSAL: Remove ping and hyperlink auditing (ISSUE-1 and ISSUE-2)

Thanks, I have recorded this for ISSUE-1 and ISSUE-2 on the status  
page: <http://dev.w3.org/html5/status/issue-status.html>

On Dec 5, 2009, at 5:47 PM, Roy T. Fielding wrote:

> SUMMARY
>
> Regarding ISSUE-1 (PINGPOST) and ISSUE-2 (PINGUI), this is a
> formal change proposal to remove the ping attribute and all
> mention of hyperlink auditing from the HTML5 specification.
> The feature is half-baked, insufficiently implemented, and
> therefore not yet suitable for standardization.
>
> RATIONALE
>
> Hyperlink auditing is important because advertising and
> referral-based user tracking are two of the primary means of
> generating revenue via Web sites.  However, by its very nature,
> such tracking must be comprehensive, accurate, and unavoidable
> by a typical user or it simply won't be relied upon by site
> owners and advertisers.  The ping feature is incapable of
> providing such accuracy.
>
> The ping feature was added to HTML based on speculation that
> an optional mechanism would be usable instead of the typical
> redirect, javascript, or gateway-based tracking mechanisms.
> However, it cannot be used reliably until all browsers have
> implemented ping, are deployed, and do not configure it "off"
> by default.  Sites would therefore either ignore the ping
> feature until all of the browsers turn it on or use it only
> for secondary counts, thus duplicating the traffic that already
> handles this functionality.
>
> Ping 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 URL corresponds to the ping-per-referral URL.  It is for
> all of those reasons that people use redirects, referer,
> javascript, and cookies today to do tracking and those will
> never be solved by ping.
>
> Also, as described in ISSUE-1, ping's use of POST causes an
> unsafe method to be used in response to a safe activation request,
> in violation of the method constraints that have been part of
> Web architecture since 1992.
>
> 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/etc.).  While some user agents may already fail
> to protect the user in that regard, that is not an excuse to add
> another broken feature to the standard. Implementors are responsible
> for their own implementations.  We are only responsible for the
> standards by which those implementations are judged broken.
>
> The discussion on ping assumes that the ping target is expecting
> to receive a POST request with the content "PING" (i.e., that the
> target has not been deliberately supplied to fool an unsuspecting
> user into triggering an unsafe action when they select the link).
> That is an invalid assumption -- the target of the ping could be
> any URL, 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 unsafe resources even read the body before
> taking an action on behalf of the user.  That's why HTTP and HTML
> both have requirements on use of safe methods.
>
> If a decent solution to hyperlink auditing is ever found, then
> it can be specified separately from HTML5 and implemented in
> practice before it is standardized for the whole world.  That
> would also solve ISSUE-2 (PINGUI), which the past two years have
> demonstrated that implementing a preferences UI should at least
> be figured out before it is demanded of all implementations.
>
>
> DETAILS
>
> Apply the patch enclosed, based on r13140 of webapps/source.
> If the patch file gets eaten by the mail system, then try
>
> http://gbiv.com/protocols/html/patch/diff-vs-13140-rm-ping.txt
>
>
> IMPACT
>
> None.  This feature was never defined sufficiently to be
> implemented in practice.
>
>
> Cheers,
>
> Roy T. Fielding
> Chief Scientist, Day Software (http://www.day.com/)
>
> <diff-vs-13140-rm-ping.txt>
>

Received on Sunday, 6 December 2009 02:12:00 UTC