Live data from Hacker News

Signal Server code on GitHub is up to date again

github.com

171–180 of 206 posts

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

#171

Earlier quoted context omitted.

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

> 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

What exactly do they rely on google for? They use them for their push notifications and they use some google servers on the back end.

They do offer the app on the app store as 99% of android users get their apps that way, but signal also offers app downloads from the signal website if the user doesn't want to use play store.

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

#172
post #64

Earlier quoted context omitted.

> highly secure alternative exists in the form of matrix At least for metadata, as of now, Signal seems to provide better guarantees than Matrix. I can imagine Matrix competing with Discord and Slack, but I don't think they'll ever be able to compete with WhatsApp and Signal. You can blame "stupid" users and the media all you want, that won't change the path of least resistance. I really like Matrix as an IRC replace…

> At least for metadata, as of now, Signal seems to provide better guarantees than Matrix. Agree here. Matrix servers log everything by default. If somebody cares about protecting metadata, I don't know why they'd choose Matrix over Signal.

The people screaming the loudest about how signal is bad for x reason always seem to be the ones recommending y(usually matrix) that suffers the same issue.

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

#173
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…

> Whether or not Signal's server is open source has nothing to do with security.

Wrong. Availability is a core component of security. Keeping your server implementation closed and only available from one single entity gives signal a failing grade in my book.

Signal is great for one-off messaging but is a poor long-term solution for secure instant messaging.

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

#174

kinda crazy that the signal team doesn't GPG sign their commits.

A example of how irrational hate can make smart people do stupid things, unfortunately.

Certain people on their team don't like the PGP standard despite the fact that it is mature, standardized, and proven to work well for code signing. When questioned about their reasoning, they'd usually deflect and criticize some aspect of PGP that is irrelevant to code signing at all.

In their minds, they believe it is better to rely on git's broken SHA1 fingerprints than to use PGP.

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

#175
post #146

Earlier quoted context omitted.

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?

By silent, I don't just mean they held back commits. They were evasive about it the entire time. They could have explained and chose not to.

They don't owe me anything but I think it's a shame that the leading open source messenger app does such a poor job of communicating with its users and the larger open source community.

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

#176
post #129

Earlier quoted context omitted.

> A lot of these comments are just manifestations of the kneejerk HN "crypto bad" reflex. Nope. It's a reaction to "who the f* asked for this in a messaging app?!".

Unless you have your head thoroughly buried in the sand, you'd understand that all the major players allow people to send money AND people are using those platforms to send money. When people evaluate a new messaging client, the minimum feature set required to be considered viable now includes sending money for a lot of the population. * removed insult

> all the major players allow people to send money AND people are using those platforms to send money.

So if major players jump off a cliff, everyone should always follow?

> the minimum feature set required to be considered viable now includes sending money for a lot of the population.

? No, thank you. Not where the actual banking system is working.

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

#177
post #145

Earlier quoted context omitted.

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.

You cannot currently run your own Signal server, no. That's what prevents mobility.

You are free to examine the source of theirs (if they choose to continue releasing it), but you cannot self-host.

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

#178
post #166
post #164

Earlier quoted context omitted.

Sure, it would be nice if any software were open source, but that you are entitled for it? Funny attitude.

There's plenty of writing on that issue [1]. It makes a lot of sense to think of people being actually entitled to certain rights, especially in domains with network effects. Btw, the Signal Foundation is a non-profit organization that benefits from community goodwill based on an open-source ethos. So people are critical when its software is closed source. [1] https://www.gnu.org/philosophy/free-sw.en.html

I don't think a piece on gnu.org qualifies as "plenty of writing" and for sure doesn't count as basis for what you are entitled for :).

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

#179
post #93
post #73

Earlier quoted context omitted.

And of course, that's exactly why people were recommending Signal. Of all the practically frictionless apps it provided best encryption.

privacy isn't just encryption. Forcing users to link their phone number as an identifier like signal does is just one of the myriad of questionable choices signal has made. And with their coin based payment they just painted a large bullseye on them.

Sure, and if there had been a frictionless alternative that didn't require that, that would've been great - but there wasn't.

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

#180

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…

Addendum: Out of pure interest I just went into a deep dive into the Signal-Android repository and tried to figure out where exactly the SGX remote attestation happens. I figured that somewhere in the app there should be hash or something of the code running on the servers. Unfortunately, `rg -i SGX` only yielded the following two pieces of code: https://github.com/signalapp/Signal-Android/blob/master/libs... https:/…

[deleted]
Post reply on HN