5 ms·

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 a

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.

callahad 11y ago
I believe my article on Hacks (https://hacks.mozilla.org/2016/01/web-push-arrives-in-firefox-44/ 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 https://github.com/mozilla-services/autopush. We recently rewrote it from Go into Python, which we now run with PyPy in production.
- fancy_pantser 11y ago
  > 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?
  - rhelmer 11y ago
    Ben Bangert has given a presentation about this that was discussed here: https://news.ycombinator.com/item?id=10402307 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 https://www.youtube.com/watch?v=_F2peRzJzhU
- silviogutierrez 11y ago
  Like the sibling comment, I'm also interested in learning about your switch.
- acqq 11y ago
  >> 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?
  - callahad 11y ago
    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 https://tools.ietf.org/html/draft-ietf-webpush-encryption-01
    - deleted 11y ago
      [deleted]
    - drdaeman 11y ago
      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)
gdeglin 11y ago
> 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/ 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).
- mtberatwork 11y ago
  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_Worker_API/Using_Service_Workers https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
- windlep 11y ago
  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 https://bugzilla.mozilla.org/show_bug.cgi?id=1153504

callahad 11y ago

I believe my article on Hacks (https://hacks.mozilla.org/2016/01/web-push-arrives-in-firefox-44/ 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 https://github.com/mozilla-services/autopush. We recently rewrote it from Go into Python, which we now run with PyPy in production.

fancy_pantser 11y ago
> 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?
- rhelmer 11y ago
  Ben Bangert has given a presentation about this that was discussed here: https://news.ycombinator.com/item?id=10402307 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 https://www.youtube.com/watch?v=_F2peRzJzhU
silviogutierrez 11y ago
Like the sibling comment, I'm also interested in learning about your switch.
acqq 11y ago
>> 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?
- callahad 11y ago
  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 https://tools.ietf.org/html/draft-ietf-webpush-encryption-01
  - deleted 11y ago
    [deleted]
  - drdaeman 11y ago
    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)

gdeglin 11y ago

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

mtberatwork 11y ago
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_Worker_API/Using_Service_Workers https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
windlep 11y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1153504