Ratty Re notifications, suggest you lower your needs. FWIW I use protonmail and simply take a look every hour or so when necessary. Not great.... but an acceptable inconvenience.
Trouble with google is that it can change its behavior with little or no notice. I try to use non-google or F-Droid (denatured) apps whenever possible. Really tough to be pure, I think.
Some here are running without google anything. You might seek them out in a post and find what life is like.
Good Luck.
Questions about privacy
[deleted]
Ratty I have overcome the need for notifications from Protonmail by simply switching to Tutanota. Now I have no need for Protonmail. Sorted.
[deleted]
- Edited
Ratty if you think Switzerland is part of no eyes, you may be in for a surprise. Well, maybe not you, but someone is... There is nothing like absolute privacy anywhere in the world, especially when it comes to email.
Ratty That advice is outdat
Equal2024 I assume @Ratty is wondering whether Google has the ability to examine push notifications which Protonmail sends to Google, which they then send to your phone.
No, that's not how push notifications work. Google Play Services only sees which app the push notification is for. It can't read the contents of the notification.
No, that's not how push notifications work. Google Play Services only sees which app the push notification is for. It can't read the contents of the notification.
You're saying that, on app installation, the app negotiates an end-to-end encryption key pair between the user and the app developer? So that, even when the notification is sent to Google's notification service by the developer, it cannot be decrypted by Google, and is only decrypted by the user's phone when the user receives it?
Equal2024 A simpler possibility is that Google merely tells the app that some notification arrived, and the app then contacts its own server to fetch it.
The win would be that the entire phone would have one TCP connection open from Play Services to Google regardless of how many apps have registered to get which notifications from which apps.
de0u That sounds more likely by virtue of Occam's Razor. I'm not currently equipped to read through the dense Android documentation, but I've found an answer breaking this down: https://stackoverflow.com/a/23604394
The first step in GCM is that a third-party server (such as an email server) sends a request to Google's GCM server. This server then sends the message to your device, through that open connection. The Android system looks at the message to determine which app it's for, and starts that app. The app must have registered with Android to use GCM, and it must have the relevant permission. When the app starts, it might create a notification straight away with the data from the message. GCM messages are very limited in size, so the app might instead open a normal connection to the third-party server to get more information (for example, downloading the headers of new emails).
So, it sounds like, in its simplest form, neither the app developer's server nor Google's GCM server receives the content of the notification (though Google knows a notification has been sent), but the developer may store a copy anyway. However, GCM is now deprecated, so this may not be how it works currently: https://developers.google.com/cloud-messaging
So, we need to investigate Firebase now. Here's a link explaining the Firebase architecture: https://firebase.google.com/docs/cloud-messaging/fcm-architecture
- The message is composed, either in the Notifications composer or a trusted environment, and a message request is sent to the FCM backend.
- The FCM backend receives the message request, generates a message ID and other metadata, and sends it to the platform specific transport layer.
- When the device is online, the message is sent via the platform-specific transport layer to the device.
- On the device, the client app receives the message or notification.
Now, we need to figure out what platform-specific transport layer refers to.
Earlier on in the page, it defines this:
- Android transport layer (ATL) for Android devices with Google Play services
- Apple Push Notification service (APNs) for Apple devices
- Web push protocol for web apps
That doesn't really tell us whether this lives only on the phones and makes no outbound connections. I don't know enough about this, so I started following another thread which didn't lead anywhere conclusive.
So...FCM and Google probably don't know the contents of the notification...maybe? All the tutorials I've seen for setting up Firebase Cloud Messaging involve telling Firebase the content of the notification to send to the user. I'm not an Android app developer, so I couldn't say.
Equal2024 So...FCM and Google probably don't know the contents of the notification...maybe?
Thanks for digging! I looked a little too and am concerned.
First, this very long page is completely non-reassuring: https://firebase.google.com/support/privacy/
Second, Wikipedia makes it sound as if app developers could use the system safely or unsafely. For example:
Messages send with FCM are integrated with the Firebase Analytics functionality to track user conversion and engagement.
And:
Security compromise examples include private messages on a user’s social media account being pushed to the hacker’s device.To ensure the privacy of the platform, the user can build end-to-end protection schemes around the open communication channels provided by the Cloud Messaging Services, which are unsecure.
So, FCM seems definitely private or not-private! Engagement analytics sounds properly ominous. GPDR is satisfied, apparently by the recitation of many words.
Messages send with FCM are integrated with the Firebase Analytics functionality to track user conversion and engagement.
I had a closer look and this assertion is given no citation in Wikipedia, and the rest of the paragraph cites [10], which is a link to a 2014 conference about GCM, not FCM:
Yilmaz, Y. S., Aydin, B. I., & Demirbas, M. (2014, December). Google cloud messaging (GCM): An evaluation. In 2014 IEEE Global Communications Conference (pp. 2807-2812). IEEE.
Firebase was acquired in October 2014 by Google, 2 months before this conference, and the conference is about Google Cloud Messaging, not Firebase, so it seems likely this source does not mention FCM at all. However, I haven't seen the original source and there's no direct link to a recording of this conference. I don't even know how to go about chasing this reference down enough to know for sure...
Anyway, it's a really weird, obscure reference for something that should be easily verifiable elsewhere, and Firebase would be advertising as a feature. Keep in mind that Wikipedia history shows this page did not even exist until 2017, so surely there were better references to use at the time?
Here are some better references:
[0] https://firebase.google.com/docs/cloud-messaging/understand-delivery
[1] https://firebase.google.com/docs/analytics
Also, it uses Google Analytics, not Firebase Analytics, which makes more sense now that Google owns it.
Analytics also integrates with a number of other Firebase features. For example, it automatically logs events that correspond to notification messages sent via the Notifications composer and provides reporting on the impact of each campaign.
The source for the encryption used by FCM might be fine (I wish it was more detailed about "open communication channels"), but it's behind a paywall so I can't verify it. We can look at the Firebase privacy page for the type of encryption used by Cloud Messaging: https://firebase.google.com/support/privacy#data_encryption
- Edited
This is a take on FCM by the folks at sessions:
"...Session’s Android client has two options for notifications: background polling (slow mode), and Firebase Cloud Messaging (fast mode).
If you choose slow mode, the Session application runs in the background and periodically polls its swarm (see What is a swarm) for new messages. If a new message is found, it is presented to you as a local notification on your device.
If you choose fast mode, Session will use Google’s FCM push notification service to deliver push notifications to your device. This requires that your device IP address and unique push notification token are exposed to a Google operated push notification server. Additionally, you will expose your Session ID and unique push notification token to an OPTF operated push notification server, for the purpose of providing the actual notifications to the Google FCM server.
These exposures are fairly minimal, Google will likely already know your device’s IP address through telemetry data or other applications on your device using push notifications. Registration of your Session ID and unique push notification token to the OPTF push notification server is necessary for detection and signaling of new messages and is low impact as registration occurs using onion requests meaning your Session ID and push notification token are never tied to any real world identifier (such as your IP address).
When using fast mode neither Google nor the OPTF can see the contents of your messages, who you’re talking to, or exactly when messages are sent or received. ..."
FWIW I personally have no urgent need to interact with online communications applications. If that should occur, I would simply reload that app frequently 'til the messaging is completed.
So I avoid FCM.
Discussions like this leave me wishing:
I was smarter.
I knew more.
I understood more of what I do know.
newbie24689 This is a take on FCM by the folks at sessions: [...]
Thanks! But I think that might say more about Session's carefulness than about how careful other apps using Firebase are, or what analytics Google does when possible.
Also... I think Google gets to find out that you are a Session user. I think they can associate your (for example) Gmail i.d. with you being a Session user, even if you put Gmail and Session in different profiles, because both apps will be getting push notifications to the same IP address close in time.
de0u Yes....Agreed.
Which is why I don't use push on either Session or Gmail. If I'm a little late on replying to an email, so be it.