This is a Feature Request to gauge WebKit's interest in implementing Periodic Background Sync (https://github.com/WICG/BackgroundSync/blob/master/explainers/periodicsync-explainer.md) It's available as an Origin Trial (https://www.chromium.org/blink/origin-trials) in Chrome 77 and later. (https://www.chromestatus.com/feature/5689383275462656) For more context, here's a web.dev article about it: https://web.dev/periodic-background-sync/
Filing a WebKit bugzilla bug requesting a feature is not a good way to get our input on whether the feature is a good idea. The recommended ways are to email webkit-dev@webkit.org or to tag an AP or tag an appropriate WebKit person on a relevant GutHub issue.
We oppose this feature and will not implement it. Reasons: (1) We are opposed to Service Worker Background Sync and this extends Background Sync. (2) We agree with all the reasons that Mozilla stated in considering this specification to be “harmful” <https://github.com/mozilla/standards-positions/issues/214#>. (3) To be more specific there is a significant privacy risk. (a) Without a solution for hiding IP addresses, this enables persistent IP-based tracking any time the user grants the permission, and it’s difficult to word a permission dialog in a way the user would understand. (b) Background Sync allows a web app granted the permission to “phone home” with any sensitive information it obtains through another powerful capability, even if that information is only available temporarily due to a bug, and even if the user doesn’t launch the web app during the exploitability window of the bug. (4) In addition, we believe there is significant security risk. (a) Periodic BackgroundSync could be used to build BotNets along the lines in this paper: https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_01B-2_Papadopoulos_paper.pdf (b) More specifically, a mechanism to periodically phone home could turn an installed base of apps into an active BotNet at any time with no prior warning. Even with no further vulnerabilities, it could be used for purposes such as DDOS, CryptoMining or mass fraud (albeit somewhat mitigated by limits on execution time and time). (c) A mechanism to periodically phone home can be used to greatly extend the attack scope of 0-day vulnerabilities and can make it more efficient to abuse n-day vulnerabilities. Assume a sandbox escape vulnerability usable from a Service Worker is revealed. Periodic background sync allows it to be used against the whole pool of users who have granted the permission right away, perhaps before they have had time to install the patch. (d) I pointed out a number of similar risks for models with persistent background content (then called "persistent workers") in 2009: https://lists.w3.org/Archives/Public/public-whatwg-archive/2009Jul/0868.html (e) All these vulnerabilities are exacerbated by the fact that domains and websites can be purchased. Even if the actor registering for periodic background sync is trustworthy at the time, their assets could be purchased at a later time by a malicious entity. For a website, users can simply stop visiting, but with periodic background sync, they may continue to be vulnerable even if they don’t visit/launch any more. (f) Concerningly, the specification does not even have a Security Considerations section, even though these types of risks have been known for years. Perhaps mitigations to these threats exist, but one wouldn’t know it from reading the spec. (5) Periodic background execution is likely to harm mobile device battery life, and would be difficult for the user to notice and disable. (6) Background Sync and Periodic Background Sync appear to be Chromium-only technologies. Background Fetch serves some of the same use cases in a safer way and has wider consensus.
Thanks for raising these points Maciej and for also filing a Github issue with security concerns. I have posted a response to those on the Issue you raised: https://github.com/WICG/BackgroundSync/issues/169#issuecomment-563942794 Let's continue this discussion there. Best,