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

141–150 of 162 posts

Re: Technology preview: Sealed sender for Signal

#141

Post by cyphar »

tialaramex wrote: post #133
cyphar wrote: post #129

Earlier quoted context omitted.

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 n…

> However you can't [...] connect it to Signal's network.

Which is precisely what this thread is talking about.

Re: Technology preview: Sealed sender for Signal

#142

Post by ric2b »

esotericn wrote: post #116

I'm confused here. It seems the identities are trivially linkable via the IP address. The Signal servers can't determine cryptographically that the message originates from Device A. But it is certainly from device A, because this isn't a peer to peer protocol. It seems to me like what you'd need to make this work is some sort of intermediate layer, a bit like onion routing, that would have messages arrive at the Sign…

I think the point is that they can simply discard IP addresses as soon as they receive the message.

If later they get a request from the NSA to look at their database, the undelivered messages can no longer be traced back to the sender.

Re: Technology preview: Sealed sender for Signal

#143

Post by ric2b »

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…

It makes their database of undelivered messages even more useless.

Yes, their servers can see your IP but if they discard it immediately you're safer if the NSA or another government agency reaches out to them.

Re: Technology preview: Sealed sender for Signal

#144

Post by ngngngng »

windexh8er wrote: post #20
ngngngng wrote: post #12

How does signal do media messages? All the time i'll open signal and see someone sent a picture but I have to download it. If signal doesn't store anything on it's own servers but ip and timestamp, where is this media message stored after it's sent but before I received? Am I just downloading it from the device that sent it to me? That would explain why it's so unreliable.

"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…

Signal is great, but on my home internet sending and receiving a photo in fb messenger or whatsapp might take 3-4 seconds total. In signal it regularly takes 30 seconds just to send or receive. I'm inclined to believe that's a problem with signal.

Re: Technology preview: Sealed sender for Signal

#145

Post by esotericn »

ric2b wrote: post #142
esotericn wrote: post #116

I'm confused here. It seems the identities are trivially linkable via the IP address. The Signal servers can't determine cryptographically that the message originates from Device A. But it is certainly from device A, because this isn't a peer to peer protocol. It seems to me like what you'd need to make this work is some sort of intermediate layer, a bit like onion routing, that would have messages arrive at the Sign…

I think the point is that they can simply discard IP addresses as soon as they receive the message. If later they get a request from the NSA to look at their database, the undelivered messages can no longer be traced back to the sender.

Aha! I see now. So it's a temporal thing.

Previously, an undelivered message would have to sit on Signal's servers with the sender's metadata in cleartext. Now, it doesn't.

Re: Technology preview: Sealed sender for Signal

#146

Post by simias »

tialaramex wrote: post #133
cyphar wrote: post #129

Earlier quoted context omitted.

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 n…

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

What I had in mind was to make a gateway that would act as an IRC server, not client. Basically I'd run it alongside my usual IRC client and use it to access Signal discussions using the same interface that I already use to browse IRC. The IRC connection would be local and completely trusted so as far as I understand it nothing would be "destroyed". Alternatively I could just write an irssi plugin that would directly connect to Signal for instance.

Basically what I want is to use Signal as it is today but with a different UI. I don't want to tweak the protocol or anything like that and I'm perfectly happy using a Signal-sanctioned implementation of the protocol.

I suppose they could forbid non-official clients to connect to the network (although I'm not sure why they would care) but then since as far as I know the server-side software is not available in any form it's not like I can rehost it anyway.

Re: Technology preview: Sealed sender for Signal

#147

Post by dbrgn »

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…

Threema had decentralized, user-controllable (yep/whitelist/nope) avatars for longer than Signal had their server-stored avatars :) And without the requirement of linking your identity to a phone number.

Re: Technology preview: Sealed sender for Signal

#148

Post by tialaramex »

simias wrote: post #146
tialaramex wrote: post #133

Earlier quoted context omitted.

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 n…

>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. What I had in mind was to make a gateway that would act as an IRC server, not client. Basically I'd run it alongside my usual IRC client and use it to access Signal discussions using the same interface that I already…

I agree that your local server IRC doesn't obviously make the security story much worse (although it does throw an entire IRC client into the mix which isn't good news security wise).

In practice I suspect that if you just build this and use it, that will actually work. If you make a big song and dance, I suspect Moxie will tell you this is not allowed.

Re: Technology preview: Sealed sender for Signal

#149

Post by simias »

tialaramex wrote: post #148
simias wrote: post #146

Earlier quoted context omitted.

>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. What I had in mind was to make a gateway that would act as an IRC server, not client. Basically I'd run it alongside my usual IRC client and use it to access Signal discussions using the same interface that I already…

I agree that your local server IRC doesn't obviously make the security story much worse (although it does throw an entire IRC client into the mix which isn't good news security wise). In practice I suspect that if you just build this and use it, that will actually work. If you make a big song and dance, I suspect Moxie will tell you this is not allowed.

>I agree that your local server IRC doesn't obviously make the security story much worse (although it does throw an entire IRC client into the mix which isn't good news security wise).

Irssi's codebase is probably a tiny, tiny fraction of the electron framework and it's super stable these days. Meanwhile didn't Signal suffer an HTML tag injection vulnerability a while ago? But anyway, that's besides the point.

>In practice I suspect that if you just build this and use it, that will actually work. If you make a big song and dance, I suspect Moxie will tell you this is not allowed.

Okay I see. I hope eventually they'll open the door a little so that we'll be able to build around the application in broad daylight. But hey, that's their project and they give it out for free so who am I to complain? Maybe one day I'll seriously consider implementing Simias Comms 1000 (tm).

Thank you for the feedback.

Re: Technology preview: Sealed sender for Signal

#150

Post by bjoli »

dbrgn wrote: post #147
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…

Threema had decentralized, user-controllable (yep/whitelist/nope) avatars for longer than Signal had their server-stored avatars :) And without the requirement of linking your identity to a phone number.

But they still claim that TLS provides proper forward secrecy, which is of course is true for a passive attacker, but not for a malicious server.
Post reply on HN