Review request for Push API

[triblondon]

From @LJWatson:

I'm requesting a TAG review of:

• Name: Push API
• Specification URL: https://www.w3.org/TR/push-api/
• Explainer, Requirements Doc, or Example code: No explainer
• Primary contacts: @LJWatson

Further details (optional):

• Relevant time constraints or deadlines: Review originally requested for 16 June on the mailing list
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[chaals]

Please consider carefully that user agents effectively requiring a single push service may introduce concerns related to privacy and security, as well as internationalisation given the realistic scenario that a "standard" service may be unavailable regionally. The asserted design trade-off is against efficiency for power consumption.

It would be helpful to understand whether the TAG supports this sort of design, and what should be taken into account in determining the trade-off between power consumption and user privacy and security.

[torgo]

Comments from f2f: no explainer...

[LJWatson]

Thanks for looking at this. Do you think comments by 31st July might be possible?

[triblondon]

@LJWatson we are looking at this now.

[cynthia]

I tend to pick a lot of nits and couldn't find any to pick.

[triblondon]

Overall we have no substantive feedback, and the API looks great. On the push service relationship with the browser:

• We acknowledge the need that browsers and OSes have expressed in minimizing the number of background wake-ups which have a detrimental effect on battery life. This concern has led to nearly all mobile OSes minimizing the number and diversity of push backends. Allowing sites to select their own services would make it difficult to mediate this delicate balance.
• If the user is to be offered a choice of push services (and we note there's nothing in the spec to preclude this), the choice must be made a meaningful one, and we are not sure how this might be achieved, or indeed whether it is possible.
• We note that the provision of an effective, usable push service is an area in which browsers can compete, and therefore there is an incentive for the service to be well maintained.