101–110 of 150 posts
The issue is highlighted in this article [1].
[1] https://www.sixthtone.com/news/1011308/the-real-story-behind...
Earlier quoted context omitted.
> There, encryption is unnecessary complexity. If you are sending a small amount of data it is likely a tiny overhead for some notable benefits. 1. If all data is encrypted then no data stands out for being encrypted. 2. It provides integrity which may prevent push servers from changing message to be invalid or triggering parsing bugs in applications. 3. If only encrypted messages are supported it is impossible for u…
I agree, though it of course it depends on the threat model. As a self hoster, encryption is pretty much irrelevant, as my push server is controlled by myself, and accessible with https. Not having encryption makes it easy to debug and experiment. I agree encryption should be the default choice though. Maybe we can introduce it in a future protocol revision? Client side, I expect most people use libraries, making thi…
Earlier quoted context omitted.
> There, encryption is unnecessary complexity. If you are sending a small amount of data it is likely a tiny overhead for some notable benefits. 1. If all data is encrypted then no data stands out for being encrypted. 2. It provides integrity which may prevent push servers from changing message to be invalid or triggering parsing bugs in applications. 3. If only encrypted messages are supported it is impossible for u…
I agree that mandatory encryption would massively help privacy, integrity and even compliance [1]. However, the main cost is developer-effort involved in keeping track of keys and implementing encryption. As a small project, ease of adoption has been our most important goal. However, as we work towards better WebPush compatibility [2], I personally absolutely want to promote RFC8291 encryption and make it easy to imp…
Earlier quoted context omitted.
Sorry if I’m not understanding something but… Doesn’t Apple and Google on the OS level only allow push notifications to come from its own services? Like, they look for the signature to be compatible with https certificate etc. Otherwise the phone could have a ton of push notifications incoming from anywhere on the Internet. The APN service for instance would only route notifications to a phone if it came from a regis…
I believe the notifications used to be delivered by a very long-lived TCP connection, and there probably is no limit to those on Android. The reason to use the google services is mostly touted as for battery savings, I believe.
Not true since Android Oreo. Long running background Service execution (without a foreground notification) has been dead for a while. Most of the useful system-wide config change updates (implicit Broadcasts) got killed as well. Basically, only Google (or GCM/Firebase Messaging) gets to do timely push notifications. You can try to roll your own MQTT server, but there’s a good chance the OS will kill your Service, in which case you would have to poll every 15 minutes with JobScheduler/WorkManager, with no guarantee that background task would even get run every 15 min.
Earlier quoted context omitted.
Afaik Google and Apple just discount their own poller. It still has to wake up and check periodically.
They have special deals with the telcos that TCP connections to their servers can have longer TTLs. Plus of course, even if you do polling, if you have 5 different apps that connect every 10 minutes to their own respective services with different offsets, you have the device waking up every 2 minutes, with a potential latency of up to 10 minutes for each individual service. If it uses a central push service, you can…
This is now impossible with background execution restraints set in Oreo. The OS clusters requests for background execution and does them with the same wake. Apps can only wake the device every 15 minutes at most (and requests to wake are not guaranteed).
Earlier quoted context omitted.
We can't get users to understand that the ceo isn't sending them mail from giftcards563@gmail.com to go and buy giftcards, and not to ask any questions. What's the actual likely hood that the average end user is going to install a random service?
> What's the actual likely hood that the average end user is going to install a random service? For now, UnifiedPush is targeted towards De-Googlers, self-hosters and FOSS enthusiasts, not average users.
Which implies the use case people are seeing is phone apps. Unless people are building one off apps for themselves, you've got end users in the mix.
I don't see how this can be positions as much outside of phone apps, as txt messages or emails would be easier and more universal. Being that they're probably going to be supported here.
To note, i haven't see anyone talking about this being replacement for the part of webpush that handles registration for notifications or whatnot, but as a whole separate channel/technology. Not 'install this to avoid using google/apple for webpush' but 'use this in your app, and have your users install the service'.
Why is it named decentralized when it uses a central server to route/distribute the messages?
Looks like a cool solution to one of the biggest issues in FOSS on Android.