Discussed in Reykjavik.

I see there is an initial privacy writeup (happy it's started) + permission. Permissions by default?

The explainer talks about the browser being able to respect 'do not disturb' - would it also be able/intended to respect metered connections/roaming and power save mode? Would be good to add to the explainer then

Thanks!

We've exposed a periodic-background-sync permission through the Permissions API. Using that permission may show a permission request to the user, depending on the browser implementation. The feature must only be available on secure origins, and may be further restricted to installed web apps only, based on the browser implementation. The frequency of the periodic task is decided by the browser, and the browser may base that on the user's engagement with the site.

Notifications are suppressed by the OS in DND mode, and so we don't feel that the Periodic Background Sync spec needs to define any special treatment of DND. Please let us know if you disagree.

Regarding changing behavior on metered connections and in power save mode, we're of the opinion that this should be by way of guidance, rather than a requirement. Implementations should be conservative about data usage on metered networks, and should respect the device's battery saving mode, if it has one. The browser implementation is better positioned to make these decisions, based on the unique requirements of the user. For instance, data plans are becoming cheap in India and not everyone has access to wifi. So disabling the feature on mobile networks might not be the right decision for that demographic.

I'm happy to include words to that effect in the explainer. I'll update it soon. :)

Thanks for the feedback!

@mugdhalakhani Does this feature work on an installed app on desktops OS'es like Mac OS? or is this feature limited to only Andriod OS?

It'll work for PWAs on Desktop as well.

Thanks for this, @mugdhalakhani! We're looking at this in our face-to-face TAG meeting in Tokyo.

We're curious about your thoughts on @kenchris's question. If the user can't specify behaviour on things like battery life and metered connections, is that going to confuse the user? We are thinking specifically about the example of tethering on your phone, where your browser assumes it's on a fat pipe while in fact you want the connection to use as little data as possible. We'd welcome your thoughts.

And we're happy to see that you've exposed the permissions through the Permissions API. It also raises the question though about what happens in browsers that haven't implemented the Permissions API? Also, how should a user revoke the permission? (Revoking is linked to the previous paragraph too.)

Thanks for the question Hadley.

We have to distinguish between controls the developer has for this API, and those the user does. Our reasoning is that the developer can't reliably differentiate a metered connection from an unmetered one, any better than the browser can. The browser doesn't need to rely on the developer correctly setting these levers when it can detect these situations itself.

You are right that there may be cases when the browser might not detect the type of connection correctly, like the tethering example you gave. The user can, through mechanisms such as turning on "Data Saver" mode, indicate to all apps on the device that data should be consumed conservatively. It is recommended that the browser not send periodicsync events when in Data Saver mode and connected to cellular networks. (see bug for Chrome here: https://bugs.chromium.org/p/chromium/issues/detail?id=529351) I've sent a PR to the explainer to include this recommendation, thanks for pointing it out: https://github.com/beverloo/periodic-background-sync/pull/16

Regarding your other question, note that Permissions API is simply a way for the developer to query the status of this permission through Javascript. A user prompt may or may not be shown to the user, depending on the browser implementation. Chrome's current implementation automatically denies 'periodic-background-sync' for any request made from outside a PWA and no user prompt is shown. My point is that even if the browser has an implementation of the Permissions API, the user might not be prompted for a permission.

However, the spec can mandate that the user or the user agent on behalf of the user grant permission before this API can be used. (I'm looking at https://notifications.spec.whatwg.org/#permission-model for inspiration). I've proposed adding words to this effect in the PR as well: https://github.com/beverloo/periodic-background-sync/pull/16

How to revoke the permission is again browser implementation dependent and will be done through the browser's UI. The Permission API spec mandates that the browser implementation must notify the appropriate components when the user revokes permission for a capability for a site. (https://www.w3.org/TR/permissions/#reacting-to-revocation)

@hadleybeeman, the Chrome origin trial for the API is coming to an end, and I was wondering if my answers to your previous questions make sense, and if you had any other comments about the API.

Hi there,

We read about the discussions at TPAC: https://jakearchibald.com/2019/service-workers-tpac/

and were wondering about the steps going forward? It seems that background fetch can cover many of the same use-cases and we wonder whether you are still pursuing background sync.

In a way we feel that background sync is changing the core behavior of the web. One of the sales pitches that I have heard for PWAs is that, unlike native apps, if you don't use them, then they don't update and don't waste your data plans. Basically, you can install a PWA and not use it for a year and only when you open it up (or load the web site) it is able to update itself via the SW and regular caching.

It feels like background sync changes all of that, and thus a core tenet of the web, at least as long as there are no strong restrictions on how often and how long after last use background sync can be active.

This also touches a bit on silent push notifications (which are currently not allowed - they need to show UI), these could potentially be used to sync in a similar fashion. We understand that background sync can be limited by the platform (they are just a hint) but what makes them radically different?

@beverloo @jaffathecake

The discussion at TPAC focussed on one-off Background Sync Let's focus on Periodic Background Sync here.

1. Background Fetch is designed to handle long-running downloads and uploads that can't be serviced within the execution time of a serviceworker event. They're also one-off, i.e., a new background fetch needs to be registered for each set of logical downloads. Because these can persist for long periods of time, across browser restarts, it's important to show persistent UI for the duration of background fetches. Periodic Background Sync solves a different problem. It enables a website to get repeated opportunities for updating state and content after registration, provided there's ongoing user engagement with the site.

2. The way Chrome has implemented Periodic Background Sync, and the recommendation given in the spec is to cap the frequency of periodicSync events, and tie it in with user engagement with the origin. This means that if you stop using an installed PWA, we stop sending periodicSync events. The origin won't be able to keep consuming data and resources in that case.

3. Web Push requires developers to code up a server that speaks the Push protocol, in order to send updates. It also causes the browser to be woken up to service the push event whenever the developer thinks is appropriate. Periodic Background Sync is different in that it gives the control of when to allow sites to update, to the browser. This allows the browser to optimize resources by clubbing updates of various PWAs while being respectful of user choices such as Data Saving mode, and prioritizing apps the user engages with more in the usage of these resources. A happy side effect is that it's easier to use for developers than Web Push is.

4. We've added a 'periodic-background-sync' permission to the Permission API which will allow browsers to build their own privacy model for the API. The browser may choose to show an audit style UI to the user to avoid surprising them, or automatically deny permission on behalf of the user when the capability isn't considered safe. Chrome for instance, only allows the capability to be used from installed web apps.

Let me know if this answers your questions. @beverloo, @jaffathecake, feel free to add to this.

Thanks for the answers, this sounds good. I didn't know that there was a one-off background sync as well, but I found it here: https://github.com/WICG/BackgroundSync/blob/master/explainers/sync-explainer.md

Are you thinking about adding some UI notification showing that the site is sync'ing in case users would want to block that? or do you expect the sync to be so fast that that doesn't make sense?

Is there a restriction on how long you can spend in a sync event? I know that SWs are killed if they spend too much time.

Thanks!

Yes, perhaps we should cross link both one-off and periodic background sync explainers for better discoverability.

Chrome is exploring an easily discoverable audit-style UI for all types of background activity which also allows opting out. This will surface both one-off and periodic syncs, but since it's in the exploration stage, the exact shape of the UI is unknown and thus we won't implement this in the very near future.

At present, there's a "Background Sync" site setting, which when disallowed for an origin, will also disallow Periodic Background Sync for the origin.

Different browsers can impose different limits on the service worker execution time. Chrome currently limits to three minutes, but I'm working on an experiment to reduce that time by half. Background Fetches, by comparison, have no time limit.

Are you thinking about adding some UI notification showing that the site is sync'ing in case users would want to block that? or do you expect the sync to be so fast that that doesn't make sense?

Note that Chrome already has something like this, in the context of push notifications:

I have developed a sample app that doesn't use push notifications, but that does use periodic background sync, and I have received this message.

Would be great if there actually was an info button so that people could figure out what that actually means, like [SITE SETTINGS] [MORE INFO]

I think it would be a good idea to turn off sync when the Save-Data header is present

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/save-data/

@kenchris and I were reviewing this specification during our Wellington F2F. One aspect is that there is currently no way for servers administrators to block such traffic. It would be good to be able to flag those requests (via a HTTP header) so that servers can deny traffic if unwanted. Also, in case of HTTP error (4xx status), the periodic sync should be unregistered.

@mugdhalakhani, @KenjiBaheux any update?

According to https://goo.gle/fugu-api-tracker this is already shipping in Chrome since M80

@kenchris Just FYI: my PR to update MDN with Periodic Background Sync availability was approved at the beginning of May: https://github.com/mdn/browser-compat-data/pull/6030 So the correct status should appear at CanIUse and MDN docs.

It is shipping in M80 according to https://chromestatus.com/features/5689383275462656

This is exactly what I submitted :)

Yes this API has already been shipped in Chrome, sorry for the delayed response and thanks for the suggestions!

@kenchris and I were reviewing this specification during our Wellington F2F. One aspect is that there is currently no way for servers administrators to block such traffic. It would be good to be able to flag those requests (via a HTTP header) so that servers can deny traffic if unwanted. The website is able to stop periodic sync by calling 'unregister' anytime through their service worker. Are you suggesting adding a way for IT admins to block all periodicSync traffic for a given site? They're able to do so by auto-denying the periodic-background-sync permission. In Chrome, that's possible by disabling the "Background Sync" content setting for the site.

Also, in case of HTTP error (4xx status), the periodic sync should be unregistered. This is also possible today but the developer needs to encode this. The idea is to let the web app sync whatever resources they like periodically. To that end, the browser simply sends periodicSync events to the service worker and the service Worker in turn sends any fetch requests to their server. The browser isn't initiating the fetches (giving more flexibility to the website to execute whichever fetches they like), and doesn't look at the responses from them either. The service worker can thus look for a 4xx response and call 'unregister'.

Let me know if you think the browser should do things differently. @KenjiBaheux FYI.

Hi, thank you for your response. @kenchris and I were looking at this during our f2f. Regarding the unregister on 4xx response, I think that it is important to have that, an error core (4xx or 5xx) should trigger an unregister to avoid zombie WebAppSec doing slow DDoS (if triggered by enough clients), so unregistering on errors mitigate that issue.

Ping, did anyone consider @ylafon 's last comment?

ylafon@'s suggestion of triggering an unregister on 4xx or 5xx errors makes sense to me. I've filed https://github.com/WICG/periodic-background-sync/issues/3 to track the update to the spec.

CC @beverloo, @jakearchibald

Thanks for filing the issue @mugdhalakhani - I don't think there is much more for us to do here, so I propose closing. Thanks for bringing this to the TAG

Thanks for all the feedback here!