Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple and Google Monitor Notifications. We Need Push Notification Alternatives

tuta.com

Post reply on HN
Print view View original

11–20 of 67 posts

Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives

#11

Post by phh »

> Final thought: Every user should be able to choose a "Notification Provider" for every app

That is too much I think? It would be weird to trust one notification provider for some stuff, and another one for others? Every user should be able to choose a "Notification Provider" is IMO enough.

On that front, there is already a push standard which is called WebPush which allows to do this seemlessly. Except it's only in browsers (also I don't think any major browser allows customizing it?). On non-Google Android, you have UnifiedPush. (It isn't a standard. Not sure it would make sense to make a standard of an Android API?)

I've been thinking of making a OwnerOS: a bare Android who lets users pick every component they want. You select which store you want, which assistant you want, which notification provider you want, which SystemUI you want etc. All of which currently require to root your device to customize.

Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives

#12

Post by fmajid »

olliej wrote: post #6

People really don't understand the attack here. It does not matter who is providing the notification service. No amount of encryption (actual E2EE encryption) prevents that ability for a government agency or criminal enterprise to functionally compromise the service to determine which users are getting push notifications from which other users or services. It also does not matter if you use push notifications (which…

There are systems like MIT's Alpenhorn and Vuvuzela that protect metadata like push notifications by using encryption and deliberately adding noise to foil traffic analysis. Notably both sender and receiver are kept private and you do not need an out-of-band key exchange mechanism to initiate communications for the first time.

Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives

#13

Post by geckbench »

The pushing services must be running in the background constantly to provide the push notification services. This is how apps can receive notifications without even running it.

If every app uses its own push notification services, an average consumer may end up with half dozens of those notification agents running consuming more RAM and battery life. For Android devices this might be OK (8-16GB RAM nowadays) but for Apple, this may not even be possible for its RAM size (<=8GB).

Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives

#16

Post by HowardStark »

WesolyKubeczek wrote: post #5
raggi wrote: post #3

I campaigned for this for years when working on fuchsia, to folks in fuchsia and android folks. We lack a unixy API for “the radio is now on, do your reconnects or send your queues” The platforms always hoist this stuff higher level and it rarely works that well. Platform leads insist the platform will do it better, but it’s never true. They also insist that persistent connections are battery killers - which for sure…

systemd-networkd and NetworkManager have something to that effect. There’s however a big difference between an interface coming online, an interface getting its addresses, a particular address being resolvable and reachable, and the particular address being routed to the place you actually want to reach. In an ideal world, you want all four; NM kinda sorta has it. There are d-bus APIs, just maybe not easy to use in s…

This irked me recently. I think it’s very reasonable for networkd to delegate everything after the interface meets an “online criteria” to later services. However I was disappointed that you couldn’t then tell networkd an interface was “active” (vs. online) later down the line.

Would be interested to hear how you & others approach this. Perhaps I’m not thinking systemd-y enough hah.

Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives

#17

Post by tyingq »

olliej wrote: post #10
082349872349872 wrote: post #2

One obvious alternative: eschew push for as-high-as-practical latency automated pull.

Pull does not solve the problem. The attack here is the metadata "what was the origin" and "what is the destination", and pulling data does not solve that.

There was some discussion on techniques to get around that in this HN post about a messenger type product: https://news.ycombinator.com/item?id=37105477

Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives

#18

Post by Nextgrid »

It's disappointing to see everyone freaking out about this while ignoring the hundreds of different analytics SDKs littering every single mainstream app out there that leak even more metadata and store it on the provider's server (unlike push notifications which can be end-to-end encrypted).

Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives

#19

Post by antoinealb »

raggi wrote: post #3

I campaigned for this for years when working on fuchsia, to folks in fuchsia and android folks. We lack a unixy API for “the radio is now on, do your reconnects or send your queues” The platforms always hoist this stuff higher level and it rarely works that well. Platform leads insist the platform will do it better, but it’s never true. They also insist that persistent connections are battery killers - which for sure…

I also had some experience in that space, and my conclusion was that what was really hard is handling keep-alive correctly. Some mobile networks will very aggressively flush their NAT entries while other will be fine with a packet every hour or so. And sometimes the NAT timeout changes depending on the server's IP range. Building a solution that is both battery-optimal and that will keep the connection alive is pretty hard.

Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives

#20

Post by 082349872349872 »

olliej wrote: post #10
082349872349872 wrote: post #2

One obvious alternative: eschew push for as-high-as-practical latency automated pull.

Pull does not solve the problem. The attack here is the metadata "what was the origin" and "what is the destination", and pulling data does not solve that.

Sorry, I thought the problem was that the pushes were going through Apple's and Google's systems, which direct pulling would avoid.

How about messaging via wide-spectrum dead-drop hopping? (redundant array of inexpensive drops?)

Post reply on HN