On Fri, May 16, 2014 at 2:54 PM, L. David Baron <[email protected]> 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 > set.)
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. / Jonas _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
