1454252 - Please set beacon.enabled to false by default

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect, P2)

Description

[Darkspirit]

Such a request must be well reasoned, so I list a few points:

== About the Beacon API ==
https://developer.mozilla.org/en-US/docs/Web/API/Beacon_API/Using_the_Beacon_API
> This method addresses the needs of analytics and diagnostics code that typically attempts to send data to a web server prior to the unloading of the document. Sending the data any sooner may result in a missed opportunity to gather data.

https://caniuse.com/#search=beacon
> Allows data to be sent asynchronously to a server with navigator.sendBeacon, even after a page was closed. Useful for posting analytics data the moment a user was finished using the page.


== About European Law ==
EU GDPR: Privacy by Design and by Default
> https://gdpr-info.eu/art-25-gdpr/
> "such as data minimisation"

https://www.econsultancy.com/blog/69376-gdpr-requires-privacy-by-design-but-what-is-it-and-how-can-marketers-comply
> 1. Proactive not reactive; preventative not remedial 
> 2. Privacy as default
> 3. Privacy embedded into design

To enable such an API by default seems to be clear against European Law. This bug report is not only an enhancement request anymore.


== Opt-In ==
Privacy by Default would mean the user had to Opt-In for tracking capabilities.
If someone wanted to enable this function, he/she had to flip it on about:config.
(If Mozilla would have reasons to promote this capability, it could implement something like a DNT:0 checkbox on about:preferences to Opt-In into tracking features.)


== Mozilla is on a mission to keep the Internet growing and healthy. Join us! ==
https://www.mozilla.org/en-US/internet-health/privacy-security/
> A Healthy Internet is Secure and Private

This API seems to be against Mozilla's goals. An abolition would confirm Mozilla's reputation and credibility.


== No breakage expected ==
https://www.macobserver.com/news/product-news/apple-13-webkit-features-safari-11-1/
Up until recently Safari did not even support the Beacon API, so there shouldn't be any breakage.


What are your thoughts about this from a privacy (Mozilla) perspective? Thank you.

Comment 1

[Darkspirit]

== Alternative ==
navigator.sendBeacon() could be restricted to first-party https:// URLs.

Comment 2

[Andrew Overholt [:overholt]]

I feel like Tanvi would know what to do/say here.

Comment 3

[Tanvi Vyas[:tanvi]]

We implemented this API a few years ago in https://bugzilla.mozilla.org/show_bug.cgi?id=936340.  So to answer the question of whether we can disable by default (which sounds great to me on the surface), we have to figure out why we needed to implement it in the first place.

Is the answer performance? https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
"To solve this problem, analytics and diagnostics code have historically made a synchronous XMLHttpRequest call in an unload or beforeunload event handler to submit the data. The synchronous XMLHttpRequest blocks the process of unloading the document, which in turn causes the next navigation appear to be slower. There is nothing the next page can do to avoid this perception of poor page load performance, and the result is that the user perceives that the new web page is slow to load, even though the true issue is with the previous page."

If we can't disable this by default, we could tie this into Tracking Protection - when the user has TP on, disable sendBeacon.

As for European Law, adding Marshall to see if we have any requirements as a user agent that we need to consider here.

Comment 4

[Darkspirit]

I am unsure about this. I think a major question could be how games could implement an on-the-fly "save on exit" function. Service workers? Restricting beacons to first-party https might be enough for a while?

Has someone thought about a permission system? Exemplary pre-set profiles:
- Default: e.g. Canvas, Service Worker
- Game: Everything is allowed. Beacon, WebGL/WebGPU, Performance APIs, wasm Large-Allocation, gamepad, WebVR
- Unprotected: Tracking Protection disabled + All web platform features are allowed (like now)

Comment 5

[Tanvi Vyas[:tanvi]]

We have thought about some sort of privacy slider - basic, medium, high.  We could turn off sendbeacon as part of medium or high.  We could instead have sendbeacon off by default and let a website opt-into it with Feature Policy (still needs to be implemented and properly speced).

So sounds like we have lots of options:

* disable beacon.enabled
* restrict to first party
* restrict to HTTPS
* restrict to first parties and third parties not on the tracking protection list.
* turn off by default and let website opt in with feature policy.

Do we have telemetry on usage?  If the numbers are low, we may be able to just turn this off.  If not low, or we don't have telemetry, we could try first party only.  Maybe also HTTPS, but we should consider whether HTTP opens up potential vulnerabilities that don't exist without sendBeacon HTTP.  I'm not sure sendBeacon over HTTP opens up any issues that don't already exist on the web.

We could also try to disable in nightly only and see what happens - is there user visible breakage?

Would be good to run this by webcompat or developer tools to see if we can get more anecdotal data on the usage of sendBeacon, in addition to the telemetry that may exist.

Comment 6

[(no longer active)]

I think there may have been some confusion here about the purpose of the sendBeacon() API, so let me first explain what that API was added for, and what websites do for browsers which do not have it enabled.

The question of whether to implement an API like sendBeacon() is not related to privacy at all, rather it is about performance and user experience. There are two things to pay attention to here:

A) The sendBeacon() API does not provide any additional capabilities to the page in terms of connecting to a remote analytics server in order to submit some analytics data (which may contain some cross-site tracking identifiers inside it too.) Before this API was available, pages used to implement the same functionality through mechanisms such as using synchronous XHR in unload event handlers or asynchronous XHR with an artificial timeout delaying the rest of the processing of the page to ensure that the analytics ping has been submitted to the server.

B) The sendBeacon() API merely provides an asynchronous non-blocking feature for pages to do exactly what they were already capable of doing. But in doing so, the browser can now take over the submission of this ping and do so without blocking the execution of the page or delaying some part of it.

Therefore, through providing sendBeacon(), we have replaced a slow, user-hostile mechanism for sending analytics pings with a fast user-friendly one. From a privacy perspective, nothing changed after we implemented the sendBeacon API.

More importantly, note that most pages use feature detection to decide how to submit their analytics pings, and if they detect that the browser doesn't support their preferred mechanism they fall back to the less preferred ones. So disabling sendBeacon in practice would put most pages using this feature on the slower code path they were previously using to do exactly what they were doing before. That means that it would provide zero privacy benefits, and would hurt the performance that the user would experience.

That is why instead of ineffective measures such as disabling this API, we have started to work on tracking protection features which are on by default which can protect the user's privacy against various forms of cross-site tracking (see bug 1460058 and its large dependency tree for all of the ongoing work right now.)

As far as this bug goes, we're not going to accept a patch here for the reasons I mentioned above. So I'm gonna close it now as WONTFIX. Hopefully this helps clarify how we're thinking about this subject.

Comment 7

[Rich Felker]

This should be reopened.

Therefore, through providing sendBeacon(), we have replaced a slow, user-hostile mechanism for sending analytics pings with a fast user-friendly one

is the whole point. Sites doing hostile things like tracking on close should have unpleasant ux so that they suffer from user dissatisfaction.

Comment 8

[Tanvi Vyas[:tanvi]]

I agree to reopening and investigating further, per previous comment. Clearing needinfo, and passing it to Paul to look into.

Comment 9

[Emma Zühlcke [:emz]]

I'll bring this up in our next team meeting.

Comment 10

[Emma Zühlcke [:emz]]

We think Ehsan's point stands (comment 6). Additionally there are webcompat concerns with unshipping this API that is supported in all major browsers. Merely increasing friction (by removing this API) is not sufficent to protect users. We instead rely on fundamental protections such as state partitioning to protect users.