Looking back at how Signal works • Hacker News Board

Re: Looking back at how Signal works

#201

Post by gingerlime » Sat, Jun 06, 2020, 6:18 AM UTC

KingOfCoders wrote: post #200

gingerlime wrote: post #192

Earlier quoted context omitted.

anecdote time: My 6 year old son just discovered the augmented-reality tricks in the LINE app (adding a mustache, hair, glasses, sound effects etc). He got my mother (68) to install it and now they use it pretty much for all their video conversations. This replaced FaceTime, despite FaceTime having better sound and picture quality (edit: and even some effects). He's in the age (and COVID-19 environment) where he star…

Favoring mustaches over security is always the choice you can make. I don't care about adoption unless it falls below levels to make signal worth developing.

> Favoring mustaches over security is always the choice you can make

Unfortunately not. If most of my friends and family favour mustaches and effects (which seems to be the case, I would imagine as a general rule), and I favour security (the minority, as a general rule?), then I won't be able to talk to them securely.

Re: Looking back at how Signal works

#202

Post by kagenouta » Sat, Jun 06, 2020, 6:21 AM UTC

toast0 wrote: post #176

kagenouta wrote: post #168

Earlier quoted context omitted.

I, for one, have a bigger problem with it forcing the use of phone numbers as a sign-in method. They're an arbitrary identifier from a legacy system that there's not really a point in continuing to extend, because if your device is capable of anything more advanced than SMS it's also capable of... well, this. Also KaiOS and the like are making chat feasible even on feature phones. Don't get me wrong, RCS will be a fi…

> Don't get me wrong, RCS will be a fine enough fallback (once it's E2E), but standardized chat is the dream. Is there a plan for RCS to be E2E? Given that RCS went under the GSMA umbrella in 2008, and it's 2020 and adoption is minimal, I don't have any hopes for a future update that supports E2E to come out any time sooner than 2040, with handsets supporting it in 2050, and all endpoints supporting it in 2065; Googl…

Not within the spec. Which was sort of the point I was (poorly) trying to make - that it's a huge caveat, but otherwise a decent fallback if and when that changes.

Google is adding an implementation into Messages, and it's honestly not a critical problem if OS vendors are supporting it at that level, but there's still too much we don't know about it imo. Will that be supported by iOS, if and when it supports RCS at all? Will it work for third-party clients, if and when Android gets APIs?

I'm not sure how much optimism I have that this will be anything other than a fragmented mess in the short term.

Re: Looking back at how Signal works

#203

Post by KingOfCoders » Sat, Jun 06, 2020, 6:31 AM UTC

gingerlime wrote: post #201

KingOfCoders wrote: post #200

Earlier quoted context omitted.

Favoring mustaches over security is always the choice you can make. I don't care about adoption unless it falls below levels to make signal worth developing.

> Favoring mustaches over security is always the choice you can make Unfortunately not. If most of my friends and family favour mustaches and effects (which seems to be the case, I would imagine as a general rule), and I favour security (the minority, as a general rule?), then I won't be able to talk to them securely.

If they don't want to talk securely to you, then they don't want to, why do you want to force them to? They will spill secrets to other people all the time, using Signal or not. They will talk to other people about things you thought was a secret between you. They don't patch their computer. They use trivial passwords to their computer, they reuse passwords on all websites, they don't encrypt their drives or their Micro-SD on their mobile phones. Why should they care about things you want them to care about? They won't.

I use WhatsApp to people who don't care about security, and I can only be contacted by Signal for business stuff.

Re: Looking back at how Signal works

#204

Post by brnt » Sat, Jun 06, 2020, 6:46 AM UTC

walrus01 wrote: post #88

Mediterraneo10 wrote: post #53

Earlier quoted context omitted.

I recall reading something recently about how in a coming release, Android will disable sideloading. The sole permitted way to sideload will be to enable ADB and then install the app with adb install. Some techies will continue to do that, just like some people unlock the bootloader and install LineageOS on their device, but removing Signal from the Play Store would make it as good as dead for the general public. (Ev…

There is a concern with getting ordinary non technical users accustomed to the concept of sideloading apps... It might be totally safe to download the official Signal APK and sideload it. But people will then think that's a suitable and acceptable way to install other things, and will then be more likely to be easily social engineered or phished into loading other malicious APKs. The ordinary non technical user has n…

As if the Play store is such a safe vector. I avoid it as the plague precisely because you'll pull in all kinds of spyware that way.

Re: Looking back at how Signal works

#205

Post by toast0 » Sat, Jun 06, 2020, 6:51 AM UTC

kagenouta wrote: post #202

toast0 wrote: post #176

Earlier quoted context omitted.

> Don't get me wrong, RCS will be a fine enough fallback (once it's E2E), but standardized chat is the dream. Is there a plan for RCS to be E2E? Given that RCS went under the GSMA umbrella in 2008, and it's 2020 and adoption is minimal, I don't have any hopes for a future update that supports E2E to come out any time sooner than 2040, with handsets supporting it in 2050, and all endpoints supporting it in 2065; Googl…

Not within the spec. Which was sort of the point I was (poorly) trying to make - that it's a huge caveat, but otherwise a decent fallback if and when that changes. Google is adding an implementation into Messages, and it's honestly not a critical problem if OS vendors are supporting it at that level, but there's still too much we don't know about it imo. Will that be supported by iOS, if and when it supports RCS at a…

The only thing getting RCS any real traction is Google seems to be pushing it in their SMS application, and is now running an RCS server for everyone (or something).

Which basically means, instead of having a federated mess as designed to replace the federated mess of SMS and MMS, we'll get a Google mess, maybe. But if Google was any good at making messenger apps, maybe enough people would use one of them that it wouldn't be killed.

Re: Looking back at how Signal works

#206

Post by brnt » Sat, Jun 06, 2020, 6:52 AM UTC

emptysongglass wrote: post #61

harry8 wrote: post #6

Earlier quoted context omitted.

Burner sim to setup and throw away addresses this concern. Telegram, messages in plaintext on the server? Encryption that isn't open? Yeah telegram is a bit of a non-starter if you have these kinds of concerns as far as I'm aware.

Both of these rhetorical claims are misinformation. Please don't do this. Telegram messages are encrypted at rest on Telegram's servers with the keys held by Telegram the company. [1] MTProto is fully open-source. [2] Here's a FAQ of Telegram's most frequent criticisms. [3] [1] https://telegram.org/faq#q-do-you-process-data-requests [2] https://core.telegram.org/mtproto [3] https://telegra.ph/How-really-secure-and-pr…

I wish it was different, but it isn't. Mtproto v2 seems OK, but it is not default, so hardly used. Server side encryption protects against very little.

I like Telegram, but not for security. Nobody should.

Re: Looking back at how Signal works

#207

Post by brnt » Sat, Jun 06, 2020, 6:55 AM UTC

lsiebert wrote: post #181

Lately I've been wishing Signal had a bridgefy type mesh mode that enabled operation peer to peer over wifi direct or bluetooth, either directly or via a mesh of such devices. First I think it would be useful at protests, to preserve privacy (and whatever side of the political divide you are on, I hope we agree that covert government surveillance and tracking of people at a protest is wrong, here, in HK, or wherever)…

You're looking for the https://briarproject.org

Re: Looking back at how Signal works

#208

Post by vinay427 » Sat, Jun 06, 2020, 6:56 AM UTC

goatsi wrote: post #194

walrus01 wrote: post #70

Earlier quoted context omitted.

One of the other problems with using phone numbers, is that it provides an opening for adversaries. Now they know your phone number, which can be used for social-engineering attacks to attempt to bypass 2FA for any other online services tied to your phone number. Either for 2FA or for account-recovery/i-forgot-my-password functionality. 2FA by SMS is wrong and broken and nobody should use it, but they do. Adversaries…

Signal uses a registration pin to prevent that exact attack.

Maybe I misread, but the GP doesn't seem to be talking about impersonating a user on Signal, but rather impersonating that user on other websites that depend on SMS 2FA sent to their phone number that is now visible through Signal.

Re: Looking back at how Signal works

#209

Post by kagenouta » Sat, Jun 06, 2020, 7:01 AM UTC

toast0 wrote: post #176

kagenouta wrote: post #168

Earlier quoted context omitted.

I, for one, have a bigger problem with it forcing the use of phone numbers as a sign-in method. They're an arbitrary identifier from a legacy system that there's not really a point in continuing to extend, because if your device is capable of anything more advanced than SMS it's also capable of... well, this. Also KaiOS and the like are making chat feasible even on feature phones. Don't get me wrong, RCS will be a fi…

> Don't get me wrong, RCS will be a fine enough fallback (once it's E2E), but standardized chat is the dream. Is there a plan for RCS to be E2E? Given that RCS went under the GSMA umbrella in 2008, and it's 2020 and adoption is minimal, I don't have any hopes for a future update that supports E2E to come out any time sooner than 2040, with handsets supporting it in 2050, and all endpoints supporting it in 2065; Googl…

Tackling this point separately: the entire reason they do this is because they routinely experiment with side projects and then build the ideas that work well into the services that gain traction. As much as it comes with the drawback of being scattershot in general, it specifically creates a track record for failure with messaging because successful messaging products, as a rule, have network effect - something you can't build when you're playing with three different approaches simultaneously.

For an example of where this works really well, look at how all of their adaptive UI efforts feed into each other:

* The enhancements to multiwindow that were built for foldables became Android's desktop mode, to the point that it was built specifically as a test environment and now underpins DeX etc

* Desktop mode's only hardware requirement is a display output, suggesting in addition that Android apps as a whole are no longer bound to specific 1:1 relationships of UI and form factor. (This is, imo, a much bigger deal than we're making it out to be, and opens up possibilities ranging from hybrid game consoles to mobile content creation to better takes at mobile-powered VR.)

* The existence of a base OS implementation and the fact that it's controlled by the system launcher, a component the user can rip and replace, pretty much ensures that custom ROM communities are already toying with this

* Android supports PWAs - installable, natively-scalable webapps - meaning that when desktop mode inevitably stops being feature-flagged there will be examples of convergent apps that work on day 1

* Desktop support for Android apps enhances those same apps when used on ChromeOS

* Flutter, the toolkit built for Fuchsia - an OS designed from the ground up with this sort of scalability in mind - is capable of targeting all of the above

Re: Looking back at how Signal works

#210

Post by emptysongglass » Sat, Jun 06, 2020, 7:03 AM UTC

Legogris wrote: post #138

emptysongglass wrote: post #61

Earlier quoted context omitted.

Both of these rhetorical claims are misinformation. Please don't do this. Telegram messages are encrypted at rest on Telegram's servers with the keys held by Telegram the company. [1] MTProto is fully open-source. [2] Here's a FAQ of Telegram's most frequent criticisms. [3] [1] https://telegram.org/faq#q-do-you-process-data-requests [2] https://core.telegram.org/mtproto [3] https://telegra.ph/How-really-secure-and-pr…

The "encrypted at rest" claim is completely meaningless since there's no way of verifying it. If their web client can read your messages by you reverifying your phone number, so can anyone else with access to their servers.

But that's not true. We can verify a Cloud Chat message is wrapped in a key generated on a user's device. You can look at the client code and prove this. We can also prove that client-server messages must be decrypted on their way back to a user's device. [1]

[1] https://core.telegram.org/mtproto#authorization-and-encrypti...