6,910 karma · joined March 12, 2010
I led a program for teens in the Caribbean one summer. One of my teens took a shit in the woods on an island, and unknowingly wiped his ass with a leaf from this tree. It was a long 5 weeks for him.
It's an asynchronous world, trying to use a synchronous protocol in that world doesn't make a lot of sense. If you want to initiate an OTR session with your friend on an iPhone, you have to wait for them to pull the device out of their pocket and physically tap the notification (which just says something like 'you might get a message soon'), then receive the response (which might involve pulling the device out of your pocket and physically tapping the notification which says something like 'you can send a message now'), before you can send the actual message.
This isn't just "initial presence," either. OTR is a three-step ratchet, so if you want the benefits of forward secrecy, you have to "end" your OTR session after each conversation and "start" an OTR session at the beginning of the next one. Except we don't live in a world where there are "beginnings" and "endings" anymore. People aren't sitting down at their computers and chatting until they get up again, it's just one long asynchronous conversation now.
> I guess, it's a wrong sort of ubiquity, probably not something that works for the goal of "encryption for everyone", but it still works if I don't want to hop the services but layer security instead. Maybe that's too old-fashioned. Hope there will be Signal Protocol-based addons/libraries like this one day.
You can do this today if you want to, but what's the point when Signal Protocol is being baked into the messaging services themselves. Layering encryption has been a losing strategy for a decade or more now, building something that works so seamlessly that it can be a part of the default experience is actually showing progress.
In terms of ubiquity, Signal Protocol is running on over two billion monthly active devices. I would be surprised if OTR's active install base exceeds a hundred thousand.
We renamed the Axolotl ratchet and Axolotl protocol because there was a lot of confusion around what it meant to say "Axolotl." Some people who continue to use the term "Axolotl" do so because they seek to benefit from that confusion.
It is great that Wire has finally open sourced their software. They have been advertising themselves as open source for the past two years, though, so I guess they weren't really able to make an announcement about this.
I assume that higher latency communication like WhatsApp's push-to-talk "voice notes" works just fine in SA though.
The author's suggestion that it's impossible for SA to block VoIP without blocking messaging is incorrect.
It seems as if WhatsApp is short circuiting this frustrating series of timeouts to improve a flaky seeming UX. That strategy does negatively effect people on the internet who register for WhatsApp with Saudi VoIP numbers when they're in France, but it is a much clearer UX for almost everyone who is actually a Saudi WhatsApp user or calling actual Saudi users. What the author is demanding is a worse UX for the same outcome.
It sounds like there might be room for improvement, but I have a feeling that if WhatsApp were recording their users' locations in order to provide a more advanced location-aware version of the same strategy, people would not be very happy about that.
Voice/video etc are obviously straightforward; hopefully they'll continue to iterate towards support for e2e by default.
This is not a "giant flip." We told Chris and everyone else both in person and publicly that they were free to use these libraries in their apps so long as they were otherwise complying with the GPL. You can even see my response to that exact comment here: https://news.ycombinator.com/item?id=11727870
Even though we had given explicit permission for Chris and others to use this code in their OSS apps, people like you -- who wish to see conspiracy in every choice we make -- continued to paint it as some kind of cold calculated move to prevent OSS apps from using our software (for what reason is beyond me). So we worked with a lawyer on this solution.
And now, what? This is part of the conspiracy too. Great.
Yes, that is what I said, after they explicitly asked "Let's ask @moxie0 if he is OK with LibreSignal using OWS servers."
They asked, "are you OK with this," and I responded "I'm not OK with this." I never took any action at all, just gave them my opinion when they asked for it.
If you think it's reasonable to go around telling people that I "threatened legal action" to LibreSignal based on that exchange, I don't know how you expect me to take anything you say seriously.
What in the world do you think our motivation is, then? We're not a business, it's not like we're doing all of this to capture revenue. We could all be making orders of magnitude more working elsewhere. We're doing this because we believe it's the most effective way to make private communication ubiquitous, and it's working.
> How many Signal users don't have GCM or Play Store? 1%? Hardly an extreme server load burden. More so, it would have attracted code contributions to further improve Signal. Equating THAT with assault as you have, is rather fkng melodramatic.
What code contributions? If this is something you want to see in Signal, sure, submit a clean well-written PR and stick around to maintain it. The only contributions we've seen from this particular community haven't even begun to pass code review.
> Oh, wait, people are taking liberties and entitlements? Well what the hell do you think you're doing by using the GPL in the first place? What was the spirit and intent of the authors who wrote it? Do you think THAT is being respected?
Exactly, we make our code available under the GPL. That entitles you to use the code for whatever you would like under the terms of the license. It does not entitle you to use our service for your product, or to use our name for your product.
> Quite simply, don't give people nasty lock-in surprises. If you intend to be a closed, tightly-controlled cathedral of non-optional dependencies on large swathes of commercial mystery meat blobs - then just say so in the first place. If you start off with non-commercial protocols like SMS, then switch to GCM, plus have federation clearly in your plan, until you're big enough you don't have to care and can rip it - then give people an out that doesn't involve losing their whole network.
I think I've been pretty consistent in my position from the beginning. I've been saying the same things over and over at least since #127, which was early 2013. It's true that we wanted to pursue federation, and we did. But when we tried it with Cyanogen, it was a total nightmare that probably set us back a year in development time. So we've learned from our mistakes, which I think is a good thing. We'd all be better off if projects like XMPP had also learned from their mistakes.
> Whether you like it or not, a big part of the reason Signal attained the critical mass of users necessary to take it to the next level, was the promotion and backing of the FOSS community.
I don't know what you consider "the FOSS community," but I think of them as being the same people who have been sending me a torrent of verbal abuse, legal threats, and even death threats pretty much non-stop over the past three years. At no point have I wanted any part of that.
> The attack on open protocols, cooperation, standards and community is hence the most disappointing part. We wouldn't even be having this conversation, if we weren't here standing on the shoulders of giants of open protocols from IETF, W3C, etc. Signal's contribution was respected as one of those, until it transformed (or revealed?) itself as a closed monopoly.
Plenty of people have used the Signal source to build their own projects (some even in "the FOSS community" like SMSSecure), so I don't know how you can say it's closed. Plenty of other people have also come to our project with an understanding of our development goals, and have helped to contribute to making Signal something better. A very small vocal minority of FOSS moralists have decided that we should have to do whatever they want if they scream loudly enough, and have contributed very little of anything but verbal abuse.
Olm/Megolm is not Signal Protocol. It is an entirely different protocol that has made different choices, and those choices have received less study and scrutiny. It hasn't been deployed anywhere that I know of. It's fine if you want to explore those choices, but I would caution against calling it the same thing.
> the one major thing LibreSignal wanted and were threatened legal action with if they did
I understand that because we have what you consider to be unpopular opinions, it's easy to believe that we're somehow single-handedly responsible for everything bad in the world. However, you can't just make shit up. Legal action? Could you cite that?
The entirety of our exchange is in the top of that issue. They asked for permission, and I said we'd prefer for them to use their own servers and their own name. The same thing we say to everyone. Many people do set up their own servers for their own products, these people chose not to. We didn't threaten anyone with anything, legal or otherwise.
> 'Open' Whisper aren't open sourcing their server. The voice side is locked up.
https://github.com/whispersystems/textsecure-server https://github.com/whispersystems/pushserver https://github.com/whispersystems/websocket-resources https://github.com/whispersystems/dropwizard-simpleauth
By "the voice side," do you mean a TURN server? Plenty of options for you out there. Or are you just more interested in having something to blame us for?
And LibreSignal already doesn't support voice, even with our servers, so your complaint doesn't make much sense.
> Why have Signal Protocol chosen now to open the license up a little? Well, I can't help but wonder if it's because Olm is finally ready, done and merging for public release.
The conspiracy theories never stop. We haven't changed anything, this has been what we said our policy was all along, but people thought that was some kind of conspiracy. Of course, now that we've made it an explicit license term instead, that's also suspicious somehow. Why would anyone ever want to be involved in this community you think we're not appropriately considering?
Yes, the expectation is that you still have to comply with the GPLv3 (including making the corresponding source for your derivative work available), at which point you have the additional freedom to distribute the app through the app store.
Totally. Client interoperability as well. For us, the problem is that when a 3rd party client breaks compatibility, that doesn't just affect the users of those 3rd party clients, but the normal Signal users who communicate with them as well.
For example, LibreSignal doesn't support voice calls. When normal Signal users try to call LibreSignal users, it just doesn't work. Most normal Signal users don't care or understand or sympathize with the idea that the person they're trying to call uses some other app which doesn't support voice calls. They'll just think that Signal voice calls are flaky and randomly don't work sometimes.
That's one example, but as development progresses, there will inevitably be more. We're concerned about exactly the same set of problems we found with federation.
> But that's stopped being a unique feature since WhatsApp also uses the Signal Protocol, which simultaneously made it feel much less pressing to convince non-nerds to switch from WA to Signal.
Just to be clear, I think that's great. If people don't feel it's necessary to use Signal because Signal Protocol is "the new normal" in the apps they already use, then I think we've succeeded. Hopefully we'll eventually have the chance to push the envelope forward again and restart that cycle.
However, I'd be interested to hear more about why you think those unpopular opinions constitute "mistreatment." Am I guilty of something more than articulating my preferences and explaining our rationale for the decisions that we've made with our project?
We renamed the Axolotl Protocol and the Axolotl Ratchet because of the confusion between the two (https://whispersystems.org/blog/signal-inside-and-out/), particularly when people just used the word "Axolotl."
Often when people intentionally continue to use the word "Axolotl" now, it's because they're trying to benefit from that confusion. Olm, however, has been clear about being a different protocol.
Most of your communication has centered around asking us to change the license on our source base to something other than the GPL. We like the GPL for the quality control that it provides. If someone publicly says that they're using our software, we want to see if they've made any changes, and whether they're using it correctly.
You don't like the GPL because you feel that it is incompatible with the Apple App Store, despite our feelings to the contrary. If you'd like to do the work of developing a strong copyleft version of the GPL that you feel is appropriate for use in the app store, and get it OSI approved, we'd certainly look at using that.
As for documentation, there has never been a protocol called AxolotlV2. There was TextSecure, the crypto layer of which has evolved into Signal Protocol. We'd like to get this better documented so that people without crypto expertise can integrate it without having to talk to us, but that's a pretty heavy task that comes with a massive amount of responsibility, and some parts of this are still evolving. It's a priority, but we are taking the time to do it right, and hopefully we'll have more to publish this year.
We haven't patented any of the concepts here, and we've done a lot to explain and popularize them. We're happy for people to use these concepts to build their own implementations of similar protocols, but we don't want people slapping things together and calling that Signal Protocol.