search

mozilla / standards-positions

https://mozilla.github.io/standards-positions/
Mozilla Public License 2.0
614 stars 69 forks source link

Periodic Background Sync #214

Closed mugdhalakhani closed 4 years ago

mugdhalakhani commented 4 years ago

Request for Mozilla Position on an Emerging Web Specification

mugdhalakhani commented 4 years ago

@asutherland PTAL

asutherland commented 4 years ago

In general, we haven't figured out how to address the privacy and security UX of APIs like this in Firefox yet in a way that provides informed consent and where the potential upsides outweigh the downsides. It's my hope that we are able to formulate a strategy to this following our Jan-Feb 2020 all-hands which will help us determine a course of action as it relates to the background sync and background fetch APIs.

(As a practical example of this, I recently observed a Chrome install where the combination of Service Workers, Desktop Notifications, and the Push API allowed a nefarious website to effectively create persistent local popup adware using Chrome. I understand Chrome's mitigations related to this to require a user interaction budget, but in every attempt I made to try and figure out what was happening or stop what was happening, I seemed to only generate more user interaction. Thankfully I knew about chrome://serviceworker-internals, but I have no idea how a user who's not a browser engineer was supposed to figure out how to stop what was happening as all clicks seemed to immediately spawn a tab that redirected to a target ad page on a different origin than the SW origin. See https://twitter.com/asutherland/status/1192960338091761664 for screenshots. Note that it's possible the ServiceWorker was a secondary stage to an indirectly related webextension. I didn't spend a lot of time doing forensic analysis. And to clarify, while ad spam is one threat of concern, the greater concern for APIs like this is tracking/stalking.)

mugdhalakhani commented 4 years ago

Thanks for the prompt response, Andrew.

The proposed API integrates with the Permission API by adding a periodic-background-sync permission, and thus makes it possible for browsers to build any suitable privacy and security model around it. The capability will only be available, as designed, once 'periodic-background-sync' permission has been granted.

We're planning to ship this API once the origin trial ends (it's been available since Chrome 77 and is planned to run through to Chrome 80). Do you have concerns with that given the flexibility I pointed out?

bzbarsky commented 4 years ago

The concern is that there might be no possible model that can be built, because there might not be any circumstances in which the permission can be granted in a sane way. This is a general philosophical difference in API design: the Chrome team feels that "just ask the user" is a reasonable answer, and we do not. That's what the reference to "in a way that provides informed consent" in @asutherland's comment means.

That is, the flexibility here may in fact not be enough. It really depends on how possible it is to actually gain the permission in a way that does not endanger users. And just to reiterate: a number of things that Chrome considers OK we consider to be endangering users.

dbaron commented 4 years ago

I think the above discussion suggests a position of either harmful or defer. Which do you think makes sense? Do you think we can clearly state today that we believe it's harmful, or do you think we need further analysis?

asutherland commented 4 years ago

The shape of the API is reasonable. It provides the browser with a wide latitude in how to schedule things. The problem is that the only trust model Firefox currently has that matches the power and the risk right now are WebExtensions. I don't think our current enumeration includes a value that corresponds to that.

dbaron commented 4 years ago

A well-designed API that we think is not appropriate for being exposed to Web content should be marked as harmful... is that what you're saying this is?

asutherland commented 4 years ago

The Firefox OS developer inside of me is not happy about it, but yes, harmful sounds appropriate at the current time given all other factors.

mugdhalakhani commented 4 years ago

For what it's worth, Chrome doesn't show a permission prompt to the user for Periodic Background Sync, and only enables the capability on behalf of the user if accessed from within an installed web app, from a site that the user has non-zero engagement with.

I have shared a write-up by one of the privacy reviewers discussing privacy concerns and their mitigations for Chrome here: https://docs.google.com/document/d/1c9sQIF4QzzvAxbVCK9XjpIToGB8dq8w1-avQWkzKLK4/edit?usp=sharing

Here's the section of the PRD discussing privacy: https://docs.google.com/document/d/1FI4x3G6vzEWDplghSx-pH13aAwuGHiUGtXliEkZf0Vc/edit#heading=h.jmv0hdau3kk0

annevk commented 4 years ago

Installation/bookmarking coupled with interaction is not a sufficient signal that script execution in the background (and thereby sharing your location, letting it drain your battery, etc.) is okay. (Edit: see also #173.)

othermaciej commented 4 years ago

For reference, the WebKit team at Apple also opposes this, for reasons outlined here: https://bugs.webkit.org/show_bug.cgi?id=204117#c2

In addition to the privacy risk, we think there is a serious security risk (and the spec does not even have a Security Considerations section). Security risk also filed here: https://github.com/WICG/BackgroundSync/issues/169

aarongustafson commented 2 years ago

Installation/bookmarking coupled with interaction is not a sufficient signal that script execution in the background (and thereby sharing your location, letting it drain your battery, etc.) is okay. (Edit: see also #173.)

@annevk As I understand it, navigator.geolocation is not exposed in the context of a Web Worker, let alone a Service Worker. Is there another mechanism that might divulge location in the background that I’m not considering?

martinthomson commented 2 years ago

@aarongustafson, the concern isn't about the sort of location that navigator.geolocation reveals, but more the network location. That is often a good proxy for physical location.

aarongustafson commented 2 years ago

@martinthomson Gotcha. Would a browser-based VPN proxying those requests be the only mitigation for that?

binki commented 2 years ago

Maybe pinned tabs is the solution. On mobile platforms, the pinned tabs could be shown with a foreground service notification.

aarongustafson commented 2 years ago

@binki If ambient awareness is enough of a mitigation, there's also the possibility of tray icons (Windows), menubar icons (macOS, iOS, etc.), silent notifications (Android), and so on.

martinthomson commented 2 years ago

Would a browser-based VPN proxying those requests be the only mitigation for that?

All I have for your there is a solid "perhaps". There are probably lots of cases where your apparent network location doesn't change, where some sort of ambient notice might be sufficient. But when you move, cutting off the API or proxying requests is possible. We have similar issues with the Push API and the answers are similarly unsatisfactory.