Intent to Ship: The Budget API’s reserve() method

[Peter Beverloo]

Contact emails

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

Spec

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

https://github.com/WICG/budget-api#web-budget-api

Summary

The Budget API grants developers a budget, based on Site Engagement Score, that can be spent on certain background operations such as receiving push messages without showing notifications. (Which will continue to require the user’s permission.)

The reserve() method decisively tells a developer whether they are able to do, or not do something. For Push Notifications, it enables them to verify whether a notification has to be shown when receiving a push message.

This should help to significantly drive down the number of generic “we have an update for you” notifications that websites show as a final effort when the contents for the Push Notification cannot be determined, for example because of poor networking conditions.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/I3FhKqtui_k/discussion

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

All but Android WebView. This is because the Budget API is tightly coupled with the Site Engagement Score, which is only available in the //chrome layer. (Having many dependencies.)

Interoperability and Compatibility Risk

Whereas we’ve proposed to experiment with the rest of the Budget API, we’d like to ship this immediately.

The method adds a cheap, clear way for sites employing Push Notifications to improve their user experience, by not showing low value notifications when they don’t have to. Given that there are many high traffic websites that use Push Notifications, this will bring significant improvements to users.

The exposed method is very simple and returns a Promise that indicates whether budget could be reserved or not. In a situation where we’d have to move away from this method we can safely always make it return `false`.

Edge: No public signals

Firefox: No public signals

Safari: No public signals

Web developers: Positive

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=704725

Entry on the feature dashboard

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

[Chris Harrelson]

Hi, a question inline below.

Could you point to the places where discussion/outreach with other browsers has occurred, and examples of web developer feedback?

 

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=704725

Entry on the feature dashboard

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

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

[Peter Beverloo]

Mostly at the WICG: https://discourse.wicg.io/t/proposal-budget-api/1717

The Push API, currently the main beneficiary of this API, has only been shipped on Chrome and Firefox. The model has been designed with their budget system in mind, but my understanding is that they're not currently scheduling an implementation in favor of higher priority projects.

An example of a developer requesting this is the following Stack Overflow page:

http://stackoverflow.com/questions/33092065/google-chrome-silent-push-notifications

In practice, many developers have code in their Service Worker to show a low-quality, generic notification when fetching more relevant data fails, for example because the user loses connectivity. Nobody likes those. The reserve() method enables taking them away, although admittedly that is about the functionality it enables as opposed to the API itself. That's why we'd separately like to experiment with the two methods that enable them to make this decision over a window of time.

Thanks,

Peter

[Philip Jägenstedt]

My guess is that the largest risk is that not all implementation have an internal notion of per-origin background budget, and thus don't have the underpinnings for this API. There is positive feedback from Gecko, have you prodded WebKit and Edge folks for reactions?

A recent addition to the Intent to Ship template is this section:

Is this feature fully tested by web-platform-tests?

Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to issues, e.g.:

• A web-platform-tests issue with the "infra" label explaining why a certain thing cannot be tested. (example)

• A spec issue for some change that would make it possible to test. (example)

• A Chromium issue to upstream some existing tests. (example)

Such issues are not blocking in an Intent to Ship.

This looks to me like an API that falls into the first category and cannot be tested without test automation APIs (WebDriver or internal), but can you file the appropriate issues?

P.S. I noticed a trivial mismatch between spec and implementation that would be good to fix spec-side:

https://github.com/WICG/budget-api/issues/9

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

[Peter Beverloo]

Hi Philip,

See in-line.

On Mon, Apr 10, 2017 at 2:05 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

My guess is that the largest risk is that not all implementation have an internal notion of per-origin background budget, and thus don't have the underpinnings for this API. There is positive feedback from Gecko, have you prodded WebKit and Edge folks for reactions?

We've designed the API to be flexible for a variety of backends. We've also asked the other vendors for more data, but have nothing we can publicly share I'm afraid.

A recent addition to the Intent to Ship template is this section:

Is this feature fully tested by web-platform-tests?

Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to issues, e.g.:

• A web-platform-tests issue with the "infra" label explaining why a certain thing cannot be tested. (example)

• A spec issue for some change that would make it possible to test. (example)

• A Chromium issue to upstream some existing tests. (example)

Such issues are not blocking in an Intent to Ship.

This looks to me like an API that falls into the first category and cannot be tested without test automation APIs (WebDriver or internal), but can you file the appropriate issues?

Yes, indeed. However, as the Budget API in itself is a generalisation, any testing infrastructure would be very targeted towards supporting the ability to test this speciifc API. Is the intention for the web-platform-tests issue tracker to track such cases too?

P.S. I noticed a trivial mismatch between spec and implementation that would be good to fix spec-side:

https://github.com/WICG/budget-api/issues/9

Thank you! I have sent you a PR to address the issue.

Thanks,

Peter

 

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

[Philip Jägenstedt]

On Wed, Apr 12, 2017 at 7:27 AM Peter Beverloo <pe...@chromium.org> wrote:

Hi Philip,

See in-line.

On Mon, Apr 10, 2017 at 2:05 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

My guess is that the largest risk is that not all implementation have an internal notion of per-origin background budget, and thus don't have the underpinnings for this API. There is positive feedback from Gecko, have you prodded WebKit and Edge folks for reactions?

We've designed the API to be flexible for a variety of backends. We've also asked the other vendors for more data, but have nothing we can publicly share I'm afraid.

This intent is about navigator.budget.reserve(), but I'll now ask a bit about the Budget API as a whole, as I think we cannot consider it completely independently. (Shipping only reserve() in the long term would be somewhat odd.)

Can you file an issue at https://github.com/w3ctag/spec-reviews/issues so that TAG review is complete before Intent to Ship for the Budget API as a whole?

BackgroundOperationComparison.md is good document, showing that iOS has some model for background execution. However, from a superficial reading it doesn't take the shape of a single budget that an app can spend. Rather, it seems to be a per-feature thing. For the generic background task, it sounds like there's a time limit. For downloads, it sounds like starting it in the foreground is the requirement, making it more like the web's user gesture requirements for some APIs.

The Budget API is explicitly based on user engagement, which is still a fairly new thing in Chrome and I don't know if it exists in Edge and Safari. The interop risks are then roughly:

• Other vendors don't have a per-origin budget, concept and don't feel they need it to provide a compelling user experience.
• A per-origin budget may not map to how the underlying OS grants permission for various background operations.

Doubts like these aren't actionable, feedback from EdgeHTML and WebKit engineers would be much better. Did you poke them in a public forum? Doing that, also poking via private channels, and then giving them a week would be reasonable I think. Would it be a problem if this misses the M59 branch point?

Other API owners, please weigh in here.

A recent addition to the Intent to Ship template is this section:

Is this feature fully tested by web-platform-tests?

Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to issues, e.g.:

• A web-platform-tests issue with the "infra" label explaining why a certain thing cannot be tested. (example)

• A spec issue for some change that would make it possible to test. (example)

• A Chromium issue to upstream some existing tests. (example)

Such issues are not blocking in an Intent to Ship.

This looks to me like an API that falls into the first category and cannot be tested without test automation APIs (WebDriver or internal), but can you file the appropriate issues?

Yes, indeed. However, as the Budget API in itself is a generalisation, any testing infrastructure would be very targeted towards supporting the ability to test this speciifc API. Is the intention for the web-platform-tests issue tracker to track such cases too?

Yes, that's fine, the type:missing-coverage label is used for lots of specific APIs. In this case, an issue with that label and the infra label seems appropriate, tracking both that tests are missing, and why they cannot easily be added.

[Jochen Eisinger]

I wonder whether shipping reserve() is the right call before the other methods are ready. 

The developer feedback you pointed to asks for silent push notifications, not for the budget API's reserve method in particular, right?

Have you reached out to the privacy team about this API in general? Won't we essentially expose an API for a site to query its own site engagement score (which you could consider cookie-like?)

[Rick Byers]

On Wed, Apr 12, 2017 at 3:29 AM, Jochen Eisinger <joc...@chromium.org> wrote:

I wonder whether shipping reserve() is the right call before the other methods are ready. 

IMHO there's a lot of details here to work out that ideally we wouldn't feel too rushed on.  Personally I think the interop risk is lower by shipping reserve now and waiting for more consensus between engines on the other aspects of the API, then if we tried to ship a larger chunk of the API sooner.

If the main urgency we're feeling for budget can be addressed by 'reserve', I'd personally rather ship the minimal thing for that first and iterate from there.  Worst case and the budget model changes, reserve is so simple that it probably still makes sense (and worst case is just confusingly named).  This seems like the sort of "ship the MVP and iterate" model we (especially slightlyoff@) have encouraged elsewhere.

 

The developer feedback you pointed to asks for silent push notifications, not for the budget API's reserve method in particular, right?

Budget.reserve is all that's necessary to enable silent-push, right?  So I think feedback requesting to know whether Chrome would show the scary default notification or not does represent demand for this API.

Have you reached out to the privacy team about this API in general? Won't we essentially expose an API for a site to query its own site engagement score (which you could consider cookie-like?)

On Wed, Apr 12, 2017 at 8:52 AM Philip Jägenstedt <foo...@chromium.org> wrote:

On Wed, Apr 12, 2017 at 7:27 AM Peter Beverloo <pe...@chromium.org> wrote:

Hi Philip,

See in-line.

On Mon, Apr 10, 2017 at 2:05 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

My guess is that the largest risk is that not all implementation have an internal notion of per-origin background budget, and thus don't have the underpinnings for this API. There is positive feedback from Gecko, have you prodded WebKit and Edge folks for reactions?

We've designed the API to be flexible for a variety of backends. We've also asked the other vendors for more data, but have nothing we can publicly share I'm afraid.

This intent is about navigator.budget.reserve(), but I'll now ask a bit about the Budget API as a whole, as I think we cannot consider it completely independently. (Shipping only reserve() in the long term would be somewhat odd.)

Can you file an issue at https://github.com/w3ctag/spec-reviews/issues so that TAG review is complete before Intent to Ship for the Budget API as a whole?

BackgroundOperationComparison.md is good document, showing that iOS has some model for background execution. However, from a superficial reading it doesn't take the shape of a single budget that an app can spend. Rather, it seems to be a per-feature thing. For the generic background task, it sounds like there's a time limit. For downloads, it sounds like starting it in the foreground is the requirement, making it more like the web's user gesture requirements for some APIs.

The Budget API is explicitly based on user engagement, which is still a fairly new thing in Chrome and I don't know if it exists in Edge and Safari. The interop risks are then roughly:

• Other vendors don't have a per-origin budget, concept and don't feel they need it to provide a compelling user experience.
• A per-origin budget may not map to how the underlying OS grants permission for various background operations.

Doubts like these aren't actionable, feedback from EdgeHTML and WebKit engineers would be much better. Did you poke them in a public forum? Doing that, also poking via private channels, and then giving them a week would be reasonable I think. Would it be a problem if this misses the M59 branch point?

Other API owners, please weigh in here.

I think reaching out in some way (public or private) to ask someone from each of the other engines to weigh in on the public discussion and waiting a week is our typical min-bar for something like this, right?  Peter, have you asked for feedback in any form from WebKit and EdgeHTML?

It does look like there's support from Gecko for exploring the space along these lines, but perhaps we should ask one of those people explicitly whether they have any specific concerns with us shipping 'reserve' as-is?  +Marcos.

[Peter Beverloo]

The discussion boils down to whether it's a good idea to ship reserve(), which does not have to depend on the concept of having a budget, separately of the other two methods which do depend on it. That's a bit unfortunate as they enable different things and come with very different risks.

Would it help if we were to focus the specification and feature on the functionality provided by reserve(), and move the other two methods to a future version when the interests of other vendors are more clear?

More answers in-line. The action items for filing a WPT bug and TAG review carry over.

On Wed, Apr 12, 2017 at 12:04 PM, Rick Byers <rby...@chromium.org> wrote:

On Wed, Apr 12, 2017 at 3:29 AM, Jochen Eisinger <joc...@chromium.org> wrote:

I wonder whether shipping reserve() is the right call before the other methods are ready. 

IMHO there's a lot of details here to work out that ideally we wouldn't feel too rushed on.  Personally I think the interop risk is lower by shipping reserve now and waiting for more consensus between engines on the other aspects of the API, then if we tried to ship a larger chunk of the API sooner.

If the main urgency we're feeling for budget can be addressed by 'reserve', I'd personally rather ship the minimal thing for that first and iterate from there.  Worst case and the budget model changes, reserve is so simple that it probably still makes sense (and worst case is just confusingly named).  This seems like the sort of "ship the MVP and iterate" model we (especially slightlyoff@) have encouraged elsewhere.

This is exactly why we were hoping that it'd be safe enough to ship reserve(). Even if the budget model does not turn out to be applicable to all other vendors, it's provides a boolean answer to a can-I-do-this-thing question that can be backed by anything.

The rest of the Budget API is much less clear, which is why experimentation only makes a lot more sense there. There's many things we have to learn.

 

The developer feedback you pointed to asks for silent push notifications, not for the budget API's reserve method in particular, right?

Budget.reserve is all that's necessary to enable silent-push, right?  So I think feedback requesting to know whether Chrome would show the scary default notification or not does represent demand for this API.

Yes, the feedback is about knowing whether Chrome would show its default notification, this API provides an answer to that question, and future similar questions too.

Silent push requires some knowledge of whether the next message(s) will also need to show a notification. In most silent push use-cases it's too late to make that decision when the message has already been received by the device.

Have you reached out to the privacy team about this API in general? Won't we essentially expose an API for a site to query its own site engagement score (which you could consider cookie-like?)

Yes, a privacy review is in progress.

 

On Wed, Apr 12, 2017 at 8:52 AM Philip Jägenstedt <foo...@chromium.org> wrote:

On Wed, Apr 12, 2017 at 7:27 AM Peter Beverloo <pe...@chromium.org> wrote:

Hi Philip,

See in-line.

On Mon, Apr 10, 2017 at 2:05 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

My guess is that the largest risk is that not all implementation have an internal notion of per-origin background budget, and thus don't have the underpinnings for this API. There is positive feedback from Gecko, have you prodded WebKit and Edge folks for reactions?

We've designed the API to be flexible for a variety of backends. We've also asked the other vendors for more data, but have nothing we can publicly share I'm afraid.

This intent is about navigator.budget.reserve(), but I'll now ask a bit about the Budget API as a whole, as I think we cannot consider it completely independently. (Shipping only reserve() in the long term would be somewhat odd.)

Can you file an issue at https://github.com/w3ctag/spec-reviews/issues so that TAG review is complete before Intent to Ship for the Budget API as a whole?

BackgroundOperationComparison.md is good document, showing that iOS has some model for background execution. However, from a superficial reading it doesn't take the shape of a single budget that an app can spend. Rather, it seems to be a per-feature thing. For the generic background task, it sounds like there's a time limit. For downloads, it sounds like starting it in the foreground is the requirement, making it more like the web's user gesture requirements for some APIs.

The Budget API is explicitly based on user engagement, which is still a fairly new thing in Chrome and I don't know if it exists in Edge and Safari. The interop risks are then roughly:

• Other vendors don't have a per-origin budget, concept and don't feel they need it to provide a compelling user experience.
• A per-origin budget may not map to how the underlying OS grants permission for various background operations.

Together with the possibility of having per-feature budgets, yes, this describes the situation. Thank you!

Doubts like these aren't actionable, feedback from EdgeHTML and WebKit engineers would be much better. Did you poke them in a public forum? Doing that, also poking via private channels, and then giving them a week would be reasonable I think. Would it be a problem if this misses the M59 branch point?

Other API owners, please weigh in here.

I think reaching out in some way (public or private) to ask someone from each of the other engines to weigh in on the public discussion and waiting a week is our typical min-bar for something like this, right?  Peter, have you asked for feedback in any form from WebKit and EdgeHTML?

Yes, we have, but unfortunately there's nothing to share, so we'll have to consider this as no public feedback.

Thanks,

Peter

[owe...@google.com]

TL;DR - I'm supportive of shipping reserve() now while experimenting with the more complex portions of the API.

As Peter says, we've spoken to some of the other browser vendors and we will keep attempting to get a public statement, but based on those interactions we feel comfortable shipping the reserve method.

In terms of functionality, the reserve() method allows developers to solve the issue of users seeing 'example.com has been updated in the background' notifications. Given the number of notifications are shown per day, this is a really big win. It also allows developers to start experimenting with silent push even before the rest of the API becomes available.

In summary, I think the value of shipping this weighted against the risk is well balanced in this case (as Peter says, in the worst worst case scenario this API can be set to return false and won't introduce any breakage).

Thanks

[Philip Jägenstedt]

On Wed, Apr 12, 2017 at 6:04 PM Rick Byers <rby...@chromium.org> wrote:

On Wed, Apr 12, 2017 at 3:29 AM, Jochen Eisinger <joc...@chromium.org> wrote:

I wonder whether shipping reserve() is the right call before the other methods are ready. 

IMHO there's a lot of details here to work out that ideally we wouldn't feel too rushed on.  Personally I think the interop risk is lower by shipping reserve now and waiting for more consensus between engines on the other aspects of the API, then if we tried to ship a larger chunk of the API sooner.

If the main urgency we're feeling for budget can be addressed by 'reserve', I'd personally rather ship the minimal thing for that first and iterate from there.  Worst case and the budget model changes, reserve is so simple that it probably still makes sense (and worst case is just confusingly named).  This seems like the sort of "ship the MVP and iterate" model we (especially slightlyoff@) have encouraged elsewhere.

By shipping navigator.budget.reserve("silent-push"), we are anticipating that we will eventually want to ship navigator.budget.reserve("something-else") and navigator.budget.somethingElse(), or the shape of the API would be different.

Having no signals at all for Edge or Safari, it's not a given that they have/want a notion of a shared budget for all background operations, but we would have a strong incentive to keep going with navigator.budget.*. (I'm skeptical that we would just live with the confusing name and go off to pursue another model.)

I think reaching out in some way (public or private) to ask someone from each of the other engines to weigh in on the public discussion and waiting a week is our typical min-bar for something like this, right?  Peter, have you asked for feedback in any form from WebKit and EdgeHTML?

This expectation isn't documented AFAIK, and looking back at past intents it's easy to find "no signals" with no questions asked. In most cases I think this isn't a problem, I asked in this case only because the model was tied to a new thing (user engagement) in Chrome that others might not have/want.

A renewed and explicit request for feedback in a place like https://github.com/WICG/budget-api/issues/ referencing this issue would be good. If that's already happened in another public forum, or if a new request times out, then I think we should ship the thing we want.

[Rick Byers]

I agree it makes sense to apply some extra care here since we're introducing an API shape that really implies the existence of a new model (that's also why I wanted to double check with Marcos to make sure Mozilla was still comfortable with the basic shape).

It's a 4-day Easter holiday in Canada and then I'm travelling for a week so I'm going to proactively LGTM1 now under the assumption we won't get any specific concerns with the basic model from Mozilla or other vendors. 

Rick

[Rick Byers]

API owners met today and discussed this.  Since we don't have any public signals on shipping this specific API from other vendors and there's some concern on whether the model will make sense for other browsers, we believe we should try to get a TAG review on the overall API design.  So please file a request for a TAG review.

However we're OK with optimistically shipping for M60 under the assumption that TAG (or other vendors) aren't likely to have a major concern with just the 'reserve' method.  So LGTM3 to ship in M60 after the TAG review request is filed.  But please circle back here if there are concerns from TAG or other vendors that would pose a compat risk for us shipping reserve.  If necessary we can always revert from M60 to give more time for discussion if useful discussion is happening.

[owe...@google.com]

Thanks for the guidance Rick!

We'll attempt to work with TAG and other vendors to get a public signal here.

FWIW we're going to try to rush and get something by next week which would still allow us to ship in 59 (enabling or disabling is a very small merge), but if that's not possible then we'll retarget for 60.

Thanks!

[Rick Byers]

Thanks Owen.  The feedback from API Owners was that we believe we need more time than M59 would afford to get and consider feedback on this question.  If we're going to request input from TAG on this, it doesn't really seem fair to merge for an accelerated ship schedule.  WDYT?

By the way, I forgot to mention that the LGTMs came from chrishtr@, jochen@ and myself.