

Push API – W3C Working Draft - sinak
http://www.w3.org/TR/2014/WD-push-api-20141007/#example

======
mike-cardwell
This should have mandatory crypto built in from the beginning so that third
party push providers can be used without causing privacy/security concerns.

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.

~~~
andrewstuart2
I think the whole point of the spec _is_ third-party push servers, a la GCM.

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/](http://www.w3.org/TR/eventsource/)

~~~
mike-cardwell
Yes, you can already add your own encryption on top of the push system. What I
was proposing is that it is standardised and doesn't require any extra code
from the application developer.

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.

------
swartkrans
The push API is pretty awesome, the key difference between it and websockets
in term of what it offers is this bit:

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

~~~
SynchrotronZ
I'm... not sure I want this. It sounds pretty useful/fun form a programmers
perspective.

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.

~~~
mmahemoff
"User agents must not provide Push API access to webapps without the express
permission of the use"

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.

~~~
dspillett
_> The permission requirement is the same one that allows for local storage_

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

------
Beltiras
It's great that there are some standardization efforts in this space but for
this to be useful we would need wide coverage of clients implementing it.
Stuck using websockets for the next decade I suppose ....

------
millisecond
This (and current Safari support) is what we (Roost -
[https://goroost.com](https://goroost.com) \- YCS14) are building off. Moving
toward a complete web-push suite that supports all browsers on both desktop
and mobile. Long road in front of us, but it's going to be an exciting world.

------
paulojreis
What I find particularly interesting in the spec is the editors list.

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.

~~~
tokenizerrr
I'm not sure how this would be used for advertising? This is about pushing
messages to the user agent when it is not actively visiting a page. Ads are
actively requested when you view a page, there is no need for push there.

~~~
paulojreis
So "they" can reach you, even if you don't visit. I guess it will be used to
"remind" or notify you of all new posts/entries/content/everything. From
there, it can move fast to notifying you about a new sponsor (or just saying
who sponsored the new post).

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

------
Animats
The client has to have a TCP connection open to the server for this to work,
right? Otherwise you run into all the problems of trying to reach machines
behind DHCP, firewalls, etc.

~~~
swartkrans
That detail is implementation dependent. The site that wants to push to your
browser hits up a third party push service provider that the user uses to get
push notifications. That will probably Apple for iOS and Safari, Google for
Chrome and Android, and I'm guessing Mozilla might provide one, as well as a
host of other smaller companies that might be interested.

------
dmritard96
the interesting question for me is what this means for the big players and
their respective platforms.

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.

------
joneil
It's good to see this in the works. Some of the apps I build are simple enough
that a web-app is sufficient for almost everything, except that users really
want push notifications. If this API becomes implemented (widely enough)
that's one less thing we need PhoneGap and friends for.

~~~
millisecond
Hey, check us (Roost YCS14) out at [https://goroost.com](https://goroost.com)
\- we already do this in a way that will abstract the browser part so you
don't have to change anything once the other non-Safari browsers come online.

------
Too
OT: Does anyone know what software was used to create those sequence diagrams?

~~~
DanBC
If you want free / open source you could look at Dia. [http://dia-
installer.de/index.html.en](http://dia-installer.de/index.html.en)

You could also try yED.
[http://www.yworks.com/en/products/yfiles/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/](http://alternativeto.net/software/dia/)

~~~
grap
The list from your edit is great. I didn't even know that alternativeto.net
existed.

------
arihelgason
Any word on when browsers other than Safari will be supporting push
notifications?

~~~
millisecond
FWIW, I've hearing "late this year" and "early next year" from some contacts.

------
robbytwashere
'This section is non-normative'

Like what the hell does that mean?

Please explain.

~~~
nhaehnle
It means that this section contains example code, but is not actually part of
the standard. From an operative point of view, this means that if it conflicts
with anything else in the document, the "anything else" takes precedence.

