Closed Bug 1454252 Opened 3 years ago Closed 2 years ago
Please set beacon
.enabled to false by default
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.
== Alternative == navigator.sendBeacon() could be restricted to first-party https:// URLs.
I feel like Tanvi would know what to do/say here.
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.
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)
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.
Component: DOM → DOM: Core & HTML
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.