microg / GmsCore

Free implementation of Play Services
https://microg.org
Apache License 2.0
8.64k stars 1.73k forks source link

View/encrypt FCM messages #2187

Open ThreeDeeJay opened 9 months ago

ThreeDeeJay commented 9 months ago

Are FCM messages encrypted? Could MicroG ever offer end-to-end encryption or does it depend on each app's FCM implementation? And can we monitor the message contents? I'm not too fond of the idea of unencrypted messages going through Google's servers, so I'd at least like to know if/which apps send sensitive data so I can deny them FCM access 🤔

ale5000-git commented 9 months ago

The best implementation is the one of Signal: if I remember correctly it just send empty messagges through FCM to signal that there is something then the app takes the data itself (without Google servers).

mar-v-in commented 9 months ago

Apps can also decide to send encrypted payloads themselves, but microG couldn't do it for them.

MicroG does log the content of received messages to logcat, so you can check for your apps if they send push messages encrypted or not. You can then easily unregister and block them from push messaging via microG settings.

ThreeDeeJay commented 9 months ago

Yeah, I read Signal and ProtonMail allegedly do it, which is why they're the only apps I do allow to use FCM to save battery life, but I'm not sure about other apps (or how to even verify these 2 do hide sensitive data for sure). Thanks just saw that last message so I'll check the logcat 👌

It's still annoying that some apps would spam attempt to connect to firebaseinstallations.googleapis.com even when explicitly denying FCM in the MicroG popup dialog and settings (app's not registered and Allow registration and Start app on push message are both disabled). Disabling the ComponentDiscoveryService (com.google.firebase.components.ComponentDiscoveryService) service with MyAndroidTools (root required) seems to prevent that, but that causes some apps to crash on startup.

mar-v-in commented 9 months ago

Firebase Installations is independent of Google Cloud Messaging (even if app developers or Google claim its a requirement). As these requests come directly from the app, I don't think there's anything we can do from microG side to prevent them (though I haven't looked into it in detail yet so their might be ways).

ale5000-git commented 9 months ago

There is a way but I haven't tried:

ThreeDeeJay commented 9 months ago

@ale5000-git Yeah, I already do something like that in Rethink DNS (though my approach is to use a per-app whitelist to block other BS not covered by public hosts/block lists) so I'm not worried about those app establishing connection, but I just wanted to prevent unnecessary connection attempts, battery usage and inefficiency (not to mention the spam I see in the RDNS log, I'm talking about hundreds of useless connection attempts that might not let my phone go into deep sleep)

@mar-v-in Whew, I just used a log viewer and searched for incoming and surprise surprise, they were sending personal info as plain-text. What's this, SMS?🤦

It would be nice if we could see the message history right in the app like FCM Toolbox, as a visible/regular notification or toast message, so that the user can make an informed decision on whether to allow the app to continue using FCM. Maybe MicroG could even include a list of package names known to use FCM without encryption and warn the user 🤔

mar-v-in commented 9 months ago

Having a history in microG would mean we'd have to store those messages. If they include plain text, it's probably better for user's privacy to not store them. Maybe we could have it as an option that can be enabled for advanced users.

Also, an option we could have is to warn users about apps that send plain text. We could do this with a list of known bad apps or with an heuristic (and a list of known good apps to prevent false positives). Detecting that things are not encrypted is probably reasonably possible (e.g. we can search for email address patterns or text consisting of mostly lowercase letters and spaces)

ThreeDeeJay commented 9 months ago

Yeah, it'd be reasonable to have the user set a password for message history backup encryption like Signal and others do. And I agree, a list of bad apps and pattern matching detection sound great. Perhaps even notify the user once the first message is received so they can like click a lock button to input the password and see the message content to manually check whether it's encrypted and decide whether it should continue letting Google store such data

But yeah, probably just as an option for advanced users that wouldn't mind trading some convenience for fine-grained control and awareness. Then again, people using MicroG are probably advanced users that aren't fond of Google's intrusive, proprietary software to begin with 😅

dylangerdaly commented 8 months ago

I was surprised using logcat, seeing just how many apps send stuff in plain text.

rugk commented 5 months ago

Detecting that things are not encrypted is probably reasonably possible

The standardâ„¢ way to check such a thing usually just is to calculate the entrophy of the text/data and if it is higher than a certain threshold, it is likely encrypted. See https://stackoverflow.com/questions/9448193/simple-way-to-detect-encryption or https://stackoverflow.com/questions/9448193/simple-way-to-detect-encryption or https://stackoverflow.com/questions/64845981/is-there-a-way-to-check-that-the-file-data-is-encrypted-or-not

mar-v-in commented 5 months ago

@rugk, we wouldn't really want to detect if the content as a whole is encrypted or not, we want to detect if it contains unencrypted sensitive data. And even if they are encrypted logically, they might be in a frame that makes them have little entropy.

Just to make an example, these would be totally fine IMO and don't need to issue a warning to users.

{
  "type": "new-message",
  "id": "fd239bfa-db75-48e6-8ad5-649b2f895246",
  "remote-id": "b6739123-78d0-4cee-873f-61298c420291"
}
{
  "type": "new-message",
  "payload": "dEuNKyaIpklEfuHoNJrnDPKioocTiFAaxfwjD4axcilt4FY0iQu+QcBrEms7FgWpsx+9ED2J8uiCfyos0ewOng==",
  "iv": "CkSIkBWhvfR+IYG+F8RYtkYTKOMG5+vOtFIwIHrNWrQ="
}

The following would not be good though:

TME16xuser@example.comP64xdEuNKyaIpklEfuHoNJrnDPKioocTiFAaxfwjD4axcilt4FY0iQu+QcBrEms7FgWpsx+9ED2J8uiCfyos0ewOng==ICkSIkBWhvfR+IYG+F8RYtkYTKOMG5+vOtFIwIHrNWrQ=

A naive entropy calculation will likely consider the last one to have the highest entropy.

rugk commented 5 months ago

Yeah just wanted to note it may be used as an additional factor or so, surely needs more consideration.