For (my) magic-wormhole, yep, entirely, source is on the github link above.
It uses a pair of helper servers (that I run), for which the source is also on github. But the protocol (implemented in the client, not the server) is carefully designed to be resistant against server misbehavior.
So you can either study the client and convince yourself the protocol is indeed secure, or rely upon my claims that my code is working as advertised. But you don't need to rely upon my claims that my servers are not snooping or interfering: that's protected by the protocol.
BTW for anyone reading, https://wormhole.app/ is awesome and serves a very similar purpose, but uses entirely different technology (no PAKE) and has a different security model.
In my (https://magic-wormhole.io) world, we've kicked around ways to make a good browser-based client (and I've tried to prepare the protocols to work well there), but I haven't had time to pursue any of them. The tasks include 1: port everything to JS (or take the core of the Rust port and compile it to WASM, then write an IO layer in JS), 2: glue it to the browser's file/blob upload/download APIs, 3: settle on a trusted-application security model.
To make it work in a vanilla browser with no setup phase, you're pretty much limited to relying upon the webserver from which you get the page, which is the model wormhole.app provides. Other options include using an addon (which shifts the reliance set slightly), or running some sort of Electron thing (making it not really a browser app) that you get from some distribution channel (debian, homebrew, etc) which shifts the reliance set in a better direction.. at least you're probably getting the same application as everybody else using that distribution, vs a webserver that could conceivably serve up a different version each time.
For what it's worth, and I know you're not looking for this fight, but I think it's important:
There is a world of difference between what Magic Wormhole can promise and what Wormhole.app can promise. Magic Wormhole relies entirely on clientside cryptography; once you have it installed, you can trust that it's doing what it says on the tin. Which means you can reasonably use it operationally.
"Wormhole.app" --- which has a frustrating name, given the distinction --- demands that you trust the server, since the server can on every transaction defeat the cryptography you're using.
If someone owns up a Magic Wormhole relay server, there's not much they can plausibly do to intercept the files you send. But if someone owns up Wormhole.app, they can, I believe, quietly pick up and store people's files.
Incidentally, apropos none of this: I've been using the Golang https://github.com/psanford/wormhole-william port on some of my machines for a year now, interoperating with the standard Python Magic Wormhole, and it works great.
Magic Wormhole is an achievement. I wrote a blog post about modern cryptographic tools, and what I have to say about Magic Wormhole is that everyone I've introduced to it immediately starts wormholing all sorts of stuff; it's kind of addictive. Thanks for designing it!
I _really_ want to see the Rust version get more mature and see this made into a browser plugin. I keep mulling over trying to help out with the project, at least on the Rust side (since I know nothing about WASM).
There are some folks who have a fork of Wormhole William that runs in the browser (via wasm) and uses a websocket based relay (keeping the rest of the Magic Wormhole protocol the same): https://github.com/psanford/wormhole-william/pull/49
If you're looking at trusted-application security models, you've probably considered TOFU and what I call BEEF (Beware Each and Every Fetch).
The standard criticism of web-based apps is that you have no guarantee that the code you receive will be the same as that which you received on your previous visit. (This ignores problems with self-updating desktop apps, but let's pretend users make informed decisions about every new version published).
Fortunately there is, at least in principal, a way of achieving TOFU for web apps. It relies on the bookmarklet/SRI trick[0], which lets the user store the hash of a script which bootloads the rest of the application. The major downside with this is that the browser's address bar shows a Data URI rather than the domain of your app. That limitation wouldn't exist, though, if browsers supported Hashlinks[1].
to avoid confusion Ferros should have chosen a different and better name, considering that magic-warmhole is an older project doing more or less the same thing (with different and better technology and it's real free software)
That seems like a wonderful service, but if it allows up to 100 downloads over 24 hours, I kind of worry that it's gonna get massively abused for nefarious purposes. It's not quite "publicly writable S3 bucket" abusable, but it's close.
I'm a little confused about the security model - with a default middle server and a 1/65536 chance of guessing the password, isn't it fairly likely it could be guessed? Or just a clash of passwords (birthday paradox)?
> PAKE effectively trades off interaction against offline attacks. The only way for a network attacker to learn the shared key is to perform a man-in-the-middle attack during the initial connection attempt, and to correctly guess the code being used by both sides. Their chance of doing this is inversely proportional to the entropy of the wormhole code. The default is to use a 16-bit code (use –code-length= to change this), so for each use of the tool, an attacker gets a 1-in-65536 chance of success. As such, users can expect to see many error messages before the attacker has a reasonable chance of success.
(It does strike me, however, that if a 'mailbox server' becomes heavily used, with many pending-but-incompleted wormholes, then an attacker making random guesses might manage to receive someone's random file, instead of the real intended-recipient. Perhaps the sending-side should optionally require an interactive sender-ack, after showing for confirmation a receiver-generated unique secret? In any case: using a longer code, and/or using a private mailbox, could each help eradicate such risks.)
Ok, I'm definitely not understanding this then. This is my understanding so far:
You are sending the file runs
wormhole send myfile
I, the attacker run
wormhole receive __guess_code__
If my code is right, I get the file. If not, you cannot know, surely? There's no identification here other than the code. I can guess repeatedly as many times as I want. If lots of people are using the same server, the chance I start getting someones files is quite high.
~~In addition, with generating the code, either the sender has a way of checking if codes are in use (and so the attacker can more easily find current open valid codes) or there is the chance of a clash.~~ Edit - looking at the code I don't think this side is an issue. It'll ask for a connection then generate a code for that connection I think.
Good question! The code is broken up into two parts: a number, and some words. The number is like a mailbox: you put messages into it, the person you're intending to talk to puts messages into it, (maybe an attacker puts messages into it), everybody can read the messages there.
The words are secret. There's a special cryptographic protocol named PAKE ("Password Authenticated Key Exchange") that tells you what messages to put into the mailbox. The protocol has a lock-step part in the middle, where you don't generate your second message until you've seen the other person's first message (and vice versa).
When the protocol is done, if the two people used the same secret words, they'll wind up with the same secret encryption key, and nobody else will know the key. If they used different words, they'll wind up with random strings. The file transfer uses the shared key to encrypt the bulk data.
Your client will generate a random wormhole code (random words plus server-allocated mailbox number) and run the protocol exactly once. It will generate and send its first message, wait for the partner's first message, then generate and send the second message, wait for the partner's second message, compute the shared key, do a test to see if it matches the other side (send a hash of the key), negotiate a direct connection if possible, then encrypt and transmit the file data.
If an attacker is trying to guess your code, their only option is to pretend to be your intended recipient and follow the same protocol. They watch the server and learn the mailbox number: that part isn't secret. But then, to send their first message, they have to commit to some particular secret words. And they don't get to find out if they were right or not until they see your second message, by which point your client knows that this "one shot" has been used up, and it's either correct (the key-verification hash matches) or it's not (or the attacker disconnects and runs away, in the hopes of getting you to blame a flaky network instead of suspecting an attacker).
If it fails, the client tells you that fact and quits, and you have to re-run the program (getting a brand new random wormhole code) to try again. Which means the attacker is back to square one: they know their first guess was wrong, but now the code is different, so their second guess has exactly the same chances of being right as the first guess.
In addition to what everyone else here points out, you can also set an arbitrarily long code, to make that probability as low as you want; you're looking for the `-c` option.
Most people stick to default options, and this one looks worryingly short.
I personally love the idea of using Diceware words (specifically, the EFF shortlist version). Fairly high security can be achieved with 3 only or 4 words (at 10 bits of entropy per word, you get a billion possibilities with just 3 words).
Maybe Magic Wormhole already has that option, I haven't checked. In any case, I would like whatever is the default to be raised to at least 20 bits of entropy.
You can also use python and any kind of http download tool (browser, curl). Works well within a local network, or if you have control over your firewall.
I'm a huge fan of croc[0]. Very similar to Magic Wormhole, but a bit more flexible and written in go.
Straight from the README:
> croc is a tool that allows any two computers to simply and securely transfer files and folders. AFAIK, croc is the only CLI file-transfer tool that does all of the following:
- allows any two computers to transfer data (using a relay)
That sounds super useful, but I don't see it mentioned in the documentation anywhere. I found it in the source code, though. Looks like it allows a remote user to add credentials to an authorized_keys file?
croc maintainer here: like mentioned from the throwaway account above - yes, this is true that there was a recent major vulnerability. [1] It was fixed within a week [2], so I guess it is also true that croc has a history of fixing vulnerabilities, rather quickly. I should hope this means that security is taken seriously.
Anyways, croc is pretty similar to wormhole except that it allows resuming files (which wormhole does not yet [3]) and has some peer discovery for local network transfers. I've been using croc everyday for over three years and I'm still very happy with it. But, you should totally use magic-wormhole if that floats your boat - its a great tool, along with psanford's Go version. That may help me actually as I think croc has too many users on the public relay and the cost of bandwidth is becoming too high to keep the public relay available after this year.
The free hosting from DigitalOcean is for one year and ends on 12/31 this year. After that the public relay will cost me over $70/month (or maybe more, as that's the current cost covered but it continues to grow). I cannot afford that so around that time I'll try to get donations.
Magic Wormhole has a good implementation in Go, which is compatible with the original Python implementation (croc is not compatible with magic wormhole). It has windows binary and binaries for most of the popular OS.
In a sense it is good when people actually check opensource software for security vulnerabilities, and these get fixed, no? There would only be reason of concern if a project shows overall continued sloppiness, but I'm not aware of that for croc. Correct me if I'm wrong.
See also the (compatible, same middle server by default) golang port, https://github.com/psanford/wormhole-william, complete with static binaries for mac/win/linux. I've found this helpful when I've needed to send files to somebody who would have problems getting a whole pythonpile of dependencies installed.
As always, the most difficult problem is not sending files between computers, but between smartphones, tablets and computers.
I'm still looking for a solution I could use to share pictures and PDF files from Android phones to iPads and Laptops using the "share" modal and completely self-hosted...
Being completely plaintext makes it unacceptable for many use cases in the modern world. It's also a touch more complicated than it needs to be for the standard use case. Binary vs. ASCII transfer mode (and ASCII is the default most of the time even though it only very rarely makes sense). Plus the whole passive vs. active mode thing. Too many footguns and no security rule it out.
If you're running FTP as plaintext you're indeed doing it wrong, I'm not sure that that must be what GP meant. Not as if we explicitly mention (START)TLS for every other protocol that supports it.
You can't have secure FTP without a certificate and you can't have a certificate without DNS/domain names unless you want to manually add certificates around which is bad UX again.
The ideal situation would be some universal airdrop which will never happen. The next easiest solution is to use cloud storage and send a link to the other person.
Yeah, that's fair. I think FileZilla shows who signed the cert, but yeah it still gives that pop-up asking the user to decide and I haven't checked whether they verify that signer against the system CA list. Either way, that's as canon as FTP clients get and since they don't have it, indeed it's mostly opportunistic encryption. (Not that relying on the CA system rather than TOFU'ing or sharing a fingerprint is without problems of its own, but that's a discussion for another thread.)
Then you could just implement your own client. There are already dozens of not hundreds of FTP clients for any device you could imagine, if you don't like the ux take an open source one and clean it up a bit.
I guess you can install in on multiple devices (Android phones and tablets), then use a file explorer that supports ftp or use a dedicated ftp client, to then transfer between each other. But accessing my phone from my computers via ftp (Fedora and Windows 10) is a piece of cake and reliable - don't even need anything like filezilla.
To stop changing ip's:
I recommend having a static ip range in your router instead of using dhcp (or some routers/dhcp server can allocate the same ip address to the same mac address), so all of your devices ip's stay stable (on newer phones, you have to disable the random mac address feature though).
I recently spent 15 minutes trying to figure out how to get Android to connect via smb, couldn't figure it out. It's such a stupid PITA it's almost by design and "yeah just use the cloud".
Android, just like iOS, was designed with the idea of turning the user into a customer for products and services, therefore many things that we take for granted on desktop PCs, often even free, under those mobile OSes are either non existing or proprietary, filled with adware etc. By becoming mainstream they pretty much destroyed decades of efforts in bringing free and open source and standards to the masses.
Agreed. Especially on iOS, there isn’t really a convenient way to do this. I’d love something that uses an ssh key pair to accept files from the “share” dialog and have them end up in ~/Desktop. I tried hacking something with Shortcuts, but couldn’t get it working.
I've been using KDE connect recently and it's great for moving files between my phone and laptop. Another fun feature is sharing a url from the phone to the laptop and it opens the browser to the page.
I don't know of any similar software but being able to do the same thing between iOS and android would be great.
I second this. File transfers between my phone and computer are seamless and quick. I can even use it to find my phone when I use it. It is rare to find open source software that Just Works, and KDE Connect is one of these rare gems that does so.
I second KDE Connect. Despite the name, it's not limited to KDE by any means - there's implementations for Windows, MacOS, and even GNOME Shell. It's very straightforward to set up and has a bunch of other features besides file transfer, like using your phone as a touchpad, sending SMS messages from the desktop, or pinging either device.
I use Snapdrop (https://snapdrop.net/) to transfer files between my iPhone and my Linux laptop. It offers a self-hosting option, and there are apps for Android and iOS available (though I've only used the Web interface).
I used snapdrop as well, but it's not working with the share modal on phones. This means it's not what I am looking for!
The primary use case is for me to share PDF scans made with my iPad/phone with my laptop. The second use case is for sharing screenshots of my laptop with others on my favorite messenger.
There's no security, so everyone who has the URL can download your last file (well, not if you downloaded it, because then it will be automatically deleted on server). Why? Because sometimes you just want a quick solution for non-sensitive/personal data, rather than a super secure solution that would take 2 minutes (go to Gmail on phone, enter login, enter password, upload file, go to Gmail on computer, enter login, enter password, download the file...)*
NextCloud is great if you need Dropbox-like functionality. For straight-up syncing of a single directory, or multiple single directories, SyncThing is fantastic.
I've used Total Commander's Send to Wifi [1] before and found it workable for that use case (where both are on the same WiFi network; presumably you could use a hotspot for a place without WiFi at all).
There is no technical reason sending files should be difficult, the problem is entirely political. A file transfer service that works too well immediately becomes a hotbed of porn, warez, rips, etc... Then it gets sued and/or shut down by the authorities. So all file services have to suck in specific ways to discourage abuse. The trick is to find the one that sucks in ways that aren't as much of an issue for your use case.
There's a fairly significant difference between 1:N file transfer (1 person "sends", N "recieve") and 1:1 file transfer. What you say seems like a good summary of the issues for 1:N, but not particularly relevant for 1:1
Being only a 1:1 transfer is itself a problem when you need to send the file to more than one person. There are plenty of cases where you need to send a file to a small group like 4 or 5 people. Worse, this sometimes means you have restrictions like downloading the file one causes it to self destruct, which means if said person clicks the link on his phone then realizes his error and clicks the link on his computer the link will already be dead and you have to re-upload the file.
The problem with email attachments is that they're stored on the recipients inbox forever unless the message is specifically deleted. If the attachment limit is very large, you could fill up someone's inbox with a couple of messages.
No host in their right mind would accept such large messages.
Emails are sent over different servers, sometimes several, before being delivered. Each of them has to push the attachment forward. Making attachment sizes too permissive opens the door for a pretty neat DDoS vector.
Most EMail servers do not accept more than 10MB, and considering the file sizes of your typical PDF, Word Document or photo, that seems sensible.
I have a Magic Wormhole client for Android that I wrote for the occasional sensitive file transfer to and from my phone[0]. I was planning on adding iOS support as well, but Apple's general hostility toward open source apps discouraged me enough to not want to work on that.
Can't you just go to it in a browser? I only have Android at the moment but the whole idea behind Send was that I could easily share files from all devices since it's a web app.
I made https://dro.pm for this. You get a link like dro.pm/h which is short enough to even share over the phone or tell someone at a conference to open. Not like chat apps where you have to be connected to the other person first (even if that is yourself, need to navigate to that chat) and no need to install any software. It's made to be fast on any connection (e.g. by allocating the link before you even entered any data), and due to being ephemeral it's also less prone to being used for phishing like other link shorteners are.
It auto-detects when you enter a link, otherwise treats text inputs as a pastebin, you can ctrl+v an image, and it has file uploads up to a few gigabytes. Code is on github (https://github.com/lgommans/dro.pm/) though I still have to change the license to be more permissive (I've decided that I won't pursue this as a commercial thing, just open a ticket if you want me to change the license sooner than whenever I work on this next). Viewing uploaded files instead of downloading is also possible for image/audio/video mime-types by adding /preview to any link.
You can also use it from the command line if you're on a keyboard+terminal-only machine, e.g. just `wget -L dro.pm/h.txt` to download the uploaded file (the links accept an arbitrary .extension) or for uploading from the command line there is a bash one-liner contained in the page source itself, see: `curl https://dro.pm | head`
Made a mistake and uploaded something private or want to edit the link? Just click delete on the website, or on the command line you can use the token that you get when creating a new link.
Should I package it as a .deb, or what makes something self-hosted? The code is already on github: https://github.com/lgommans/dro.pm/ (link was buried in the text - I had a hard time prioritizing what people would want to read first, since that depends on your use-case).
I guess magic wormhole is the wrong context to be making this argument in since everyone's primed for peer to peer now, but in general, yeah when using dro.pm it will put your data on dro.pm, similar to how pastebin stores your data when you use pastebin. It otherwise (and that's why I made this design decision) couldn't work after you close the tab, making it much less suitable for most of the intended use-cases. If you want peer to peer file transfer, you could have a look at https://file.pizza (not made by me)
You license is non-standard and does not appear to permit self hosting.
This appears to me much more like blantant self promotion rather than attempt to participate in the discussion. Your tool has none of the requested features (self hosted file transfer using the native share dialog.)
> though I still have to change the license to be more permissive (I've decided that I won't pursue this as a commercial thing, just open a ticket if you want me to change the license sooner than whenever I work on this next).
Guess that'll have to be now then. Getting this sort of crap is what makes me wonder why I bother putting this work out there in the first place.
> Your tool has none of the requested features
The main premise was a way to have file sharing between tablets, phones, and computers. This does that. It is open source (as of now) and has an Android share app to boot[1]. Anything else you're very welcome to make yourself, it's not a commercial plug, I'm obviously disclosing my affiliation, I host this on my personal machine at home, you're just welcome to make use of this or not if you don't like it.
If it has a closed license, you haven't really "put it out there" yet have you? If you are already feeling drained by it, you probably don't actually want to run an open source project...
This discussion isn't constructive. To reflect on how I interpret what you write: first the complaint is that one can't self-host it when the post already contained a github link, then that it doesn't have a share app when in fact it does (at the same link that I now posted a second time), and now that I shouldn't be running an open source project altogether. Perhaps judge whether I am suited for running this by how I treat your contributions when you make them. Otherwise, there's always that fork button!
I'm glad you moved to a more permisive license, it now could be self hosted with a bit of work.
Neither your initial comment, nor the project readme discuss the Android App. You have to browse the project dirextory to find out that it exists. The Android app has the dro.pm url hardcorded as a string and generally does not appear setup to work with a self-hosted solution.
All of this is fixable, but it very much belies a project that is immature. I would personally be uncomfortable promoting this as a solution without being very clear about the limitations and work required to fit the specidies use case.
I definitely never intended to say that you shouldn't ever run an open source project. My earlier wording was not done well. My point is that if you are burning out this early in open sourcing this project, then maybe this particular project is not meaningful or valuable enough to be worth it to you.
> You license is non-standard and does not appear to permit self hosting.
You were just given carte blanche to host it, by the author in public. If that isn't a legal exception, I really, really do not know what is.
Also, if you do self-host it, who is going to find out and sue you? Software licenses are not magical. The hammer of god is only going to come down on you if the person:
a) sees you do it
b) has the power to stop you
And if they're outside of the GNU project or the Linux foundation, they very likely do not! And regardless, that only matters if:
c) you have the money to pay for the damages
Which unless you're rich (I dunno, maybe you are rich), you probably don't!
that's quite irrelevant. not everyone has the time and energy to deal with legal uncertainty or a lawsuit. even if they can't take any money from you, the stress could have a major effect on your life. so no thanks.
and if you run a business, it's automatically a no-go.
however, what really matters for FOSS is that suggesting the license does not matter only reduces the strength of FOSS licenses. you are effectually suggesting that licenses can be ignored.
note that i am not suggesting that the author of the product should change their license, or clarify it with regards to self-hosting, just that your advice to ignore the actual license is dangerous.
In this specific instance, the author gave a written exemption to literally everyone, in public -- specifically to allow them to self-host and modify it. So the license does not apply with this exemption in place, and that would be arguable in a court of law.
Now with my point in general,
> however, what really matters for FOSS is that suggesting the license does not matter only reduces the strength of FOSS licenses. you are effectually suggesting that licenses can be ignored.
Right, but if they are ignored by large companies, there's no chance in hell that we're ever going to find out about it. The fact of the matter is that big companies really do not have to give a shit, at this point, because even if someone challenges them, it's unlikely that any one person is going to have the financing to win the war of attrition that will follow.
Likewise, if you take someone's code and it's not open source, and you don't actually distribute it, but instead just host it, and you're small enough, then the license itself does not matter.
The claim that pointing out that the rules only matter as far as the rules can be enforced, actually damages the rules, is utterly absurd. The people who will want to ignore the rules and do whatever, and bank on not getting caught are already doing that.
In this specific instance, the author gave a written exemption to literally everyone, in public -- specifically to allow them to self-host and modify it
that may be the case, but that makes it a custum exemption that is not vetted by lawyers. for my personal use that my be ok, but for my company it is not, no matter how small my company is, i just can't take the risk. not only the risk getting sued, which indeed may be minimal, if non-existant, but also the risk that any of my current or worse future business partners, investors or clients have less trust in an unvetted license than me.
and from a client perspective, i do not want to deal with a business that doesn't take licensing seriously.
the difference between a big company ignoring licenses and me is, that a big business can afford to deal with getting caught, but if i am wrong, i am ruined.
It starts to become a little repetitive, so I'll cite from what I replied to the sibling comment:
> Should I package it as a .deb, or what makes something self-hosted? The code is already on github: https://github.com/lgommans/dro.pm/ (link was buried in the text - I had a hard time prioritizing what people would want to read first, since that depends on your use-case).
As for no mobile app: how much faster is it going to get than opening the browser that's already on everyone's homescreen and typing a 7-8 character link? Or if you self-host it, you can host it on your own TLD like https://me/. It being an app was also never mentioned as a requirement and I don't see how it helps, but I guess I don't need to understand. As a bonus tip, though: you can add browser bookmarks to your homescreen. Since you'll need internet to share things in the first place, it should behave roughly the same (aside from a share menu, but...).
And there is a share modal for Android, actually. See the github link.
Most of this post is telling a user that what they want is wrong. Perhaps you are correct, but this absolutely doesn't work. It both most likely deters the user you respond to and most people reading your reply from using it.
maybe Syncthing (for Android, ideally syncthing-fork via F-Droid) will work for you. Share modal, cross platform, works with or without a centralised server.
I use Resilio Sync for this purpose. It uses a peer-to-peer model (you install the app on all of your devices and they sync between themselves. there's no central server.), it's free, and it works well enough. If you want it available 24/7 without relying on peers being online then you can install the application on a cheap Kimsufi VPS.
It's not free, and it's more a Dropbox clone. When I share using the modal, it doesn't send the file directly I have to open the app to allow them to sync.
I'm a happy user of Solid Explorer which has a plugin to host a local folder over FTP. It seems like there should be a more "modern" option but FTP has the advantage that pretty much everything still supports it. (It also connects to GDrive, SMB, and SSH, which covers 99% of my file sharing needs).
I still haven't found a better way than sending yourself a message. It can be email or it can be IM; all platforms have working email/XMPP/Matrix clients where this can work. Email is probably a bit harder to self-host but still doable; the other two are easy in comparison. For Matrix the standard client is Element, for XMPP that would probably be Conversations. For emails I highly recommend using deltachat (https://delta.chat/en/), which gives a more IM-like interface along with automagic e2e encryption. All of those are applications, so they have the share modal.
I could send myself an email, but it's not even a good option for shared devices like ipad. I don't want to expose the full content of my email account, nor private messages on that device, therefore, sending emails is not the best solution.
I completely agree. I would say that in that case the best is to have a specific shared account, which only contains stuff you want to exchange between your devices, but that means juggling with multiple accounts from the sender's device.
Tailscale does everything peer to peer so it might fit what you wanted. They recently added a feature to share files between any computers in your network
I’m content to use commercial solutions for this. Personally, I do all my transfers between different systems and devices using dropbox. I’ll probably get downvoted by even mentioning something commercial though :)
Honestly, considering the abysmal gap in open source solutions, dropbox and google drive are "kind-of okay". The only issue is, it needs to sync up files between devices before allowing a download. The ux is not excellent, but at least it works.
I'm really looking for a "universal airdrop", but I would settle even for a pale copy of it.
Thanks! Here's a formatted list. (I think we'll probably just make HN's software automatically render links to past threads this way—I can't think of any downsides.)
It could be very interesting to have a list of features tabled along with "plan to implement by X date" or "requires more convincing" or "will never be implemented for Y reason".
I can see such a list being incredibly polarizing, but also something the community could rally behind.
How many of these webrtc peer to peer file sharing sites are we going to have? I swear there are hundreds at this point. None of them offer anything different than each other. Sure, it's a great project for a frontend dev to throw together on a weekend. But that's about it
Magic wormhole isn’t strictly peer to peer nor uses WebRTC as the traffic is routed through a relay server. This was my motivation to build one of these hundreds file sharing tools [0]. My aim was to build a truly decentralised file sharing CLI as basically a drop-in replacement for croc/magic-wormhole - so it seems relevant to mention it here. It’s based on libp2p and comes with its own trade offs.
lotharrr (the author of magic-wormhole) gave kind and valuable feedback when I posted it on HN [1].
Is this suitable for transferring files I own off a work computer without getting in trouble? My notes files have gotten too numerous for the amount my work will let me email as one zip file.
What are the use cases for this program and Croc? What does "safely" mean? Is this to share files amongst untrusted computers?
For a small number of files, I currently just email them. If the file is too big, Google Drive or MS OneDrive can be used to send a link. This works across any OS and form factor.
For bulk downloads (e.g. downloading all photos/videos I took on a certain day), I plug my phone into my PC via USB. Navigation and selection using the file browser on the PC is much nicer than selecting files on the phone.
Does Wormhole and Croc enable use cases not covered here?
* You're sitting next to someone at a conference (remember those?) and want to hand them a file: fewer steps than email, the wormhole code is easier to transcribe than most email addresses, the file lands where you want it to rather than in a spam folder somewhere, and neither of your email providers or the network in between them can snoop on or modify the data in transit.
* You're ssh'ed into a remote machine, via two layers of proxy servers, deep in a directory structure with lots of spaces and quotes and backslashes and other shell metacharacters in the path, and you want to transfer a file from there back to your desktop. You have no idea how to quote everything properly. So you wormhole it to yourself.
* I'm on zoom or the phone with a friend and want to send something from my desktop machine to their laptop. I can read the wormhole code off the sending machine, speak it to them over the phone, they can type it into their machine. The codes are optimized for spoken clarity.
* I'm debugging something on the little computer attached to my television and want to copy a logfile off to a real machine. I've got a terminal window open on the screen, and a shell, but that account doesn't have an email address, nor is it listening on SSH. I could write a python one-liner that listens on an HTTP port, but there's no security to that. I can 'wormhole send LOGFILE' and read the code from the screen, and type it into my laptop.
By "safely" I mean: confidentiality against anything outside your two computers (eavesdropper only learns the length of the data, as is true for most networks), and integrity (nobody in the middle can modify the file, or cause you to receive something different than what your partner sent). The security of most common file transfer methods depends upon some intermediate server, or two, or a dozen (in the case of email).
If by "untrusted computers" you're making a distinction between distributing files to computers that you already know about, vs to computers that you've just met, then yes, that's exactly right. If your laptop and your desktop already know about each other, there are a bunch of tools that work better for a lot of cases, like a shared network filesystem or AirDrop. Magic-wormhole is kinda aimed at how to introduce two machines that don't already have a connection. The wormhole code is a way to leverage the connection between the humans who control those computers, into a secure shared encryption key between the computers themselves.
(Hello from an old Mozilla colleague.) Magic wormhole is a lovely gift to the rest of us, for which I thank you. It also illustrates the tremendous latent power that can be unleashed by accepting some constraints. The read-once is a usability limitation judo-ed into a strong security property. It reminds me of a great sonnet: the mechanical constraints of form generate tension, which an artist channels to great effect.
> The wormhole send file mode shares the IP addresses of each client with the other (inside the encrypted message), and both clients first attempt to connect directly. If this fails, they fall back to using the transit relay.
I know nothing about computers. If the clients successfully connect, the file goes from A -> B, but if the connection fails, it goes from A -> relay server -> B? What conditions might cause the connection to fail?
Yep, if both parties are behind NAT, or some sort of firewall that prevents inbound connections from the other, they'll fall back to using the pre-configured public relay server (or any other server you tell them to use).
I need to build some better stats dashboards, but at a glance it looks like maybe a third of the connections wind up using that relay. I'd like to add better hole-punching code (using WebRTC sounds like the right approach), but haven't had the time or found the right library yet.
Maybe $20/mo. The bandwidth is growing but not too bad so far, every once in a while I see a really huge transfer that makes me wince (seriously, who sustains a gigabit/s for five hours?), but I've still got some margin before I run up against the monthly transfer allowance. When that happens, I'll probably move the server to a provider that has a slower but flat-rate bandwidth plan, maybe Scaleway. Transfers would be capped by their network limit (100Mbit?), but effectively free.
I might also change the transit relay to throttle the connection somewhat after some total number of bytes have been transferred (but that takes actual code, and switching providers would be easier). I'm really glad folks are using it, but I do sort of think that >10GB at a time is a bit much. But I don't have a way to notify a given user about any sort of soft limit like that (the transit relay has no idea how much you're going to send ahead of time, and doesn't have a notification channel other than throwing an error).
I've also been meaning to figure out NAT hole punching for years now, and the thought has always been that hole-punching will save a lot of the server bandwidth by making direct connections happen a larger percentage of the time.
Network attached devices are generally not directly addressable from outside their local network. There's a thing called "network address translation" on routers which hides the addresses used internally. The router substitutes it's own address for the internal ones on internet facing connections, acting on their behalf, and just remembers which connections belong to which local device. For new incoming connections, it won't know which device it's receiving the connection request on behalf of. That's unless that device announces to the router it's waiting for the connection using a thing called uPnP, or you manually configure the router to forward to a specific device for specific types of connections. When uPnP or manual forwarding aren't there, intermediaries on the internet allow both A and B to make outgoing connection requests to set up the link, which is no trouble for any router to do.
>...in general, the sending machine generates and displays the code, which must then be typed into the receiving machine.
So you need to have a secure method of communication to transfer the code? Then why not just use whatever that is to transfer stuff?
How is this end to end encryption without any identity management? How do you know who you are exchanging stuff with? How is this different than just regular encryption?
> So you need to have a secure method of communication to transfer the code? Then why not just use whatever that is to transfer stuff?
Because sometimes that secure method of communication is speech. This is a particularly good utility for transferring information to parties that you can talk to verbally. Also, a bit quicker than plugging a USB stick in.
From the section titled "Motivation": "Copying files through Dropbox is not secure against the Dropbox server [and results in ...]"
Let's say a user encrypts a file outside of Dropbox, using a program of the user's choice, then she transfers the encrypted blob to Dropbox.
Is the author suggesting this is "not secure against the Dropbox server". I am not a Dropbox user. I know it was originally for syncing folders and they orginally used an rsync library and that is about all I know. Pardon the ignorance.
Magic Wormhole by default uses hardcoded host:port for a rendezvous server and a transit server operated by [undisclosed].
"The URL of a public server is baked into the library for use as a default, and will be freely available until volume or abuse makes it infeasible to support."
This Github page is only for the client, not the servers.
In the section titled "Dilation", we are reminded that MW is store and forward by default, not direct connection.
How are messages stored on the default public MW server operated by [undisclosed] "secure against [undisclosed]" in a way that messages stored with Dropbox are not "secure against Dropbox". Maybe the author only uses MW with private MW servers, not public ones run by other people. Then his comment about Dropbox would make sense. However I have to wonder, how many new MW users are running their own servers.
Obviously if you encrypt client side, and can securely share a strong key, it does not matter where you store; MW and Dropbox would be equally secure in this respect.
With MW you share a weak key (vs a strong key in Dropbox case). Dropbox also provides access to all data.
On the other hand, you have to hope there is no vulnerability in MW. With Dropbox, you have much more control over crypto.
As aborsy said, if you can encrypt ahead of time, that's great, you're only relying upon the server for availability, (just like magic-wormhole). You would not be vulnerable to the Dropbox server, or the folks who run them, or someone who managed to compromise it, or to confuse it into giving your files to them, or.. say, that bug which caused all authentication to just be turned off entirely for four hours in 2011.
But to let your recipient decrypt your pre-encrypted data, you have to communicate your strong (>=128 bit) key to them, as well as enough information to point at the ciphertext (hostname, port, file ID if the server handles more than one at a time). That's a UX challenge, because 128 bits aren't very humane, no matter how you encode them. Dropbox has a feature to let you upload a file and then get a URL you can give to someone else, but it's long and random and hard to read, and still doesn't include any cryptographic protection.
Some secure file-transfer systems deal with this by using fewer bits and then applying a "key stretching" algorithm like bcrypt or Argon2. That forces the attacker to do more work for each guess, which maybe lets you get away with.. 80 bits? 60 bits?. But whoever holds the ciphertext (like the server) can remember it forever, so they can just keep trying for as long as they like, so it's hard to have confidence that you've picked parameters that are strong enough, and the attack resistance is directly at odds with the usability.
Magic-wormhole is using PAKE to bring the necessary cryptographic data down to a safe minimum (16 bits or so), baking in knowledge of a server (plus allocating the shortest distinct file identifier it can, usually just one digit) to minimize the non-cryptographic data, and using a phonetically-distinct wordlist to maximize the usability / transcribability of the whole thing. It lets you say just "use magic-wormhole and the code is 4-purple-sausages" and you're done. But it's a trick, of course: we can only get aware with codes that short by pointing everybody at the same servers. You can easily self-host, but then you must either recite a lot more information to your recipient ("use magic-wormhole with --relay-url=ws://myserver.example.net:4000/v1 and a code of 4-purple-sausages"), or pre-stage that information by giving them a config file ahead of time.
As for the servers, I run them. Their source code is in repos next to that of the client, namely https://github.com/magic-wormhole/magic-wormhole-mailbox-ser... and https://github.com/magic-wormhole/magic-wormhole-transit-rel... . But the client is designed so that you don't have to rely upon the servers or the people running them to still get confidentiality and integrity of your transferred data. Those properties depend just upon the implementation of the client, and of course the computer that you run it on.
The initial low-bandwidth data (a few hundred bytes) goes through the "mailbox server". That phase is store-and-forward, and is used both to perform the PAKE protocol (to get a strong shared key), and to use the now-encrypted connection to negotiate whatever else you want to do (like establish a direct connection for file transfer). The bulk data transfer happens over a direct connection if one can be made, else it goes through the "transit relay", but in neither case does large amounts of data get stored on a server.
This means magic-wormhole lacks an important feature that many of its competitors have: the ability to close your computer before your recipient has finished (or even started) retrieving the data. I decided to use an approach that was more sustainable by me (the servers use just a t...
Direct computer to computer transfer seems like a nice convenience. Is there a large scale use for something like this though? At the enterprise level we just use networked drives with some that have write-only access when you need to drop a file to someone else.
It's not particularly secure but in a pinch I just use the python standard lib server to start an http server in a folder then open up the port with ngrok temporarily to share the file. Security through obscurity for a very discreet time period works.
I'm sure this is a noobish question, I don't deal with this sort of operation that often. Can anyone help me understand when you would use this or croc instead of scp?
When you don't have a direct connection to the sending/receiving ends. Magic Wormhole and croc use Relays for that. And if you want to transfer files to systems without sshd installed and configured.
186 comments
[ 5.5 ms ] story [ 299 ms ] threadsee also https://wormhole.app/
It uses a pair of helper servers (that I run), for which the source is also on github. But the protocol (implemented in the client, not the server) is carefully designed to be resistant against server misbehavior.
So you can either study the client and convince yourself the protocol is indeed secure, or rely upon my claims that my code is working as advertised. But you don't need to rely upon my claims that my servers are not snooping or interfering: that's protected by the protocol.
This is what I could find for wormhole.app source: https://github.com/SocketDev/wormhole-crypto
aww, thanks :)
BTW for anyone reading, https://wormhole.app/ is awesome and serves a very similar purpose, but uses entirely different technology (no PAKE) and has a different security model.
In my (https://magic-wormhole.io) world, we've kicked around ways to make a good browser-based client (and I've tried to prepare the protocols to work well there), but I haven't had time to pursue any of them. The tasks include 1: port everything to JS (or take the core of the Rust port and compile it to WASM, then write an IO layer in JS), 2: glue it to the browser's file/blob upload/download APIs, 3: settle on a trusted-application security model.
To make it work in a vanilla browser with no setup phase, you're pretty much limited to relying upon the webserver from which you get the page, which is the model wormhole.app provides. Other options include using an addon (which shifts the reliance set slightly), or running some sort of Electron thing (making it not really a browser app) that you get from some distribution channel (debian, homebrew, etc) which shifts the reliance set in a better direction.. at least you're probably getting the same application as everybody else using that distribution, vs a webserver that could conceivably serve up a different version each time.
There is a world of difference between what Magic Wormhole can promise and what Wormhole.app can promise. Magic Wormhole relies entirely on clientside cryptography; once you have it installed, you can trust that it's doing what it says on the tin. Which means you can reasonably use it operationally.
"Wormhole.app" --- which has a frustrating name, given the distinction --- demands that you trust the server, since the server can on every transaction defeat the cryptography you're using.
If someone owns up a Magic Wormhole relay server, there's not much they can plausibly do to intercept the files you send. But if someone owns up Wormhole.app, they can, I believe, quietly pick up and store people's files.
Incidentally, apropos none of this: I've been using the Golang https://github.com/psanford/wormhole-william port on some of my machines for a year now, interoperating with the standard Python Magic Wormhole, and it works great.
Magic Wormhole is an achievement. I wrote a blog post about modern cryptographic tools, and what I have to say about Magic Wormhole is that everyone I've introduced to it immediately starts wormholing all sorts of stuff; it's kind of addictive. Thanks for designing it!
I'm Brian Warner.
The standard criticism of web-based apps is that you have no guarantee that the code you receive will be the same as that which you received on your previous visit. (This ignores problems with self-updating desktop apps, but let's pretend users make informed decisions about every new version published).
Fortunately there is, at least in principal, a way of achieving TOFU for web apps. It relies on the bookmarklet/SRI trick[0], which lets the user store the hash of a script which bootloads the rest of the application. The major downside with this is that the browser's address bar shows a Data URI rather than the domain of your app. That limitation wouldn't exist, though, if browsers supported Hashlinks[1].
[0] https://news.ycombinator.com/item?id=17776456
[1] https://datatracker.ietf.org/doc/html/draft-sporny-hashlink-...
I think I'm probably missing something.
> PAKE effectively trades off interaction against offline attacks. The only way for a network attacker to learn the shared key is to perform a man-in-the-middle attack during the initial connection attempt, and to correctly guess the code being used by both sides. Their chance of doing this is inversely proportional to the entropy of the wormhole code. The default is to use a 16-bit code (use –code-length= to change this), so for each use of the tool, an attacker gets a 1-in-65536 chance of success. As such, users can expect to see many error messages before the attacker has a reasonable chance of success.
(It does strike me, however, that if a 'mailbox server' becomes heavily used, with many pending-but-incompleted wormholes, then an attacker making random guesses might manage to receive someone's random file, instead of the real intended-recipient. Perhaps the sending-side should optionally require an interactive sender-ack, after showing for confirmation a receiver-generated unique secret? In any case: using a longer code, and/or using a private mailbox, could each help eradicate such risks.)
Check out the `--verify` flag for `wormhole send` and `wormhole receive`
You are sending the file runs
I, the attacker run If my code is right, I get the file. If not, you cannot know, surely? There's no identification here other than the code. I can guess repeatedly as many times as I want. If lots of people are using the same server, the chance I start getting someones files is quite high.~~In addition, with generating the code, either the sender has a way of checking if codes are in use (and so the attacker can more easily find current open valid codes) or there is the chance of a clash.~~ Edit - looking at the code I don't think this side is an issue. It'll ask for a connection then generate a code for that connection I think.
So - how do I only get one guess?
The words are secret. There's a special cryptographic protocol named PAKE ("Password Authenticated Key Exchange") that tells you what messages to put into the mailbox. The protocol has a lock-step part in the middle, where you don't generate your second message until you've seen the other person's first message (and vice versa).
When the protocol is done, if the two people used the same secret words, they'll wind up with the same secret encryption key, and nobody else will know the key. If they used different words, they'll wind up with random strings. The file transfer uses the shared key to encrypt the bulk data.
Your client will generate a random wormhole code (random words plus server-allocated mailbox number) and run the protocol exactly once. It will generate and send its first message, wait for the partner's first message, then generate and send the second message, wait for the partner's second message, compute the shared key, do a test to see if it matches the other side (send a hash of the key), negotiate a direct connection if possible, then encrypt and transmit the file data.
If an attacker is trying to guess your code, their only option is to pretend to be your intended recipient and follow the same protocol. They watch the server and learn the mailbox number: that part isn't secret. But then, to send their first message, they have to commit to some particular secret words. And they don't get to find out if they were right or not until they see your second message, by which point your client knows that this "one shot" has been used up, and it's either correct (the key-verification hash matches) or it's not (or the attacker disconnects and runs away, in the hopes of getting you to blame a flaky network instead of suspecting an attacker).
If it fails, the client tells you that fact and quits, and you have to re-run the program (getting a brand new random wormhole code) to try again. Which means the attacker is back to square one: they know their first guess was wrong, but now the code is different, so their second guess has exactly the same chances of being right as the first guess.
Thanks for the clear explanation.
https://www.youtube.com/watch?v=oFrTqQw0_3c&t=1775s
Hope it helps, it's a good question.
I personally love the idea of using Diceware words (specifically, the EFF shortlist version). Fairly high security can be achieved with 3 only or 4 words (at 10 bits of entropy per word, you get a billion possibilities with just 3 words).
Maybe Magic Wormhole already has that option, I haven't checked. In any case, I would like whatever is the default to be raised to at least 20 bits of entropy.
1. you can't start downloading on the other side until the upload is complete - for large transfers this is a significant delay
2. the Telegram operators can read your files
Straight from the README:
> croc is a tool that allows any two computers to simply and securely transfer files and folders. AFAIK, croc is the only CLI file-transfer tool that does all of the following:
- allows any two computers to transfer data (using a relay)
- provides end-to-end encryption (using PAKE)
- enables easy cross-platform transfers (Windows, Linux, Mac)
- allows multiple file transfers
- allows resuming transfers that are interrupted
- local server or port-forwarding not needed
- ipv6-first with ipv4 fallback
- can use proxy, like tor
refs:
[0]https://github.com/schollz/croc
""" wormhole ssh --help Usage: wormhole ssh [OPTIONS] COMMAND [ARGS]...
Options: --help Show this message and exit.Commands: accept Send your SSH public-key In response to a 'wormhole ssh invite'... invite Add a public-key to a ~/.ssh/authorized_keys file """
Anyways, croc is pretty similar to wormhole except that it allows resuming files (which wormhole does not yet [3]) and has some peer discovery for local network transfers. I've been using croc everyday for over three years and I'm still very happy with it. But, you should totally use magic-wormhole if that floats your boat - its a great tool, along with psanford's Go version. That may help me actually as I think croc has too many users on the public relay and the cost of bandwidth is becoming too high to keep the public relay available after this year.
[1]: https://redrocket.club/posts/croc/
[2]: https://schollz.com/blog/croc9/
[3]: https://github.com/magic-wormhole/magic-wormhole/issues/88
[1] https://news.ycombinator.com/item?id=27054885
[2] https://twitter.com/Sc00bzT/status/1396199915638992896
Magic Wormhole has a good implementation in Go, which is compatible with the original Python implementation (croc is not compatible with magic wormhole). It has windows binary and binaries for most of the popular OS.
https://github.com/psanford/wormhole-william
Binaries: https://github.com/psanford/wormhole-william/releases
There's GUI: https://github.com/Jacalz/wormhole-gui
Android app too: https://github.com/psanford/wormhole-william-mobile
Support for resuming transfers is planned I think.
I'm still looking for a solution I could use to share pictures and PDF files from Android phones to iPads and Laptops using the "share" modal and completely self-hosted...
The ideal situation would be some universal airdrop which will never happen. The next easiest solution is to use cloud storage and send a link to the other person.
https://f-droid.org/en/packages/be.ppareit.swiftp_free/
I guess you can install in on multiple devices (Android phones and tablets), then use a file explorer that supports ftp or use a dedicated ftp client, to then transfer between each other. But accessing my phone from my computers via ftp (Fedora and Windows 10) is a piece of cake and reliable - don't even need anything like filezilla.
To stop changing ip's: I recommend having a static ip range in your router instead of using dhcp (or some routers/dhcp server can allocate the same ip address to the same mac address), so all of your devices ip's stay stable (on newer phones, you have to disable the random mac address feature though).
1. gpl and apple appstore don't go along
2. ios apps cannot run in the background in ways that kde connect needs
3. ios does not permit 99% of things that make kde connect interesting and useful
blame apple for this, not the kde connect devs.
I see kdeconnectd.exe and kdeconnect-indicator.exe running in the task manager but nothing else. Nothing in the tray either.
I've seen similar complaints on googling but none has ever been resolved.
Does anyone else have it working on Windows?
The primary use case is for me to share PDF scans made with my iPad/phone with my laptop. The second use case is for sharing screenshots of my laptop with others on my favorite messenger.
https://github.com/josephernest/Yopp
> This tool requires a total number of 7 actions to get the work done
What the hell?!
I use this for cross-family backup and sharing. My main use-case is getting my photos from my phone to my desktop.
[1]: https://www.ghisler.com/androidplugins/wifi/
[0]: https://github.com/linuxmint/warpinator
Everyone has UltraPhones with 4k videos they can't share with anyone.
No host in their right mind would accept such large messages.
Most EMail servers do not accept more than 10MB, and considering the file sizes of your typical PDF, Word Document or photo, that seems sensible.
[0]: https://github.com/psanford/wormhole-william-mobile
https://gitlab.com/timvisee/send (a fork of the original code)
It auto-detects when you enter a link, otherwise treats text inputs as a pastebin, you can ctrl+v an image, and it has file uploads up to a few gigabytes. Code is on github (https://github.com/lgommans/dro.pm/) though I still have to change the license to be more permissive (I've decided that I won't pursue this as a commercial thing, just open a ticket if you want me to change the license sooner than whenever I work on this next). Viewing uploaded files instead of downloading is also possible for image/audio/video mime-types by adding /preview to any link.
You can also use it from the command line if you're on a keyboard+terminal-only machine, e.g. just `wget -L dro.pm/h.txt` to download the uploaded file (the links accept an arbitrary .extension) or for uploading from the command line there is a bash one-liner contained in the page source itself, see: `curl https://dro.pm | head`
Made a mistake and uploaded something private or want to edit the link? Just click delete on the website, or on the command line you can use the token that you get when creating a new link.
I guess magic wormhole is the wrong context to be making this argument in since everyone's primed for peer to peer now, but in general, yeah when using dro.pm it will put your data on dro.pm, similar to how pastebin stores your data when you use pastebin. It otherwise (and that's why I made this design decision) couldn't work after you close the tab, making it much less suitable for most of the intended use-cases. If you want peer to peer file transfer, you could have a look at https://file.pizza (not made by me)
This appears to me much more like blantant self promotion rather than attempt to participate in the discussion. Your tool has none of the requested features (self hosted file transfer using the native share dialog.)
> though I still have to change the license to be more permissive (I've decided that I won't pursue this as a commercial thing, just open a ticket if you want me to change the license sooner than whenever I work on this next).
Guess that'll have to be now then. Getting this sort of crap is what makes me wonder why I bother putting this work out there in the first place.
> Your tool has none of the requested features
The main premise was a way to have file sharing between tablets, phones, and computers. This does that. It is open source (as of now) and has an Android share app to boot[1]. Anything else you're very welcome to make yourself, it's not a commercial plug, I'm obviously disclosing my affiliation, I host this on my personal machine at home, you're just welcome to make use of this or not if you don't like it.
[1] https://github.com/lgommans/dro.pm/tree/master/android/dropm...
Neither your initial comment, nor the project readme discuss the Android App. You have to browse the project dirextory to find out that it exists. The Android app has the dro.pm url hardcorded as a string and generally does not appear setup to work with a self-hosted solution.
All of this is fixable, but it very much belies a project that is immature. I would personally be uncomfortable promoting this as a solution without being very clear about the limitations and work required to fit the specidies use case.
I definitely never intended to say that you shouldn't ever run an open source project. My earlier wording was not done well. My point is that if you are burning out this early in open sourcing this project, then maybe this particular project is not meaningful or valuable enough to be worth it to you.
You were just given carte blanche to host it, by the author in public. If that isn't a legal exception, I really, really do not know what is.
Also, if you do self-host it, who is going to find out and sue you? Software licenses are not magical. The hammer of god is only going to come down on you if the person:
a) sees you do it
b) has the power to stop you
And if they're outside of the GNU project or the Linux foundation, they very likely do not! And regardless, that only matters if:
c) you have the money to pay for the damages
Which unless you're rich (I dunno, maybe you are rich), you probably don't!
and if you run a business, it's automatically a no-go.
however, what really matters for FOSS is that suggesting the license does not matter only reduces the strength of FOSS licenses. you are effectually suggesting that licenses can be ignored.
note that i am not suggesting that the author of the product should change their license, or clarify it with regards to self-hosting, just that your advice to ignore the actual license is dangerous.
Now with my point in general,
> however, what really matters for FOSS is that suggesting the license does not matter only reduces the strength of FOSS licenses. you are effectually suggesting that licenses can be ignored.
Right, but if they are ignored by large companies, there's no chance in hell that we're ever going to find out about it. The fact of the matter is that big companies really do not have to give a shit, at this point, because even if someone challenges them, it's unlikely that any one person is going to have the financing to win the war of attrition that will follow.
Likewise, if you take someone's code and it's not open source, and you don't actually distribute it, but instead just host it, and you're small enough, then the license itself does not matter.
The claim that pointing out that the rules only matter as far as the rules can be enforced, actually damages the rules, is utterly absurd. The people who will want to ignore the rules and do whatever, and bank on not getting caught are already doing that.
that may be the case, but that makes it a custum exemption that is not vetted by lawyers. for my personal use that my be ok, but for my company it is not, no matter how small my company is, i just can't take the risk. not only the risk getting sued, which indeed may be minimal, if non-existant, but also the risk that any of my current or worse future business partners, investors or clients have less trust in an unvetted license than me.
and from a client perspective, i do not want to deal with a business that doesn't take licensing seriously.
the difference between a big company ignoring licenses and me is, that a big business can afford to deal with getting caught, but if i am wrong, i am ruined.
> Should I package it as a .deb, or what makes something self-hosted? The code is already on github: https://github.com/lgommans/dro.pm/ (link was buried in the text - I had a hard time prioritizing what people would want to read first, since that depends on your use-case).
As for no mobile app: how much faster is it going to get than opening the browser that's already on everyone's homescreen and typing a 7-8 character link? Or if you self-host it, you can host it on your own TLD like https://me/. It being an app was also never mentioned as a requirement and I don't see how it helps, but I guess I don't need to understand. As a bonus tip, though: you can add browser bookmarks to your homescreen. Since you'll need internet to share things in the first place, it should behave roughly the same (aside from a share menu, but...).
And there is a share modal for Android, actually. See the github link.
https://www.resilio.com/individuals/
Dropbox is centralized (with some p2p for performance gains on local networks) whereas this is entirely p2p
https://play.google.com/store/apps/details?id=pl.solidexplor...
Although top comment here suggests a combination: https://www.reddit.com/r/Syncthing/comments/ese82l/ios_users...
Top comment snippet: "I use FE file explorer PRO (paid ) on iOS to connect connect to my VPS vis SFTP where my main syncthing pool is"
https://github.com/marcosdiez/shareviahttp
https://github.com/jimmod/ShareToComputer
The two apps I linked do exactly that. You don't need an iOS app because you're sending files only from Android.
Works great, see my other comment for explanation.
I'm really looking for a "universal airdrop", but I would settle even for a pale copy of it.
https://news.ycombinator.com/item?id=9953767
https://news.ycombinator.com/item?id=14649727
https://news.ycombinator.com/item?id=24702975
https://news.ycombinator.com/item?id=27237536
Magic-Wormhole: Get Things from One Computer to Another, Safely - https://news.ycombinator.com/item?id=27237536 - May 2021 (4 comments)
Magic-Wormhole: Get Things from One Computer to Another, Safely - https://news.ycombinator.com/item?id=24702975 - Oct 2020 (9 comments)
Ask HN: What is your favorite method of sending large files? - https://news.ycombinator.com/item?id=24351111 - Sept 2020 (354 comments)
Ask HN: A more convinient Magic Wormhole alternative? - https://news.ycombinator.com/item?id=21352217 - Oct 2019 (3 comments)
Magic-Wormhole – Get things from one computer to another, safely - https://news.ycombinator.com/item?id=14649727 - June 2017 (179 comments)
Get things from one computer to another, safely - https://news.ycombinator.com/item?id=9953767 - July 2015 (15 comments)
EDIT: how will it be done? As another link or as some kind of expandable thread, or with a bot maybe?
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
I can see such a list being incredibly polarizing, but also something the community could rally behind.
This is a cli application. I am not aware of them also offering a web site, although that would certainly be a great addition.
lotharrr (the author of magic-wormhole) gave kind and valuable feedback when I posted it on HN [1].
[0] https://github.com/dennis-tra/pcp
[1] https://news.ycombinator.com/item?id=26127923
For a small number of files, I currently just email them. If the file is too big, Google Drive or MS OneDrive can be used to send a link. This works across any OS and form factor.
For bulk downloads (e.g. downloading all photos/videos I took on a certain day), I plug my phone into my PC via USB. Navigation and selection using the file browser on the PC is much nicer than selecting files on the phone.
Does Wormhole and Croc enable use cases not covered here?
* You're sitting next to someone at a conference (remember those?) and want to hand them a file: fewer steps than email, the wormhole code is easier to transcribe than most email addresses, the file lands where you want it to rather than in a spam folder somewhere, and neither of your email providers or the network in between them can snoop on or modify the data in transit.
* You're ssh'ed into a remote machine, via two layers of proxy servers, deep in a directory structure with lots of spaces and quotes and backslashes and other shell metacharacters in the path, and you want to transfer a file from there back to your desktop. You have no idea how to quote everything properly. So you wormhole it to yourself.
* I'm on zoom or the phone with a friend and want to send something from my desktop machine to their laptop. I can read the wormhole code off the sending machine, speak it to them over the phone, they can type it into their machine. The codes are optimized for spoken clarity.
* I'm debugging something on the little computer attached to my television and want to copy a logfile off to a real machine. I've got a terminal window open on the screen, and a shell, but that account doesn't have an email address, nor is it listening on SSH. I could write a python one-liner that listens on an HTTP port, but there's no security to that. I can 'wormhole send LOGFILE' and read the code from the screen, and type it into my laptop.
By "safely" I mean: confidentiality against anything outside your two computers (eavesdropper only learns the length of the data, as is true for most networks), and integrity (nobody in the middle can modify the file, or cause you to receive something different than what your partner sent). The security of most common file transfer methods depends upon some intermediate server, or two, or a dozen (in the case of email).
If by "untrusted computers" you're making a distinction between distributing files to computers that you already know about, vs to computers that you've just met, then yes, that's exactly right. If your laptop and your desktop already know about each other, there are a bunch of tools that work better for a lot of cases, like a shared network filesystem or AirDrop. Magic-wormhole is kinda aimed at how to introduce two machines that don't already have a connection. The wormhole code is a way to leverage the connection between the humans who control those computers, into a secure shared encryption key between the computers themselves.
I know nothing about computers. If the clients successfully connect, the file goes from A -> B, but if the connection fails, it goes from A -> relay server -> B? What conditions might cause the connection to fail?
Specifically if the clients are behind NATs, having a third party server coordinate can help.
I need to build some better stats dashboards, but at a glance it looks like maybe a third of the connections wind up using that relay. I'd like to add better hole-punching code (using WebRTC sounds like the right approach), but haven't had the time or found the right library yet.
> You want to provide your users with a relay that fails at different times than the official one
What are your costs for running the official relay server? Do you have plans for if/when they significantly increase?
I might also change the transit relay to throttle the connection somewhat after some total number of bytes have been transferred (but that takes actual code, and switching providers would be easier). I'm really glad folks are using it, but I do sort of think that >10GB at a time is a bit much. But I don't have a way to notify a given user about any sort of soft limit like that (the transit relay has no idea how much you're going to send ahead of time, and doesn't have a notification channel other than throwing an error).
I've also been meaning to figure out NAT hole punching for years now, and the thought has always been that hole-punching will save a lot of the server bandwidth by making direct connections happen a larger percentage of the time.
So you need to have a secure method of communication to transfer the code? Then why not just use whatever that is to transfer stuff?
How is this end to end encryption without any identity management? How do you know who you are exchanging stuff with? How is this different than just regular encryption?
Because sometimes that secure method of communication is speech. This is a particularly good utility for transferring information to parties that you can talk to verbally. Also, a bit quicker than plugging a USB stick in.
Let's say a user encrypts a file outside of Dropbox, using a program of the user's choice, then she transfers the encrypted blob to Dropbox.
Is the author suggesting this is "not secure against the Dropbox server". I am not a Dropbox user. I know it was originally for syncing folders and they orginally used an rsync library and that is about all I know. Pardon the ignorance.
Magic Wormhole by default uses hardcoded host:port for a rendezvous server and a transit server operated by [undisclosed].
"The URL of a public server is baked into the library for use as a default, and will be freely available until volume or abuse makes it infeasible to support."
This Github page is only for the client, not the servers.
In the section titled "Dilation", we are reminded that MW is store and forward by default, not direct connection.
How are messages stored on the default public MW server operated by [undisclosed] "secure against [undisclosed]" in a way that messages stored with Dropbox are not "secure against Dropbox". Maybe the author only uses MW with private MW servers, not public ones run by other people. Then his comment about Dropbox would make sense. However I have to wonder, how many new MW users are running their own servers.
With MW you share a weak key (vs a strong key in Dropbox case). Dropbox also provides access to all data.
On the other hand, you have to hope there is no vulnerability in MW. With Dropbox, you have much more control over crypto.
But to let your recipient decrypt your pre-encrypted data, you have to communicate your strong (>=128 bit) key to them, as well as enough information to point at the ciphertext (hostname, port, file ID if the server handles more than one at a time). That's a UX challenge, because 128 bits aren't very humane, no matter how you encode them. Dropbox has a feature to let you upload a file and then get a URL you can give to someone else, but it's long and random and hard to read, and still doesn't include any cryptographic protection.
Some secure file-transfer systems deal with this by using fewer bits and then applying a "key stretching" algorithm like bcrypt or Argon2. That forces the attacker to do more work for each guess, which maybe lets you get away with.. 80 bits? 60 bits?. But whoever holds the ciphertext (like the server) can remember it forever, so they can just keep trying for as long as they like, so it's hard to have confidence that you've picked parameters that are strong enough, and the attack resistance is directly at odds with the usability.
Magic-wormhole is using PAKE to bring the necessary cryptographic data down to a safe minimum (16 bits or so), baking in knowledge of a server (plus allocating the shortest distinct file identifier it can, usually just one digit) to minimize the non-cryptographic data, and using a phonetically-distinct wordlist to maximize the usability / transcribability of the whole thing. It lets you say just "use magic-wormhole and the code is 4-purple-sausages" and you're done. But it's a trick, of course: we can only get aware with codes that short by pointing everybody at the same servers. You can easily self-host, but then you must either recite a lot more information to your recipient ("use magic-wormhole with --relay-url=ws://myserver.example.net:4000/v1 and a code of 4-purple-sausages"), or pre-stage that information by giving them a config file ahead of time.
As for the servers, I run them. Their source code is in repos next to that of the client, namely https://github.com/magic-wormhole/magic-wormhole-mailbox-ser... and https://github.com/magic-wormhole/magic-wormhole-transit-rel... . But the client is designed so that you don't have to rely upon the servers or the people running them to still get confidentiality and integrity of your transferred data. Those properties depend just upon the implementation of the client, and of course the computer that you run it on.
The initial low-bandwidth data (a few hundred bytes) goes through the "mailbox server". That phase is store-and-forward, and is used both to perform the PAKE protocol (to get a strong shared key), and to use the now-encrypted connection to negotiate whatever else you want to do (like establish a direct connection for file transfer). The bulk data transfer happens over a direct connection if one can be made, else it goes through the "transit relay", but in neither case does large amounts of data get stored on a server.
This means magic-wormhole lacks an important feature that many of its competitors have: the ability to close your computer before your recipient has finished (or even started) retrieving the data. I decided to use an approach that was more sustainable by me (the servers use just a t...
Most people won't encrypt before transfer to Dropbox.
Even if they do, all security usually relies on a password set by the user. Normal users are known to set easy to crack passwords.
So two unusual things need to happen for things to be secure.
The security of Magic Wormhole doesn't rely on the relay server, as explained elsewhere in this thread.