Intent to Experiment: Periodic Background Sync

[Mugdha Lakhani]

Contact emails

na...@chromium.org, kenji...@chromium.org

Explainer

https://github.com/beverloo/periodic-background-sync

Design doc/Spec

PRD. Design doc.

Tag review.

Summary

Periodic Background Sync is an extension of Background Sync. It allows websites to register tasks to be run in a service worker at periodic intervals with network connectivity.

Motivation

The API will allow offline-first web apps to periodically update state, and will allow periodic content producers like news sites to push content to users’ devices periodically. In countries where connectivity isn’t always reliable or fast, this will allow publishers to provide readily available content to their users either as a fallback or when launching the web app.

At present, sites can achieve this using push messages, but need to set up a server for that. Using push to address this use case is also sub-optimal for various reasons: developers need to write a server implementation that speaks the Web Push Protocol, users may not want to allow push notifications for fear of unwanted interruptions, the browser has a better understanding of how often and when new content should be fetched, etc.

 

Details

The API is currently only available to installed web apps to mitigate privacy concerns around a website being able to run logic in the background periodically.

 

We believe the user agent is in the best position to decide when to schedule a periodicsync event. So the minInterval provided by the developer is used to guarantee just that -- minimum interval between periodicsync events for the origin. Beyond that, Chrome ensures a gap of at least 12 hours (configurable through experiments) between periodicsync events. Chrome also integrates with site engagement. This way, we can allow sites that the user interacts more with, to run more frequent updates. If at any point, the site engagement falls to zero, we stop scheduling periodicsync events for the site, and pick it back up when the engagement improves.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/61yC4_xbZRA/quyt412HDQAJ

Goals for experimentation

• Is the information made available through the API sufficient to satisfy the use-cases? (Primarily interested in developer feedback.)

• Feedback on integration with site engagement. (Interested in developer feedback)

• Feedback on restricting to installed apps (Interested in both user and developer feedback).

• Is debuggability good enough? (Interested in developer feedback).

Experimental timeline

M77-M80

 

Any risks when the experiment finishes?

No.

Debuggability

Chrome DevTools will allow recording of important Periodic Background Sync events like registering, unregistering, dispatch and completion of a periodicsync event with extra information wherever appropriate, like the computed delay till the next event. This is currently behind a Devtools Experiment.

A button to dispatch a one-off periodicsync event is also in the works, again behind an experiment, which will help the developer test their response to the event.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes, except WebView. This is because there are difficulties with the lifetime of a WebView client, and with identifying the right WebView client on a page to which the Periodic Sync event should be dispatched.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5689383275462656

[Yoav Weiss]

LGTM

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7d7b1fbc-1d86-423b-a963-eacef6a21ade%40chromium.org.

[Mugdha Lakhani]

Thanks Yoav!

[Michaela Merz]

Will those syncs work even while the device is in doze?

m.

[Mugdha Lakhani]

No. We use JobScheduler on modern versions of Android, so any pending periodicsync events will be fired during the recurring maintenance window when in Doze mode. With this API, the browser is in charge of when to allow web apps to update themselves. It can thus work with the OS to schedule updates in a way that conserves resources on the device.

[Michaela Merz]

If it doesn't cut through doze - the scope of this extension is  pretty limited. That is unfortunate and should be re-thought. Because if all updates are bundled and fired at the same time, while the user uses the device,  the user experience will be greatly diminished, especially when  network speed is low. If it would work in doze, all updates could be spread over a time frame allowing for far less congestion. 

m.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/aHdERJoKYh8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3c8a4681-0f76-43f7-a454-5543c8067d82%40chromium.org.

[Peter Beverloo]

Opportunistically synchronizing content that may be consumed at some point in the future is not urgent, and thus not something we should have the device leave Doze mode for. You're right about congestion concerns, but those can be addressed in other ways.

Thanks,

Peter

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKDb%2By71NiaZnMWzaaJ--Mv6FAHqH4Wb%3DEjp8Yj_%3D9zaYYJmkg%40mail.gmail.com.

[Ben Kelly]

Note, the link in the "Demo" section of the chromestatus entry is broken.  

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7d7b1fbc-1d86-423b-a963-eacef6a21ade%40chromium.org.

[Mugdha Lakhani]

Thanks Ben. I'm actually not sure where that text is coming from. When I try to edit the entry, I don't see it anywhere, and thus can't remove it. I've added a link to the demo site in the Comments section however.

[Johnny Stenback]

That "Demo" section content is not editable for an intent whose "Intent stage" is set to "Experiment". Flip it to "Implement" and you can edit it under the "Samples links" section (which is just a list of links, thus the broken link as the text in there is not a link). And then flip it back once you're done. This is in part arguably a bug in the chromestatus.com tool, feel free to file issues at https://github.com/GoogleChrome/chromium-dashboard.

Thanks,

Johnny

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BPd-jeVz1pcru5%2B0%2BowSi1z1OoeHiMTWBnsad8q%2BPJcr_r%2Buw%40mail.gmail.com.

[Mugdha Lakhani]

Thanks! With this info, I've updated the links in the Demo section.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7d7b1fbc-1d86-423b-a963-eacef6a21ade%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Jochen Eisinger]

Is my understanding correct that the user doesn't need to grant permission to a site (but we use site engagement only)? Will it be possible for an high-engagement site to show notifications from the service worker? Can this be used to run a bot net?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7d7b1fbc-1d86-423b-a963-eacef6a21ade%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BPd-jeVz1pcru5%2B0%2BowSi1z1OoeHiMTWBnsad8q%2BPJcr_r%2Buw%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4f103f52-ea2d-4971-afc9-25204e32c70e%40chromium.org.

[Mugdha Lakhani]

The spec requires the user or the user agent on behalf of the user to have granted permission. To show notifications from the service worker, the site should additionally need the notification permission. A bot net wouldn't want to show notifications :) Also, depending on the browser implementation, this event might be subject to service worker execution timeouts. The spec also recommends capping the frequency of these events.

Site engagement integration recommended in addition to these restrictions.