Earlier quoted context omitted.
Anybody who can catch the link in transit can get the file. Emailing these links with the decryption key right in the fragment is going to allow any party in between the sender and the receiver to fetch the file. (If the file is set to only allow downloading once, the receiver can at least let the sender know that it got intercepted.) So you have to send the link through some previously-negotiated secure channel. At…
Absolutely. Security and secrecy are not binary, though, it's a spectrum. There are many things where you would mostly want to avoid dragnet attacks and undetected intrusion but don't have concerns for targeted attacks like the one you are describing. I think this fills the gap for when you want to share not-critically-secret stuff with non-technical people and would today likely send it over something like e-mail, D…
Firefox Send: Free encrypted file transfer service
321–330 of 542 posts
Re: Firefox Send: Free encrypted file transfer service
#322Earlier quoted context omitted.
Beyond AirDrop which only works between like devices, how else can files on an iPhone be transferred to another device without iTunes, and without using a 3rd party? I'm not being adversarial, I really want to know.
I’m a little confused, you don’t want to use 3rd party apps (like a Microsoft app to interact with nearby MS stuff) AND you don’t want to use Apple 1st party apps? It sounds like the only thing that would’ve satisfied you would’ve been for iOS to natively understand whatever the Microsoft system is for broadcasting videos? I agree it would be delightful if Apple and Microsoft could agree on a “I’m a short term drop-p…
Since iOS 12 they also have a "copy iCloud link" share option that gives you a Dropbox-style file download page.
Re: Firefox Send: Free encrypted file transfer service
#323How is this using end-to-end encryption? It seems like the recipient just clicks a link to download. How can it have been encrypted for that person? end-to-end encryption normally means that there's no way for the intermediary to unencrypt the data but I can't see how that's possible in this case.
The url effectively contains the decryption key, so the web server could be set to capture the urls and decrypt files. If you want, you can also set a passphrase on the file to share via another channel
If that's the case, I think setting a passphrase should be mandatory. Proxy servers are extremely common at every workplace. Since they probably log all requests, they will capture all keys in the URL.
Re: Firefox Send: Free encrypted file transfer service
#324Earlier quoted context omitted.
Anybody who can catch the link in transit can get the file. Emailing these links with the decryption key right in the fragment is going to allow any party in between the sender and the receiver to fetch the file. (If the file is set to only allow downloading once, the receiver can at least let the sender know that it got intercepted.) So you have to send the link through some previously-negotiated secure channel. At…
Absolutely. Security and secrecy are not binary, though, it's a spectrum. There are many things where you would mostly want to avoid dragnet attacks and undetected intrusion but don't have concerns for targeted attacks like the one you are describing. I think this fills the gap for when you want to share not-critically-secret stuff with non-technical people and would today likely send it over something like e-mail, D…
Re: Firefox Send: Free encrypted file transfer service
#325I also think the blog post could explain more why and how the e2e encryption works. Maybe just by showing an example link and then highlight with colors "this part is private"?
Re: Firefox Send: Free encrypted file transfer service
#326Earlier quoted context omitted.
The url effectively contains the decryption key, so the web server could be set to capture the urls and decrypt files. If you want, you can also set a passphrase on the file to share via another channel
That's why the key is in the hash part of the URL; the server can't access that (unless it also sends client Javascript that parses it and sends it back to the server, but that could be detected).
Re: Firefox Send: Free encrypted file transfer service
#327Earlier quoted context omitted.
That's cool, but it's still the same party providing both the storage mechanism, and the JS that encrypts the content on the client-side. You have to trust them that they are not "peeking" at the keys you are generating using their code in your browser.
But at least you only need to trust them now, and not every incarnation of them in the future =)
Re: Firefox Send: Free encrypted file transfer service
#328I've been building a fully featured CLI tool for Firefox Send, supporting this new release. For anyone that is interested: https://github.com/timvisee/ffsend
Re: Firefox Send: Free encrypted file transfer service
#329Earlier quoted context omitted.
>pip install --user pipe && pipe install magic-wormhole What am I looking at here? On PyPI 'pipe' is listed as a "Module enablig a sh like infix syntax (using pipes)", and magic-wormhole's own docs just say to install with pip like anything else.
I typoed. I meant `pipx`, not `pipe`. My phone tried to help. `pipx` is a convenience utility for installing cli python tools in separate virtual environments and then being able to update them nicely: https://github.com/pipxproject/pipx So i meant `pip install --user pipx && pipx install magic-wormhole`
Re: Firefox Send: Free encrypted file transfer service
#330Earlier quoted context omitted.
Anybody who can catch the link in transit can get the file. Emailing these links with the decryption key right in the fragment is going to allow any party in between the sender and the receiver to fetch the file. (If the file is set to only allow downloading once, the receiver can at least let the sender know that it got intercepted.) So you have to send the link through some previously-negotiated secure channel. At…
True, but I don't think I'd use this website for anything I'm that concerned about. At that point, I'd encrypt it myself with something like gpg or openssl on the command line. This fills a handy gap for a lot of people with smaller needs.
> This fills a handy gap for a lot of people with smaller needs.
You point out exactly the problem: the people who are technical enough to deal with GPG's UX competently are also technical enough to evaluate whether they should put a particular document through this Send service.
I don't think nontechnical people have "smaller needs".