Intent To Implement: Budget API

[Jen Harkness]

Contact emails

hark...@chromium.org, pe...@chromium.org

Spec

https://beverloo.github.io/budget-api/

Summary

This implements an API that exposes a budget with which authors can determine their available usage of resource consuming background operations, as well as the cost associated with doing a certain background operation.

The initial implementation of the API uses the budget system to allow push messages to be handled by service workers without always showing a notification. (Which is also known as silent push.)

Motivation

Web Applications can take many actions while a browser tab is open, and users associate the presence of a browser tab with the Web Application’s ability to do work on their behalf. However, with the Push API service workers can execute code in the background, outside of the user’s control or visibility.

It’s the user agent’s responsibility to find the right balance between giving powerful features to developers, and protecting the user. Both Chrome and Firefox already do this internally, and by implementing this API we hope to find the right way to explain to developers exactly what they’re allowed to do.

Interoperability and Compatibility Risk

The implementation provides a new API, so no issues with existing APIs.  We intend to evolve the API based on feedback from developers and other implementations. Incidentally, our implementation of budget (as Site Engagement Score) already is fairly similar to Firefox’.

Ongoing technical constraints

None

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

Yes

OWP launch tracking bug

http://crbug.com/629587

Link to entry on the feature dashboard

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

Requesting approval to ship?

No

[Rick Byers]

Looks exciting!  I know this is a complex and contentious space, but it's also of critical importance to getting the web platform closer to matching the capabilities of native mobile platforms without hurting users confidence in the risk associated with viewing a web page.

Once thing that would help me to better evaluate the risk tradeoff here is some document (maybe in the spec?) that compares the vision here to what's been done already in other successful mobile platforms.  iOS in particular is pretty strict about doing work in the background, right?  Does iOS expose enough information today that our model could be implemented there (i.e. by the Safari team) without OS modifications?  Should that be a goal or non-goal of the design?

[Jen Harkness]

I'm glad you're excited! Doing this in a way that benefits users is definitely my number one concern, but I think we can do that and at the same time enhance the platform.

In terms of background operations and how different platforms deal with them, there are two layers to it: the operating system flexibility, and the user agent capabilities. I don't think a discussion of that belongs in the spec itself, but I'm happy to write up a comparison and post it alongside the spec. 

I'll get the document written up and posted, and then I'l post a link in this thread.

[Rick Byers]

Sounds great, thank you!

[Jen Harkness]

There's a mistake in the original Intent, the bug linked should be  crbug.com/617971.

The document is on the way!

[Jen Harkness]

Document is now posted at https://github.com/beverloo/budget-api/blob/gh-pages/BackgroundOperationComparison.md