I've been working with jhiesey for the past 2 months on Wormhole. Wormhole lets you share files with end-to-end encryption and a link that automatically expires.
Our twin goals were speed and security – you should be able to get a link to send in less than 2 seconds. Everything is end-to-end encrypted and the server never knows anything about your files.
Wormhole supports instant streaming – there's no need to wait for your files to upload before you can send the share link to your recipient. We also use super fast P2P transfer
when possible, which comes in handy when both devices are on the same network. Finally, we host your end-to-end encrypted files for 24 hours so the share link keeps working even after you close the site.
Please give it a try and please tell us what you think.
We went to absurd lengths to make Wormhole fast and performant, without sacrificing security. All of the technical challenges we faced came from trying to accomplish these two goals simultaneously:
- Build the absolute fastest way to send files
- Deliver end-to-end encryption without any compromises
Here's a bit more of the technical details:
We use streaming encryption (specifically, the Encrypted Content-Encoding standard also used by the now defunct Firefox Send) so that we can keep memory utilization flat, no matter how large the file.
Then, we take the end-to-end encrypted file data and simultaneously stream it to browser storage and our servers.
When a downloader shows up before the file is fully uploaded, we use the browser copy of the data to stream your files to the downloader directly. This means that they can start downloading even before the files have been uploaded.
For the direct peer-to-peer transfer, we use the WebTorrent protocol (which I created). All file data is end-to-end encrypted before leaving the device. It's encrypted yet again in transit by TLS or WebRTC, and also while at rest on our servers.
We use a combination of browser storage options, depending on which is fastest and the amount of available disk space. We choose from the following storage strategies:
- In-memory storage (fastest performance, high memory usage (obviously), used as a fallback when disk is full or in private-browsing windows where storage is limited)
The browser has become so powerful – with WebAssembly and powerful new browser APIs – that we think it's time to use some of that power to make web services more private and secure. It's a lot more work to build a service this way than the normal way, but we think it's worth it.
Thanks. Yep, you can watch jhiesey give a talk about Xylem, his "semi-pure, functional reactive language" here: https://www.youtube.com/watch?v=XiEZ9_Cn5xU It comes after the talk from Dominic Tarr about Acid, his new "fun-oriented programming language".
Pretty ridiculous to take the same name as another (more famous) product that does the same thing. Have you talked to a lawyer about changing the name?
Wormhole.app looks great! I use P2P instant file sharing websites like webwormhole.io and file.pizza extensively and so this is a welcome upgrade. I used Pirate Bay's now-defunct uplovd.com and webtorrent-based instant.io for a while too! Wormhole.app is way better. Kudos.
A request, if I may:
Comms apps like WhatsApp / Email / Slack / Telegram are (ab)used for file-transfers because they instantly help send files to the intended recipient.
With wormhole.app, if you could develop a UX similar to a chat-room where I could upload files and authorized participants could instantly download it, that'd be something.
Couple questions:
As with webtorrent.io and most of your other projects, is this going to be open-source or source-available?
Does wormhole use WebRTC or rely on a mix of things like libp2p or webtorrent or something similar?
This is sweet!! It's kind of amazing to me how annoying it is to still send large files in 2021. Default end to end encryption is huge here too. Kudos for such a clean and thoughtfully-designed experience :)
From what I see elsewhere it's a custom implementation, but it feels like it wouldn't take much googling to find existing literature (i.e, magic wormhole).
Considering there's already a few MW clients, this being not compatible is... likely going to be confusing.
There's no relation to magic-wormhole. wormhole.app is an independent design and implementation. It's a similar in spirit to Firefox Send (and uses the same ECE streaming encryption that they did). Our design supports instant streaming (instant share link, downloader can start downloading before upload is finished) and peer-to-peer transfer (based on the WebTorrent protocol, which I created).
The word "wormhole" seems to be used in many different tools. For example, try running `brew info wormhole`. You don't get magic-wormhole or wormhole.app but something else entirely.
This isn't a crowded namespace, relative to many other domains. File transfer isn't setting SV and Wall Street on fire. It may look to some like you are capitalizing on Magic Wormhole's reputation, and whether you intend to or not, you may be doing that - people will confuse them.
It's worth noting that your comment makes slightly more sense when viewed with the original comment it's responding to, which said it's a crowded namespace already. Not sure why the edit happened.
For files up to 5 GB, Wormhole stores your files on our servers for 24 hours.
For files larger than 5 GB, Wormhole uses peer-to-peer transfer to send your files directly from your browser to the recipient. So you'll need to keep the page open until the recipient downloads the files.
A wetransfer-style model is popular for contractors and small businesses who often need to share files with clients and don't want to run their own file hosting service.
I think a few small businesses I worked with in the past paid something like $10/mo for 250gb of file sharing w/ links that worked indefinitely + custom branding on the upload/download pages they created.
Nice job, this works pretty well! I will say, however, that the background animation (even on the landing page, before sending) spinning up my laptop fans is a bit unwelcome. (Only tried FF.)
We’re going to spend some time optimizing the animation to resolve this problem. We’ll also likely add an option to disable the animation entirely for those who think it’s a bit too much :)
We're planning to introduce a Pro plan for larger file limits and explore an enterprise version for organizations that have high security requirements (law firms, etc.) that can't use existing cloud storage providers.
How do we know if the file is really encrypted?
How do we really know that the key is not uploaded to the server?
Unless there is ability to view the source code for the client, I don't think it can be trusted.
Auditing a web app is a challenging prospect with current web technologies. We really need a better way to "pin" a site to a current version and only update it with user consent. On wormhole.app, all assets are first-party and directly served by our servers, so there's no risk of third-party JS compromise – there's literally no third-party loaded JavaScript.
But we want to do more to re-assure users with concerns about the cryptography itself. We're going to open source the cryptography code and explore building other types of client frontends, including potentially a CLI client, so you can be more sure that the code hasn't changed out from under you when using Wormhole.
Very cool. Genuine question: is using the URL as the encryption key considered secured enough for most usecases?
I imagine most people share these links via email, and if you or your recipient use a non-secure email provider, we should expect it to be parsed.
This really is wonderful, pleasant and incredibly easy to use. A lot of thought must have gone into making the process as streamlined and secure as possible - well done!
The background animation was a fun touch, but gave me a little bit of motion sickness - I don't know whether it can be made a little smoother.
Do you intend to increase the retention length to beyond 24 hours (this could be a monetisation opportunity, I suppose - the uploader could make a small payment to keep files available for longer)?
Also, my very first question was "How long will my link work?" and I could only find the answer after starting a transfer - it would be good if this info was available up front.
We plan to support the CSS prefers-reduced-motion media query, so you won't see the animation if you get motion sickness easily. And we'll probably add a manual toggle as well.
As for retention length, we plan to add an option for extending it past 24 hours. And thanks for the tip about making it clearer that files are only stored for 24 hours upfront.
We believe that this type of functionality can be provided by generating the data on the client-side. For example, image previews can be generated lazily when the client is plugged into power and idle, or on-demand when it's needed for the first time.
50 comments
[ 3.2 ms ] story [ 122 ms ] threadI've been working with jhiesey for the past 2 months on Wormhole. Wormhole lets you share files with end-to-end encryption and a link that automatically expires.
Our twin goals were speed and security – you should be able to get a link to send in less than 2 seconds. Everything is end-to-end encrypted and the server never knows anything about your files.
Wormhole supports instant streaming – there's no need to wait for your files to upload before you can send the share link to your recipient. We also use super fast P2P transfer when possible, which comes in handy when both devices are on the same network. Finally, we host your end-to-end encrypted files for 24 hours so the share link keeps working even after you close the site.
Please give it a try and please tell us what you think.
Read our manifesto: https://wormhole.app/about
Read about our security design: https://wormhole.app/security
- Build the absolute fastest way to send files
- Deliver end-to-end encryption without any compromises
Here's a bit more of the technical details:
We use streaming encryption (specifically, the Encrypted Content-Encoding standard also used by the now defunct Firefox Send) so that we can keep memory utilization flat, no matter how large the file.
Then, we take the end-to-end encrypted file data and simultaneously stream it to browser storage and our servers.
When a downloader shows up before the file is fully uploaded, we use the browser copy of the data to stream your files to the downloader directly. This means that they can start downloading even before the files have been uploaded.
For the direct peer-to-peer transfer, we use the WebTorrent protocol (which I created). All file data is end-to-end encrypted before leaving the device. It's encrypted yet again in transit by TLS or WebRTC, and also while at rest on our servers.
We use a combination of browser storage options, depending on which is fastest and the amount of available disk space. We choose from the following storage strategies:
- Storage Foundation API (fastest performance, experimental API, Chrome only for now, https://github.com/fivedots/storage-foundation-api-explainer)
- Filesystem Access API (extremely fast, Chrome only, other browser vendors have expressed interest, https://wicg.github.io/file-system-access/)
- Cache API (pretty fast, wide browser support, comes from the Service Worker spec, https://w3c.github.io/ServiceWorker/#cache)
- Indexed DB (slowest option, wide browser support, https://www.w3.org/TR/IndexedDB/)
- In-memory storage (fastest performance, high memory usage (obviously), used as a fallback when disk is full or in private-browsing windows where storage is limited)
The browser has become so powerful – with WebAssembly and powerful new browser APIs – that we think it's time to use some of that power to make web services more private and secure. It's a lot more work to build a service this way than the normal way, but we think it's worth it.
do you have a pointer for Xylem?
A request, if I may:
Comms apps like WhatsApp / Email / Slack / Telegram are (ab)used for file-transfers because they instantly help send files to the intended recipient.
With wormhole.app, if you could develop a UX similar to a chat-room where I could upload files and authorized participants could instantly download it, that'd be something.
Couple questions:
As with webtorrent.io and most of your other projects, is this going to be open-source or source-available?
Does wormhole use WebRTC or rely on a mix of things like libp2p or webtorrent or something similar?
Source: https://xkcd.com/949/
Thanks for the kind feedback!
https://github.com/magic-wormhole/magic-wormhole
Here's an HN discussion of it:
https://news.ycombinator.com/item?id=14649727
An LWN article:
https://lwn.net/Articles/692061/
From what I see elsewhere it's a custom implementation, but it feels like it wouldn't take much googling to find existing literature (i.e, magic wormhole).
Considering there's already a few MW clients, this being not compatible is... likely going to be confusing.
The word "wormhole" seems to be used in many different tools. For example, try running `brew info wormhole`. You don't get magic-wormhole or wormhole.app but something else entirely.
For files larger than 5 GB, Wormhole uses peer-to-peer transfer to send your files directly from your browser to the recipient. So you'll need to keep the page open until the recipient downloads the files.
If there was a way to pay for semi-permanent links (a month?) I would probably cough up!
Would you want to pay for a single link? For example, pay $2 to make a particular link last for 30 days?
Or, would you want to pay as a subscription? For example, pay $10 per month for 2TB of storage to use however you want?
I think a few small businesses I worked with in the past paid something like $10/mo for 250gb of file sharing w/ links that worked indefinitely + custom branding on the upload/download pages they created.
Multiple price points & options for those with a need.
Free, limited access for occasional & low-end users.
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
It is p2p file transfer without a central server required. All done on top of TOR network.
TOR routing is overall a great tech to play around with
But we want to do more to re-assure users with concerns about the cryptography itself. We're going to open source the cryptography code and explore building other types of client frontends, including potentially a CLI client, so you can be more sure that the code hasn't changed out from under you when using Wormhole.
The background animation was a fun touch, but gave me a little bit of motion sickness - I don't know whether it can be made a little smoother.
Do you intend to increase the retention length to beyond 24 hours (this could be a monetisation opportunity, I suppose - the uploader could make a small payment to keep files available for longer)?
Also, my very first question was "How long will my link work?" and I could only find the answer after starting a transfer - it would be good if this info was available up front.
We plan to support the CSS prefers-reduced-motion media query, so you won't see the animation if you get motion sickness easily. And we'll probably add a manual toggle as well.
As for retention length, we plan to add an option for extending it past 24 hours. And thanks for the tip about making it clearer that files are only stored for 24 hours upfront.
Dropbox need the encryption keys to offer "rich" features like searching, previwing files, etc.