moxie

What's more, HTTP's recent movement is arguably only because the web experience has centralized so much around Google.

Google already had the top two most popular websites in the world, so once Google Chrome also became the most popular web client, it was easy for them to develop a new communication protocol of their own, which everyone else has more or less begrudgingly agreed to call HTTP/2 and start deploying as well.

I hesitate to get all Clay Shirkey here, but I think this is fundamentally different from media conglomerates and Bell Systems, given that now anyone has the ability to build their own overlay service with relatively minimal investment.

Part of what I've been noticing is that we have these "walled gardens" today that people consider to be synonymous with "lock in," but it's actually easier for people to move from Viber to WhatsApp to Telegram to Signal today than it is for people to move from gmail to yahoo mail.

In a sense there's less lock-in with centralized messaging services than there is with the federated ones, due in part to the move towards user-owned identifiers like phone numbers.

The source code is for generating the QR code is online here: https://github.com/WhisperSystems/libsignal-protocol-java/bl...

Most users probably aren't worried about targeted attacks from adversaries who've compromised SS7, either. But the ones that are have an easy option.

How would apps running on Sandstorm avoid the problems with federation in today's world outlined in the blog post?

Check out the image at the top of the post: https://whispersystems.org/blog/whatsapp-complete/

This article glosses over a few important details.

The reason that end to end encryption exists is precisely because man in the middle attacks are possible, and always will be. This kind of attack is devastating for Telegram, because by default they don't use end to end encryption, and instead store the entire plaintext history of every message you've ever sent or received, all of which an attacker instantly gets access to.

For WhatsApp, everything is end to end encrypted by default, so the attacker doesn't get any message history. All of the contacts for the MITM'd user also get a notice that their contact's security code changed, and a comparison will fail to match. This is exactly what E2E was built to protect against.

You're right, Fred doesn't work at Open Whisper Systems. He's a student at EPFL, and is doing a summer internship at Apple this year.

Since the article mentions Signal, I think the author just wanted to make it clear that Fred's quotes come with a potential bias since he worked on Signal in the past.

But we're hiring if you want to be quoted in future Motherboard articles on private messaging! =)

https://whispersystems.org/workworkwork/

If you want to look at the Android APK, you can use apktool to get back Java source. Hacked clients like WhatsApp+ even build new derivative products using that output, and spammers do it to get code they can use to inject messages onto the network without having to write their own software.

I think it's great when people further verify WhatsApp's client security, please share your analysis!

> which declined to allow their E2E code to be audited.

Could you cite this? The Signal Protocol implementations they're using are both open source and well audited.

Yes, it is. It's linked directly from the paper (https://www.whatsapp.com/security/WhatsApp-Security-Whitepap...) that documents their use of the protocol.

It's the exact same code we use in Signal: https://github.com/whispersystems/libsignal-protocol-java

Signal Desktop messages aren't routed through your mobile device, so it's the best of both worlds. Once you've installed Signal Desktop, you can use it when your mobile device is turned off, and vice versa.

Correct, you need to have Chrome or Chromium (if you want something fully OSS) installed. Once you do, it functions like a native app (integrates directly with your OS's launcher), rather than like an extension (something attached to a browser window).

We might consider distributing it via something like electron in the future, but that's just a matter of packaging.

We've never used GCM in conjunction with the desktop app, so I'm not sure where you were looking. Writing and maintaining three different fully native apps for Windows, OSX, and Linux is a non-starter for most organizations these days, but it's particularly true for a small open source project like us.

We developed it as a chrome packaged app because it provides the same experience as a native app (appears fully stand alone, integrates with your native OS launcher, etc), and because that's where the people are in the world we live in today.

Eventually we might consider wrapping it in electron or equivalent, but that's just a question of packaging.

Works perfectly with Chromium if you'd like a fully open source alternative.

It's a Chrome packaged app, not an extension. It integrates with your OS to function just like any other stand alone application (visible in your native launcher, etc).

There is no difference, WhatsApp and Signal both use the Signal Protocol, and the same code: https://github.com/whispersystems/libsignal-protocol-java

By default, Telegram stores a plaintext copy of every message you've ever sent or received on their servers. WhatsApp does end to end encryption using the Signal Protocol by default, and doesn't store anything server side.

WhatsApp uses a shared identity across text and voice, so Signal Protocol is used to secure both connections.

We've long planned to do the same thing in Signal, but WhatsApp is ahead of Signal here. Axolotl is now called Signal Protocol, btw.

Correct. The only people who can read a message (or hear a voice call) are their intended recipients.

> They seem to have replaced TLS/SSL between client and server with "Noise Pipes".

WhatsApp was already using a custom protocol instead of TLS. We worked with them to transition over to Noise Pipes, which has some advantages over what they were doing before. Also, we've renamed Axolotl to Signal Protocol: https://whispersystems.org/blog/signal-inside-and-out/

Open Whisper Systems • San Francisco • Full Time • ONSITE

Open Whisper Systems is making private communication simple. Our technology is used by hundreds of millions of people, and everything we produce is open source. What it's like to work with us: https://whispersystems.org/workworkwork/

• iOS Developer -- Someone intimately familiar with iOS development and internals, who has an appreciation for the craft of software development and experience with making decisions that result in great products. No experience with cryptography necessary, just solid experience developing for iOS and an eye for good design.

• Android Developer -- Is the pleasure center of your brain directly wired to the experience of a slick UX or a nice animation? Do you hunt down memory leaks and StrictMode violations for fun? We're looking for someone with deep knowledge of the Android framework and an equally strong intuition for pairing beautiful app experiences with beautiful code. You'll be the architect of major features, making your code available to the world. You don't need to be a security expert; it's knowing how to make complicated systems simple to use that's at the heart of what we do.

See more at https://whispersystems.org/workworkwork/, or send us a note at workwithus@whispersystems.org

> All else equal...having a college degree in CS is an advantage in getting hired over being self-taught.

I don't think this is uncontroversial. I've done hundreds of interviews at companies large and small, and nobody else has ever brought up the education section of someone's resume in discussion.

I look at it occasionally, but my hiring preference is inversely correlated to the amount of education a candidate has. PhDs go directly to the bottom of the pile, then masters, then undergrad, and no school is on top.

Some bad signs:

1. Hosted in Switzerland is advertised as a security feature. The point of e2e is that the servers are untrusted. If you need a "good jurisdiction" for your servers, it means they must be trusted. That's a problem, because sadly there are no good jurisdictions in today's world, and your jurisdiction doesn't help you if your servers are hacked.

2. It's webmail. That means the security of whatever e2e they're doing is based on the security of SSL. If you break SSL, you can break whatever e2e they're doing, and that means your e2e security is only as secure as the CA system.

3. Their 'threat model' documentation leads with: "From a high level, our premise is that a service like the now-defunct Lavabit does add value, despite some inherent weaknesses. We designed ProtonMail around many of the same principles..." Given what happened with Lavabit (the eventual compromise of everyone's email despite shutting down the service), considering it to have been "valuable" should really be off the table at this point: http://www.thoughtcrime.org/blog/lavabit-critique/

I can't find much in the way of technical documentation for ProtonMail, but from what little is available, it does seem that (much like Lavabit), the service is built on the premise of "won't" read your mail rather than "can't" read your mail.

Open Whisper Systems • San Francisco • Full Time • ONSITE

Open Whisper Systems is making private communication simple. Our technology is used by hundreds of millions of people, and everything we produce is open source. What it's like to work with us: https://whispersystems.org/workworkwork/

• iOS Developer -- Someone intimately familiar with iOS development and internals, who has an appreciation for the craft of software development and experience with making decisions that result in great products. No experience with cryptography necessary, just solid experience developing for iOS and an eye for good design.

• Android Developer -- Is the pleasure center of your brain directly wired to the experience of a slick UX or a nice animation? Do you hunt down memory leaks and StrictMode violations for fun? We're looking for someone with deep knowledge of the Android framework and an equally strong intuition for pairing beautiful app experiences with beautiful code. You'll be the architect of major features, making your code available to the world. You don't need to be a security expert; it's knowing how to make complicated systems simple to use that's at the heart of what we do.

• Mobile UI / Product Designer -- We’re seeking an original thinker with strong visual design skills ready to help make private communication simple. You'll take on developing the look and feel of Signal on iOS, Android, and the desktop. You’ll be responsible for updating the visual design for the app and helping shape consistent guidelines to communicate a compelling user story across our products and other touchpoints. You’ll work closely with a team of engineers with a passion for making usable software. No experience with cryptography necessary, just intuition for what makes a great product and solid experience designing products that are a joy to use.

See more at https://whispersystems.org/workworkwork/, or send us a note at workwithus@whispersystems.org

It's actually the exact opposite. Telegram has made design decisions that prevent them from ever being able to provide private messaging by default without radically altering their design and re-writing all of their clients. The Telegram "client" is really the server -- everything happens there, and the client you use is just a view onto the server.

The author definitely knows about it, since the thesis of the article is that Signal would be near-perfect if the multi-device flow were usable but "..the process for setting it up is annoying."

It's fine if the author hasn't tried it, but don't write an article criticizing the usability of something you haven't even tried.

Wait, have you actually used Signal multi-device? Your thesis is that it's not usable because you have to scan a QR code once, as opposed to Telegram where you have to receive an SMS on your device and manually type it in on your desktop?

The flow you're describing in your "possible solution" is basically identical to how Signal works now: you install Signal on a new device, approve it with your existing device, and are done. Anything involving the word "blockchain" here is fundamentally not going to work. It sounds like you want CONIKS, but there are some really substantial barriers to deploying that for marginal gains (and some clear losses).

Marginal improvement in what sense? When considering privacy, Telegram is by far the worst option. They store the plaintext message history on the server of every message that every user has ever sent or received.

Even if WhatsApp weren't using end to end encryption by default, they would have no way of complying with government requests like this one, because they simply don't have the messages. Telegram, on the other hand, is a surveillance dream.