"We use JavaScript. All encryption happens on your browser"

How do you prevent the scenario of being forced to provide a poisoned client-side encryption payload, just like e.g. Hushmail was?

1. Our code is public. https://github.com/lavab

2. We'll have Chrome/Firefox extensions for something similar to "signed binaries"

3. We offer the option to run the web client yourself (git clone https://github.com/lavab/web && cd web && npm install && gulp && open "http://localhost:5000")

4. We'll build native desktop and mobile clients.

Hope this answers your question.

Native, or client-hosted javascript sounds workable. Server hosted Javascript cannot be secure even in theory (without a client-side plugin). I gave up on this problem when I shuttered Harpo Mail because of this and I am a US Citizen and realized I can't legally or ethically claim I won't turn you over to the Feds if they hold a gun to my head. It sounds like you are addressing those issues and more, and I wish you success.

Thank you! :) Our servers and us are also based in Germany, which is a plus.

How is it a plus that they're hosted in Germany? The German spy service are on record spying for the NSA, and of course only German citizens are protected by German law, so if anything, for users from the US, being hosted in Germany should be even worse than being hosted in the US (Assuming, the current slow, blow-back against the NSA goes anywhere).

I don't really understand this fascination with hosting things outside of the US "for security" (from apparently, mostly US citizens). Personally I'm in Norway, where the secret police have been spying on "dissidents" (it used to be the "far" left, nominally the neo-nazis/fascists (although they missed the only terror attack, despite having a tip before the fact) -- now it's the "radical" Muslims (you know, a clearly defined threat to national security, aka "brown scary people")).

But regardless of how one feels about using Stasi methods to help perpetuate and sustain illegal wars on the middle east -- one thing should be abundantly clear: Nowhere (AFAIK) does foreign citizens have any rights to not be spied on by local intelligence services. And of course all of NATO is working together on gathering it (along with Sweden, which Norwegian intelligence reportedly work closely with).

All that said, while I think we should all work at taking back our respective governments, and strive for a better (more free) political environment -- I don't think the only measure for an email service should be "am I now safe from state-sponsored actors". In fact, I think that should actually be pretty low on the list.

Use gpg, or give up. More significantly, if you can't do the work for a proper web-of-trust/key distribution and verification, you can't be secure (in the sense indicated above).

I still think services like these are miles better than you-are-the-product, like gmail/outlook.com etc.

Good luck on your service!

There's a difference between spying on something and forcing you to do something. I think the idea is there's no "Patriot Act" and National Security Letters in Germany to force providers to introduce backdoors.

The "NSA can spy on you argument" doesn't really apply here. You just try to provide solid security against that. Having poor security in "America" wouldn't save you from NSA anyway.

I don't think it's realistic to expect that a provider can't be forced to facilitate secret wire-tapping in any jurisdiction (Nor do I think that is really desirable). Wasn't the (relatively) recent child-porn ring bust an operation involving lots of jurisdictions?

I also don't think Germany will be a safe haven for someone working against the drone program if that involves leaking classified information (otherwise known as espionage, even if it stems from altruistic motives).

I feel people are as much in denial about the likelihood of spying by European governments, as many were about the NSA (and for no better reason -- the NSA was documented to break the law long before Snowden, and so have various European governments).

I don't really see this as much of a win either way. But perhaps it's good marketing copy.

From what I've been told, it's significantly harder to confiscate servers in Germany - but even if that somehow happens, all they would find on our servers is a bunch of encrypted blobs.

As I've recently discovered[1], there appears to be ample room for a good xmpp service as well as for email. Any plans to host a jabber service? If you manage to handle distribution of gpg-keys, that'd be a way to bootstrap distribution/verification of OTR identities as well...

[1] https://news.ycombinator.com/item?id=9546145

We plan to build chat into Lavaboom, but we haven't figured out yet what's the best way to do it (and it's a _way_ long ahead, anyway). What you're saying makes a lot of sense and is definitely a possibility.

What is your reaction to security professionals (such as tptacek) objecting to browser encryption? Do you take any specific measures to address the concerns that they have such as browser plugins being able to see decrypted keys, and man-in-the-middle attacks injecting javascript?

We're a small team with limited resources, JS is the easiest medium to get started and ship MVP. Until we have native apps for most popular platforms, you have two options:

(1) run the web client on your own machine, and use Lavaboom this way - if you trust your own computer, of course

(2) install a Chrome/Firefox extension to have some proof that the code is the same as the one at github.com/lavab/web - this is still WIP on our end

Signed native binaries are the best solution IMHO, we're aiming to get there for most major platforms, as I said.

How does (2) actually work, given that almost any content element loaded onto the page can override what's in the .js file?

> proof that the code is the same as the one at github.com/lavab/web

Theoretically we can prove (via Chrome packaged apps, for example) that the code running on Lavaboom's servers (or locally if you run the web app yourself) is from our public repos. If the code doesn't do magic stuff like dynamically changing itself, and since we use TLS to deliver it, it should be impossible to maliciously alter what's running on the client side, unless we leverage some hypothetical unknown-yet browser-specific vulnerabilities(?).

Also, network activity can be monitored, theoretically the users will be able to detect ~if~ when we start streaming their data to NSA servers. Unless you assume our server is completely compromised and we do the streaming ourselves.

By the way, that's why I designed the system with the premise that we ourselves can't be trusted (e.g. haxorz pwnd us etc.) i.e. asymmetric encryption everywhere. Here's for instance some of my actual data (ignore the pre-refactoring messiness): https://gist.github.com/andreis/70c8f5bb1d811f6ac7db

PS: I'm not saying a web app are ideal for what we do, as I mentioned in another comment we started with it due to sheer pragmatism, and we're planning native apps (or at the very least cordova/electron "native" apps). I would really appreciate your thoughts on the matter.

i tried filing a support ticket about this a couple of days ago and haven't heard back, but i'm unable to get my inbox to decrypt on my second computer. the computer i set the account up on works fine, but it just tells me that it doesn't have a private key when i try to look at my inbox on my laptop. i tried uploading the .json file that i guess is my keypair that downloaded when i set up the account, but it doesn't seem to do anything, just keeps saying no private key. chrome on ubuntu on both devices.

Sorry for no response to the ticket, we found quite a few bugs during integration of our support system and we have a ~200 queued tickets. Please create a new one directly on http://support.lavaboom.com/help_center and I'll take care of your issue.