User Permission for Background Sync

[RichardMaher]

WRT privacy considerations how can a user "opt-out" of Background-Sync from a fullscreen PWA when there is no way to get at esoteric and obscure browser options?

Also isn't is going against the grain of the "P" in PWA to expose a user to privacy risks by default and force them to "opt-out" of the danger zone?

Why has the Permissions API been completely bypassed here?

[jakearchibald]

Hi @RichardMaher! This is the repo for spec issues, concerns about particular implementations should be posted in the bug tracker for that particular browser. I'll respond anyway…

WRT privacy considerations how can a user "opt-out" of Background-Sync

On desktop you click the security chip in the URL bar (where the other permission options are). This doesn't appear to be there on mobile, so I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=729539 to see if it's an oversight.

Also isn't is going against the grain of the "P" in PWA

The "P" standards for progressive as in progressive enhancement which background sync is entirely compatible with. See https://developers.google.com/web/updates/2015/12/background-sync#progressive_enhancement for how to apply it in this situation.

Why has the Permissions API been completely bypassed here?

Quoting from https://developers.google.com/web/updates/2015/12/background-sync#permissions

The demos I’ve shown use web notifications, which require permission, but background sync itself does not.

Sync events will often complete while the user has a page open to the site, so requiring user permission would be a poor experience. Instead, we’re limiting when syncs can be registered and triggered to prevent abuse. E.g.:

• You can only register for a sync event when the user has a window open to the site.
• The event execution time is capped, so you can’t use them to ping a server every x seconds, mine bitcoins or whatever.

Of course, these restrictions may loosen/tighten based on real-world usage.

There's also https://github.com/WICG/BackgroundSync/issues/80 which has some permission API discussion.

navigator.sendBeacon does not require permission & has similar functionality and limitations.

Is there a particular attack you think background sync exposes users to?

Closing, but will reopen if this turns out to be a valid concern.

[Solzhenitsyn]

navigator.sendBeacon does not require permission & has similar functionality and limitations.

This is wrong and two wrongs don't make a right. I am extremely surprised to see Mozilla implement this but the analytics bullies must be too strong.

But such is the power of precedent. I will get on to marketing and ask for some serious sounding security-mitigation clauses and sufficient fluff and before you know it "Prompting for permission for Background Geolocation" will be a poor user experience. Add that to "sendBeacon and BackgroundSync already do this" and we're over the wire!

[jakearchibald]

This is wrong and two wrongs don't make a right

You can't simply state these things, you need to give reasoning. By showing your working, it may become obvious that your understanding of these features is incorrect.

before you know it "Prompting for permission for Background Geolocation" will be a poor user experience. Add that to "sendBeacon and BackgroundSync already do this" and we're over the wire!

This kind of "slippery slope" reasoning is lazy. If you can't explain how one directly enables another, all you have is FUD.

[RichardMaher]

WRT the spec. The following privacy vulnerabilities are sufficient to warrant user-awareness, indeed to facilitate user-sanction, in the eyes of any casual observer: -

4.2 Location Tracking 4.3 History leaking

My interest here OTOH stems from the need to bolster the argument that the Capability Permissions model cannot solve all requirements and that background-synch and background-fetch are two such requirements.

WRT a specific implementation (Chrome)

I find the following text coercive and potentially misleading regarding "recently" : -

WRT to "This doesn't appear to be there on mobile, so I've filed [a bug]"

My guess is that bug will never be triaged and that statement is equivalent to "These are very serious issues and we've formed a committee to investigate fully. I couldn't possibly preempt their findings by commenting here."

Finally, I don't think that many Ultimate Web App and SPA users have the URL chrome on their displays so that some dicky options for BackgroundSync can be located? Do you seriously expect users to type in browser-security domain-exceptions with their virtual keyboard? "Poor" user experience?

[jakearchibald]

4.2 Location Tracking 4.3 History leaking

Can you demonstrate how those are leaked compared to sendBeacon?

WRT a specific implementation

This is the repo for spec issues, concerns about particular implementations should be posted in the bug tracker for that particular browser.