6 ms·

The client encrypts the file that is uploaded, along with some metadata. The key is appended to the share URL provided by the URL, in the fragment/hash, and is

The client encrypts the file that is uploaded, along with some metadata. The key is appended to the share URL provided by the URL, in the fragment/hash, and is never sent to the remote server. Only people having the URL including the secret will be able to download and decrypt your shared file. See https://github.com/mozilla/send/blob/master/docs/encryption.md https://github.com/mozilla/send/blob/master/docs/encryption....

bjt2n3904 8y ago
Thanks for the info. Let me see if I understand this correctly. Browsers don't send the anchor tag (ie: with GET requests). FF Send takes advantage of this by using the anchor tag to store the key for decryption. That is kinda novel. You still need to trust the upload client to not leak the key, but I see that you've written a CLI version. Interesting! Thanks for the response.
- NKCSS 8y ago
  It's not a new idea, the megaupload successor first did it as far as I can remember
  - simias 8y ago
    Indeed, the website serves you the crypto code but it runs totally on the client so it's perfectly safe and could in no way be backdoored. More seriously, did they do anything to fix this obvious design flaw? If they want to fish a key they can just serve you a modified JS file and retrieve the key. Unless of course you chose to audit the JS served every time you browse the website.
    - solarkraft 8y ago
      How would this be possible to fix? I currently don't see any possibility of this.
  - coolspot 8y ago
    Yes, the mega.co.nz . End-to-end encrypted dropbox analog.
- timvisee 8y ago
  You got it! The only thing you'd have to worry about is malicious JavaScript on the Firefox Send website which I believe would be highly unlikely. And of course, you must keep your link secret. Yes, such a CLI tool would help protect you against a MITM with malicious JavaScript.
  - deleted 8y ago
    [deleted]
  - Piskvorrr 8y ago
    Unlikely but possible. Two words: browser extensions.
    - quickthrower2 8y ago
      Three words: My Ether Wallet.
- deleted 8y ago
  [deleted]
- solarkraft 8y ago
  It's cool, but not exactly novel. Mega has done it this way for years.
air7 8y ago
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.
- mrmanner 8y ago
  But at least you only need to trust them now, and not every incarnation of them in the future =)
  - SubiculumCode 8y ago
    Not to mention that onr could always encrypt it themselves then use ff send
- jszymborski 8y ago
  This is where WebCrypto in browser extensions begins to get interesting, I think.
jszymborski 8y ago
I use a similar mechanism on my website https://expiring.link https://expiring.link I'm working on documenting the code now before I release on GitHub, but it works on the same premise :) WebCrypto is mana from the gods...
philsnow 8y ago
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 that point, why not just send the file through that channel? Is it because signal/whatsapp/etc don't allow large files or because the interface is cumbersome?
- bjt2n3904 8y ago
  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.
  - philsnow 8y ago
    > 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. 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".
- Legogris 8y ago
  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, Drive or Dropbox.
  - philsnow 8y ago
    I don't disagree. I've been thinking about how I would write the announcement copy explaining to non-technical users how the links should also be treated as secret and how email is not encrypted in general. It's a hard problem.
srecio 8y ago
Won't most people just share the links over email? With the decryption key in the url I don't see very good security guarantees here

bjt2n3904 8y ago

Thanks for the info. Let me see if I understand this correctly. Browsers don't send the anchor tag (ie: with GET requests). FF Send takes advantage of this by using the anchor tag to store the key for decryption. That is kinda novel. You still need to trust the upload client to not leak the key, but I see that you've written a CLI version. Interesting! Thanks for the response.

NKCSS 8y ago
It's not a new idea, the megaupload successor first did it as far as I can remember
- simias 8y ago
  Indeed, the website serves you the crypto code but it runs totally on the client so it's perfectly safe and could in no way be backdoored. More seriously, did they do anything to fix this obvious design flaw? If they want to fish a key they can just serve you a modified JS file and retrieve the key. Unless of course you chose to audit the JS served every time you browse the website.
  - solarkraft 8y ago
    How would this be possible to fix? I currently don't see any possibility of this.
- coolspot 8y ago
  Yes, the mega.co.nz . End-to-end encrypted dropbox analog.
timvisee 8y ago
You got it! The only thing you'd have to worry about is malicious JavaScript on the Firefox Send website which I believe would be highly unlikely. And of course, you must keep your link secret. Yes, such a CLI tool would help protect you against a MITM with malicious JavaScript.
- deleted 8y ago
  [deleted]
- Piskvorrr 8y ago
  Unlikely but possible. Two words: browser extensions.
  - quickthrower2 8y ago
    Three words: My Ether Wallet.
deleted 8y ago
[deleted]
solarkraft 8y ago
It's cool, but not exactly novel. Mega has done it this way for years.

air7 8y ago

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.

mrmanner 8y ago
But at least you only need to trust them now, and not every incarnation of them in the future =)
- SubiculumCode 8y ago
  Not to mention that onr could always encrypt it themselves then use ff send
jszymborski 8y ago
This is where WebCrypto in browser extensions begins to get interesting, I think.

jszymborski 8y ago

I use a similar mechanism on my website https://expiring.link https://expiring.link I'm working on documenting the code now before I release on GitHub, but it works on the same premise :) WebCrypto is mana from the gods...

philsnow 8y ago

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 that point, why not just send the file through that channel? Is it because signal/whatsapp/etc don't allow large files or because the interface is cumbersome?

bjt2n3904 8y ago
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.
- philsnow 8y ago
  > 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. 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".
Legogris 8y ago
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, Drive or Dropbox.
- philsnow 8y ago
  I don't disagree. I've been thinking about how I would write the announcement copy explaining to non-technical users how the links should also be treated as secret and how email is not encrypted in general. It's a hard problem.

srecio 8y ago

Won't most people just share the links over email? With the decryption key in the url I don't see very good security guarantees here