Comment by drdaeman | Hacker News Reader

Comment by drdaeman | Hacker News Reader

Is there any short explanation how this works under the hood?

Does the browser maintain an open connection (like a Websocket) for each subscription, or there are some brokers, or if it can use OS facilities (like GCM/APN on mobile) when available, etc etc.

In particular, I'm curious of privacy implications. When I subscribe - what site knows of me (say, if that's a direct connections, I'm not sure I want to tell every site out there when I'm online), or if any third parties are involved - what they know and do (say, what's about sender and receiver authentication)?

From what I saw (but really not sure I got it right), it seems that I have to trust browser vendor and maintain a live connection to some Mozilla server, that'd listen for events (POSTs from sites) and aggregate them for me. But I'm not sure I understood it correctly.

I'll surely investigate this properly, but reading standards is tough, and end-user introductions written by marketing people are virtually useless. So I wonder if there's a short reading to get the overall picture quick, but still see all the important details.

I believe my article on Hacks (https://hacks.mozilla.org/2016/01/web-push-arrives-in-firefo...), linked from the marketing article, answers all of those questions at a high level and points to docs with more detail.

In short, there's a single, persistent websocket connection between you and a broker service run by your browser vendor. Each subscription has a unique, anonymous URL on that service that gets provided to the website. To prevent abuse, there are throttles / quotas / limits imposed on push messages that do not show user-visible notifications.

The source to Mozilla's broker, autopush, is at https://github.com/mozilla-services/autopush. We recently rewrote it from Go into Python, which we now run with PyPy in production.

> We recently rewrote it from Go into Python

I am used to porting things the other direction; can I ask why you moved to Python for this service?

Ben Bangert has given a presentation about this that was discussed here: https://news.ycombinator.com/item?id=10402307

The above links to the slides only, here is a video of the talk: https://www.youtube.com/watch?v=_F2peRzJzhU

Like the sibling comment, I'm also interested in learning about your switch.

>> I'm curious of privacy implications.

> a broker service run by your browser vendor

That means that Mozilla, as an example of a browser vendor, knows anything any site which uses that feature wants to notify me, including mails and messages from those sites?

All data brokered by the service must be encrypted to a keypair whose private key is held only by the end user's browser, using the scheme described in the webpush-encryption IETF draft spec at https://tools.ietf.org/html/draft-ietf-webpush-encryption-01

Thanks for all your comments!

I wonder about metadata, though. While Mozilla doesn't know the contents of messages, it's still generally well aware of who (sender IP) is sending messages to whom (receiver IP) - is that correct?

(I suppose this can be somewhat mitigated by running private self-hosted autopush instance and replacing dom.push.serverURL)

> Is there any short explanation how this works under the hood?

Yes, the spec is the most detailed description of what goes on under the hood and it's not too long: https://www.w3.org/TR/push-api/, but here's my attempt at answering each of your questions:

> Does the browser maintain an open connection (like a Websocket) for each subscription, or there are some brokers, or if it can use OS facilities (like GCM/APN on mobile) when available, etc etc.

Yes. Chrome maintains an open connection to Google's push servers, Firefox maintains an open connection to Mozilla's push servers.

> In particular, I'm curious of privacy implications. When I subscribe - what site knows of me (say, if that's a direct connections, I'm not sure I want to tell every site out there when I'm online), or if any third parties are involved - what they know and do (say, what's about sender and receiver authentication)?

The Push connection itself would not reveal whether you are online since it's made to Google/Mozilla and not other individual sites, however the presence of a Service Worker could be used to determine this. For example, a website could send a background notification and check your network connectivity from the Service Worker without necessarily showing you a visible notification. This is already true for push notifications most people already receive from mobile apps.

A common use for these kinds of background notifications would be to do background data loading (such as loading new email messages to view later offline).

Since this does use Service Workers, it's also important to point out that everything needs to be handled via HTTPS for Service Workers to work. [1]

[1] https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

Firefox implements a quota system that restricts how many notifications may be sent "without user interaction". This is to reduce the likelihood that one could use this effectively for background tracking and to ensure you won't be swarmed with a gazillion of them if an application server has some bugs on sending notifications.

Bugzilla ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1153504

Reply on news.ycombinator.com