There's not really a good reason for this.
For example, take a service like Dropbox. They transfer your data over an encrypted connection to prevent eavesdroppers from snooping on the data as it traverses the internet. Then, once your data arrives at Dropbox's datacenters, they promise to store it in an encrypted form.
But what Dropbox fails to mention is that they have the key to unlock your files.
You can think of encryption like a lock. It's not enough that your data is locked up – it's important to know who has a key to unlock your data.
Every major web service is designed in a way that gives the key to your data to the service. They can unlock your data whenever they want. They could give your data to the government. Or a rogue employee could poke around and you'd never know.
At a fundamental level, you're entrusting Dropbox to take care of your data – something they haven't always done well. For example, they once allowed anyone to log into any Dropbox account using any password. Encryption doesn't mean much if they'll unlock your data and give it to anyone on the internet.
The lesson is: If your data is "encrypted" but someone else has the key to unlock your data, then it's not truly safe.
Let's look at why "end-to-end encryption" solves the problems with ordinary "encryption".
With end-to-end encryption, data is encrypted and decrypted only at the "end points". That means that service providers in the middle don't have access to the keys, and therefore can't read your data.
Put simply, end-to-end encryption prevents your data from falling into the wrong hands.
We built Wormhole with end-to-end encryption. When you use Wormhole, a key is generated on your device and used to encrypt your files. In transit, your data is unreadable to Wormhole and service providers like your ISP. The key never leaves your device and you're the only one who has it – unless you decide to share it. With Wormhole, you're in control of who has access to your files.
When you share a Wormhole link, the key is automatically included in the link so it's easy to share with the exact people you want, and no one else. Wormhole never sees the key. And we don't want to see it.
Every design decision in Wormhole begins with the safety and privacy of your data in mind. We can't read your files, and no one else can either. Privacy isn’t an optional mode — it’s just the way that Wormhole works.
When building a new product, there's a rule of thumb that it must be at least ten times better than the existing products or people can't be bothered to switch. For most people, an app with better security or privacy alone isn't ten times better than an insecure or un-private alternative. Most people just don't care about the details of the apps they use.
This may be starting to change, but to make an app that is truly "better" for most people, you need more than just better privacy and security.
We think Wormhole is ten times better.
Our #1 goal is speed – you should be able to get a share link in less than 2 seconds with the absolute minimum number of clicks.
That's why Wormhole supports instant file streaming. There's no need to wait for your files to finish uploading before you can copy the link and send it to your recipient. The recipient can start downloading even before the files have finished uploading.
We use super fast peer-to-peer transfer to send files directly to the recipient when possible. This improves speed and security – especially when transferring files over a local network, like when you just want to get a file from your phone onto your computer.
In addition, we store your encrypted files on our servers for 24 hours so the share link will keep working for your recipient even after you close the Wormhole site.
Let's compare Wormhole to a few competitors:
amazon-adsystem.com, and more.
We started a company – Socket Inc – to bring end-to-end encryption to consumer and enterprise apps. We plan to explore the limits of what web browsers can do – especially in terms of shifting computation to the client-side, to improve the security and privacy of web apps. Wormhole is our first foray into that.
We hope you join us on this journey.
Feross is the author and maintainer of WebTorrent, StandardJS, and 100s of other open source projects. His software is downloaded 500+ million times per month. He was a lecturer at Stanford where he created the course CS 253 Web Security.
John is the author and maintainer of stream-http and dozens of other open source projects. John is writing his own programming language – a semi-pure, functional reactive language called Xylem. Previously, he worked at Protocol Labs doing research on Distributed Hash Tables.