Intent to Ship: Background Sync One-Shot

[Josh Karlin]

Contact emails

jka...@chromium.org, icle...@chromium.org, owe...@chromium.org

Spec

Link to spec and pending tag review.

Summary

A ServiceWorker onsync event that can be registered for from a main-frame document or service worker with a main-frame client. Once registered, the onsync event will fire when next online (even after the page or browser has closed). The event doesn’t finish until either five minutes have passed, the event completes without a waitUntil, or the waitUntil rejects/resolves. If the event fails, the browser will retry (exponential backoff) up to a total of five attempts.

Motivation

Web Applications often run in environments with unreliable networks (e.g., mobile phones) and unknown lifetimes (the browser might be killed or the user might navigate away). This makes it difficult to synchronize client data from web apps (such as photo uploads, document changes, or composed emails) with servers. If the browser closes or the user navigates away before synchronization can complete, the app must wait until the user revisits the page to try again. This specification provides a new onsync service worker event which can fire in the background so that synchronization attempts can continue despite adverse conditions when initially requested. This API is intended to reduce the time between content creation and content synchronization with the server.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/iaAyTxWmx7o/SBDhV0UWa-sJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

The API functions on all platforms (that is, you can register for a sync and once you’re online it will fire). However, only on Android (non-WebView) will it fire after the browser has closed. In future releases, desktop versions will extend the lifetime of the browser process with Background mode for the duration of the sync registration.

Demo link

https://wicg.github.io/BackgroundSync/demo/

Debuggability

No DevTools support as yet, though it would be desirable.

Interoperability and Compatibility Risk

The spec was collaboratively designed with Chrome and Mozilla developers and Mozilla has expressed interest in developing this. There is ongoing privacy discussion for APIs that allow background processing such as sendBeacon and Background Sync which may result in the addition of permissions or notifications in future releases.

OWP launch tracking bug

https://code.google.com/p/chromium/issues/detail?id=449443

Entry on the feature dashboard

https://www.chromestatus.com/features/6170807885627392

[Anne van Kesteren]

On Wed, Nov 25, 2015 at 8:48 PM, Josh Karlin <jka...@chromium.org> wrote:
> Interoperability and Compatibility Risk
>
> The spec was collaboratively designed with Chrome and Mozilla developers and
> Mozilla has expressed interest in developing this. There is ongoing privacy
> discussion for APIs that allow background processing such as sendBeacon and
> Background Sync which may result in the addition of permissions or
> notifications in future releases.

Mozilla is interested in this API, but at this point we're not sure
how to implement it ourselves without devaluing the assumed browser
sandbox. It turns out that sendBeacon() has different semantics than
those thought by Jake Archibald and therefore does not impact the
browser sandbox. https://github.com/w3c/beacon/issues/14 has details.
Hopefully a satisfying solution to
https://github.com/WICG/BackgroundSync/issues/107 can be found. We're
happy for Chrome to try and move forward though.


--
https://annevankesteren.nl/

[Rick Byers]

Somewhat related to these privacy concerns, what is the thinking about network bandwidth usage?  I.e. in developing countries where data is expensive, what can a Chrome user do to reason about the data usage of the pages they visit?  If Android says Chrome recently used a ton of data, is there any way for a user to see what site that came from and prevent it from using background sync or service workers?

I'm sure this has been debated at length - I did a quick search but didn't find anything.  You could also argue this is orthogonal to the API concerns for an intent to ship thread (we can fork the thread and consider it separately from the intent to ship if desired).  But I do think it's related - there's a risk here that this feature could cause users to become more afraid to open web pages because it's harder for them to reason about how their usage will correlate with bandwidth consumption.  If users become afraid to open web pages, then that's a real problem for the web platform, so something worthy of a lot of thought and discussion IMHO.

Thanks,

  Rick

[Owen]

I think it's a good question, but broader than just this feature. Chrome-wide we have an issue that users can't tell how much bandwidth any origin is using which is a problem especially for emerging markets. For example, users can't know if that news article they just read took 3MB (read: cost $1) loading an ad etc.

I believe there is a plan to instrument and expose network usage which will help a lot, including in this case. When that is in place I think I expect it will allow users to have some control over limiting origins bandwidth usage which this could be part of.

We also anticipate future extensions of this API such that if a site wants to keep running the background sync for longer they must show a notification letting the user know that the network operation is in progress.

So summarizing: today, users can't know how much bandwidth a given origin is using in general, and in solving that we should think about how to integrate control over background networking such as this, but I don't believe solving the broader problem is a blocker for this intent to ship.

Thanks,

Owen

[Ian Clelland]

On Wed, Dec 2, 2015 at 5:37 PM, Owen <owe...@chromium.org> wrote:

I think it's a good question, but broader than just this feature. Chrome-wide we have an issue that users can't tell how much bandwidth any origin is using which is a problem especially for emerging markets. For example, users can't know if that news article they just read took 3MB (read: cost $1) loading an ad etc.

 

We had considered this problem early on, and the original API designs had an options dictionary for sync registration that included things like "Don't fire on a metered connection".

We removed this, along with all of the other options, in the interest of simplifying the API, (and also because in many cases, the decision is better left to the user, rather than the app developer -- some users may never have a non-cellular connection)

I believe there is a plan to instrument and expose network usage which will help a lot, including in this case. When that is in place I think I expect it will allow users to have some control over limiting origins bandwidth usage which this could be part of.

And this is definitely something we'd want background sync to hook into (and power accounting, when we have that as well).

[Rick Byers]

I believe this feature strikes a reasonable balance between "moving the web forward" and the various risks.  LGTM1 to ship.

There are still some tough problems to be worked out (balancing resource usage, permissions / UI affordances, privacy, etc.) but after chatting some more with Ian I'm convinced that the API doesn't paint us into a corner around any of these, and the team will continue iterating thoughtfully on balancing the concerns here.  Shipping this relatively simple one-shot API seems to me like a reasonable next step in figuring all of this out.

There is definitely some risk that sites will accidentally or intentionally abuse this feature (as with service workers generally).  The nightmare scenario I was most concerned about was some site causing a ton of data usage without any way for them to correlate the usage back to the site.  Normally a user can rely on data usage being at least somewhat correlated to the time they had a page visible.  But the '5 minute' rule puts a hard bound on this, giving users some ability to identify and change their behavior that leads to large network usage.  Additionally we're tracking sync metrics with RAPPOR and so we can look into the behavior of specific sites which are making the most use of this feature and tune our heuristics  / policy based on the usage we see in practice.  Worst case we can pretty easily put this feature behind a opt-in permissions prompt without worrying too much about breaking legitimate users.

I'm also nervous about the lack of concrete support from other vendors, but this is definitely an area with tough tradeoffs and not something we can really expect consensus on without some real-world shipping experience and hard evidence of user benefit.    This feature substantially "moves the web forward" in that it enables popular and important scenarios which are just not possible otherwise, and the discussions in GitHub indicate to me that there has been a thoughtful and open consensus building process.  I don't see any reason to delay shipping this subset of the API now.

Rick

[Elliott Sprehn]

The spec seems like it could use some work, for example it has a "tag" concept but never explains its purpose beyond a single example that uses it.

It'd be nice if the spec had some more descriptions of what the various parts of the API were for, and how they're expected to be used. For example why can I register tags but not unregister them? :)

[Josh Karlin]

The spec seems like it could use some work, for example it has a "tag" concept but never explains its purpose beyond a single example that uses it.

It'd be nice if the spec had some more descriptions of what the various parts of the API were for, and how they're expected to be used. For example why can I register tags but not unregister them? :)

Fair point. For instance Web Notifications has an example which describes the use of its tag. We could better describe tags, getTags, and why unregister isn't necessary via examples. Issue 118 created.

[Philip Jägenstedt]

I've looked through the spec and the demo and think this all looks very nice, just a few questions.

https://wicg.github.io/BackgroundSync/demo/ works on a fresh install of Chrome Dev on Windows, but not on Linux, where I get the error "Failed to execute 'register' on 'SyncManager': parameter 1 ('options') is not an object." This error looks like it happens before any of the new code would even run, but have you seen it before and can you fix it?

Also, the spec says Exposed=(Window,Worker) but the implementation uses Exposed=(Window,ServiceWorker). Is this intentional, or should the API be exposed in other kinds of workers as well?

The privacy issues are interesting, but I don't have anything to add. I assume that has this gone through internal security+privacy review or that it will before shipping?

On Wed, Nov 25, 2015 at 8:48 PM, Josh Karlin <jka...@chromium.org> wrote:

--
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.

[Ian Clelland]

On Wed, Dec 9, 2015 at 9:05 AM, Philip Jägenstedt <phi...@opera.com> wrote:

I've looked through the spec and the demo and think this all looks very nice, just a few questions.

https://wicg.github.io/BackgroundSync/demo/ works on a fresh install of Chrome Dev on Windows, but not on Linux, where I get the error "Failed to execute 'register' on 'SyncManager': parameter 1 ('options') is not an object." This error looks like it happens before any of the new code would even run, but have you seen it before and can you fix it?

That shouldn't happen; if it does it's certainly a (launch-blocking) bug. I landed the API change right before Chrome 48 beta was released, but it's possible that the patch didn't make it into the Linux build of Chrome Dev Channel. Can you try it out on Canary?

Also, the spec says Exposed=(Window,Worker) but the implementation uses Exposed=(Window,ServiceWorker). Is this intentional, or should the API be exposed in other kinds of workers as well?

Ideally, yes, it should be available to Web Workers, as well as service workers. crbug.com/532989 is tracking this, but it is currently blocked on crbug.com/371690. (ServiceWorker *itself* isn't exposed to workers yet in Chrome)

 

The privacy issues are interesting, but I don't have anything to add. I assume that has this gone through internal security+privacy review or that it will before shipping?

Yes. Privacy review (crbug.com/542110) is passed, and I think that egm's comment (https://code.google.com/p/chromium/issues/detail?id=539985#c18) means that security review has, as well. The launch would certainly be blocked on both of those reviews, if they were still pending.

[Philip Jägenstedt]

On Wed, Dec 9, 2015 at 3:19 PM, Ian Clelland <icle...@chromium.org> wrote:

On Wed, Dec 9, 2015 at 9:05 AM, Philip Jägenstedt <phi...@opera.com> wrote:

I've looked through the spec and the demo and think this all looks very nice, just a few questions.

https://wicg.github.io/BackgroundSync/demo/ works on a fresh install of Chrome Dev on Windows, but not on Linux, where I get the error "Failed to execute 'register' on 'SyncManager': parameter 1 ('options') is not an object." This error looks like it happens before any of the new code would even run, but have you seen it before and can you fix it?

That shouldn't happen; if it does it's certainly a (launch-blocking) bug. I landed the API change right before Chrome 48 beta was released, but it's possible that the patch didn't make it into the Linux build of Chrome Dev Channel. Can you try it out on Canary?

Mystery solved, I just hadn't upgraded my google-chrome-unstable package. It works!

 

Also, the spec says Exposed=(Window,Worker) but the implementation uses Exposed=(Window,ServiceWorker). Is this intentional, or should the API be exposed in other kinds of workers as well?

Ideally, yes, it should be available to Web Workers, as well as service workers. crbug.com/532989 is tracking this, but it is currently blocked on crbug.com/371690. (ServiceWorker *itself* isn't exposed to workers yet in Chrome)

Great, as long as it's not an accidental omission, that's fine.

 

The privacy issues are interesting, but I don't have anything to add. I assume that has this gone through internal security+privacy review or that it will before shipping?

Yes. Privacy review (crbug.com/542110) is passed, and I think that egm's comment (https://code.google.com/p/chromium/issues/detail?id=539985#c18) means that security review has, as well. The launch would certainly be blocked on both of those reviews, if they were still pending.

Sounds good, LGTM2!

[Chris Harrelson]

LGTM3

--