Periodic Background Sync

[mugdhalakhani]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Periodic Background Sync
• Specification or proposal URL: https://github.com/WICG/BackgroundSync/blob/master/explainers/periodicsync-explainer.md
• Mozillians who can provide input (optional): asutherland@ since he has been looking at this API and has raised an Issue on the explainer.

[mugdhalakhani]

@asutherland PTAL

[asutherland]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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: WICG/background-sync#169

[aarongustafson]

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]

@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]

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

[binki]

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

[aarongustafson]

@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]

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.

[wykopx]

Will the Web Periodic Background Synchronization API be supported in Firefox any time soon? only Firefox and Safari still don't support it yet. mugdhalakhani

How come it still doesn't work if the merge fixing this request was in December 2019?
#232

[geecko86]

How come it still doesn't work if the merge fixing this request was in December 2019? #232

@wykopx I would kindly suggest clicking your own link.

We're concerned that this feature would allow users to be tracked across networks (leaking private information about location and IP address and how they change over time)

[wykopx]

@geecko86 to be honest, as a web and PWA developer, I am only interested if and when Firefox will implement this API as it is commonly supported by other browsers for many years now.

I am looking for an answer to that question, that's all.

[geecko86]

I gave you the definitive answer in a very explicit manner. It just wasn't the answer you were looking for.

I am only interested if and when Firefox will implement this API

The answer is no. Not unless someone comes up with a very impressive magic trick to anonymize all background trafic.