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.

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.

Unlikely but possible. Two words: browser extensions.

Three words: My Ether Wallet.

It's not a new idea, the megaupload successor first did it as far as I can remember

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.

How would this be possible to fix? I currently don't see any possibility of this.

Yes, the mega.co.nz . End-to-end encrypted dropbox analog.

It's cool, but not exactly novel. Mega has done it this way for years.

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?

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.

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.

I think it's relatively intuitive for lay users that the links are secret. If you give someone the link, they get the file. What's not obvious about that?

If anything it's probably harder to understand for a somewhat semi-technical person who probably has started to think about encryption and so on but hasn't got far enough to spot that oh - the secret key is in the URL itself as an anchor and so the URL is the secret.

Computer Security is often nicer here than real world physical security, because we are often able to make the extreme cases so implausible as to be irrelevant, enabling intuitive statements to be true in practice rather than subject to endless caveats.

For example a lay person sees a padlock and they imagine that it cannot be opened except with the padlock key. And this is untrue in lots of ways - so a more technical person may think of some of them, and identify that this particular brand of padlock defends against those well, but not realise that other problems are undefended.

So this means the truth about the padlock has to be more nuanced and relative. Breaking the lock open with tools is "difficult". Picking the lock "cannot easily be done in under a minute". But lay people don't like nuanced, relative statements. It sounds a lot like this padlock won't really stop someone stealing my bike! That's because it won't.

But in computer security we often can make these cases irrelevant in practice. What if someone just tries all the key values for this AES encryption? That's fine, there are so many that even if they could try as many as there are grains of sand in the world, every second, the sun would burn out long before they had a meaningful chance of guessing the right one.

It's intuitive for lay users that the links are secret, yes. What lay users have trouble understanding is that putting something in an email automatically makes it not secret.

Right. If I were really really concerned one would encrypt it locally then send...which you could do in ff send.

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.

> 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".

Yes. I would like to add though, that you can set an optional password as well. Without it the link would be useless. You can share it through a different channel.

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 =)

Not to mention that onr could always encrypt it themselves then use ff send

This is where WebCrypto in browser extensions begins to get interesting, I think.

I use a similar mechanism on my website 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...

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