Hacker News Reader

Hacker News

Comment by lucideer | Hacker News Reader

Parent Full thread

lucideer

As there's pretty obvious bias showing in the values, some methodology would be good to accompany this sheet.

e.g.

- Telegram: E2E Private: TRUE

- WhatsApp: E2E Private: CLAIMED

These are either both "true", or both "claimed". Pick one.

In particular, what's the definition of the "Open Spec" column? Signal's GPL spec gets a FALSE here so I'm presuming the definition is something along the lines of "Spec produced by one ofa group of arbitrarily approved bodies of which Open Whisper is not a member"

View on HN

The comments specify what "claimed" means:

> Not possible to verify as application is closed source. Maintainer could compromise security at any time without detection.

I think it's useful to have this differentiation, even though technically you could say E2E is TRUE for both of these.

Telegram’s state of source code availability (and whenever prebuilt binaries match that) is a total mess. I think only F-Droid build would qualify, but not the mainstream sources.

That argument goes for every floss app. If you download their binaries from a play store (that is not f-droid), there's no guarantee that what you get is the same as what the source code would produce. f-droid is not a 100% guarantee either (e.g. not all apps support reproducible builds), but it's certainly better than the mainstream play stores.

As I've mentioned elsewhere: this is why you audit the apk, not the claimed source.

This is why you only use app stores that support reproducible builds.

That only works if you trust the store, and you somehow only know how to audit from source. Neither is true for professional audits: you'd generally start from the APK anyway, even if it's minified, and in many cases you'd actually get the source (which is an optimization only, e.g. to make bug descriptions better/faster).

Even with an open source edition it's hard to link strongly the source code to the resulting APK. How do you know that the generated APK hasn't been built with extra "features"?

For each release, independent people would have to compile the same source code and inspect if there is any differences with the published APK.

One way to make this easier would be to fix the build system so each build with the same source would provide a bit-exact APK file (without timestamps). Then the independent parties just have to check if all of the bits are the same (with a hashing function).

Ideally Google would also publish the hash output of each APK so that it can be checked against another distribution channel on installation.

F-Droid supports reproducible builds and all APK's they serve are built from source.

Ah, thanks, I didn't see those comments. That makes some sense for the E2E actually. That's a very reasonable distinction.

Technically one could still argue the same for Telegram unless you're self-building given their source-release delays but that might be nitpick too far.

However; compiled versions and binary distributed versions would not suppport E2E chats together if there were any significant difference.

This isn't true. A trivial example of a significant difference in which they would still interoperate would be a binary distributed version which phones home the shared key.

Then it’s still end to end encrypted. It’s just that one side is compromised.

Reply on news.ycombinator.com