Apple and Google Monitor Notifications. We Need Push Notification Alternatives
1–10 of 67 posts
Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives
#2One obvious alternative: eschew push for as-high-as-practical latency automated pull.
Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives
#3I 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 they _can be_ but done properly (and with the aforementioned api) it can work just fine.
Establishing such an API in the Linux and BSD ecosystem would make a good step toward encouraging its exposure in the places we need it.
Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives
#4rich coming from tuta who still lack a onion based login. this ticket from 2018 was locked as off-topic. https://github.com/tutao/tutanota/issues/528
as lenin said, the best way to control the opposition is to lead it. for me, unless the company has been raided by the government they simply cannot be trusted.
apple proudly advertises privacy on huge billboards while sharing everything they are asked under shadow laws. absolute hypocrisy and double standards. but then they wouldnt be where they are without government money and favours.
Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives
#5I 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 shell scripts CLI tools.
Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives
#6People 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 are vastly better for performance by every metric), or polling. Necessarily the intermediary (Apple, Google, Signal, FB, etc) know the origin and the destinations of anything that would currently be a notification. Requiring polling does not stop that.
Having lots of different services does not stop it either: the orders given to google and apple can just as easily be given to any other company or organization, and more importantly it sounds like google and apple were only able to say anything because a US Senator explicitly asked them so we have no way to know if any organization that was not explicitly asked is also subject to the same orders. The same applies to a criminal organization compromising such a service, only providers aren't prohibited from saying anything, they're just oblivious.
If you are using a service that necessarily involves a third party, that third party can be subject to orders that require them to turn over anything about you or messages you send or receive, or criminals compromising the provider watching the same thing. Encryption (real encryption, not just TLS, not "no one other than you or the provider can access it") can only protect the actual content, the sender and the receiver cannot be protected.
Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives
#7rich coming from tuta who still lack a onion based login. this ticket from 2018 was locked as off-topic. https://github.com/tutao/tutanota/issues/528 as lenin said, the best way to control the opposition is to lead it. for me, unless the company has been raided by the government they simply cannot be trusted. apple proudly advertises privacy on huge billboards while sharing everything they are asked under shadow laws…
I really want to like onion, but literally the only thing I can reliably find is search engines with drug and porn ads, and most results to any query I do throw in are non-responsive, and those that aren't broken are still incredibly slow.
Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives
#8I 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…
The routing table won't get flushed in between the slumber of the WiFi or 5G modem. You do not have to care about IPs or interfaces being up - we just need to synchronize network work so that most comms can be done in short bursts and then everything can go back to sleep. iOS does this, has done this for years.
Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives
#9rich coming from tuta who still lack a onion based login. this ticket from 2018 was locked as off-topic. https://github.com/tutao/tutanota/issues/528 as lenin said, the best way to control the opposition is to lead it. for me, unless the company has been raided by the government they simply cannot be trusted. apple proudly advertises privacy on huge billboards while sharing everything they are asked under shadow laws…
It’s hypocrisy and double standards to follow the law? You say “Shadow law” as though it’s them being nefarious.
I don’t know anyone who interprets Apple’s stance on Privacy as “They will break the law for you”, only in contrast to… everyone else (?) selling your advertising data?
Re: Apple and Google Monitor Notifications. We Need Push Notification Alternatives
#10One 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.