← Back to context

Comment by sroerick

1 year ago

Telegram is the only messaging app that I know of which brought attention to the fact that your messages go through Google/Apple notification APIs, which seems like it would utterly defeat any privacy advantage offered by E2EE

Why? I think Google suggests that you send the payload encrypted through the notification. Google then only knows which app to send the message to, they don't know from whom the message originates (only "a Telegram server") nor what the content is.

Also, you could just send a notification instructing the app to fetch a new message from your server.

From the docs:

Encryption for data messages

The Android Transport Layer (see FCM architecture) uses point-to-point encryption. Depending on your needs, you may decide to add end-to-end encryption to data messages. FCM does not provide an end-to-end solution. However, there are external solutions available such as Capillary or DTLS.

https://firebase.google.com/docs/cloud-messaging/concept-opt...

  • Assuming an adversarial relationship, what sort of metadata could Google capture simply knowing which app was sending the notifications and who was receiving them?

    • Schneier mentioned this late in 2023:

      https://www.schneier.com/blog/archives/2023/12/spying-throug...

      > Wyden’s letter cited a “tip” as the source of the information about the surveillance. His staff did not elaborate on the tip, but a source familiar with the matter confirmed that both foreign and U.S. government agencies have been asking Apple and Google for metadata related to push notifications to, for example, help tie anonymous users of messaging apps to specific Apple or Google accounts.

    • Aren’t notifications enqueued on the server side, implying sender info is inscrutable? I’m curious what mechanism you’d propose to gather any valuable metadata given a sufficient volume of encrypted notifications.

      1 reply →

    • "A Telegram server used FCM to send a message of size X to the device owned by individual Y at this timestamp and this IP address".

      Nothing else.

If the text appears on your screen I'm pretty sure there are ways for Google to capture it. I don't need to know how android's API works, knowing it probably just makes one blind to the big picture. You have to trust your OS/phone maker not to do a MITM.

  • Yes, but Google cannot be compelled to turn over data they don't actually have on their servers because the users encrypted it before it arrived with keys Google don't control.

    Signal could modify the application so a remote flag in the Play store binaries could be triggered to exfiltrate data as well. But the key distinction is the normal path of Signal gives them absolutely nothing they can tell anyone other then the bits they've put in the disclosure reports (namely: date and time an account ID used Signal I believe).

    • I think parent's point is, if data appears on sceen, the OS in theory can capture it and send to Google servers as screenshots or OCR'd text.

      2 replies →

  • Google (and Apple) has remote root over their message bus. This is reflected in the fact that they can remove spyware from people's phones remotely at any time.

    Should they have to comply with law enforcement they have much more straightforward ways of doing so than capturing messages off screen.

And yet Telegram doesn't allow to have e2ee chats on a Linux desktop or phone. You must rely on Google/Apple.

  • Most of Telegram clients except initial mobile apps was actually open source projects that was choosen by company to become "offcial" ones.

    They just dont implement E2EE since almost no one uses it on Telegram.

This claim is what really makes me skeptical of Telegram's privacy story. Their assertion is completely incorrect. (Source: have implemented end to end encrypted payload delivery over APNs / GCM.)

And if they are so off base on this, they must either be incompetent or liars. Neither of which builds trust.

  • I’m old enough to remember when Signal first implemented cross-device sync using a Chrome plugin.

    I’d rather developers issue cautionary warnings than give a false sense of perfect security