51–60 of 67 posts
The only problem is that no one is using it.
A bit longer comment on it:
https://gist.github.com/indigane/70ed13d5287c2d18b3e8e5d4f0c...
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.
Nobody is going to break the law on your behalf. Nobody. Not even this smug email provider who did what they did because they didn't want Google to have metadata.
Developer documentation has stated, from the very beginning, not to put sensitive info into push notifications. If you absolutely must, encrypt it with a key that they don't have. An ideal push notification is "Hi", and the app should know what to do with that. Whatever shows up on your phone screen was generated entirely on your phone and isn't sent to any server, and can't be recovered using these legal requests. Unless the app developer is stupid, in which case why would you think that another service is going to change that fact?
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 prett…
We already have a Push API specification that supports arbitrary push server URLs and self-hosting. It's called the Web Push API, although it can be used for mobile push as well. The only problem is that no one is using it. A bit longer comment on it: https://gist.github.com/indigane/70ed13d5287c2d18b3e8e5d4f0c...
Second, the Web Push API is just a unified API for websites to use Google/Apple/Mozilla notification services, which the article is trying to avoid.
rich 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.
Earlier quoted context omitted.
The interesting part is not in sending the messages but in receiving them. How are you going to fetch that email?
IMAP IDLE?
So now you’ve packaged the problem in a new layer that doesn’t solve anything but creates new problems.
The concept of an open connection waiting for the server to say anything is not novel or special, it just, as we already know, doesn’t really work reliably, you have to do more work to make it reliable.
Earlier quoted context omitted.
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.
(I think no wonder those pieces are missing, it usually isn't happening on computer-shaped things, more on embedded- and phone-shaped things.)
Why not just use UnifiedPush, which is already an open standard? Or, like other libre apps are doing, provide an option for external open providers, such as ntfy, Nextcloud Push etc.? I agree with the writer, SSEs have a lot of untapped potential and they're way less resource-hungry than Websockets. But if every app implements its own SSE manager, it'll still be a lot of overhead on the system as a whole. Better rely…