Open RussellAult opened 7 years ago
The GCM data contains the "cleared" message i.e. sender, room name, message type, text and so on.
If you send an encrypted message, the GCM data don't contain the decrypted message.
If there is no data in the push, it is required to trigger a messages catchup (which is done by default).
But, some users complains about it because it retrieves many useless data (like presences) and it increases the data consumption (when used with WWAN connection).
So, we added a button to disable the catchup when a notified message is received. In this mode, the client uses the GCM data to build a dedicated notification.
Am I correct, then, in assuming that you would have to use the Google Play version to be able to receive GCM push notification even if you are using microg's GCM implementation and not Google's?
Yes. The F-Droid version is GCM-free.
F-Droid's issue with GCM is not that Google is spying on you.
The GCM libraries are nonfree. This means that the Google build of Riot includes nonfree software. The F-Droid build does not.
What are the remaining issues for bringing F-Droid battery performance up to the Play version? I'd really like to be able to track this stuff so I can switch back to F-Droid at some point when the performance is better.
For example, is there an issue for switching from polling to GCM-style notifications (possibly using the alternative implementation posted a few comments above)?
I'm currently running the google-play version of Riot, on a GMS-less fairphone, using microg instead of GMS and have working notifications (still through Google's servers, I believe). I'm not entirely sure, but from what I've understood, the GMS/GCM setup needs a system-wide part (which is provided by microg) and a in-app part. I'm not so sure how big the in-app part is, and perhaps the microg project also provides a replacement for that (I remember reading about linking an app against microg directly for F-droid).
However, you're likely interested in running the F-droid version on a regular GMS-enabled system, so then you'd need an open version of the in-app part, that actually talks to GMS, not microg. Not sure how that would work (or perhaps there could be a thin proxy that provides the microg API / name and forwards to the real GMS)?
I'm not really familiar with how the bits fit together, but perhaps this helps you figure things out...
I'm currently running the google-play version of Riot, on a GMS-less fairphone, using microg instead of GMS and have working notifications (still through Google's servers, I believe). I'm not entirely sure, but from what I've understood, the GMS/GCM setup needs a system-wide part (which is provided by microg) and a in-app part. I'm not so sure how big the in-app part is, and perhaps the microg project also provides a replacement for that (I remember reading about linking an app against microg directly for F-droid).
However, you're likely interested in running the F-droid version on a regular GMS-enabled system, so then you'd need an open version of the in-app part, that actually talks to GMS, not microg. Not sure how that would work (or perhaps there could be a thin proxy that provides the microg API / name and forwards to the real GMS)?
I'm not really familiar with how the bits fit together, but perhaps this helps you figure things out...
@matthijskooijman Indeed, your notifications are still going through Google’s servers.
Your analysis is mostly right, however no, the μG project does not provide a replacement for the in-app part, and linking an app against μG directly was a (non-implemented as of today) feature request to be able to embed the system-wide part into the app AFAIU, which does not really makes sense.
Running the F-Droid version on a regular GMS system will never enable you to use GCM, since there won’t be any replacement of the in-app part. A replacement would mean something like implementing an alternative GCM service (I believe some people are looking at this), but that is not for today.
The idea would be for apps (and server sides) to embed a server-agnostic implementation of GCM, and then the system, for instance using μG, could tell which GCM server is to be used (that could be the one you’ve deployed yourself in the future). That way, you would have the benefit of GCM (only one open connection at a time for all push services) with the advantages of FLOSS software (being in control of the GCM server). But that is in a distant future.
This GSOC project looks promising: Alternative Push Transport Notification.
The GCM data contains the "cleared" message i.e. sender, room name, message type, text and so on.
If you send an encrypted message, the GCM data don't contain the decrypted message.
On encrypted messages, is the sender/room name/message type still sent to GCM? Perhaps an even more private option should be available that doesn't send ANY of that data, only that there is a new message (e.g. the notification simply says "New message"). Signal does something similar when the app is passcode locked, though it still gives the chat name as well. This way the only data that GCM would get is "a message was received at this time", then you have to open the app to see where and what the message is.
Not sure if this is possible as I am entirely unfamiliar with GCM. Just a thought.
Sounds possible, and obvious. Maybe evaluate other past decisions and consequences as well. For example, https://gitlab.com/libremonde-org/papers/research/privacy-matrix.org/blob/master/part1/README.md#user-content-push-server by https://gitlab.com/thegridprotocol/home
What are the remaining issues for bringing F-Droid battery performance up to the Play version?
I am just a user, and I don't know if anyone is looking into that topic. For me, monitoring behaviour of the F-Droid version lead to #3470, which should reduce the amount of energy needed while nothing is happening.
The technical difference between the Play Store and F-Droid versions of the app is clearly laid out: one uses GCM, the other does not. The reasoning behind this distinction is also quite clear (F-Droid's prohibition on non-free dependencies). Even the downsides of using the F-Droid version (battery life issues) are clearly expressed.
What I've been searching for (and haven't yet found) is a clear description of the downsides of using GCM: what data does Riot actually send through the GCM system? In other words, as a privacy-conscious individual I'm looking to complete the following sentence: "The F-Droid version of Riot eats through battery, but on the bright side I can sleep better knowing that Google doesn't have access to..."