18 ms·
Signal Server code on GitHub is up to date again
- red_trumpet 6y agoIs there any mechanism to validate that the code running on Signal's servers is the same as on Github?
- knocte 6y agoNo.
- Someone1234 6y agoHow would that work? You'd be layering trust on trust, wherein if they're willing to lie about one thing they're willing to lie about confirmation of that same thing (or not). Unless you're going to hire some independent auditor (that you still have to trust) it seems logically problematic.
- madars 6y agoSGX enclaves can attest to the code they are running, so you don't exactly need to take Signal's word on faith.
- eptcyka 6y agoExcept SGX enclaves are horribly broken.
- monocasa 6y agoLike, does an SGX enclave attest that meltdown is patched in microcode? That's one way to pull the keys out. The recentish work to get read write access to some Intel CPU's microcode can probably break SGX too. I wouldn't be surprised if the ME code execution flaws could be used that way too.
- Someone1234 6y agoThat isn't a solution to the problem being discussed (a provider's server code being verifiable by end users). I'm quite confused by the suggestion that it could be/is.
- Foxboron 6y agoThere isn't, but people are working on getting us there. The first project that comes to mind is "System Transparency". https://system-transparency.org/ https://system-transparency.org/
- mikece 6y agoSeems there should be an API endpoint, similar to a health check endpoint, that allows one to validate that the code on the server matches what's in GitHub. How exactly that would work is beyond me since I'm not a cryptographer but seems like an easy way to let developers/auditors/the curious check to see that the code on the server and GitHub match.
- monocasa 6y agovalidate_endpoint() { return hash_against_other_file_not_exe(); }
- beaconstudios 6y agoif you assume that the server can lie to you, then it's physically impossible. Any query could be answered by interrogating a copy of the github version of the server and returning the answer.
- jhugo 6y agoHow could that possibly work? The API endpoint of a malicious modified server could just return whatever the API endpoint of the non-malicious non-modified server returns.
- monocasa 6y agoThat's basically the same problem as DRM, so no, you can't verify that someone is running only code you want them to run against data you gave them, on hardware they own.
- lxgr 6y agoYet DRM does exist. (Yes, these schemes usually end up getting broken at some point, but so does other software.) The problem is more generally called trusted computing, with Intel SGX being an implementation (albeit one with a pretty bad track record).
- monocasa 6y agoDRM has only been successful in the space of making easily replicable attacks more expensive than what is being protected by the DRM. Microsoft has talked about this publicly in this great talk on the Xbox One's physical device security. 'We can't stop people hacking, but we can make each hack more expensive than what someone would spend on games on average'. https://www.youtube.com/watch?v=U7VwtOrwceo https://www.youtube.com/watch?v=U7VwtOrwceo SGX running on centralized servers turns that calculus on it's head by concentrating the benefits of the hack all in one place.
- danpalmer 6y agoI think the argument would be that with end-to-end encryption this is unnecessary, which is good because it's impossible. There's a counter-argument that there is still useful metadata a server can glean from its users, but it's certainly minimised with a good protocol... like the Signal protocol.
- cortesoft 6y agoWait, how would end-to-end encryption help this problem at all? I agree that it is impossible (currently), but not sure how E2E helps anything? E2E encryption only helps you verify WHO you are connecting to, not what they are doing with your connection once it is established.
- edejong 6y agoYes. Auditors Trusted Enclaves (but then you trust Intel) Signed chain of I/O with full semantics specified (blockchain style).
- hoophoop 6y agoNo. If Signal /was/ federated it would be a strong hint that the server code stays the same. And even if it's not the same, people would be able to run their own trusted servers.
- ViViDboarder 6y agoFederation pretty much guarantees the opposite. There would likely be many servers running many different versions whereby you’d have no way of knowing which are trusted or not. It, by design, distributes trust. This means there are more parties to trust. Anyway, Signal is designed to handle all the private bits at the client side with e2ee so you have to put as little trust in the server as possible.
- gorkish 6y agoI am curious how this could even possibly be done. As far as my understanding goes, it's hardly possible to even verify that a compiled binary represents a faithfully executed representation of the source instructions, let alone that it will execute that way when run through a modern OS and CPU pipeline. I would think the objective here is more about releasing server code that can be run independently in a way that 1) doesn't involve signal's infrastructure and 2) allows the client/server interactions to be audited in a way that trust of the server side is unnecessary, regardless of what code it may or may not be running.
- jiveturkey 6y agoYes, via SGX remote attestation. https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation
- deleted 6y ago[deleted]
- codethief 6y agoAs others have already mentioned there is Intel SGX and the Signal developers indeed say they use it, see https://news.ycombinator.com/item?id=26729786 https://news.ycombinator.com/item?id=26729786
- louwrentius 6y agoOK, good! Now please remove that cryptocoin stuff from the app. Don’t create another avenue for money laundering, tax evasion and drugs sales (if not worse).
- lvs 6y agoI read some speculation that the delay was to keep this objectionable crypto payment development under wraps until they were ready to launch.
- prophesi 6y agoYep. I posted this on a different Signal HN submission, but the very next commit on April 22nd, 2020 was when they first began working on the integration. https://github.com/signalapp/Signal-Server/commit/95f0ce181631fef8b1fdb507b7ecf5b71291ff38 https://github.com/signalapp/Signal-Server/commit/95f0ce1816...
- yunohn 6y agoOh wow. That’s incredibly suspicious...
- yjftsjthsd-h 6y agoIt could just be an arguably-legitimate desire to keep the hot new feature secret until the big announcement; this particular bit is... sub-optimal... but it doesn't seem like it needs to be nefarious.
- olah_1 6y agoThe devious aspect to this is that nobody knew the development was happening so we couldn’t invest even if we wanted to. It was kept under wraps for a grade A pump.
- pmlnr 6y ago"Signal Server code on GitHub is up to date again - now with a freshly added shitcoin!"
- mtmail 6y agoThe addition of micropayments to Signal is discussed separately at https://news.ycombinator.com/item?id=26724237 https://news.ycombinator.com/item?id=26724237
- hu3 6y agoIt's obviously related. The implication is that they pushed code to Github just to gain public trust that can be leveraged to market their cryptocurrency.
- mnd999 6y agoI think you’re part correct. I suspect they didn’t want to go public with the shitcoin until it was done.
- hvis 6y agoThat makes a lot of sense, though. It was probably apparent to them that adding the new crypto payments feature would create at least some kind of community pushback. Waiting until the feature is reasonably complete and can be judged on its merits is good from a business perspective.
- Slartie 6y agoIt's also good from a very personal business perspective to have the crucial inside information of an obscure coin named "MobileCoin" (sitting on CoinMarketCap Rank #2378) about to be pumped HARD once the news about inclusion into a popular messaging app hits the airwaves. It's especially good to have this information while said coin is already publicly traded on some (albeit obscure) exchanges. Because that allows you, as an insider, to slowly accumulate a nicely sized position in that coin while it's still cheap. "MobileCoin" wasn't publicly traded until December of last year, there wasn't even a live blockchain until that month, so if it's true that the first commits in the Signal server repo hinting at the crypto payment plans were created shortly after the repo went silent in April 2020, it is obvious that keeping these commits secret until at least December 2020 was crucial to successfully realize these good personal business perspectives - a.k.a. insider trading, but nobody cares about it if it's crypto.
- schoolornot 6y agoNice, if only they could be so kind after all this time to provide instructions on how to run it. I don't get why they have been dancing their reputation around Hacker News this way by not releasing sources until there were a bunch of front page posts about it.
- fartcannon 6y agoIf it looks like a duck, and quacks like a duck, it's probably a duck.
- newscracker 6y agoSo it just took close to a year to dump thousands of private commits into the public repo! Is there an official response as to why they stopped sharing the code for so long and more importantly, why they started sharing it publicly again? Who gains what with the publication now? And seriously, why is it even relevant anymore?
- jiveturkey 6y agoI think it's proof that security (and privacy) doesn't matter. So it is very relevant. (As if telegram as competitor isn't enough proof.) The entirety of the signal "stack" depends on the SGX enclave. The fact that no one, in all time, has bothered to notice that the running code is different than the published code, is telling. There's actually a newer SGX exploit, and related mitigation, that came to light at about the same time when they released their discovery protocol. Those mitigations were never backported to the base signal functionality. That no one audited and complained about this says quite a lot. I've not looked at this code dump but perhaps the newer fixes finally made their way in. Or have been there all along.
- ajconway 6y ago> The fact that no one, in all time, has bothered to notice that the running code is different than the published code It’s client apps who verify (via attestation) that the code inside an SGX enclave is what they expect it to be, and clients are open source. > The entirety of the signal "stack" depends on the SGX enclave Only private contact discovery depends on trusting SGX.
- jiveturkey 6y ago> It’s client apps who verify (via attestation) that the code inside an SGX enclave is what they expect it to be, and clients are open source. If the attestation signature matches the published enclave code, then we can know if there's a match. So either there's a missing mitigation, which no one ever has complained about, or the running enclave code doesn't match the source, which also no one ever has complained about. Without independent audit, there is no verification and we have established that independent parties do not care. > Only private contact discovery depends on trusting SGX. uh, no. this is demonstrably and obviously wrong.
- tlarkworthy 6y agoIf you have a PhD you might be able to verify from the client-side it does not matter. If you are into blockchain there might be another (but very expensive) way to show a system can be trusted. For normal development, I am advocating an always auditable runtime that runs only public source code by design:- https://observablehq.com/@endpointservices/serverless-cells https://observablehq.com/@endpointservices/serverless-cells Before sending data to a URL, you can look up the source code first, as the URL encodes the source location. There is always the risk I decided to embed a trojan in the runtime (despite it being open source). However, if I am a service provider for 100k customers built upon the idea of a transparent cloud, then compromising the trust of one customer would cause loss of business across all customers. Thus, from a game-theoretic perspective, our incentives should align. I think running public source code, which does not preclude injecting secrets and keeping data private, is something that normal development teams can do. No PhDs necessary, just normal development. Follow me on https://twitter.com/tomlarkworthy https://twitter.com/tomlarkworthy if you want to see this different way of approaching privacy: always auditable source available server-side implementations. You can trust services implemented this way are safe, because you can always see how they process data. Even if you cannot be bothered to audit their source, the sheer fact that someone can, inoculates you against bad faith implementations. I am building a transparent cloud. Everything is encoded in public notebooks and runs open-source https://observablehq.com/collection/@endpointservices/services https://observablehq.com/collection/@endpointservices/servic... There are other benefits, like being able to fork my implementations and customize, but primarily I am doing this for trust through transparency reasons.
- mulmen 6y agoHow do you prove the endpoint is running the code to which it links?
- tlarkworthy 6y agoSimple but not 100% foolproof, you can mutate your source code and verify the changes propagate. Note the endpoint does a DYNAMIC lookup of source code. So you can kinda reassure yourself the endpoint is executing dynamic code just by providing your own source code. It might be more obvious the runtime does nothing much if you see the runtime https://github.com/endpointservices/serverlesscells https://github.com/endpointservices/serverlesscells The clever bits that actually implement services are all in the notebooks.
- MAGZine 6y agoIs it though? We're already 6 days without a commit. Who knows that the history isn't frozen again until the next major release?
- dtx1 6y agoAfter people started to realize that WhatsApp, owned by Facebook, started changing their privacy settings from terrible to slightly differently terrible, people flocked to and were recommended Signal by so called experts. Yet no one at that time bothered to point out that signal has been opaque as fuck about just about anything they do. On the other hand a free, self-hostable, highly transparent, highly secure alternative exists in the form of matrix. But of course tech media didn't recommend it because it requires a modicum of thought and technical understanding. To me this drives home one key issue: the bulk of users is either too stupid or unwilling to invest even the tiniest amount of effort into their privacy. If you don't want to be saved then fine, give up a detailed profile of your life, interests and opinions into the hands of large megacorps that sell you as their product to advertisers, governments and whoever has the cash. But don't come crying to the experts when your private information has been leaked for the thousands time and don't ever expect a fair election again when political parties can microtarget you into oblivion. It's not a matter of not knowing anymore but willful ignorance. Democracy and Freedom won't die with thunderous applause but the silent callousness of an unthinking majority.
- grumpyautist 6y agoMatrix is still broken though. I find XMPP to be sufficient at least until matrix fixes their group encryption
- dtx1 6y agoGot a source for matrix group encryption issues? EDIT: From their [FAQ](https://matrix.org/faq/ https://matrix.org/faq/) > End-to-End Encryption is fully supported in Matrix. New rooms have encryption enabled by default, and all existing rooms can optionally have End-to-End Encryption turned on. What exactly do you think is broken here?
- omnimus 6y agoux is seriously broken. i run my own instance and even i cant verify my encrypted sessions. Like i already have some three security codes that i have no idea when to use and verification of my own devices often randomly fails. its just mess and i think it works properly maybe on main instance. its nowhere near encryption on signal
- deleted 6y ago[deleted]
- jeffo_rulez 6y agokinda crazy that the signal team doesn't GPG sign their commits.
- hda2 6y agoA example of how irrational hate can make smart people do stupid things, unfortunately. Certain people on their team don't like the PGP standard despite the fact that it is mature, standardized, and proven to work well for code signing. When questioned about their reasoning, they'd usually deflect and criticize some aspect of PGP that is irrelevant to code signing at all. In their minds, they believe it is better to rely on git's broken SHA1 fingerprints than to use PGP.
- subsubsub 6y agoGiven that you have said... "the bulk of users is either too stupid or unwilling to invest even the tiniest amount of effort into their privacy." I don't feel the need to pull my punches. This is the most deluded, idiotic response I've seen on hacker news in a long time. It seems unlikely that the average person (or even a non-techie person of above average intelligence - e.g. a doctor) will be able to set up matrix in a way that is more secure than just installing signal. Your security relies not just on you but on the weakest node in your network. Getting good security might require trade-offs. Your all or nothing mindset will not achieve it. The saying "Perfect is the enemy of done" comes to mind. Perfect security (or what you purpose) is not one of the options in a secure system that has to exist in the real world. Please remove your head from it's dark cavernous home. Love, Me
- subsubsub 6y agoP.S. Goodbye HN, you don't matter any more.
- dtx1 6y agothe average person doesn't use signal they use phones, whatsapp and facebook. You can use the public matrix node and i can use my own node and we can talk. No setup needed. If they care they can buy a hosted matrix service package like this https://element.io/pricing https://element.io/pricing with their own instance run by people who probably know what they are doing. In before "but it's not free as in no cost". That's why big corps will always fuck over the normies. As it stands, one cannot use the internet without either giving away their privacy or learning a lot about computers and how they work and how to use them. The majority chose the "i don't care, give me shiny app" route. and they fucked us all over by doing so. There's no right to easy privacy friendly computing. There's only the harsh reality that behind friendly blue and rainbow colored companies sit people that will sell a digital recreation of yourself to anyone who cares to pay and give you a few gigs of free e-mail space and a shiny app for it.
- dtx1 6y agoto prove a point here, use a browser without adblocking and other extensions like chrome for a week and look at how they are targeting you. That's what they do to anyone without the willingness to fight it with technical knowledge. And that sadly is the majority.
- BTCOG 6y agoYou can't even use MobileCoin in the US (Not that I'm a Signal user) but are they either planning on focusing on foreign markets, or planning on getting audited heavily by all the US financial agencies?
- Vinnl 6y agoI think they're anticipating support for other coins, which might work in the US, judging by their blog post [0]: > The first payments protocol we’ve added support for is a privacy focused payments network called MobileCoin, which has its own currency, MOB. (Emphasis mine.) [0] https://signal.org/blog/help-us-test-payments-in-signal/ https://signal.org/blog/help-us-test-payments-in-signal/
- random5634 6y agoThe crapcoin thing is REDICULOUS! THIS is what we setup nonprofits to support - some private entity and their crapcoin? How is this legal? How is this not a conflict of interest? How is this not private inurment? The crapcoin is totally opaque to. With premined coins.
- jeltz 6y agoIt probably isn't legal but people use non-profits all the time for personal gain and get away with it almost always.
- random5634 6y agoExploiting nonprofit status to generate a personal benefit is not legal in the US. So if the board members, officers or whomever have some personal benefit to this crapcoin taking off, it's not legal for them to use nonprofit resources and tax breaks to push for that.
- woah 6y agoA lot of these comments are just manifestations of the kneejerk HN "crypto bad" reflex. Here's the deal: - Whether or not Signal's server is open source has nothing to do with security. Signal's security rests on the user's knowledge that the open source client is encrypting messages end to end. With that knowledge, the server code could be anything, and Signal inc. would still not be able to read your messages. In fact, having the server code open source adds absolutely nothing to this security model, because no matter how open source and secure the server code might be, Signal inc. could still be logging messages upstream of it. The security rests only upon the open source client code. The server is completely orthogonal to security. - Signal's decision to keep early development of the MobileCoin feature set private was valid. Signal is not your weekend node.js module with two stars on Github. When changes get made to the repo, they will be noticed. This might mess up their marketing plan, especially if they weren't even sure whether they were going to end up going live with the feature. Signal is playing in the big leagues, competing with messengers which have billions of dollars in marketing budget, will never ever be even the smallest amount open source, and are selling all your messages to the highest bidder. They can't afford to handicap themselves just to keep some guys on Hacker News happy. - Signal's decision to keep development to the (private) master branch, instead of splitting the MobileCoin integration into a long-running feature branch is a valid choice. It's a lot of work to keep a feature branch up to date over years, and to split every feature up into the public and non-public components which then get committed to separate branches. This would greatly affect their architecture and slow down shipping for no benefit, given that the open sourceness of the server is orthogonal to security.
- unhammer 6y ago> The security rests only upon the open source client code. The server is completely orthogonal to security. For Android at least, builds are reproducible https://signal.org/blog/reproducible-android/ https://signal.org/blog/reproducible-android/ (would be neat if there was one or more third party CI's that also checked that the CI-built app reproduces the one on Google Play Store – or maybe there already are?)
- cptskippy 6y ago
- NotSammyHagar 6y agoI am disappointed they are supporting mobilecoin yet it's not available for use in the US. I understand it has important privacy and security features, but there seems little point to it if it can't be used in most of the world (the us isn't that big, but it's important financially). There were some confusing comments that it could be supported one day, easily. I guessed that it wasn't supported because they somehow want to avoid us financial regulation. So what is the reason for no us capable currencies here?
- varispeed 6y agoHow long until it gets closed down because you know dealers and stuff? On the other hand is it possible to compile the whole thing and run Signal on premises end to end?
- Klwohu 6y agoDo you still need to give them your phone number though?
- a3w 6y agoThank Fefe for that: https://blog.fefe.de/?ts=9e9221ad https://blog.fefe.de/?ts=9e9221ad (second update in posting, completely in german) Coincidence or bad press covfefe? ;)
- Aachen 6y agoFor updating the source? Fwiw I skimmed it and it doesn't say anything of the sort. But thanks for making me look at this, now I know which of my friends keep up with their blog to the minute. I've heard these arguments word for word a couple hours ago...
- deleted 6y ago[deleted]