Technology preview: Sealed sender for Signal • Hacker News Board

Re: Technology preview: Sealed sender for Signal

#41

Post by amaccuish » Tue, Oct 30, 2018, 1:32 AM UTC

tptacek wrote: post #24

amaccuish wrote: post #3

Here's an idea, Signal, how about removing the requirement that everything be tied to phone numbers? BBM back in the day worked great with their unique "PINs", that could be shared by QR code, and I could reject an "add" request.

This is the "Go y u no generics" of secure messaging. The answer is always the same: Phone numbers bootstrap a workable social network for ordinary users. Signal's goal is to transform all ordinary messaging into secure messaging. Not elite secure messaging. All messaging . The most popular messaging application in the world uses phone numbers for identifiers (as, obviously, does SMS). That's the goal they've set for…

As others have said, make it a choice. Most users will just click through various screeens and use their phone numbers, others may want to use an email or some other identifier instead. iMessage lets you do both for example.

Re: Technology preview: Sealed sender for Signal

#42

Post by tuxxy » Tue, Oct 30, 2018, 1:33 AM UTC

tptacek wrote: post #30

ikfmpwdsoz wrote: post #28

Earlier quoted context omitted.

But... Wire has both! With generics, you introduce complexity into the language that everyone has to understand, but that's obviously not true when it comes to having accounts that aren't tied to phone numbers!

Wire is a perfectly legitimate option. I'd only ask that you keep in mind that there are other privacy tradeoffs involved in using it.

Do you mind elaborating on those, or providing a link with more details?

Re: Technology preview: Sealed sender for Signal

#43

Post by megablast » Tue, Oct 30, 2018, 1:35 AM UTC

geofft wrote: post #13

I'm not sure I understand the feature. It protects the sender's identity from their servers , or from the recipient ? What's the use case / threat model? I think it prevents their servers from correlating my identity and my IP address etc., but since I want replies and I'm asking the server about replies, doesn't that operation tell the server what my identity is anyway? (There are some comments here talking about an…

Why would you want to protect the identity from the recipient? Unless you wanted to enable spam.

Re: Technology preview: Sealed sender for Signal

#44

Post by tptacek » Tue, Oct 30, 2018, 1:51 AM UTC

tuxxy wrote: post #42

tptacek wrote: post #30

Earlier quoted context omitted.

Wire is a perfectly legitimate option. I'd only ask that you keep in mind that there are other privacy tradeoffs involved in using it.

Do you mind elaborating on those, or providing a link with more details?

Make a list of privacy-preserving things Signal does: the elaborate privacy scheme for user profiles, the special privacy proxy for GIF sharing, the envelope certificate trick they just introduced, &c.

Then go see what other messengers do to provide the same UX.

Depending on the messenger you pick, you will likely not have to give up your phone number, but you will leave the messenger operator with a log of everyone you've communicated with.

Re: Technology preview: Sealed sender for Signal

#45

Post by kijiki » Tue, Oct 30, 2018, 1:51 AM UTC

Paul-ish wrote: post #34

Without cover traffic, its not clear to me that this would prevent a correlation attack from an adversary with resources.

"These protocol changes are an incremental step, and we are continuing to work on improvements to Signal’s metadata resistance. In particular, additional resistance to traffic correlation via timing attacks and IP addresses are areas of ongoing development."

It won't prevent correlation attacks, but it does make metadata attacks in general harder and less confident. An improvement is an improvement even if it doesn't completely solve a problem.

Re: Technology preview: Sealed sender for Signal

#46

Post by StudentStuff » Tue, Oct 30, 2018, 1:53 AM UTC

tptacek wrote: post #25

StudentStuff wrote: post #2

This is an unexpected move, perhaps Briar, Matrix and other distributed platforms are putting more pressure on Signal to show forward progress on the serious metadata issue with Signal and most other centralized platforms? Its been a rallying cry/common complaint by those who are technically inclined and privacy conscious for years now, surprised OWS would choose to give credit to the problem.

No mainstream messenger has ever done a better job with metadata than Signal. It took Signal several years after launch just to get user profiles with names and stuff, purely because of privacy concerns. Read the blog post they wrote about GIF sharing to get a sense of how seriously they take this, then compare how their features work to other mainstream messengers. There is one privacy issue people put pressure on S…

Briar is leading the field on privacy issues today, unlike Signal. There is no metadata leaking who you are sending messages to or from, just a connection to the Tor Network. This problem is still unsolved in Signal, with only partial protection of some messages looking to be added in the future, while mitigation tactics like running your own server are unsupported & discouraged by Open Whisper Systems.

The post about Giphy integration was a great piece of writing about an interesting technical challenge, and Signal's solution to the problem (a TLS proxy run by them, with a client that only accepts Giphy's TLS certificate, making queries quasi-anonymous) is not a bad way to go about solving things.

Re: Technology preview: Sealed sender for Signal

#47

Post by foolfoolz » Tue, Oct 30, 2018, 1:55 AM UTC

tptacek wrote: post #23

Two observations: 1. You should look into what other messengers do with sender/receiver pairs information. One very popular competing messenger logs pairs permanently, serverside, in order to make UI features work. 2. One of the least popular attributes of Signal (on Hacker News, at least) is its lack of federation and ability to interoperate with third-party clients. This feature is a pretty crystalline example of t…

#2 is part of the trade off for more privacy vs ease of use. this goes all the back to classic pgp

Re: Technology preview: Sealed sender for Signal

#48

Post by tptacek » Tue, Oct 30, 2018, 1:55 AM UTC

StudentStuff wrote: post #46

tptacek wrote: post #25

Earlier quoted context omitted.

No mainstream messenger has ever done a better job with metadata than Signal. It took Signal several years after launch just to get user profiles with names and stuff, purely because of privacy concerns. Read the blog post they wrote about GIF sharing to get a sense of how seriously they take this, then compare how their features work to other mainstream messengers. There is one privacy issue people put pressure on S…

Briar is leading the field on privacy issues today, unlike Signal. There is no metadata leaking who you are sending messages to or from, just a connection to the Tor Network. This problem is still unsolved in Signal, with only partial protection of some messages looking to be added in the future, while mitigation tactics like running your own server are unsupported & discouraged by Open Whisper Systems. The post abou…

I am willing to stipulate "short of running everything over Tor" for the sake of argument.

Re: Technology preview: Sealed sender for Signal

#49

Post by int_19h » Tue, Oct 30, 2018, 1:56 AM UTC

tptacek wrote: post #24

amaccuish wrote: post #3

Here's an idea, Signal, how about removing the requirement that everything be tied to phone numbers? BBM back in the day worked great with their unique "PINs", that could be shared by QR code, and I could reject an "add" request.

This is the "Go y u no generics" of secure messaging. The answer is always the same: Phone numbers bootstrap a workable social network for ordinary users. Signal's goal is to transform all ordinary messaging into secure messaging. Not elite secure messaging. All messaging . The most popular messaging application in the world uses phone numbers for identifiers (as, obviously, does SMS). That's the goal they've set for…

Why do you think there are no "ordinary users" who don't have phone numbers, or don't have them in a manner that Signal needs? For example, it's pretty common for older people (especially in less technologically developed countries) to not have smartphones.

I personally know at least one person who can't use Signal because they don't have a smartphone to install it on (but could install it on the desktop, if the desktop app didn't require the phone app to be configured first). I know two more people who can't use it because they use tablets, and Signal still hasn't released a table version, even one that works the same as the desktop one.

Re: Technology preview: Sealed sender for Signal

#50

Post by tptacek » Tue, Oct 30, 2018, 1:57 AM UTC

foolfoolz wrote: post #47

tptacek wrote: post #23

Two observations: 1. You should look into what other messengers do with sender/receiver pairs information. One very popular competing messenger logs pairs permanently, serverside, in order to make UI features work. 2. One of the least popular attributes of Signal (on Hacker News, at least) is its lack of federation and ability to interoperate with third-party clients. This feature is a pretty crystalline example of t…

#2 is part of the trade off for more privacy vs ease of use. this goes all the back to classic pgp

The PGP ecosystem is a pretty great example of what happens when you target unbounded interoperability.