Intent to ship: Hyperlink Auditing (<a ping>)
jonas at sicking.cc
Mon May 19 18:55:37 PDT 2014
On Fri, May 16, 2014 at 2:54 PM, L. David Baron <dbaron at dbaron.org> wrote:
> On Friday 2014-05-16 08:58 -0400, Wesley Hardman wrote:
>> Can you detect if <a ping> is enabled? If so, having a preference isn't going to be particularly useful as sites will just fallback to the redirect method. If it is added as a UI preference, it needs to be silent, or else the preference is really "track via pings, or track via slower redirect".
> Sites can certainly tell if it's enabled with the help of a server
> (which those using it would have anyway); they can try it once, and
> if they get the ping, set a cookie. (And then they might use the
> faster ping method rather than the redirect only if the cookie is
Indeed. By the nature of this feature, there is no way we can disable
it without the website noticing. If we have a mode where we still
signal in the DOM that the feature is enabled, but then simply don't
send the network requests, I would expect websites to simply not use
<a ping> in firefox until they detect that a particular user actually
sends out ping requests. At that point set a cookie indicating that
ping can safely be used.
Having the preference in about:config seems fine. This way we don't
have to worry about arguing over UI strings. But we should make the
pref disable the full ping implementation. I.e. both the network
request and the DOM property.
Then let addons mess with either flipping the pref, blocking the ping
requests (we have nsIContentPolicy), or rewriting webpages.
I would also be fine with simply having sendBeacon(). That covers the
<a ping> use cases and more. And google has indicated that they'll
start using sendBeacon() once we ship it.
More information about the dev-platform