It looks like Signal isn't as open source as you thought it was anymore(androidpolice.com)
androidpolice.com
It looks like Signal isn't as open source as you thought it was anymore
https://www.androidpolice.com/2021/04/06/it-looks-like-signal-isnt-as-open-source-as-you-thought-it-was-anymore/
185 comments
https://news.ycombinator.com/item?id=26345937
This is for sure not a duplicate and should be restored to it's rightful spot.
Edit: Also, you cannot post on the other link for some reason?
Edit: Also, you cannot post on the other link for some reason?
The significant new thing in this story is on the front page already:
https://news.ycombinator.com/item?id=26713827
The rest is a dupe-by-value, which is how dupuolity works on HN.
https://news.ycombinator.com/item?id=26713827
The rest is a dupe-by-value, which is how dupuolity works on HN.
There were so many Signal threads yesterday that it was hard to sort out which were technically dupes vs not. When they all overlap into the same discussion, they're all morally dupes anyhow.
There's another active thread today: https://news.ycombinator.com/item?id=26725915
There's another active thread today: https://news.ycombinator.com/item?id=26725915
Can I ask why this is flagged as a duplicate? The comment threads in here feel substantially different than what was being discussed in that older thread linked there.
That the repo was still without current code, another month later, was certainly interesting & novel to lots of people - especially given the 3x upvotes compared to the older story!
But also: now that the linked page has been updated to reflect that Signal has pushed a newer version of source, it's fresh news again, under its current headline. (If it was, by chance, attention to this 'old news' that prompted Signal's update, that also suggests it was more than a simple 'dupe' in significance.)
But also: now that the linked page has been updated to reflect that Signal has pushed a newer version of source, it's fresh news again, under its current headline. (If it was, by chance, attention to this 'old news' that prompted Signal's update, that also suggests it was more than a simple 'dupe' in significance.)
It looks like they had been working on adding MobileCoin support server side https://signal.org/blog/help-us-test-payments-in-signal/ .
Just a few minutes ago the server code was updated. Im honestly not happy about this. Feels yucky
Just a few minutes ago the server code was updated. Im honestly not happy about this. Feels yucky
Yep the date matches perfectly, they hid the signal-server repository explicitly to keep their MobileCoin integration secret for a year. This is bad even for them.
> they hid
how did they hide anything? do you know this code has been in production?
how did they hide anything? do you know this code has been in production?
If this code was _not_ in production, they had known vulnerabilites: https://github.com/signalapp/Signal-Server/commit/3432529f9c...
There is no interpretation of these events that's a good look, especially for a platform focused on privacy.
There is no interpretation of these events that's a good look, especially for a platform focused on privacy.
we're talking about the code released today.
All of the code was released today. Up until earlier today, the most recent public commit on the repo was https://github.com/signalapp/Signal-Server/commit/3432529f9c... , the commit immediately prior to the previously unseen https://github.com/signalapp/Signal-Server/commit/95f0ce1816... "Support for advertising payment addresses on profile"
Yes, they released a new feature so theres new code. The only way that violates open-source is if this code has been in production, which no one has any proof of.
Apparently everyone thinks opensource means real time access to development.
Apparently everyone thinks opensource means real time access to development.
Please re-read my comment four posts upthread. It's possible that this code wasn't in production; if so, there were known vulnerabilities left open for months.
im a little confused what the argument is here. TFA is implying a bunch of server code is being updated without telling anyone, violating their open-source stance. then they release a post, possibly in response to criticism, saying they've been working on a major feature thats ready for its beta release. so now youre arguing the feature they chose to work on feels yucky? this is textbook goalpost moving.
i use signal and my impression of moxie is extremely positive. at face value, a payment system built by moxie and the signal team with cryptocurrency screams "incredible". kind of taken aback by the overwhelming negativity around here.
i use signal and my impression of moxie is extremely positive. at face value, a payment system built by moxie and the signal team with cryptocurrency screams "incredible". kind of taken aback by the overwhelming negativity around here.
I would agree if the post by Signal would say "Hey, we know the server code hasnt been updated in a while, yall have been asking, so here is the updated source and this is the reason why. We have working to incorporate MobileCoin yada yada"
People have been asking about the server code for a while, with zero response or even acknowledgement.
No explanation why, no apology.... just boom, new crypto support in our server. Trust us its cool.
They knew this would be a bad look from the get go , to they did it in secret.
People have been asking about the server code for a while, with zero response or even acknowledgement.
No explanation why, no apology.... just boom, new crypto support in our server. Trust us its cool.
They knew this would be a bad look from the get go , to they did it in secret.
I mean, for what it's worth, the MobileCoin bits weren't truly secret - that "turmoil in Signal" article that made the rounds a few months ago explicitly made mention of this, and the recent MOB runup in the past few weeks had rumors of this flying around.
Leaks don't change the fact they tried to keep it a secret. The article was published 9 months after they stopped releasing server source. And Marlinspike dismissed the MobileCoin work as "design explorations".[1]
[1] https://www.platformer.news/p/-the-battle-inside-signal
[1] https://www.platformer.news/p/-the-battle-inside-signal
That's by definition a scoop and not a piece of communications from Signal itself.
AFAIR there was even a discussion here on HN a few years ago that Moxie had started collaborating with MobileCoin. No news, really.
News to most people.
https://news.ycombinator.com/item?id=15935583
https://www.wired.com/story/mobilecoin-cryptocurrency/
https://techcrunch.com/2018/04/24/mobilecoin-moxie-marlinspi...
https://www.wired.com/story/mobilecoin-cryptocurrency/
https://techcrunch.com/2018/04/24/mobilecoin-moxie-marlinspi...
What percent of Signal users do you think read either of those articles?
And Marlinspike advising MobileCoin isn't the same as Signal developers actually integrating it.
They might be wanting to get the jump on the competition.
Actually that feels like a reasonable reason for keeping the source temporarily secret.
I've been worried about it but now I see they had a good reason I have hope the behavior changes.
I've been worried about it but now I see they had a good reason I have hope the behavior changes.
It leaves a bad taste honestly. They've done it once, offered no explanation inspite of people asking all the time. What they have done has eroded trust, whose to say what they have published is the latest ? What more could they be hiding ??
> a reasonable reason for keeping the source temporarily secret.
that's the crux, isn't it though? lots of people don't. that's a pretty big implicit ask there.
that's the crux, isn't it though? lots of people don't. that's a pretty big implicit ask there.
[deleted]
> While communication is guaranteed to be secure due to the end-to-end encryption implemented in the open-source client apps and the Signal protocol
So the client is open source and guarantees end-to-end encryption regardless of what the server does. Ok, then I honestly don't care. Why should I?
I use Signal for its safety characteristics, which as stated are apparently ensured by the client regardless of what the server does, not because of the server, and I continue to agree with Moxie that federation is a white whale that doesn't solve any regular person problems.
So the client is open source and guarantees end-to-end encryption regardless of what the server does. Ok, then I honestly don't care. Why should I?
I use Signal for its safety characteristics, which as stated are apparently ensured by the client regardless of what the server does, not because of the server, and I continue to agree with Moxie that federation is a white whale that doesn't solve any regular person problems.
I tend to agree with you - but keybase made a similar argument and then sold out their users to Zoom (with all of the concerns around the CCP's influence over Zoom). When that happens there isn't much recourse except to jump ship.
I think this is unlikely with Signal since Brian Acton's $50M donation is contingent on them keeping inline with the mission (iirc) and also Moxie being involved is a good sign. Plus, realistically if the company gets ruined you're probably better of jumping ship anyway (as long as there's somewhere else to go - matrix? urbit?).
I think this is unlikely with Signal since Brian Acton's $50M donation is contingent on them keeping inline with the mission (iirc) and also Moxie being involved is a good sign. Plus, realistically if the company gets ruined you're probably better of jumping ship anyway (as long as there's somewhere else to go - matrix? urbit?).
A few problems with this:
1) Much (most?) of the time, participants don't get to verify their safety numbers, and in those cases you are at least trusting the server to deliver your messages to the right client. There's a potential vector for man-in-the-middle attack (witting or unwitting) on the server side which shouldn't be dismissed here just because users are "supposed to" verify safety numbers.
2) Their behavior regarding server software might be predictive of their behavior regarding client software in the future. Given network effects, it might not be so easy to leave the Signal ecosystem in the future if your social network is on it, so it's worth knowing right now that it's possible that in the future the client software will also be closed-source.
1) Much (most?) of the time, participants don't get to verify their safety numbers, and in those cases you are at least trusting the server to deliver your messages to the right client. There's a potential vector for man-in-the-middle attack (witting or unwitting) on the server side which shouldn't be dismissed here just because users are "supposed to" verify safety numbers.
2) Their behavior regarding server software might be predictive of their behavior regarding client software in the future. Given network effects, it might not be so easy to leave the Signal ecosystem in the future if your social network is on it, so it's worth knowing right now that it's possible that in the future the client software will also be closed-source.
"..trusting the server to deliver your messages to the right client."
This is where I feel a little unsure about Signal. It wants access to my contacts, and so it is possible to poison my contacts to get a rogue recipient into Signal. I would like a Signal in which I have the option to manually add contacts. Ideally a hash or key exchange or something, maybe a la PGP...
This is where I feel a little unsure about Signal. It wants access to my contacts, and so it is possible to poison my contacts to get a rogue recipient into Signal. I would like a Signal in which I have the option to manually add contacts. Ideally a hash or key exchange or something, maybe a la PGP...
PGP has one of the worst metadata stories in all of secure messaging.
Can you elaborate what you mean by this?
He means that key exchange is frought with trust issues online. An exchange in meat-space is (can be!) 100% reliable, but doesn't scale. PGP is a posterchild for the impracticality of public key crypto.
The UK actually made it work in conjunction with identity federation through the Government Gateway, but then the Government Digital Service got hold of it and destroyed any chances of moving it forward.
Having seen it work I believe PKI can be practical at scale. And this is why I'd hoped a chat app might break some ground here.
The UK actually made it work in conjunction with identity federation through the Government Gateway, but then the Government Digital Service got hold of it and destroyed any chances of moving it forward.
Having seen it work I believe PKI can be practical at scale. And this is why I'd hoped a chat app might break some ground here.
> Having seen it work I believe PKI can be practical at scale. And this is why I'd hoped a chat app might break some ground here.
If you believe that this webpage was delivered securely to your computer, then PKI might be practical. Of course, there are a few implementation details with that PKI.
If you believe that this webpage was delivered securely to your computer, then PKI might be practical. Of course, there are a few implementation details with that PKI.
No, this is not at all what I mean.
Then pray tell good sir.
Metadata problems in messaging systems are about what data about the communication leaks.
Sorry, I suspect I'm missing something obvious. You specifically said PGP, which is an encryption program that provides cryptographic privacy and authentication for data communication.
And above you're saying it's about meta data problems in messaging systems. What is PGP's bad meta data story you were referring to?
And above you're saying it's about meta data problems in messaging systems. What is PGP's bad meta data story you were referring to?
A quick entry point might be found here: https://crypto.stackexchange.com/questions/42247/are-the-met...
Essentially, for most PGP workflows, PGP encrypts the body of the message but the entirety of the metadata (things like sender, recipient, subject line, basically anything you’d think of as “metadata”) are fully unencrypted.
Essentially, for most PGP workflows, PGP encrypts the body of the message but the entirety of the metadata (things like sender, recipient, subject line, basically anything you’d think of as “metadata”) are fully unencrypted.
This is not a problem with PGP. This is a problem with an application of PGP.
We're into the weeds here on this thread but the search bar below will avail.
True but not quite my point.
> So the client is open source and guarantees end-to-end encryption regardless of what the server does. Ok, then I honestly don't care. Why should I?
You should because any successful centralized messenger is one update away from becoming entirely closed source.
If Signal will reach say a billion users it will be able to do that without significant userbase loss, due to network effect.
> safety characteristics, which as stated are apparently ensured by the client regardless of what the server does
In reality, the contact social graph and the frequency and pattern of messages between users is leaked.
Any global observer can do a correlation attack thanks to the centralized servers (and absence of onion routing).
You should because any successful centralized messenger is one update away from becoming entirely closed source.
If Signal will reach say a billion users it will be able to do that without significant userbase loss, due to network effect.
> safety characteristics, which as stated are apparently ensured by the client regardless of what the server does
In reality, the contact social graph and the frequency and pattern of messages between users is leaked.
Any global observer can do a correlation attack thanks to the centralized servers (and absence of onion routing).
If you think the security aspect of the server don't matter, then can I please have all the metadata that get generated on the server and which only security is the public statement by Moxie Marlinspike that they do not save the logs or store them.
The client only guarantees security in term of the message content. Who talks to who, when, where, how long, and the historical patterns are secured by the policy of the server provider. Trust in the server is critical.
The client only guarantees security in term of the message content. Who talks to who, when, where, how long, and the historical patterns are secured by the policy of the server provider. Trust in the server is critical.
This is really silly. Signal has discussed repeatedly what metadata they keep. It might be sane to ask questions about that, except that every competing messenger keeps the absolute worst case metadata, generally in plaintext, nicely bundled up in SQL tables. At best, you'd be making the claim that Signal might... secretly be as bad as everything else.
And, of course, the source code does nothing to do address this concern; they control their servers and can run any secret fork they want. It's a purity test and nothing more.
And, of course, the source code does nothing to do address this concern; they control their servers and can run any secret fork they want. It's a purity test and nothing more.
Be kind. Don't be snarky. Respond to the strongest plausible interpretation of what someone says.
Trust is a personal relationship. I am not making a claim that such trust should be abandoned because they delayed an update and did not transparently and openly communicated with the community about what they are doing on the server side or why. A personal relationship is personal, and what is or isn't a problem in building and maintaining that trust is up to each person.
I do however claim that the placed trust in signals servers is critical for the security, and that the server side security matter. Who runs the server matters and what the server code does also matters.
Trust is a personal relationship. I am not making a claim that such trust should be abandoned because they delayed an update and did not transparently and openly communicated with the community about what they are doing on the server side or why. A personal relationship is personal, and what is or isn't a problem in building and maintaining that trust is up to each person.
I do however claim that the placed trust in signals servers is critical for the security, and that the server side security matter. Who runs the server matters and what the server code does also matters.
> It's a purity test and nothing more.
Wrong. Publishing the server sources allow people to create a parallel and independent service.
Wrong. Publishing the server sources allow people to create a parallel and independent service.
What's stopping you? What does that have to do with having a bit-for-bit identical version to what Signal is running?
...the simple fact that there's no guarantee that either the server or the client would receive updates.
That means hard-forking the old server and client and maintain them as an independent project forever.
That's what's stopping me and many other people from creating a community and federated version.
That means hard-forking the old server and client and maintain them as an independent project forever.
That's what's stopping me and many other people from creating a community and federated version.
Any independent server is of necessity going to be an independent project forever, so I'm not sure what your difficulty is here.
> So the client is open source and guarantees end-to-end encryption regardless of what the server does. Ok, then I honestly don't care. Why should I?
What operations does your client do? How would you know?
If the client is open source and the build is reproducible and you can built it yourself to compare the binary with the official binary on the app store, then.. yes, you can trust that the client is guaranteeing your end-to-end encryption.
If there is a snapshot of open source code which doesn't match the official binary, you have no way to know what the client you run is actually doing. That's why you should care.
This has nothing to do with trusting Signal, good people. If your threat model is such that you care about secure messaging, you can't just trust a binary that's handed to you.
What operations does your client do? How would you know?
If the client is open source and the build is reproducible and you can built it yourself to compare the binary with the official binary on the app store, then.. yes, you can trust that the client is guaranteeing your end-to-end encryption.
If there is a snapshot of open source code which doesn't match the official binary, you have no way to know what the client you run is actually doing. That's why you should care.
This has nothing to do with trusting Signal, good people. If your threat model is such that you care about secure messaging, you can't just trust a binary that's handed to you.
Eh, I don't think open source necessarily implies open development. Being able to look at and modify the source code of the software I use is the bar for "open source" for me; I don't expect every organization to do all their development out in the open. Seems like this code was made available while it was still relevant, so I don't think anyone is really at fault here.
If I can't get a Signal server running myself, or if I can't compile the Signal client and install it on my phone, what's the point of being open source?
They could release a version of the server codebase that is not the production one, and who knows? They could put on the Google Play Store/Apple App Store a version of the client compiled from different sources (and mobile builds are not reproducible), and who knows?
Also the main benefit of FOSS is the possibility to take the source code, modify it, implement new functionality, fork it, and so on. And Signal is against that. So to me it's like a proprietary software.
Telegram on the other hand it doesn't provide an open source server, but the clients are 100% open, you can compile a client from source, modify a client, make third party clients that implements the Telegram protocol with the official libraries. All of that it's useful not only for improving existing clients, but for automating stuff, there are libraries for basically every programming language to interact with Telegram. That to me means being open source, and what distinguish Telegram from all the other applications.
They could release a version of the server codebase that is not the production one, and who knows? They could put on the Google Play Store/Apple App Store a version of the client compiled from different sources (and mobile builds are not reproducible), and who knows?
Also the main benefit of FOSS is the possibility to take the source code, modify it, implement new functionality, fork it, and so on. And Signal is against that. So to me it's like a proprietary software.
Telegram on the other hand it doesn't provide an open source server, but the clients are 100% open, you can compile a client from source, modify a client, make third party clients that implements the Telegram protocol with the official libraries. All of that it's useful not only for improving existing clients, but for automating stuff, there are libraries for basically every programming language to interact with Telegram. That to me means being open source, and what distinguish Telegram from all the other applications.
Both the server code and client code are open source. You're absolutely free to take them, modifly them, and do whatever you want with them. You're free to make your own fork and create your own chat service.
However, signal won't (and had not obligation to) provide your forks infrastructure. It costs money and time to maintain servers and they don't want 3rd party projects leeching their resources.
Again, your free to take their open source code and modify it and stand up your own infrastructure. If you do, you'll end up with your own chat service.
However, signal won't (and had not obligation to) provide your forks infrastructure. It costs money and time to maintain servers and they don't want 3rd party projects leeching their resources.
Again, your free to take their open source code and modify it and stand up your own infrastructure. If you do, you'll end up with your own chat service.
I feel like you missed the point of this discussion: the server code in fact hasn't been open source for the past year, and so one couldn't make a fork of it.
I wouldn't say that, they just didn't provide open access to their feature branches before they were merged (or "production-ready", however you want to put it).
> I feel like you missed the point of this discussion: the server code in fact hasn't been open source for the past year, and so one couldn't make a fork of it.
That seems to be overstating things. The server source in fact was always available, but there's nothing about open source that says a developer has to push their changes out on a particular schedule.
Also, it's supposed to be E2E encrypted, so I think the source that's really important is the client.
That seems to be overstating things. The server source in fact was always available, but there's nothing about open source that says a developer has to push their changes out on a particular schedule.
Also, it's supposed to be E2E encrypted, so I think the source that's really important is the client.
For security software like Signal it does. When there is a lag in publishing server source code, the running version isn't what the public can inspect, but an old one that is no longer valid.
And it produces the appearance that they have something to hide, like the need to sanitize the source and get rid of something. Maybe it is just embarrassing WIP stuff, maybe a backdoor.
And it produces the appearance that they have something to hide, like the need to sanitize the source and get rid of something. Maybe it is just embarrassing WIP stuff, maybe a backdoor.
I don't think it does, at least not for the security reasons you name.
If you are self-hosting a server, you may not have the latest and greatest features, but all the code you are running is open-source, so no sneaky backdoors (well, no more sneaky backdoors than the ones in the open source code).
If you are not self hosting, than it really doesn't matter if the server source code is open or not. There is not a single guarantee that they are actually running the that code on their server.
(For client code this is a different story of course, but we're talking about server source code)
If you are self-hosting a server, you may not have the latest and greatest features, but all the code you are running is open-source, so no sneaky backdoors (well, no more sneaky backdoors than the ones in the open source code).
If you are not self hosting, than it really doesn't matter if the server source code is open or not. There is not a single guarantee that they are actually running the that code on their server.
(For client code this is a different story of course, but we're talking about server source code)
In a strict sense, you are completely right. But nonetheless people are recommending Signal because the client implementation looks good and is somewhat verifiable (absent appstore evilness and ignoring the lag between update and verification). The server implementation however is only based on trust in the people running the servers. And there, openness about the code at least gives a few hints about what is going on there, enabling me to trust at least a little more than not-at-all.
> The server implementation however is only based on trust in the people running the servers.
They literally chose a zero server trust model when designing the protocol. NSA could be running modified signal servers and it wouldn't make a difference. Your messages would still be safe since all the magic happens on the clients. The servers just route the encrypted data, it's all just 1's and 0's to them.
> And there, openness about the code at least gives a few hints about what is going on there, enabling me to trust at least a little more than not-at-all.
Do we even know if signal was running updated server code in production? Maybe they have been running the same code that was on github this whole time.
They literally chose a zero server trust model when designing the protocol. NSA could be running modified signal servers and it wouldn't make a difference. Your messages would still be safe since all the magic happens on the clients. The servers just route the encrypted data, it's all just 1's and 0's to them.
> And there, openness about the code at least gives a few hints about what is going on there, enabling me to trust at least a little more than not-at-all.
Do we even know if signal was running updated server code in production? Maybe they have been running the same code that was on github this whole time.
> Your messages would still be safe
Only the message contents. Everything else, like time, identities, communication networks is still at risk. What you are saying is very misleading since you completely neglect to mention the importance of all that non-content metadata.
Only the message contents. Everything else, like time, identities, communication networks is still at risk. What you are saying is very misleading since you completely neglect to mention the importance of all that non-content metadata.
Signal creator is actively against 3rd party clients, because they "use his infrastructure for free":
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
EDIT: inaccuracies, see below.
Moxie is also using his position as the creator of Signal to promote and integrate his pet cryptocurrency project MobileCoin as a payment provider for Signal, of which he owns a majority stake in.
Technical merits of MobileCoin aside, it's not a good look.
Signal is really not inspiring confidence right now.
EDIT: Sorry, Moxie is only serving as a paid technical advisor to MobileCoin--it is not his project and presumably does not own stake in MobileCoin. So that's better, but remains to be seen what enfolds.
Found a summary of events here if anyone can confirm:
1. MobileCoin premines 250m coins
2. Moxie gets paid for being on their advisory board
3. Moxie directs his non-profit to integrate MobileCoin in secret
4. MobileCoin offers 1/5 of their premine for sale.
5. Signal announcement spikes price to $60
https://twitter.com/lrvick/status/1379536536459431937
Moxie is also using his position as the creator of Signal to promote and integrate his pet cryptocurrency project MobileCoin as a payment provider for Signal, of which he owns a majority stake in.
Technical merits of MobileCoin aside, it's not a good look.
Signal is really not inspiring confidence right now.
EDIT: Sorry, Moxie is only serving as a paid technical advisor to MobileCoin--it is not his project and presumably does not own stake in MobileCoin. So that's better, but remains to be seen what enfolds.
Found a summary of events here if anyone can confirm:
1. MobileCoin premines 250m coins
2. Moxie gets paid for being on their advisory board
3. Moxie directs his non-profit to integrate MobileCoin in secret
4. MobileCoin offers 1/5 of their premine for sale.
5. Signal announcement spikes price to $60
https://twitter.com/lrvick/status/1379536536459431937
Can you provide a source for this...?
The Wired article covering this has a note clarifying that both Moxie and Signal own no MobileCoins, and that he's been a paid advisor to the project.
>Signal's choice of MobileCoin is no surprise for anyone watching the cryptocurrency's development since it launched in late 2017. Marlinspike has served as a paid technical adviser for the project since its inception, and he's worked with Goldbard to design MobileCoin's mechanics with a possible future integration into apps like Signal in mind. (Marlinspike notes, however, that neither he nor Signal own any MobileCoins.)
https://www.wired.com/story/signal-mobilecoin-payments-messa...
The Wired article covering this has a note clarifying that both Moxie and Signal own no MobileCoins, and that he's been a paid advisor to the project.
>Signal's choice of MobileCoin is no surprise for anyone watching the cryptocurrency's development since it launched in late 2017. Marlinspike has served as a paid technical adviser for the project since its inception, and he's worked with Goldbard to design MobileCoin's mechanics with a possible future integration into apps like Signal in mind. (Marlinspike notes, however, that neither he nor Signal own any MobileCoins.)
https://www.wired.com/story/signal-mobilecoin-payments-messa...
Sorry, you're right. That was a misreading on my part.
It is the case that Moxie is a paid technical adviser, not that MobileCoin was his project.
I've amended my above post for accuracy.
It is the case that Moxie is a paid technical adviser, not that MobileCoin was his project.
I've amended my above post for accuracy.
Two things, I think:
3) The "turmoil in Signal" article that made the rounds a few months ago had mentions of the MobileCoin work; I don't think is news so much as people weren't really paying attention.
5) The price spike, to my knowledge, was (partly) some whale at play. This is not a rebuttal to your point as I don't think anybody could prove this for sure tho, but mostly throwing it here for context.
3) The "turmoil in Signal" article that made the rounds a few months ago had mentions of the MobileCoin work; I don't think is news so much as people weren't really paying attention.
5) The price spike, to my knowledge, was (partly) some whale at play. This is not a rebuttal to your point as I don't think anybody could prove this for sure tho, but mostly throwing it here for context.
The article came out 9 months into a 12 month process. And expecting everyone to see every article about every app they use is unrealistic.
>And expecting everyone to see every article about every app they use is unrealistic.
The article was posted here with significant discussion, so no, I feel fine assuming that readers of this forum (and certainly with respect to this topic) have a likelihood of having seen it.
The article was posted here with significant discussion, so no, I feel fine assuming that readers of this forum (and certainly with respect to this topic) have a likelihood of having seen it.
You overestimate how consistently and thoroughly people read HN.
Sure.
But that's better than having multiple commenters across these threads show you links indicating that this wasn't a grand secret, which you just disregard because it doesn't fit a narrative.
shrug
But that's better than having multiple commenters across these threads show you links indicating that this wasn't a grand secret, which you just disregard because it doesn't fit a narrative.
shrug
The article you keep talking about[1] and the articles the other person linked[2] don't indicate what you claim they do.
The article you keep talking about relied on leaks. Marlinspike dismissed the MobileCoin work as "design explorations" less than 3 months ago. They stopped publishing the server source just before they started working on payments. They started again just after announcing it.
Someone who read the right article 3 years ago might have predicted this would happen some day. That doesn't change Marlinspike tried to hide they were actually working on it in 2020 and 2021.
[1] https://www.platformer.news/p/-the-battle-inside-signal
[2] https://news.ycombinator.com/item?id=26718488
The article you keep talking about relied on leaks. Marlinspike dismissed the MobileCoin work as "design explorations" less than 3 months ago. They stopped publishing the server source just before they started working on payments. They started again just after announcing it.
Someone who read the right article 3 years ago might have predicted this would happen some day. That doesn't change Marlinspike tried to hide they were actually working on it in 2020 and 2021.
[1] https://www.platformer.news/p/-the-battle-inside-signal
[2] https://news.ycombinator.com/item?id=26718488
> While it regularly publishes the code of its client apps, it hasn't updated the Github repository for its server for almost a year.
Last commit was 5 days ago: [0]
As for not playing nice with third-party clients, I can give you that point.
[0] https://github.com/signalapp/Signal-Server/commit/365ad3a4f8...
Last commit was 5 days ago: [0]
As for not playing nice with third-party clients, I can give you that point.
[0] https://github.com/signalapp/Signal-Server/commit/365ad3a4f8...
This is a change that's very recent, perhaps even in response to this article in particular.
https://web.archive.org/web/20210311053716/https://github.co...
As of earlier this month, the repository was a year out of date.
https://web.archive.org/web/20210311053716/https://github.co...
As of earlier this month, the repository was a year out of date.
You can approximate the push date by looking for the first reference to the commit:
https://github.com/search?q=365ad3a4f821a9e2393c5a3e1522b2c0...
https://github.com/signalapp/Signal-Android/issues/11101#iss...
The article was published at 2021-04-06 17:50 UTC.
The first reference on GitHub is at 2021-04-06 18:43 UTC, less than an hour afterwards.
https://github.com/search?q=365ad3a4f821a9e2393c5a3e1522b2c0...
https://github.com/signalapp/Signal-Android/issues/11101#iss...
The article was published at 2021-04-06 17:50 UTC.
The first reference on GitHub is at 2021-04-06 18:43 UTC, less than an hour afterwards.
True, but the author of the blog post posted this '1 hour ago' (As of my comment) and maybe should have at least triple-checked the signal-server repository again rather than linking to a now outdated discussion thread on Signal-Android [0].
[0] https://github.com/signalapp/Signal-Android/issues/11101#iss...
[0] https://github.com/signalapp/Signal-Android/issues/11101#iss...
If you read that thread, it's very possible the change happened in that hour. It seems to have been at some point today.
I think a member of the team made it public ~15 minutes ago if I'm reading correctly.
I think a member of the team made it public ~15 minutes ago if I'm reading correctly.
Google Cache shows that as of Apr 6, 2021 00:16:05 GMT the source had not been updated since 2020, so it happened within the last 6 hours.
https://i.imgur.com/r1Y0Wgz.png
http://webcache.googleusercontent.com/search?client=safari&r...
Screenshot from twitter showing it not updated "2 hours ago", about 04:43 GMT.
https://twitter.com/AnanasPizza2/status/1379474849974910980
https://i.imgur.com/r1Y0Wgz.png
http://webcache.googleusercontent.com/search?client=safari&r...
Screenshot from twitter showing it not updated "2 hours ago", about 04:43 GMT.
https://twitter.com/AnanasPizza2/status/1379474849974910980
Author: Moxie Marlinspike <[email protected]>
AuthorDate: Thu Apr 2 12:45:24 2020 -0700
Commit: Moxie Marlinspike <[email protected]>
CommitDate: Wed Apr 22 12:32:53 2020 -0700
Support for advertising payment addresses on profile
It's practically a principle of the Signal project to discourage third-party clients. Signal's security work is done, for obvious reasons, mostly clientside. If you have a diversity of clients, you're stuck with the lowest common denominator of mainstream clients. Without them, you can roll out any feature you want to.
While I can understand not wanting a diversity of clients for the support headache that could rapidly become, I don't fully agree that a diversity of clients forces them to be stuck at a lowest common denominator. What prevents them from making the breaking changes necessary for security and features, and letting the devs of 3rd party clients successfully conform or not?
I see it as something like mandating minimum version of TLS or cipher suite. The security flaws of TLS version <1.2 have been documented for some time now. I've had to tell customers more than once we are disallowing use of older insecure protocols to access my employer's services.
Or am I misunderstanding you and actually happen to be agreeing?
I see it as something like mandating minimum version of TLS or cipher suite. The security flaws of TLS version <1.2 have been documented for some time now. I've had to tell customers more than once we are disallowing use of older insecure protocols to access my employer's services.
Or am I misunderstanding you and actually happen to be agreeing?
The problem is you can never make protocol breaking changes or add mandatory features. You might think "well just do it anyway and ignore people who complain about third party clients breaking" but in reality you can't
ignore them. You end up with lowest common denominator. You end up with IRC basically.
Look at what happened when that Python crypto package added Rust support and broke some obscure platforms that nobody uses and were never supported. Geek outrage!
Look at what happened when that Python crypto package added Rust support and broke some obscure platforms that nobody uses and were never supported. Geek outrage!
Then you get something analogous to the PGP problem, where you have so many options that it only takes one misunderstanding to compromise your communications.
You can't just have security features not implemented on some clients; you have to actively break them. The simplest thing you can do there, versioning the protocol to indicate compliance, is easy for developers to work around. Users will stick with the client that has their preferred UX (really, in practice, they're going to stick with whatever the first client they got working is, because users hate installing stuff). It's a total mess.
I can't blame the Signal project for wanting to avoid it entirely. You can of course disagree!
I can't blame the Signal project for wanting to avoid it entirely. You can of course disagree!
> What prevents them from making the breaking changes necessary for security and features, and letting the devs of 3rd party clients successfully conform or not?
This _is_ the support headache, not a workaround for some other straw man support headache.
This _is_ the support headache, not a workaround for some other straw man support headache.
> It's practically a principle of the Signal project to discourage third-party clients
It depends on what you call "client". At the protocol level sure, you're supposed to behave just like any official client. But to do that you just have to use their client library[0] and implement whatever you want on top of this, like signal-cli[1] has been doing successfully for quite some time now.
Some forks exist here and there (from memory, there's one with WhatsApp import, another with UI features), there's just no interest for a completely new client. There's only so much space for innovation for what is mostly a messaging app.
To be fair, the absence of an API (which Telegram has) also limits possibilities.
[0]: https://github.com/signalapp/libsignal-client [1]: https://github.com/AsamK/signal-cli
It depends on what you call "client". At the protocol level sure, you're supposed to behave just like any official client. But to do that you just have to use their client library[0] and implement whatever you want on top of this, like signal-cli[1] has been doing successfully for quite some time now.
Some forks exist here and there (from memory, there's one with WhatsApp import, another with UI features), there's just no interest for a completely new client. There's only so much space for innovation for what is mostly a messaging app.
To be fair, the absence of an API (which Telegram has) also limits possibilities.
[0]: https://github.com/signalapp/libsignal-client [1]: https://github.com/AsamK/signal-cli
They threatened to block a fork before. It just removed Google dependencies as far as I know.
[0] says use outside Signal is unsupported. And it's only for Java, Swift, and TypeScript.
[0] says use outside Signal is unsupported. And it's only for Java, Swift, and TypeScript.
So why doesn't Telegram have the same issue? Just like Signal, the client is fully open source and most of the secure bits are client-side, but unlike Signal they make no pretenses about being "fully" open source as they've never published any server sources, nor they make hostile moves towards blocking third-party client interoperability.
Because Telegram is not secure at all and the only content that is not stored on server unencrypted are so-called secret chats, used by approximately 0% of audience. So they have zero need to be paranoid about data privacy.
In comparison, Telegram offers APIs and libraries that allow you to create clients for any platform [0].
[0] https://core.telegram.org/tdlib
[0] https://core.telegram.org/tdlib
You also need to give your developer keys to Telegram if you want your client to receive push notifications.
Push notifications are pretty standard, though - this is an issue with the app store model, if anything.
The last time I looked, Telegram didn't even have E2E-secure group messaging. It's easier to use and more pleasant to code to, but then, if that's all you're optimizing for, that's not a high bar to clear.
>If you have a diversity of clients, you're stuck with the lowest common denominator of mainstream clients. Without them, you can roll out any feature you want to.
This only matters if you cared about backward-compatibility. Otherwise you can just push breaking protocol changes without regard for third party clients.
This only matters if you cared about backward-compatibility. Otherwise you can just push breaking protocol changes without regard for third party clients.
And the users of those clients will say “Signal is always breaking” and switch to another platform.
The scarier outcome is that they continue to use clients that lack security controls because the client continues to work well enough for them. Look how popular Telegram is.
Interestingly, this brand-new custom coin they're using is not Proof-of-Work or Proof-of-Stake.
> The MobileCoin Consensus Protocol avoids the environmentally-damaging mathematical “work” required by Proof-of-Work (PoW) consensus protocols like Bitcoin and realizes a much higher transaction rate than the Bitcoin consensus protocol. In contrast to Proof-of-Stake (PoS) consensus protocols, practical control of governance in MCP is ceded to the users who are trusted the most by the extended MobileCoin community, rather than to the wealthiest users who control the largest financial stakes.
https://github.com/mobilecoinfoundation/mobilecoin/tree/mast...
> The MobileCoin Consensus Protocol avoids the environmentally-damaging mathematical “work” required by Proof-of-Work (PoW) consensus protocols like Bitcoin and realizes a much higher transaction rate than the Bitcoin consensus protocol. In contrast to Proof-of-Stake (PoS) consensus protocols, practical control of governance in MCP is ceded to the users who are trusted the most by the extended MobileCoin community, rather than to the wealthiest users who control the largest financial stakes.
https://github.com/mobilecoinfoundation/mobilecoin/tree/mast...
So it is POT. Proof of Trust. If you break it, it is crackpot and goes up in smoke /s
I am not familiar with this Quorums consensus mechanism, but in general I feel - especially given the scammy veil surrounding the entire field - that it is quite early to adopt such as-yet unproven technology in production software that is widely used by people where security and privacy (among others) is utterly important.
I am not familiar with this Quorums consensus mechanism, but in general I feel - especially given the scammy veil surrounding the entire field - that it is quite early to adopt such as-yet unproven technology in production software that is widely used by people where security and privacy (among others) is utterly important.
They are using Byzantine Fault Tolerant Quorums. That is just a class of majority election algorithms that is tolerant to the presence of evil participants. But in short, it is just the majority of servers allowed to vote, so either proof of stake or a cartel. What they neglected to specify is the difference there: "who is allowed to vote?"
I have asked this before but without an answer. Has anyone been able to successfully do a verified build of a recent version of the Android client?
I have not been able to get it to compile but have not spent much time trying to figure out why it doesn't want to compile.
I have not been able to get it to compile but have not spent much time trying to figure out why it doesn't want to compile.
Hi there! Signal-Android developer here. Are you following the steps listed in our repo[1]? The steps use the very same docker image we use to build our releases.
[1] https://github.com/signalapp/Signal-Android/tree/master/repr...
[1] https://github.com/signalapp/Signal-Android/tree/master/repr...
Yes I did but it was more than 15 days ago. I will try again.
You have a fix waiting as a PR for what could be OP's issue: https://github.com/signalapp/Signal-Android/pull/11134
What’s new with matrix? Honestly curious, I find federated systems a little confusing and would love an overview
I ran a private Synapse server on an OpenBSD host w/ an encrypted fs. The only problem I ever had was I messed around w/ the SSL cert and someone's mobile app cached the old one, causing some connectivity problems (uninstalling and reinstalling did the trick, finally).
The mobile app is a little unpolished. It constantly wants you to validate other sessions, always flashes the "loading" graphic whenever you switch to it, etc. Those two things feel a little half-baked--enough that my friends were like "no thanks" (I know, I know but, what can you do).
But broadly I still think it's very promising and would personally use it if I could get anyone else to. They're also building another server in Go that should have much better performance, if you're interested in that kind of thing.
The mobile app is a little unpolished. It constantly wants you to validate other sessions, always flashes the "loading" graphic whenever you switch to it, etc. Those two things feel a little half-baked--enough that my friends were like "no thanks" (I know, I know but, what can you do).
But broadly I still think it's very promising and would personally use it if I could get anyone else to. They're also building another server in Go that should have much better performance, if you're interested in that kind of thing.
Been using it for a while now, mostly through bridges. e2ee works pretty much seamlessly now, as does the entire federation thing. Cross-device verification is simple; manual fingerprint comparisons have been replaced by the simple emoji comparison screens also found in other apps.
If you don't want to bother setting up a server (and power to you, because server maintenance is annoying) just register with any open Matrix server you deem reliable enough. The matrix.org one is (obviously) pretty popular. As an end user, the federation stuff is no different from your average email address; there's a domain you store your stuff on and send your stuff through, that server is part of your address. If you make an account with a service provider that goes down, your messages disappear, same thing as would happen if Gmail or iCloud would take their servers down.
If you want the security of your domain but none of the hassle of managing a server, you can get managed Matrix servers from different providers these days [0]. Just get your own domain like normal, so your address will always be your own property and you can take it somewhere else if you really need to, and point the domain records at the servers of your provider.
If you do want to set up a server and join the Matrix network, there's an Ansible playbook [1] that'll set everything up on your server. You can also use the complete guide [2] if you want to manage everything manually. If you have any trouble getting federation to work, there's a nice diagnostic utility [3] that can help you identify the most common problems.
Alternative client are coming along nicely now, as well. For the longest time, encryption support was missing from the major ones (with "solutions" like running a pantalaimon instance in the mean time), but e2ee support has been added to most clients now. The only fully-featured client without encryption support I've come across has been GNOME's Fractal. On mobile, Fluffychat [4] has been working well for me, and on desktop Element [5] has been working well, too.
TL;DR: go to https://app.element.io/#/register, pick a username, and give it a try in your browser. You can join a bunch of the bridged IRC servers to get a feel of the conversation flow if you have no contacts on Matrix.
[0]: https://matrix.org/hosting/
[1]: https://github.com/spantaleev/matrix-docker-ansible-deploy
[2]: https://github.com/matrix-org/synapse/blob/master/INSTALL.md
[3]: https://federationtester.matrix.org/
[4]: https://fluffychat.im/en/
[5]: https://element.io/get-started
If you don't want to bother setting up a server (and power to you, because server maintenance is annoying) just register with any open Matrix server you deem reliable enough. The matrix.org one is (obviously) pretty popular. As an end user, the federation stuff is no different from your average email address; there's a domain you store your stuff on and send your stuff through, that server is part of your address. If you make an account with a service provider that goes down, your messages disappear, same thing as would happen if Gmail or iCloud would take their servers down.
If you want the security of your domain but none of the hassle of managing a server, you can get managed Matrix servers from different providers these days [0]. Just get your own domain like normal, so your address will always be your own property and you can take it somewhere else if you really need to, and point the domain records at the servers of your provider.
If you do want to set up a server and join the Matrix network, there's an Ansible playbook [1] that'll set everything up on your server. You can also use the complete guide [2] if you want to manage everything manually. If you have any trouble getting federation to work, there's a nice diagnostic utility [3] that can help you identify the most common problems.
Alternative client are coming along nicely now, as well. For the longest time, encryption support was missing from the major ones (with "solutions" like running a pantalaimon instance in the mean time), but e2ee support has been added to most clients now. The only fully-featured client without encryption support I've come across has been GNOME's Fractal. On mobile, Fluffychat [4] has been working well for me, and on desktop Element [5] has been working well, too.
TL;DR: go to https://app.element.io/#/register, pick a username, and give it a try in your browser. You can join a bunch of the bridged IRC servers to get a feel of the conversation flow if you have no contacts on Matrix.
[0]: https://matrix.org/hosting/
[1]: https://github.com/spantaleev/matrix-docker-ansible-deploy
[2]: https://github.com/matrix-org/synapse/blob/master/INSTALL.md
[3]: https://federationtester.matrix.org/
[4]: https://fluffychat.im/en/
[5]: https://element.io/get-started
It's been like this for a while, and the project owner's attitude is pretty negative overall. I do use signal daily, but I believe it's likely compromised ala lavabit.
I thought they were never compromised? They shut down rather than comply with the order
>The service suspended its operations on August 8, 2013 after the U.S. Federal Government ordered it to turn over its Secure Sockets Layer (SSL) private keys, in order to allow the government to spy on Edward Snowden's email
>The service suspended its operations on August 8, 2013 after the U.S. Federal Government ordered it to turn over its Secure Sockets Layer (SSL) private keys, in order to allow the government to spy on Edward Snowden's email
Lavabit was never compromised, I'm saying that Signal may have been compromised by the feds, instead of choosing to shut down. Feds may have learned their lesson and not provided an option this time.
The chance that a small nonprofit with so much traffic is not leaking/providing data to the feds is astronomically slim imho, there are so many actors who would love to there hands on it. Maybe it thwarts some inteligance services but not those with unlimited resources.
Based on what information would you draw such a conclusion?
I would point you towards Stuxnet and take a look at how sofisticated a state level attack can be and the fact that today Iran still can not keep us (America/Israel) out of it's centrifuges. Everything you type online is being stored by multiple actors, to think they can't access a small company with limited resources is wishful thinking. If no one in Signal's 180 employees is working for the feds I would be embarrassed to be an American.
Add easily-bruteforceable PIN-codes forced on users, protected only by vulnerable Intel SGX.
Add requirement of a phone number to create an account.
Add requirement of a phone number to create an account.
That's a bold claim with 0 data to back that up. What are your sources for believing it's received a love letter?
What's in the Signal server to be compromised?
List of phone numbers? Pairs of communication partners? Timing and size of messages? Metadata about transferred media? There is still a lot, sufficient for targeting a drone strike as the usual wisdom goes.
Some of that information you don't even need a backdoor to collect; the rest is stored in plaintext by Signal's competitors.
Signal claims to specially protect some of that data, such claims need verification. Storing or not storing that data needs verification, without the trust that they do what they say they are no better than their competition. Trust is earned e.g. by openness about the source code. And that a server backdoor isn't strictly necessary is also beside the point because the server is the easiest and most obvious way to get at all that data.
Also, there is competition like Briar which has less of those pesky metadata problems (but some other problems instead)
Also, there is competition like Briar which has less of those pesky metadata problems (but some other problems instead)
I don't recall Signal ever having made implausible claims about traffic analytic attacks. I also don't buy into the idea that platforms are as trustworthy as their source release policies are orthodox.
It isn't advanced difficult traffic analysis if it is all your servers. Or all your logs landing in one logstash.
The goalposts now seem to be at "someone might subpoena Signal's logs for some metadata", having moved pretty far from the original claim of "Signal's server code hasn't been updated because it has been secretly backdoored or intentionally weakened." It's difficult to see this as good faith security analysis rather than fearmongering.
What difference does this make? In your threat model the only serious countermeasure between you and state-level adversaries is a Logstash implementation?
Signal doesn’t store lists of phone governments have lists of phone numbers. Comunication partners are hidden from the server using Sealed Sender for many conversations.
The rest of this could possibly be obtained, it it wouldn’t require a patch to the server as message sizes and timestamps likely appear on disk somewhere. Though the data is encrypted, you could tell “x received a message from some party (sealed sender prevents knowing who) at y time of roughly z size”.
The rest of this could possibly be obtained, it it wouldn’t require a patch to the server as message sizes and timestamps likely appear on disk somewhere. Though the data is encrypted, you could tell “x received a message from some party (sealed sender prevents knowing who) at y time of roughly z size”.
Signal still uses and verifies phone numbers, so at some point they will pass through their infrastructure. They could still save them, knowing the source code they use gives at least at hint that they don't.
Sealed sender also is based on the pinky-swear that the infrastructure distributing the sender auth certificates doesn't correlate identities and connections with the messaging infrastructure. And that the server receiving the enveloped messages doesn't log. So all based on trust based on believing the right source code is running somewhere.
When access to that source code is restricted suddenly, of course people are worried.
Sealed sender also is based on the pinky-swear that the infrastructure distributing the sender auth certificates doesn't correlate identities and connections with the messaging infrastructure. And that the server receiving the enveloped messages doesn't log. So all based on trust based on believing the right source code is running somewhere.
When access to that source code is restricted suddenly, of course people are worried.
Being able to hide from a government that wants to drone you while still being in the cellphone network requires much much much more OPSEC than just using Signal. For an average user Signal is about protecting the content of your messages, not your network, and it's good at that.
Yes, that "drone strike" thing is actually a stupid saying. I'm sorry to have used it because it is somewhat distracting from the actual points.
If you use the Signal app from the app stores, and communicate with the server, you are using 100% closed source software.
They could easily add a backdoor in the client despite the fact that it's "open source", because no one builds it from source.
They could easily add a backdoor in the client despite the fact that it's "open source", because no one builds it from source.
Are Signal's Android builds no longer reproducible?
It looks like they are, but there might be a minor issue in verifying the content: https://github.com/signalapp/Signal-Android/issues/10476
But despite best efforts by the community to verify builds, Google and Apple can be forced to upload a malicious app to a particular user, meaning they aren't using the same app at all.
But despite best efforts by the community to verify builds, Google and Apple can be forced to upload a malicious app to a particular user, meaning they aren't using the same app at all.
> But despite best efforts by the community to verify builds, Google and Apple can be forced to upload a malicious app to a particular user, meaning they aren't using the same app at all.
Hi there! Signal-Android developer here. App signing verification is done at the OS-level, and Google does not have our signing key, so they wouldn't be able to give an existing user a different APK and have it successfully install.
Hi there! Signal-Android developer here. App signing verification is done at the OS-level, and Google does not have our signing key, so they wouldn't be able to give an existing user a different APK and have it successfully install.
Is that really true? Couldn't Google forcibly turn off the code-signing requirement on an individual's phone?
They've been known to reset passwords remotely in the past: https://www.theverge.com/2016/3/30/11330892/fbi-google-andro...
They've been known to reset passwords remotely in the past: https://www.theverge.com/2016/3/30/11330892/fbi-google-andro...
No, they could not. And if you don't want to trust $random_manufacturer's Android ROM, you could switch to GrapheneOS[0] whose developer Daniel Micay attaches a lot of importance to reliable app signatures (which is why GrapheneOS doesn't come with MicroG as the latter would need signature spoofing).
[0]: https://grapheneos.org/
[0]: https://grapheneos.org/
If your threat model includes the ability to force Apple to do X, then Signal is irrelevant.
That's probably a good point, I'm using GrapheneOS which is not identifiable to Google/Apple and can't be singled out for updates.
"No one" is a bit harsh; I even helped a poster in r/Signal set up a CircleCI build for the repo in order to show that it's not oppressively hard, just tedious (as with all things CI/CD)
The Signal android build now uses some PKCS11 machinery that requires patching out to build without using a smartcard, but otherwise it works as expected.
I dove into this darkness while trying to fix the borked MMS handling on Visible (a Verizon MVNO), and is the reason I'm generally with you: if someone can't build the project, then it's not effectively open source, IMHO, because I lose my "right to repair"
The Signal android build now uses some PKCS11 machinery that requires patching out to build without using a smartcard, but otherwise it works as expected.
I dove into this darkness while trying to fix the borked MMS handling on Visible (a Verizon MVNO), and is the reason I'm generally with you: if someone can't build the project, then it's not effectively open source, IMHO, because I lose my "right to repair"
By this standard, there is practically nothing that qualifies as open source. Compile something yourself? Well can you really trust your compiler unless you compiled it? How do you compile your compiler without a compiler? Obviously this is possible but no one does it; therefore no software is truly open source.
I disagree that these are on the same level - compiling something yourself, or having something compiled by ie the Arch Linux maintainers requires a number of people to comply.
The app store is a single point of failure with huge reach.
The app store is a single point of failure with huge reach.
I've said it before, and I'll say it again:
Only children trust Signal. A "private" messenger that only works by attaching to your phone number. Another nail in the coffin.
Edit: Look at that, negative points on my post that fast. We sure do have TLA's in here screening every single comment, while ensuring that this thread stays out of the front page.
Guys, give it up already. No one with a bit of intelligence falls for your "app-traps"
Only children trust Signal. A "private" messenger that only works by attaching to your phone number. Another nail in the coffin.
Edit: Look at that, negative points on my post that fast. We sure do have TLA's in here screening every single comment, while ensuring that this thread stays out of the front page.
Guys, give it up already. No one with a bit of intelligence falls for your "app-traps"
(Whispering): But you know what is? Matrix.
Just use Status: https://status.im/private-messenger/
Mozilla Public License - E2E Encryption - P2P Messaging - Active community & git repo - Integrated Ethereum wallet for Web3 access
Mozilla Public License - E2E Encryption - P2P Messaging - Active community & git repo - Integrated Ethereum wallet for Web3 access
The integrated ethereum wallet is a red flag for me.
Many persons that are interested in decentralized messaging are also interested in cryptocurrency, but not all are.
If someone wishes to use the app only as a messenger, the wallet will neither add to nor take away from their experience, i.e. use of the wallet is entirely optional.
I'm a developer at Status, and am on the team responsible for the Status Desktop client[+] (currently in beta), feel free to ask me anything.
[+] https://github.com/status-im/status-desktop
If someone wishes to use the app only as a messenger, the wallet will neither add to nor take away from their experience, i.e. use of the wallet is entirely optional.
I'm a developer at Status, and am on the team responsible for the Status Desktop client[+] (currently in beta), feel free to ask me anything.
[+] https://github.com/status-im/status-desktop
[deleted]
Why? Brave has an integrated Ethereum wallet. In the future, you won't want to use an app that doesn't have one, or at least doesn't have hooks for WalletConnect. Web3 has a fairer monetization system than the exploitative Web2 advertising model built on spying and manipulation.
The crypto bullshit inside Brave is also a red flag and why I don't use it anymore and wouldn't recommend it to anyone.
Brave having an integrated Ethereum wallet is also reason enough for me to not consider using Brave.
I wouldn't use Brave _because_ of that feature. After all, you can install any Chrome extension you want in Brave and use the wallet of your choice. But the existence of that feature is not a pre-requisite or post-requisite for using the product.
What makes crypto currencies solve a problem in this area that can’t be solved using traditional currencies and payment processors?
Blockchain is a system for introducing trust, who is it you don’t feel we should trust?
Blockchain is a system for introducing trust, who is it you don’t feel we should trust?
The messaging itself actually runs on the ethereum network.
No it doesn't.
The messaging is run on a decentralized network that uses the Waku protocol.
Currently the clients (mobile and desktop) use Waku v1: https://rfc.vac.dev/spec/6/
But work to transition to Waku v2 is underway: https://rfc.vac.dev/spec/10/
The messaging is run on a decentralized network that uses the Waku protocol.
Currently the clients (mobile and desktop) use Waku v1: https://rfc.vac.dev/spec/6/
But work to transition to Waku v2 is underway: https://rfc.vac.dev/spec/10/
Yes but isn't the Waku v1 protocol running on ÐΞVp2p, which uses the Ethereum network? The protocol is Waku, but as far as I understand the 'decentralized network' is the Ethereum network?
Here's the specs: https://specs.status.im/spec/10
That's correct. It uses Waku for routing and messaging, but the Waku nodes are Ethereum nodes with Waku v1 enabled.
Here's more from VAC, the org behind Waku and their plans for v2: https://vac.dev/waku-v2-ethereum-messaging
That's correct. It uses Waku for routing and messaging, but the Waku nodes are Ethereum nodes with Waku v1 enabled.
Here's more from VAC, the org behind Waku and their plans for v2: https://vac.dev/waku-v2-ethereum-messaging
Try New Awesome Messenger!
It has:
* E2E encryption * Awesome new features * Decentralization * Everything you ever wanted
Small drawbacks:
* Can't actually talk to any of the people you want to talk to.
It has:
* E2E encryption * Awesome new features * Decentralization * Everything you ever wanted
Small drawbacks:
* Can't actually talk to any of the people you want to talk to.
Well you can just stick with Facebook Messenger then and feed the beast.
Given the direction Signal is going... I do regret not having stuck with Whatsapp.
The only realistic alternative would be Matrix, but that's not usable for the average user yet (too unpolished).
The only realistic alternative would be Matrix, but that's not usable for the average user yet (too unpolished).
I wish. Status has even less adoption and dev support. If I have bugs on signal for MMS with my carrier, I presume any smaller niche messenger will be tougher to have loved ones adopt and will have even more bugs.
Current numbers re: adoption were discussed in Status' most recent Town Hall: https://www.youtube.com/watch?v=98wsQe6hHHs&t=365s
As for dev support: Status has teams of full-time devs working on various projects related to the mobile[1] and desktop[2] (beta) apps, as well projects that are related to the larger Ethereum ecosystem, e.g. nimbus-eth2[3]. Our teams aren't particularly large, but are working steadily to squash bugs and add/improve features. We also have teams dedicated to UX and design.
[1] https://github.com/status-im/status-react
[2] https://github.com/status-im/status-desktop
[3] https://github.com/status-im/nimbus-eth2
As for dev support: Status has teams of full-time devs working on various projects related to the mobile[1] and desktop[2] (beta) apps, as well projects that are related to the larger Ethereum ecosystem, e.g. nimbus-eth2[3]. Our teams aren't particularly large, but are working steadily to squash bugs and add/improve features. We also have teams dedicated to UX and design.
[1] https://github.com/status-im/status-react
[2] https://github.com/status-im/status-desktop
[3] https://github.com/status-im/nimbus-eth2
If anything Threema seems like the best alternative.
They finally pushed the code out: https://github.com/signalapp/Signal-Server/commits/master
From an open source perspective Signal-Server is still not open and never was: No outside contributions and no public issues. No community. No installation documentation. etc. ... and recently they seem to have added a dependency to DynamoDB: https://github.com/signalapp/Signal-Server/commit/0dcb4b645c... (2 weeks after they were overloaded from user registrations)
From an open source perspective Signal-Server is still not open and never was: No outside contributions and no public issues. No community. No installation documentation. etc. ... and recently they seem to have added a dependency to DynamoDB: https://github.com/signalapp/Signal-Server/commit/0dcb4b645c... (2 weeks after they were overloaded from user registrations)
[deleted]
Wasn't Apple's iMessage protocol supposed to be an open implementation too? Whatever happened to that?
That was FaceTime that they intended to open source, and it was supposedly a patent troll that forced them to move FaceTime to a more centralized design (it was originally P2P) which in turn made open sourcing more problematic.
That was certainly the excuse. But it is trivial for Apple to buy any patent it needs. I believe the real reason is that FaceTime and iMessage hook people to Apple platform and discourage switching to another one.
Wouldn’t that encourage future lawsuits from other patent trolls?
> trivial for Apple to buy any patent it needs.
Yea ... umm thats not how reality works. Companies CAN refuse to sell or license a patent at a rate that is not absurd.
Yea ... umm thats not how reality works. Companies CAN refuse to sell or license a patent at a rate that is not absurd.
The patent troll in the case got a 440M award… and Apple had to spend a bunch of engineering time throwing out the already-working p2p implementation and rebuilding a centralized version… and you’re suggesting that this was all a mere smoke screen?
They have 200 billion dollars in cash. They could have bought out the troll if they wanted to.
No, but even if you were right, what would that have to do with Signal?
I feel like it’s a honey trap.
> I feel like it’s a honey trap
That's a serious accusation you are 'feeling'. What evidence do you have?
That's a serious accusation you are 'feeling'. What evidence do you have?
Not op, but for me personally the moment it stopped being possible to send an e2e encrypted text message it became suspect.
I'm forced to register and to send all messages through their central server. It also seems to scan through my phone book and inform me who else is using signal, even if I've not had contact with them in years. I'm still convinced this is a massive provacy leak.
If I check the magic number to verify the security of my encryption with a contact, there's only one number to verify, yet I can have any number of desktop clients attached which seem to be independently capable of decrypting messages with my phone offline. There's also no indication to the sender that their message has been sent to multiple devices or any obvious way of working out where its been seen.
There's also been the historical reliance on google services, the holsitlity towards people running their own servers and on occasion general hostility towards devs and end users too.
For something that started off as a way of sending p2p e2e encrypted textual communication over the lowest common demoninator protocol worldwide, it's come a long way. Being able to send animated cat gifs to a group is great, but it feels (especially with the server code so far behind and no real way of verifying thats actually what's running anyway) like we're getting further and further from simple & verifiable and more and more into trust us territory, and it seems right to treat that with some suspicion.
If I check the magic number to verify the security of my encryption with a contact, there's only one number to verify, yet I can have any number of desktop clients attached which seem to be independently capable of decrypting messages with my phone offline. There's also no indication to the sender that their message has been sent to multiple devices or any obvious way of working out where its been seen.
There's also been the historical reliance on google services, the holsitlity towards people running their own servers and on occasion general hostility towards devs and end users too.
For something that started off as a way of sending p2p e2e encrypted textual communication over the lowest common demoninator protocol worldwide, it's come a long way. Being able to send animated cat gifs to a group is great, but it feels (especially with the server code so far behind and no real way of verifying thats actually what's running anyway) like we're getting further and further from simple & verifiable and more and more into trust us territory, and it seems right to treat that with some suspicion.
> the moment it stopped being possible to send an e2e encrypted text message
You're confusing e2e and p2p here.
Please don't do this, they are completely different things.
Signal messages are encrypted end to end, by the client, which is unambiguously open source: people can, and do, build the latest client using the published source code, to verify the binary.
You do have to register, so the server can perform contact discovery, and route messages. And it isn't peer-to-peer, messages pass through a central server for routing.
I have no objection to your disliking this architecture, I readily concede that it isn't as secure and anonymous as it theoretically could be, and as Matrix actually is.
But please don't propagate misinformation while doing so.
You're confusing e2e and p2p here.
Please don't do this, they are completely different things.
Signal messages are encrypted end to end, by the client, which is unambiguously open source: people can, and do, build the latest client using the published source code, to verify the binary.
You do have to register, so the server can perform contact discovery, and route messages. And it isn't peer-to-peer, messages pass through a central server for routing.
I have no objection to your disliking this architecture, I readily concede that it isn't as secure and anonymous as it theoretically could be, and as Matrix actually is.
But please don't propagate misinformation while doing so.
I think OP was actually talking about sending e2e-encrypted text messages (as in: SMS) through their phone carrier's infrastructure – which is what TextSecure (Signal's predecessor) used to support.
[deleted]
> You're confusing e2e and p2p here.
I was trying to consciously use both those terms and not interchangeably. It's still end-to-end encrypted, but it's impossible to work without interacting with their servers. When it first started as TextSecure it was capable of encrypting SMS between two handsets in a completely peer-to-peer way; no internet or 3rd party interaction required (just some ability to send SMS).
I was trying to consciously use both those terms and not interchangeably. It's still end-to-end encrypted, but it's impossible to work without interacting with their servers. When it first started as TextSecure it was capable of encrypting SMS between two handsets in a completely peer-to-peer way; no internet or 3rd party interaction required (just some ability to send SMS).
Ah, yes, that had completely slipped my mind. Sorry, I did misunderstand you: to be fair, Signal does send an e2e encrypted message-which-is-text, but referring to SMS as "text messages" is also pretty standard, I just didn't glean that from context.
Sure, being able to E2E an SMS was pretty cool! I've given up on SMS ever being replaced with a reasonably modern protocol, I think we're just stuck with siloed apps for the foreseeable future. Which is a pity. Maybe Riot/Matrix will be a fait accompli once its been around for long enough.
Sure, being able to E2E an SMS was pretty cool! I've given up on SMS ever being replaced with a reasonably modern protocol, I think we're just stuck with siloed apps for the foreseeable future. Which is a pity. Maybe Riot/Matrix will be a fait accompli once its been around for long enough.
Why put feeling in quotes? No need to be rude. I guess comments about feeling aren't allowed on HN.
What was serious or negative about my response?
[deleted]