The question was simply "are there non-tracking use-cases for sendBeacon", and it sounds like the simple answer is "yes". Still not clear how common they will be relative to the tracking use cases in practice, though. What we do in terms of UI and exposing the ability to disable it depends on better understanding of that, but that discussion should probably be had separately.
Gavin On Wed, Apr 16, 2014 at 2:31 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com>wrote: > On 2014-04-16, 2:25 PM, Benjamin Smedberg wrote: > >> On 4/16/2014 2:18 PM, Richard Barnes wrote: >> >>> >>> I don't know about "problematic", but ISTM that it might be useless. >>> If people disable sendBeacon in an effort to avoid tracking, then the >>> trackers can always just test and polyfill with XHR. If you really >>> want "disable tracking", you're going to have to do a lot more, and >>> probably break a lot of the web. >>> >> >> Oh, I figured the pref flip would leave the sendBeacon API visible, it >> just wouldn't *do* anything. That would be a lot more effective than >> completely hiding it. >> >> This is very similar to the discussion about <a ping>. Can we enhance >> privacy for the users who care a lot by implementing the ping, getting >> sites to stop using redirectors for metrics, and allowing some users to >> disable the ping? >> > > There are two problems for that idea: one is that it's not possible for > Gecko at the call site to determine whether a beacon is meant for tracking > purposes or not, so if we do what you suggest we would potentially be > dropping important beacons on the floor. The other problem is that if we > tie making sendBeacon a no-op with something like DNT, or if the preference > that we expose for this purpose gains any popularity, the trackers would > fall back to the existing ways of tracking our users. > > Cheers, > Ehsan > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
