https://wormhole.app/
简单，私密的文件分享
Wormhole 让你能以端到端加密和自动过期链接的方式分享文件。 所以你可以确保你分享的文件私密且不会一直留在互联网上。
我们为什么要建造虫洞
为什么大多数 Web 服务不端到端加密您的数据？
这实际上没有一个很好的理由。bulabulabula.....
Why We Built Wormhole
Why don't most web services end-to-end encrypt your data?
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 website is designed so that the service provider possesses the key to your data. 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 it, then it's not truly safe.
Let's look at why "end-to-end encryption" solves the problems with ordinary "encryption".
The importance of end-to-end 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.
Ten times better
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.
The fastest way to send files on the internet. Period.
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.
Comparison
Let's compare Wormhole to a few competitors:
WeTransfer
WeTransfer doesn't use end-to-end encryption. So the government, rogue employees, or hackers (in the case of a data breach) can see your data.
WeTransfer shows ads next to your files, with all the creepy tracking and third-party JavaScript security risks that come with that.
WeTransfer sends your data to tracking companies. For example, they connect to googletagmanager.com, facebook.net, bing.com, amazon-adsystem.com, and more.
WeTransfer requires your email address in order to use the service.
WeTransfer makes you wait for your files to fully upload before your recipient can start downloading. This is wasteful when you just want to get a file from two devices on the same network, like from your computer to your phone.
Dropbox
Dropbox doesn't use end-to-end encryption. So the government, rogue employees, or hackers (in the case of a data breach) can see your data.
Dropbox "accesses, stores, and scans" your files and shares them with "affiliates" and "third parties", according to their Terms of Service.
Dropbox requires your full name, email address, and other personal information in order to use the service.
Dropbox makes you wait for your files to fully upload before your recipient can start downloading, or before you can copy a share link.
A better way
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.
Who we are
We're Feross and John.
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.
