The idea behind this is awesome (although we already have this for some platforms - e.g. https://developer.apple.com/library/mac/documentation/Networ...)

But the API looks over-engineered. e.g.

navigator.serviceWorker.ready.then(function(serviceWorkerRegistration) {

serviceWorkerRegistration.pushRegistrationManager.register().then(...

Whether this is a good thing or not is another question I don't know the answer to.

A manager object/class also usually rings a bell.

Not that I'm an API specialist but I would rather implement it as:

document.addEventListener("serviceready", function() {

window.pushNotification.register().then(.....

    navigator.serviceWorker.ready.then(function(){...

    document.addEventListener("serviceready", function() {

> > A push service allows a webapp server to send messages to a webapp, regardless of whether the webapp is currently active on the user agent.

Actually, the difference you describe is what Server-Sent Events [1] already provide: one-way notifications vs bidirectional communication with websockets.

This spec, rather, would standardize an API for a single-connection (read: better battery life) push server that third party webapps can use in the same way Google Cloud Messenger is used by third-party application servers for android apps.

[1] http://www.w3.org/TR/eventsource/

But from an end-user perspective I fear that it will lead too various "features" hogging resources. I would assume I could block them client-side, but I'm also the family-tech and quite frankly I don't expect my grandparents to do the same.

I share your concern. but I share a great fear that web apps will become increasingly irrelevant if they remain just documents that can't do anything when they're not explicitly in a running tab/window.

The permission requirement is the same one that allows for local storage, which could have caused great problems, but has so far held up well.

Assuming this does not allow the push of UI interaction, then yes. If it would allow UI responses to be pushed then we would be one XSS vulnerability or "uneducated users" away from a new set of exploits for forcing pop-under advertising , and other potentially more insidious problems, through.

Local Storage and Index DB are storage only so the only attack routes are DoS-due-to-disk-full-errors which is generally less attractive (you can make more money pushing stuff to people than pushing people off the network).

Or is the option to include that choice going to be left to site designers?

The questions you keep asking are basic things solved by reading the article - you seem to have concerns, but you haven't done the minimum amount of work necessary to determine whether your concerns are valid.