Technology preview: Sealed sender for Signal • Hacker News Board

Re: Technology preview: Sealed sender for Signal

#131

Post by jake_the_third » Tue, Oct 30, 2018, 11:59 AM UTC

tptacek wrote: post #98

jake_the_third wrote: post #96

Earlier quoted context omitted.

> A small but vocal minority of Signal's user base wants non-phone-number identification. Have you done a survey before arriving to this conclusion. If so, I'd love to take a look at it, if possible. Otherwise, I can't see how you can make this assertion; everything can be dismissed as a "small but vocal minority". As a previous signal user, I stopped using signal because I discovered this issue.

As a previous user of a program that uses phone numbers as identification you stopped using Signal because you discovered that it uses phone numbers as identification?

Yes. More precisely, I stopped when I discovered that I couldn't decouple the signal user from my phone number.

More importantly, I'm still very interested in seeing the data behind your vocal-minority assertion.

Re: Technology preview: Sealed sender for Signal

#132

Post by Terretta » Tue, Oct 30, 2018, 12:14 PM UTC

Certhas wrote: post #117

mintplant wrote: post #82

Earlier quoted context omitted.

I see you explaining and re-explaining the same point throughout this thread: "ordinary users" are used to using phone numbers as identifiers in the messaging apps Signal is trying to replace. That's an answer to the question: why does Signal default to a phone number-based social graph? What it doesn't answer is: why can't Signal also provide an option to add a contact using something other than a phone number? Bold…

Part of being a solution that aims to make secure messaging usable for everyone is that the UX needs to be there. By way of analogy: In every HN thread about Firefox there are dozens of comments by people who say that they just couldn't use Firefox because page loads are so awfully slow. Consider that for a second: HN readers are willing to give their entire browsing history to Google in return for at the very worst…

I don’t buy the UI for discovery thing. Email is fine without discovery. So are.. phone numbers.

I don’t want to be discovered. I want to give you my pseudonymous pointer and you can ping me to connect.

Using phone numbers to ‘discover’ doesn’t solve the problem you say prevented encrypted email adoption, that’s a next step in the dance.

Re: Technology preview: Sealed sender for Signal

#133

Post by tialaramex » Tue, Oct 30, 2018, 12:16 PM UTC

cyphar wrote: post #129

simias wrote: post #121

Earlier quoted context omitted.

Ah, interesting. I assumed that this didn't exist because I had never heard of it and as far as I know there are no third party signal clients out there. Is it just that nobody bothered to do it or is there a catch? Frankly if it's just that nobody did it I might seriously consider adding Rust bindings and making a basic IRC gateway or something like that.

Moxie was against people publishing the official Signal app (rebuilt) on F-Droid specifically because he was against the idea that ordinary users would be exposed to a minor fork of Signal (which would then require them to co-ordinate changes between the two forks). I would be very shocked if he would be any nicer about someone writing an entirely new app from scratch that uses their protocol and inter-operates with…

Right. You're entirely welcome to use Signal's excellent protocol to go build your own thing. "Simias Comms One Thousand" or whatever. You can have that connected to IRC, or interoperate with ICQ, or whatever other nonsense you want. In doing so obviously you destroy most of the upsides of the Signal design, but whatever - your choice.

However you can't label this "Better Signal" (they own a trademark on the Signal name) or connect it to Signal's network.

Re: Technology preview: Sealed sender for Signal

#134

Post by Terretta » Tue, Oct 30, 2018, 12:19 PM UTC

hardwarescope wrote: post #112

balladeer wrote: post #93

Earlier quoted context omitted.

Or maybe let a user sign up with a phone number (as it happens today) but create a unique ID - a user selected username (Telegram, Wire) or auto-generated PIN (BBM) (and then remove any link to that phone number right at the sign up iff the user wants it - it can be hidden in advanced setting UI wise - A). Use the phone number just to prevent spam (though it can't prevent one user having multiple accounts using the s…

I think this issue is more complicated than people realize. There are really only three options here: 1. Use the device's address book (phone numbers). 2. Use Facebook Connect (FB id). 3. Store the entire social graph on the server (custom identifiers). I think #3 is what every messenger that offers non-phone identifiers does (Snapchat, Twitter, Telegram, Wire, Viber, etc). The reason is simple: if someone does manag…

For a counter example, consider Threema. Granted, it can be a rigamarole if you opt out of publishing contact info. But you can. And then backing up and restoring your graph is up to you, or you can rebootstrap people one by one.

On iPhone, after a hardware upgrade w/ restore, Threema offers to restore your client side graph from a client side backup.

Re: Technology preview: Sealed sender for Signal

#135

Post by Terretta » Tue, Oct 30, 2018, 12:31 PM UTC

tptacek wrote: post #88

mintplant wrote: post #82

Earlier quoted context omitted.

I see you explaining and re-explaining the same point throughout this thread: "ordinary users" are used to using phone numbers as identifiers in the messaging apps Signal is trying to replace. That's an answer to the question: why does Signal default to a phone number-based social graph? What it doesn't answer is: why can't Signal also provide an option to add a contact using something other than a phone number? Bold…

I don't understand the complexity or see the blind spot. Your use case is not a priority for them right now.

There are a ton of decidedly non-vocal casuals turning to ‘secure’ messengers to have chats they imagine are ‘military grade’ encrypted (they heard that was good) and not associated with their IRL identity (they consider that a must). They end up using terrible things and their entire chat histories exposed.

But they ‘know’ the phone number is a non starter because that’s how other social networks outed them. So they will also often end up using a string of bad tools as an awkward way to keep several worlds separate.

Most won’t admit it, but this second reason is why they, as iPhone users, aren’t in encrypted Messages for those chats. Neither end wants the chats in their phone number world.

While you can argue this use case is for hiding that one even participates in chats others might frown on, that to me sounds like a use case that matters, since today, most of the world doesn’t agree what should be frowned upon.

// This is not a technical assessment, it’s from the non-technical users’ point of view, how they think it’s working or not working. Same folks assume phone number is more identifying than finding an app that doesn’t need phone number because it can accept their FB log in. It’s a pretty rough world for non-techies.

Re: Technology preview: Sealed sender for Signal

#136

Post by zbentley » Tue, Oct 30, 2018, 12:39 PM UTC

mintplant wrote: post #82

tptacek wrote: post #24

Earlier quoted context omitted.

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…

I see you explaining and re-explaining the same point throughout this thread: "ordinary users" are used to using phone numbers as identifiers in the messaging apps Signal is trying to replace. That's an answer to the question: why does Signal default to a phone number-based social graph? What it doesn't answer is: why can't Signal also provide an option to add a contact using something other than a phone number? Bold…

> Is it simply a question of finite developer time?

Maybe. Or it could be because they don't want to. People equipped to solve one problem may not want to solve another, related problem. It might not be a priority, interest, or motivation for them. That's not apathy; that's decision-making.

Re: Technology preview: Sealed sender for Signal

#137

Post by trash_panda » Tue, Oct 30, 2018, 1:40 PM UTC

lrvick wrote: post #99

tptacek wrote: post #53

Earlier quoted context omitted.

Well, a lot of things seem to speak volumes to you. You're also someone who wants to sysadmin their phones (no judgement, perfectly valid lifestyle choice). When you determined that Signal was making it hard to run through F-Droid, you wrote a long blog post casting aspersions on Moxie Marlinspike's motives. There are two groups of people (among others) Signal clearly doesn't aim to serve: 1. People that are very sen…

You repeatedly accuse F-droid users as people wanting to do sysadmin on their phone, instead of just users with a different threat profile than you. Why can't we just be people that want better day to day security and privacy assurances than we get with stock devices? I have F-droid installed as a system app and the only method for installing apps on my device. It is an AOSP device without Google play services or any…

Google tracks you, yes. But Google also takes good measures to ensure that they are the only ones that can track you (and the Google Play apps of course). You may be obsessed with Google and they tracking you, but that's ok. What I think is wrong is saying that your solution is more private or secure. Privacy relies on security, and I believe your solution is not more secure than a flagship stock Google phone (let's not engage in the Android heterogeneity and lack of updates). I'm sure that any dedicated actor who wants to compromise F-Droid or any of the apps in there could do it without major effort, rendering your privacy useless as you got completely owned. The same for your custom ROMs.

What you achieve with custom ROMs and custom app stores is customization capabilities and nothing more. If you believe you're achieving next-level security or privacy because you don't have Google installed; you're kidding yourself. Yes, you may be leaking (at first glance) less data to advertisers; but you've opened a whole different kind of attacks that could compromise all your data on your phone, not just what Google and the Android platform allow to share.

A perfect example is the "LibreSignal" project you mentioned, what kind of joke was that? The project was abandoned because it didn't get Moxie's blessing? That's a really strong sign of commitment with the cause. I'm sure that LibreSignal has more than zero active users, what do you think about their security/privacy level currently?

Re: Technology preview: Sealed sender for Signal

#138

Post by trash_panda » Tue, Oct 30, 2018, 1:57 PM UTC

zaarn wrote: post #113

Sir_Cmpwn wrote: post #27

Earlier quoted context omitted.

No, it's not. By requiring a phone number, Signal does not defend privacy. This is a binary question, there's not a grey area here. It doesn't matter that they're building a social network, or anything else. What matters is that it's not private so long as they require a phone number.

Privacy is not binary like Security isn't binary. The type and amount of privacy a user wants and what you can realistically achieve beyond that depend on your market and threat model. Thinking Privacy is binary is like thinking IT Security is binary; until it's 100% it doesn't exist. That kind of thinking doesn't allow thinking in incremental improvements.

Privacy and security are intertwined. I believe Signal's decisions are based on the objective of making secure communications easy.

If they catered to what some people want (no phone numbers and federated network) then the regular user would have different options to use Signal. Which one is the correct one? Are they all the same? No. if you decide to develop your own client (like the LibreSignal example), do you trust that the client is secure? If the end application has vulnerabilities, then the communication privacy is compromised. That's why I say they're intertwined. Even Signal suffered from this same thing with the Desktop client. It is not an easy problem to solve, and that's why Signal does not want to have random people creating custom client apps and having them associated with the project, as it could confuse non-technical users.

Re: Technology preview: Sealed sender for Signal

#139

Post by trash_panda » Tue, Oct 30, 2018, 2:05 PM UTC

StudentStuff wrote: post #76

tptacek wrote: post #60

Earlier quoted context omitted.

Of those issues, I believe only mandatory phone numbers are valid, for what it's worth. And I'm fine with mandatory phone numbers; there are other options for people who have a problem with that.

You obviously have a different opinion on what a standard threat model is then...

There is no such thing as a "standard threat model". That's why the threat modeling concept exists in the first place, so you can adapt different solution to different requirements.

It is totally OK if you are extremely worried about hypothetical scenarios where the phone number you used to register to the Signal network can be correlated to your physical location and then a gas station camera filmed you and then all is lost; but I want to believe that really at risk people are smarter than that, and just get a burner phone and even pay a homeless person a few bucks to buy it for them.

There are also ways to get a phone number through the Internet, so you don't even have to go to a physical location to buy it.

I think that's why Signal isn't prioritizing this right now, phone numbers can be a problem? yes. Is it hard to get a fake phone number that is not traceable to you? not really. Next problem please.

I think Signal is achieving the goal of being the default go-to secure messenger. I'm sure, even technical people who like to nerd out on alternatives, faced with a real world risky situation when they have to communicate with a non-technical person, would recommend Signal without a second thought.

Re: Technology preview: Sealed sender for Signal

#140

Post by Certhas » Tue, Oct 30, 2018, 2:08 PM UTC

Terretta wrote: post #132

Certhas wrote: post #117

Earlier quoted context omitted.

Part of being a solution that aims to make secure messaging usable for everyone is that the UX needs to be there. By way of analogy: In every HN thread about Firefox there are dozens of comments by people who say that they just couldn't use Firefox because page loads are so awfully slow. Consider that for a second: HN readers are willing to give their entire browsing history to Google in return for at the very worst…

I don’t buy the UI for discovery thing. Email is fine without discovery. So are.. phone numbers. I don’t want to be discovered. I want to give you my pseudonymous pointer and you can ping me to connect. Using phone numbers to ‘discover’ doesn’t solve the problem you say prevented encrypted email adoption, that’s a next step in the dance.

What exactly do you not buy? I think you might be missing the point on what is meant by discovery here. This is not about random strangers talking to you, but about the issue that you have signal, your friend has signal, but even though you're already in each others phone books you can't talk to each other because you haven't exchanged pseudonymous pointers.

There are exactly two pseudonymous identifiers that have "made it". Both associated to technological revolutions. One is phone numbers, the other is email. You put them on business cards and save them in your contacts.

This is strong evidence that this is a hard problem. No other identifiers have been successful long term.

And yes, this absolutely prevents encrypted email adoption. Imagine if switching to encrypted was like installing signal (back in the SMS fall back days).

It's: "Hey use this email client, it automatically detects when the person you're mailing also has an encryption capable client and then all your communication with that person is encrypted."

vs.

"Hey use this EMail client, and if you find out that someone you know is also using it, you can go to this menu item here and search this database in order to find out how to email them securely, and if that doesn't work just email them normally to get a public key from them, before you send them the document you wanted to send."

No guarantee that the former would work, but it would have a fighting chance.

Of course such a solution isn't possible partly due to usage patterns that email has that would break. But that's why I'm relatively forgiving of Signals strict stance on shooting down these type of feature requests. Because they actually have massively improved secure communication for more than a billion people.