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.
replies(4):
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...
https://web.archive.org/web/20210311053716/https://github.co...
As of earlier this month, the repository was a year out of date.
[0] https://github.com/signalapp/Signal-Android/issues/11101#iss...
I think a member of the team made it public ~15 minutes ago if I'm reading correctly.
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.
>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
That's a serious accusation you are 'feeling'. What evidence do you have?
This only matters if you cared about backward-compatibility. Otherwise you can just push breaking protocol changes without regard for third party clients.
They could easily add a backdoor in the client despite the fact that it's "open source", because no one builds it from source.
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?
Just a few minutes ago the server code was updated. Im honestly not happy about this. Feels yucky
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"
I can't blame the Signal project for wanting to avoid it entirely. You can of course disagree!
This _is_ the support headache, not a workaround for some other straw man support headache.
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”.
Author: Moxie Marlinspike <moxie+github@signal.org>
AuthorDate: Thu Apr 2 12:45:24 2020 -0700
Commit: Moxie Marlinspike <moxie+github@signal.org>
CommitDate: Wed Apr 22 12:32:53 2020 -0700
Support for advertising payment addresses on profile
Also, there is competition like Briar which has less of those pesky metadata problems (but some other problems instead)
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.
Mozilla Public License - E2E Encryption - P2P Messaging - Active community & git repo - Integrated Ethereum wallet for Web3 access
The app store is a single point of failure with huge reach.
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.
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.
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 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.
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.
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.
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!
There is no interpretation of these events that's a good look, especially for a platform focused on privacy.
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
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/
[1] https://github.com/signalapp/Signal-Android/tree/master/repr...
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.
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.
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.
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)
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.
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/
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?).
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
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.
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.
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
> 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...
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.
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...
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
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.
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.
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 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.
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...
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.
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)
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.
They've been known to reset passwords remotely in the past: https://www.theverge.com/2016/3/30/11330892/fbi-google-andro...
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 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.
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
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.
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.
Edit: Also, you cannot post on the other link for some reason?
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).
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"
The only realistic alternative would be Matrix, but that's not usable for the average user yet (too unpolished).
https://news.ycombinator.com/item?id=26713827
The rest is a dupe-by-value, which is how dupuolity works on HN.
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.)
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).
[0] says use outside Signal is unsupported. And it's only for Java, Swift, and TypeScript.
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.
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.
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.
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.
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.
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.
Apparently everyone thinks opensource means real time access to development.
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.
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.
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?
There's another active thread today: https://news.ycombinator.com/item?id=26725915
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.
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.