RT @lopp: After switching to a version of Android with Google services ripped out it becomes painfully obvious how many apps are sending your notification data through Google's servers. It's no different on iOS with Apple. App devs trade privacy for convenience. https://t.co/bG1lUxYkZh
After switching to a version of Android with Google services ripped out it becomes painfully obvious how many apps are sending your notification data through Google's servers. It's no different on iOS with Apple. App devs trade privacy for convenience. https://t.co/bG1lUxYkZh
The plan is still to replace FCM, but this will be after the Android app rewrite that is in progress right now. In the meantime, we have been using end to end encryption on all push notifications which mostly solves the privacy issue of FCM.
Couldn't ProtonMail just modify and use Tutanota's code for now? Then you could have a non-FCM notification system and work on other stuff. You could always write your own FCM implementation one day if needed.
It may not scale to the volumes that we have to deal with, which could be 100x more. The current situation with end-to-end encrypted push notifications is relatively secure, even though it's not ideal. We will have to do deeper analysis of this before redoing notifications, and we will do that once we have an engineer available to do a deep dive into this.
Yeah but I mean... The indiegogo campaign was 4 years ago... The fediverse has developed in less time... And it is fully open source... I think this is a matter of attitude, they just dont see free software as something remotely close to a priority.
And then there's the issue of GCM, from a company that loves to say that anything from the US is satan. I think we would see the app on f-droid arround 2022. Tutanota already is, and they were created at the same time, with the caveat that proton is way bigger and has more resources. I'd really like to be proven wrong, their product is amazing, but 4 years is way too much time.
IMO that does not solve the privacy issue. The privacy issue is that you have to install Google Play Services on your phone in order to use all the features of the app. Once I've done that I have no way of knowing what data Google is collecting from my phone usage. So as a paid user I'm forced to go without push notifications unless I want to give Google access to my data.
That said I do understand that you're working on this. It just baffles me a little that a company that says it focuses on open source would ever a) release a closed source app that b) relies on Google Play Services.
To protect your privacy was the main goal when rebuilding the notification system. When using FCM, Google sees all information you send along with the notifications (email address, subject line in unencrypted emails). That's why we stopped using Google's service. ;)
I appreciate your efforts at de-googlification, and wasn't aware of that aspect of their tracking. However, let's say one is paranoid : is there an advantage, anonymity-wise, to not using Tutanota's notification system ?
I installed the fdroid app. The notifications are still the same as the one from Google playstore. I was under the impression that with fdroid there will be better detailed notifications as with address, subject etc. Is it not the case?
Is it possible for every app developer to stop using FCM? Yes, in China.
The result is a chaotic market. App devs will have to use multiple push machinism for different device: on Huawei phones, Huawei's own push service is the most reliable; on other phones, you might want use SDKs from Tencent/Baidu/Alibaba so their app (Wechat/Baidu search/Taobao/Alipay) can "wake up" your app to receive push. Battery life become miserable, push become unreliable. It's to a point where the government start "regulating" the market (the Unified Push Alliance, http://www.chinaupa.com, is lead by CAICT, a think tank of Gov of China).
This is really the chance for a great open source project. So many open source apps (Signal, Mastodon clients, riot.im, telegram-foss and more) have to do hacks to be able to deliver push notifications without GCM/FCM
What if there was an open source software one could setup on a server that would provide push services for all these apps and would interact with one open source client running on android.
That way one would have the energy saving benefits of only handling one server connection, but the privacy benefits of a private server for oneself/friends/people one trusts.
This is definitely not easy and would require coordination between many open source projects and also additions in Android to run on a system level (maybe in lineageos and similar), but I really think it would be worth it.
> Wouldn’t it be great if the user could just pick a “push notifications provider” in the phone settings and OS managed all these hard details by itself? So every app, which doesn’t want to be policed by the platform owner, didn’t have to invent the system anew? It could be end-to-end encrypted between the app and the app server. There’s no real technical difficulty in that, but as long as our systems are controlled by big players who do not allow this, we have to solve it by ourselves.
Fking this. ideally, this would also involve a standard API on the backend for how to send push notifications. E.g., something like:
1) App on phone queries OS for selected push provider.
2) Phone OS returns some metadata about the push provider to the app, including a a backend URL for sending messages.
3) App sends that URL to it's own backend server.
4) When a push message should be sent, the app's backend server invokes that URL with the message to be sent in some standardized way.
If - which is likely - push servies require that developers register their apps with them before use, this could be expanded by the phone OS returning a list of providers instead of just one.
>SSE fits our needs better than WebSocket would (it is cheaper and converges faster, because it’s not duplex). We’ve seen multiple chat apps trying using WebSocket for push notifications and it didn’t seem power efficient.
This is just not true unless there is some serious fuckery going on with the websocket implementation. Both require full duplex communications on the transport layer.
I'm wondering how it works with different messaging apps. I'm using mostly Facebook Messenger, because of the network effects. A few months ago I tried to use several apps to communicate with my wife. Both Signal and Wire failed to reliably send messages in under 30 minutes or so. More often then not the message would be delivered after a few hours. That's totally unacceptable. If there are some magic settings in Android they were not properly advertised. Our phones are on quite pure 8.1 and 7 versions. So I'm back to Messenger.
Reading this it seems that there is a known solution to this problem. Does Mastodon offer something like private messages? Or is there a messaging app that doesn't use FCM, but works in a way described in article?
What's the deal with push notifications if the modem has to be switched on every couple of minutes to keep a connection alive? I was under the impression that push notifications were implemented similar to a call handshake that only activates the phone if there is a call.
Are the FCM service and the iOS equivalent also IP based or can they use some lower level, more energy efficient protocols to wake up the phones?
> Wouldn’t it be great if the user could just pick a “push notifications provider” in the phone settings and OS managed all these hard details by itself?
Having the possibility of choice is a good thing but in this particular case I don't think it would be good if 3rd party notifications providers were available. This should be an integral part of the OS, not a field for competition; knowing that Google itself can harvest data from notifications we can't exclude the possibility that there would appear companies interested only in that activity, at the same time enticing users with pretty and simple design of notifications or whatever else.
Another difficulty was caused by the Doze mode, introduced in Android M. The Doze, which is turned on after a period of inactivity, among other things prevents background processes to access the network. As you can imagine, this prevents our app from receiving notifications.
We mitigate this problem by asking users to make an exemption from battery optimisations for our app. It worked fairly well.
This is why we were migrating to FCM from our own custom built MQTT solution that was invented back in 2012.
Final thought: Every user should be able to choose a “Notification Provider” for every app
At Qbix, we thought deeply about this problem. Ideally, to maintain anonymity, each notification would come from some random endpoint on the cloud. But that’s not how the Internet works these days, you have to connect periodically to SOMETHING. So you can choose your own notification providers.
The trouble is if you have many apps, then your device is constantly connected to many servers.
What we settled on for now is a background process with WebSockets, but perhaps this works better. The operating systems weren’t designed for this use case and the phones aren’t optimized for it. For example, how would you do the same on iOS?
However, what IS possible is tunneling through the native iOS VoIP notifications support and encrypting your notifications. You can even process them on the client side with some “IFTTT” type logic. To do that for Android, however, we had to implement this background process approach. But it’s a hack.