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

Signal Server code on GitHub is up to date again

github.com

Post reply on HN
Print view View original

141–150 of 206 posts

Re: Signal Server code on GitHub is up to date again

#141

Post by selykg »

emptysongglass wrote: post #137
woah wrote: post #96

A lot of these comments are just manifestations of the kneejerk HN "crypto bad" reflex. Here's the deal: - Whether or not Signal's server is open source has nothing to do with security. Signal's security rests on the user's knowledge that the open source client is encrypting messages end to end. With that knowledge, the server code could be anything, and Signal inc. would still not be able to read your messages. In f…

You're apologizing for a project that has repeatedly damaged user trust with excuses. These are "valid" reasons for keeping the source code private for a year? By whose book? Yours? Certainly not by mine. I wouldn't let any other business abscond from its promise to keep open source open source in spirit and practice, why would I let Signal? This is some underhanded, sneaky maneuvering I'm more used to seeing from th…

Repeatedly? This is the first I'm aware of, what are the others?

Re: Signal Server code on GitHub is up to date again

#143

Post by mindslight »

iudqnolq wrote: post #134
mindslight wrote: post #110

Earlier quoted context omitted.

Signal's choices never really felt right, as their justifications tended towards authoritarian paternalism - eg willfull reliance on Play services, keeping it out of F-Droid (which while flawed as Signal pointed out, seems to be the best we currently have), bottleneck centralized servers, and phone numbers as primary identifiers (?!). But the standard Free Software development/distribution model does lack in some are…

I don't agree with adding cryptocurrencies, but I was very sympathetic to the play services argument. Android is very difficult to program for, and it's even more difficult without play services. For notifications the alternatives are noticably worse (higher battery usage because you can't coordinate request timings with other apps, an annoying permanent notification), and the leakage is minimal. If you protect your…

I said willfully for a reason, as opposed to just reluctantly.

I agree about the sorry state of non-Google notifications on Android. I wish someone would make a common notification framework for the Free world that would be installed alongside system-level F-Droid. Although F-Droid Conversations and Element notifications do work fine for me, regardless of purportedly less battery life, I can understand not everyone wants to make the same choice.

However, I'm referencing more than the notifications issue. I recall an early thread from Signal where they touted the benefits of fully opting into the Google ecosystem - the gist was that Google has expended all of this effort on security and they wanted to take advantage of it to bring security to the masses. And that simply doesn't line up with my own threat model, in which Google is one of the most significant attackers.

Re: Signal Server code on GitHub is up to date again

#144

Post by outime »

theptip wrote: post #128
kelnos wrote: post #122

Earlier quoted context omitted.

The server being or not being secure is only important to the people who operate it. You can examine the client code and see that your messages are encrypted end to end. Signal's entire security model revolves around the idea that you don't need to trust the server.

There's no concern about metadata leakage?

Even if you have access to an up-to-date source code it doesn't guarantee at all they'd be running a completely different version if so they wish. I mean this have just happened yet this question kind of implies you'd still trust such entity to run the server from the source code you have access to. I hope this collective illusion dies already.

Re: Signal Server code on GitHub is up to date again

#145

Post by kreetx »

lucideer wrote: post #117
kreetx wrote: post #113

Earlier quoted context omitted.

But now the server code is there, so we now have this mobility, no?

Yes and no. Signal is not actually designed with mobility in mind (in fact I would argue, based on Moxie's 36C3 talks, it was designed to be and continues to be persistently kept anti-mobility). That fact is independent of it being open- or closed-source. However, if the server is open-source, it opens the door for future mobility in the event of org change. If it's closed-source, you get what's currently happening w…

So in principle we do have this mobility because you can run your own servers. Perhaps it is not all that unlikely that they will do a bridge to matrix.

Re: Signal Server code on GitHub is up to date again

#146

Post by kreetx »

acrispino wrote: post #116
kreetx wrote: post #113

Earlier quoted context omitted.

But now the server code is there, so we now have this mobility, no?

Until they decide to go silent for another 11 months

Most of the popular chat-app space is not open source. What is it with Signal that people feel entitled to condemn it for not having the latest commits on github?

Re: Signal Server code on GitHub is up to date again

#147

Post by grumpyautist »

dtx1 wrote: post #59
grumpyautist wrote: post #58

Earlier quoted context omitted.

Matrix is still broken though. I find XMPP to be sufficient at least until matrix fixes their group encryption

Got a source for matrix group encryption issues? EDIT: From their [FAQ]( https://matrix.org/faq/ ) > End-to-End Encryption is fully supported in Matrix. New rooms have encryption enabled by default, and all existing rooms can optionally have End-to-End Encryption turned on. What exactly do you think is broken here?

In group chat constantly there are members who you cannot decrypt.

Re: Signal Server code on GitHub is up to date again

#148

Post by codethief »

wolverine876 wrote: post #139
codethief wrote: post #126

Earlier quoted context omitted.

> Whether or not Signal's server is open source has nothing to do with security This true only when you are exclusively concerned about your messages' content but not about the metadata. As we all know, though, the metadata is the valuable stuff. There is a second reason it is wrong, though: These days, lots of actual user data (i.e. != metadata) gets uploaded to the Signal servers[0] and encrypted with the user's Si…

> These days, lots of actual user data (i.e. != metadata) gets uploaded to the Signal servers[0] and encrypted with the user's Signal PIN (modulo some key derivation function). Unfortunately, many users choose an insecure PIN, not a passphrase with lots of entropy, so the derived encryption key isn't particularly strong. If I understand what you are saying and what Signal says, Signal anticipates this problem and pro…

> If I understand what you are saying and what Signal says, Signal anticipates this problem and provides a solution that is arguably optimal

Yep, this is what I meant when I said "This is where a technology called Intel SGX comes into play". :)

And you're right, SGX is better than nothing if you accept that people use insecure PINs. My argument mainly was that

- the UI is designed in the worst possible way and actually encourages people to choose a short insecure PIN instead of recommending a longer one. This means that security guarantees suddenly rest entirely on SGX.

- SGX requires the server code to be verified and published (which it wasn't until yesterday). Without verification, it's all pointless.

> uses a key derivation function to maximize the master key's entropy

Nitpick: Technically, the KDF is deterministic, so it cannot change the entropy and – as the article says – you could still brute-force short PINs (if it weren't for SGX).

> I'd love to hear from a security specialist regarding this scheme. I'm not one and I had only limited time to study the link above.

Have a look at link [1] in my previous comment. :)

Re: Signal Server code on GitHub is up to date again

#149

Post by mindslight »

jedberg wrote: post #99
dtx1 wrote: post #80

Earlier quoted context omitted.

Then the reality is that those users cannot expect privacy anymore

This part I disagree with. They can (and should) lobby for laws that protect their privacy. Users don't want to give up convenience, but if the majority are using the services of BigCorp, and we push to force BigCorp to provide privacy through legislation, then society still wins.

Lobbying for privacy laws requires legal knowledge to know which proposals can actually be effective, otherwise one is merely lending their uninformed support to whatever the media tells them is a good idea today.

It all comes down to self actualization, no matter how you slice it. Installing Element instead of Signal (even with its @weird%identity.syntax) is quite technically easy, especially compared to politics! The issue is almost entirely social, in that it requires pushing back on friends who want you to install the proprietary stuff to communicate, and pushing them to the Free solutions.

Post reply on HN