Hacker News Reader

Comment by sgjohnson | Hacker News Reader

It doesn't actually even matter if they did this. The only thing that matters is that they are physically capable of doing so. Telegram is not e2e encrypted by default, and therefore you shouldn't use it if you're concerned about privacy.

Look no further than Signal's supboenas and how they respond to them. With all the information they hold about an account. Which is just the creation date and last connection date. https://signal.org/bigbrother/eastern-virginia-grand-jury/

View on HN

> Look no further than Signal's supboenas and how they respond to them. With all the information they hold about an account. Which is just the creation date and last connection date. https://signal.org/bigbrother/eastern-virginia-grand-jury/

Signal's subpoenas have always left a sour taste in my mouth. I just can't believe that they are getting so few, at least some cases they'll just send the standard letter out and will try to get something. Having no list of how many they have rejected would at least increase my confidence in them a bit.

But the bigger issue is, that they data they provide is just too good to be true for the majority of users. Signal has a push token for the vast majority of accounts otherwise they wouldn't be able to send out push notifications on iOS and would waste at least some battery on devices with Google Play services installed. The subpoenas always seem to affect people who have an Android phone without Google Play services installed. In my eyes is too strange of a coincidence to be true.

Signal does at least a bad job of explaining what kind of data they keep on an average user.

> Signal has a push token for the vast majority of accounts otherwise they wouldn't be able to send out push notifications on iOS

It's technically possible for them to not know which phone numbers correspond to which devices and tokens.

If they have the ability to send notifications, it's irrelevant how exactly that works: they can let a third party do that through them.

Not to mention that cryptocoin integration attempt to cash out with privacy reputation. It just left so sour taste as well. What else they are ready to do?

> With all the information they hold about an account. Which is just the creation date and last connection date. https://signal.org/bigbrother/eastern-virginia-grand-jury/

It doesn't matter. The problem with Signal is that it is vulnerable to being shutdown easily.

So Google or Amazon or where ever Signal is hosted can just shut it down and will receive a request by the authorities to show that it is aiding and facilitating in illegal activities and will blame it on the tons of criminal networks, terrorists, insurrectionists and gangs all using Signal.

Thus, Signal really is a centralized dead end in the long run. Anything that is decentralized or allows self-hosting is the way to go.

It is particularly amusing that they provided the two date/time pairs in the form of "Unix millis" only. Obviously there's the legal risk of getting the conversion to Gregorian wrong, but I suspect that may have cause some head-scratching at the court.

It's probably some malicious compliance on their part. They are probably storing those timestamps, as, well, UNIX timestamps. So it's exactly what they provide.

Meh. In any case involving data/tech I suspect there are people involved who can handle much more sophisticated formats/conversions than this. I may disagree with the government’s stance on privacy, bit they’re not stupid or tech-illiterate.

I regularly help my lawyer friend parse the DVDs she gets from police with the evidence from her case and it's a nightmare collection of proprietary ancient standards for old versions of Windows. They also still use fax machines for everything.

The only place you'd find technical talent is in the federal police or a few guys higher up in the major urban police forensics labs.

Sure, but my point is that any agency or group that is going to subpoena Signal definitely has someone on their team who understands what a UNIX timestamp is. Think about it: If a service actually does comply with one of these subpoenas, they probably had over a trove of JSON files that need to be parsed or searched.

Signal is just another walled garden actively fighting decentralization. If it becomes big enough, attacks of big adversaries will be inevitable. Also, the problem with funds. Consider Matrix instead.

> It doesn't actually even matter if they did this. The only thing that matters is that they are physically capable of doing so.

Exactly. It could be the truth or Russian psyops to undermine the trust among users, which happens very often from all sides involved, not just during war time. It should be noted that all governments hate private communications systems, except when they suit their needs. That's one more good reason to push for systems offering full e2e encryption by default.

It absolutely matters that they did this. We can’t ever trust them again

Not really. Nobody should have trusted them in the first place.

If the capability exists, it will be exploited sooner or later.

Terrible advice. If you want e2e you can choose to enable it. It is not enabled because many users choose to receive their messages across multiple personal devices simultaneously. This is not possible with e2e, which is why it is an option.

> Terrible advice. If you want e2e you can choose to enable it. It is not enabled because many users choose to receive their messages across multiple personal devices simultaneously. This is not possible with e2e, which is why it is an option.

Signal, WhatsApp, iMessage and Threema seem to do just fine.

> iMessage

Unrelated to this, but for all intents and purposes, iMessage cannot be considered e2e encrypted if either party has iCloud backups enabled. Apple has access to your iCloud backups, and they contain the iMessage keys.

IIRC With the keys they can technically decrypt in line, backups are not required.

Yes they can choose to decrypt messages going forward (by injecting a third key controlled by the gov/Apple in a multi person message and silently copying messages) but they can't retroactively decrpyt them in that case.

"Just fine" by conveniently managing the keys for you. You have no idea what they really do with them.

Well, except Threema. Last time I used it, it was not possible to receive their messages across multiple devices simultaneously.

You have no idea what any software does with your keys unless you audit it, then compile and install it on your device yourself. Oh, and audit your compiler. And its compiler...

If you have a piece of software, that can read supposedly encrypted messages on several devices, it is obvious that it does something with the keys. You don't have to audit the compiler and argument into ad-absurdum.

The Sesame protocol lets the linked device generate its own keypair, the only thing in common is your user id. Each private key never leaves the respective device.

A talk on the technicals can be found here: https://www.youtube.com/watch?v=7WnwSovjYMs&t=1762s

Guess who conveniently holds your "secret key" in escrow just like AWS KMS does by default? The provider.

> This is not possible with e2e

Why not? You can encrypt a message with more than one key, no? It’s still e2e, just that there are multiple ends.

Apple’s Messages is e2e (until SMS is used) and they have group chats.

Until SMS is used OR until either side has iCloud backups turned on (which is the default setting)

Just shipping keys to someone to hold on doesn't make the encryption not-end-to-end, though it does reduce the point quite a bit.

Reply on news.ycombinator.com