standards-positions
standards-positions copied to clipboard
WebKit
Web Background Synchronization (BackgroundSync)
Request for position on an emerging web specification
Information about the spec
- Spec Title: Web Background Synchronization
- Spec URL: https://wicg.github.io/background-sync/spec/
- GitHub repository: https://github.com/WICG/BackgroundSync
Design reviews and vendor positions
- TAG Design Review: https://github.com/w3ctag/design-reviews/issues/95
- Mozilla standards-positions issue: https://github.com/mozilla/standards-positions/issues/173
Bugs tracking this feature
- WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=182565
- Radar:
Anything else we need to know
Background sync is a new web API that lets you defer actions until the user has stable connectivity. This is useful for ensuring that whatever the user wants to send, is actually sent.
Background Sync might be limited enough to be ok, but we generally have power and security concerns about invisible background script execution by a site that the user isn't currently visiting (potentially even if the browser is not running / not frontmost). Push API as written doesn't have sufficient protection against this (in the form of silent push) and has required browsers implementing it to design or reverse-engineer ad-hoc protections. So this other spec needs careful evaluation along these lines.
As far as I know, the web push API implemented as spec have been announced (desktop first, next year for mobile)
Does this mean your concern about power and security concerns will be fixed after mobile availability?
Thus this API and request could be officially answered at this point?
We came up with our own ad-hoc non-spec solution for prevention of silent push (like other browsers did, independent of the spec). It seems unlikely the same solution works for Background Sync.
Adding concerns: power as generally having activity running in the background is not great for battery life. In my experience as a user of "native" apps this can also be tricky to get right. Sometimes background syncing would have taken place, but the moment you open the app it does another sync and blows away the content you just started to read.
Adding concerns: privacy as this would allow a website to monitor you switching IP addresses. As the draft notes there also some network attacker leaks due to this, revealing origins that you visit that use this functionality to them.
Regarding power: What if background sync is only available when website have been added to homescreen?
And the intensity of background sync could also depends on real usage: the more the user open the website, the more background sync event is triggered.
Regarding privacy: If the website have been added to homescreen, we could infer that the user trust it. Moreover if the intensity of sync event trigger depends on usage, the less it's used, the less event will be triggered.
In that case, could it be conceivable to implement it?
What if background sync is only available when website have been added to homescreen?
I'm not sure how that helps. As I mentioned even with native apps this is a problem.
If the website have been added to homescreen, we could infer that the user trust it.
No we cannot. I might add a game to my homescreen to make it easier to get to. Doesn't mean I trust the code.
FWIW, background fetch scope is partially intersecting with background sync, but it does not have the same privacy/power concerns. It would be good to evaluate what background fetch is missing to cover background sync use cases.
@youennf is this superseded by Background Fetch? Can we close this issue in favor of #149?
@hober as far as I know Background Sync and background fetch are separate APIs, just quite related.
