Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technology preview: Sealed sender for Signal

signal.org

Post reply on HN
Print view View original

91–100 of 162 posts

Re: Technology preview: Sealed sender for Signal

#91

Post by tptacek »

comex wrote: post #90
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…

> This is the "Go y u no generics" of secure messaging. Yes, it is – and it turns out that Go 2 will be adding generics. Before that, you could have said "If generics are super-important to you, use Rust." But it turns out you can have both Go and generics, and (if you prefer Go over Rust for other reasons) that's even better than having to pick one or the other. The designers made a choice to omit generics in the in…

Me too! I don't love the phone number thing. But I understand it.

Re: Technology preview: Sealed sender for Signal

#92

Post by tptacek »

mintplant wrote: post #89
tptacek wrote: post #88

Earlier quoted context omitted.

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

I'll re-rephrase. Is it a problem of: (1) allocating developer time and organizational priorities; or, (2) a technical incompatibility with Signal's existing, phone number-based model? Based on your response I'm inferring (1), but I'm frustrated that this is never directly answered when the topic comes up.

It's more (1) than (2), is what I think, although I think non-phone authentication is probably trickier than we think it is and so the two categories bleed a bit.

I seriously don't understand what people expect in these discussions, though. The situation is straightforward. A small but vocal minority of Signal's user base wants non-phone-number identification. Signal hasn't prioritized that feature. Put up, or use a different messenger. How is this complicated?

Don't pick horrible messengers, like ones where encryption isn't enabled by default, or doesn't even exist for group messages, or isn't built on a protocol anyone understands or has reviewed. But even with that constraint, you have options.

Re: Technology preview: Sealed sender for Signal

#93

Post by balladeer »

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…

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 same phone number).

This will serve two use cases:

1. People who need simple private IM like WhatsApp can continue using it without asking for A or without giving it any heed.

2. Or you go for A and you are communicating w/o any real world identity attached to your messages.

Re: Technology preview: Sealed sender for Signal

#94

Post by [deleted] »

akvadrako wrote: post #33
windexh8er wrote: post #20

Earlier quoted context omitted.

"Unreliable" - It's not. I've been using it since the early RedPhone and TextSecure days. The only times it's been remotely unreliable is because of my connectivity. I can say I've never had either a lost picture or file sent to me that I can recall. My family and circle of friends (~40 people) use it daily. I just transferred my backup from my old phone to a new one (which by the way thank you for implementing real…

Sorry but you must see how that's obviously jumping to conclusions. Just because you haven't had issues with Signal doesn't mean it's reliable. I have been using it for 3 years and struggle to recommend it to people because I constantly have reliability issues, including messages delayed for hours, bugs where contacts get in an unusable state and other little weird things. Whatsapp doesn't have these issues, so even…

[deleted]

Re: Technology preview: Sealed sender for Signal

#95

Post by agnokapathetic »

joecool1029 wrote: post #68
tptacek wrote: post #67

Earlier quoted context omitted.

The Signal team essentially invented the cryptographic constructions the current wave of (good) secure messengers are based on, work for which they were awarded the Levchin Prize at RWC (for perspective, this year's winner was Hugo Krawczyk). They did the work, then published it, for the other messaging systems to adopt --- which is why you can easily get a comparable, though inferior, version of Signal's cryptograph…

> which is why you can easily get a comparable, though inferior, version of Signal's cryptography in a messenger that doesn't require phone numbers. How so? Are things like OMEMO different cryptographically from Signal protocol?

OMEMO just implements the Double Ratchet Algorithm that Perin and Marlinspike created for Signal as an XMPP extension.

[1] https://en.wikipedia.org/wiki/OMEMO

[2] https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm

Re: Technology preview: Sealed sender for Signal

#96

Post by jake_the_third »

tptacek wrote: post #92
mintplant wrote: post #89

Earlier quoted context omitted.

I'll re-rephrase. Is it a problem of: (1) allocating developer time and organizational priorities; or, (2) a technical incompatibility with Signal's existing, phone number-based model? Based on your response I'm inferring (1), but I'm frustrated that this is never directly answered when the topic comes up.

It's more (1) than (2), is what I think, although I think non-phone authentication is probably trickier than we think it is and so the two categories bleed a bit. I seriously don't understand what people expect in these discussions, though. The situation is straightforward. A small but vocal minority of Signal's user base wants non-phone-number identification. Signal hasn't prioritized that feature. Put up, or use a…

> 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.

Re: Technology preview: Sealed sender for Signal

#97

Post by spockz »

tptacek wrote: post #92
mintplant wrote: post #89

Earlier quoted context omitted.

I'll re-rephrase. Is it a problem of: (1) allocating developer time and organizational priorities; or, (2) a technical incompatibility with Signal's existing, phone number-based model? Based on your response I'm inferring (1), but I'm frustrated that this is never directly answered when the topic comes up.

It's more (1) than (2), is what I think, although I think non-phone authentication is probably trickier than we think it is and so the two categories bleed a bit. I seriously don't understand what people expect in these discussions, though. The situation is straightforward. A small but vocal minority of Signal's user base wants non-phone-number identification. Signal hasn't prioritized that feature. Put up, or use a…

I think mintplant intentions are simply to figure out why Signal is sticking to using phone numbers as ID. I can imagine wanting a tool you like and trust to get broader adoption.

Re: Technology preview: Sealed sender for Signal

#98

Post by tptacek »

jake_the_third wrote: post #96
tptacek wrote: post #92

Earlier quoted context omitted.

It's more (1) than (2), is what I think, although I think non-phone authentication is probably trickier than we think it is and so the two categories bleed a bit. I seriously don't understand what people expect in these discussions, though. The situation is straightforward. A small but vocal minority of Signal's user base wants non-phone-number identification. Signal hasn't prioritized that feature. Put up, or use a…

> 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?

Re: Technology preview: Sealed sender for Signal

#99

Post by lrvick »

tptacek wrote: post #53
Sir_Cmpwn wrote: post #38

Earlier quoted context omitted.

>Clearly Signal has improved privacy compared to other messaging platforms as has been proven by subpoenas by law enforcement. Secure systems are not built on trust. They're built with math and with facts. Their goal isn't based on what tptacek said just because tptacek said it, either. If I'm wrong and privacy isn't their goal, well that speaks volumes on its own.

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 anything proprietary save for the minimum blobs required to allow the device to boot and communicate with the cell networks.

I don't enable root, as normally assumed of users that don't run stock. Doing so on Android is a well known terrible security idea. This is a hardened personal device where I choose to opt out of Google tracking, and backdoors like SprintDM.apk that Google bundles with their stock OS.

In order to install signal without Google Play I would need to turn on unverified sources on my phone and open myself up to Man In The Disk style attacks, and other security issues.

This is ridiculuous that a company that champions itself an advocate for security and privacy refuses to support users like me that opt out of proprietary software and the tracking systems that come with them.

Moxie not only said he will never support third party signed installation methods like F-Droid but has been actively hostile to those trying to do this for him.

Example: https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

Moxie suggesting people fork and make their own private network that simply want a secure installation method of third party signed/verified binaries on security optimized Android devices is irresponsible and does not inspire trust.

Re: Technology preview: Sealed sender for Signal

#100

Post by killjoywashere »

tgsovlerkhgsel wrote: post #78
upofadown wrote: post #64

Earlier quoted context omitted.

Yes you can do stuff more easily if you control all parts of the network. That doesn't mean we have to give up on standards based messaging just because it is harder. In the long run silo based systems are more work because you have to reinvent everything every time you create the next entirely incompatible system. If that system doesn't catch on then you have to reinvent everything again and again until you get luck…

On the other hand, Signal works. Messages get delivered and phone calls get established. All the open/interoperable solutions that I found were sufficiently broken that I no longer use them, since it felt like I was spending more time debugging them than actually communicating.

+1. Even my mom and dad use Signal. Like, use it. Not can use it. They use it.
Post reply on HN