The browser and the web server should negotiate an encryption key, or set of encryption keys during setup, and any push messages signed and encrypted. That way, any third party push provider can't inpect the messages.

Also, pigs should learn to fly.

Encryption is still totally doable, as the client can negotiate directly with the service provider and then hand off to the single-socket push provider who would only see encrypted messages. You'd need metadata readable by the push server, however, so it can deliver messages to the right client.

Push messages already exist via Server-Sent Events [1]. This would simply standardize a less resource intensive single-connection model that third parties can interact with.

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

So when I want to push a message out to one of my users, the push software I am using will handle encrypting it, and the push software on the users device will handle decrypting it. They will both be aware of the encryption keys involved because they will have negotiated them during the initial direct connection and will have them stored.

> 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

So you can send push notifications to a user even if they don't have a tab open to your website.

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.

This has the potential to create cool and useful stuff, of course, but (IMO) it will be used mostly for advertising. Guess who's around the spec? Google and two telcos, of course.

Of course, it will need user approval, so the problem is (I hope) minimized (but just wait for the amount of Google+ "friend invites" notifications you will receive, even if you visited it only once).

For instance, the more traditionally native features webapps take on, the less reason I have to need a native app hence am less coupled to a platform. I have always been a bit apprehensive to native apps because of platform lockin and it feels like this plus some of the push from google and their upcoming iot url push system makes it feel like web standards might really make webapps as common/popular/featured(or more) as native. It has plenty of kinks to work out around not being too spammy/sneaky with permissions but overall it feels like this is a major advancement for the web as a platform - assuming the big platform players implement it well.

You define everything with text and it renders a diagram based on what you've written. It's kind of like the dot/Graphviz of sequence diagrams.

You could also try yED. http://www.yworks.com/en/products/yfiles/yed/

EDIT: This site has a nice list of a bunch of software that you can check. http://alternativeto.net/software/dia/

Like what the hell does that mean?

Please explain.

Usually it is a concise or dramatic means to demonstrate something, but not adherent to the norms of that context.

For example, pouring petrol over a sofa and igniting it to demonstrate its fireproof attributes. Not normal behaviour but useful as a demonstration.