Live data from Hacker News

Firefox Send: Free encrypted file transfer service

blog.mozilla.org

521–530 of 542 posts

Re: Firefox Send: Free encrypted file transfer service

#521
post #261
post #227

Earlier quoted context omitted.

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.

Re: Firefox Send: Free encrypted file transfer service

#522
post #444

Earlier quoted context omitted.

In a browser, the server serving the JS has an opportunity to access the keys.

subtlecrypto has API to generate a keypair that you can't extract and access from the JS side. You can only use it to encrypt/decrypt buffers, but not access the key itself.

Sure, but having access to encryption/decryption/key derivation is pretty much equivalent to having the key in most circumstances. Plus, JS generates the key and sets "extractable" flag.

Re: Firefox Send: Free encrypted file transfer service

#523

Earlier quoted context omitted.

It's not outdated; it remains fundamentally true. But I'm uncomfortable with people calling it a "legendary rant" because it was dashed off and I never promoted it as any kind of last word on the subject. There are better arguments against browser cryptography than mine. In particular: you'd hope that WebCrypto would have changed things a bit, but, of course, it doesn't: it leaves all the cryptographic joinery up to…

You have said a bunch of useful stuff in HN comments that people end up pointing to, but in those comment rants you also have a tendency to leave things hanging or allude to things without further explanation (I think for fear of being boring), or to assume people understand the context of a long-running debate. I think you should consider hoisting more of this stuff out into standalone blog posts that you can flesh…

This place has basically ruined me for writing. I used to sort of know how to do it! The idea of writing a top-to-bottom "browser Javascript is evil" post is intimidating to me now. It was intimidating when I wrote the post referred to above! And that one wasn't even good!

I'll work on it.

Re: Firefox Send: Free encrypted file transfer service

#524
post #510
post #107

Earlier quoted context omitted.

Is there anything specific you are missing in Firefox today? Or is it purely the fact that it's broken since version 61? Did you submit a bugzilla issue, or know the existing number? I'd be happy to check it out.

A million things, like missing functionalities from the new extensions api (meaning no Pentadactyl), no good way to manage keyboard shortcuts, having to disable many google integrations after installation, no way to disable "do not track" if using built-in tracker blocking, no sidebars a la Vivaldi, buggy rendering (e.g. transitions animating elements using css transforms), unexplained slowdowns, lack of proper tab i…

Thank you! This is great input to us, it just needs a few more details to become actionable: bugs filed (for things that are not by design, of course, like the extension API), repro steps and detailed information provided. If I can reproduce it, I can file bugs myself, but I still need to get some clarifications on how to reproduce.

Re: Firefox Send: Free encrypted file transfer service

#526

In the not so recent past, HN'ers loved to quote tptacek's legendary rant about how in-browser JavaScript crypto is fundamentally broken[0]. What changed? Is that rant finally outdated? Couldn't Mozilla at any time serve a corrupted JS bundle (with or without their knowledge) which would leak the key somewhere, silently replace the encryption by a noop, etc? I ask out of interest, not skepticism. I much prefer an int…

It's not outdated; it remains fundamentally true. But I'm uncomfortable with people calling it a "legendary rant" because it was dashed off and I never promoted it as any kind of last word on the subject. There are better arguments against browser cryptography than mine. In particular: you'd hope that WebCrypto would have changed things a bit, but, of course, it doesn't: it leaves all the cryptographic joinery up to…

>There are better arguments against browser cryptography than mine.

mind pointing to or sharing them?

Re: Firefox Send: Free encrypted file transfer service

#527
post #512

Earlier quoted context omitted.

Signing infrastructure does seem like a significant improvement over Javascript delivery, but does that also carry over to platforms like Windows? Again, please correct me if I'm wrong, but Windows doesn't do anything with signing app updates, does it? Come to think of it, I'm not 100% sure my Linux version has this either, since Signal isn't being distributed as part of the official repos. If Signal is being updated…

While Windows does allow for code signing of executable files in general, I doubt Signal is using their system. The official windows store would probably work similarly to how Apple and Google handle updates, but Signal doesn't use it either. You can always implement signing yourself, though, without relying on somebody else's infrastructure. Just include the public key in the app itself and use it to verify your upd…

So the takeaway I'm getting from this and a few other comments is that, in general, running automatic updates for most software is still more secure than not, since a 0-day is more likely than a compromised server.

E2E encryption is still valuable, because assuming that the codebase is delivered/signed separately from its app servers, it decreases the number of available attack points. It's usually easier to secure code delivery than it is to secure your entire backend/database. It's even easier than that to secure a private key that you never put on your delivery servers in the first place.

JS has some additional concerns regarding stuff like Spectre and random number generation, but ignoring those for a sec, E2E encryption is in theory viable and valuable on the web, assuming you've split your backend from your code delivery endpoint and are taking extra steps to secure those specific code delivery servers.

But E2E encryption on the web could be improved a lot if we expanded code-signing for browsers. We download code over SSL, but that's just to make sure no one MITMs the server itself. We could, in theory, have some kind of signing system for raw assets that was completely unrelated to the connection to the server -- a "only allow Javascript to download/eval on this domain if it's signed with a key that's not even stored on the delivery server at all" policy. But we don't have anything like that yet.

Is that a reasonable interpretation?

Re: Firefox Send: Free encrypted file transfer service

#528

Earlier quoted context omitted.

Not as far as I can tell. Mozilla also has (or had, I forget whether it's still a thing or not) a built-in WebRTC client they called "Hello", but that was a different thing.

What's the reason it's not made this way or doesn't include WebRTC-based P2P transfer as an option?

I have no idea.

Re: Firefox Send: Free encrypted file transfer service

#529

Earlier quoted context omitted.

You have said a bunch of useful stuff in HN comments that people end up pointing to, but in those comment rants you also have a tendency to leave things hanging or allude to things without further explanation (I think for fear of being boring), or to assume people understand the context of a long-running debate. I think you should consider hoisting more of this stuff out into standalone blog posts that you can flesh…

This place has basically ruined me for writing. I used to sort of know how to do it! The idea of writing a top-to-bottom "browser Javascript is evil" post is intimidating to me now. It was intimidating when I wrote the post referred to above! And that one wasn't even good! I'll work on it.

One idea is to get a volunteer or hired goon to simply collate your HN posts and post them somewhere editable. Then when you read them over, you'll be horrified and the editing instinct will kick in.

Re: Firefox Send: Free encrypted file transfer service

#530
post #444

Earlier quoted context omitted.

> In a web app, a single compromised server will compromise all security instantly. This is only true if the server has access to the keys of your data. E2EE typically means that it doesn't, only you do.

In a browser, the server serving the JS has an opportunity to access the keys.

This is the case with all E2EE tools. You have to trust that they do their crypto correct and that they aren't evil. As Firefox Send is open source you can setup your own server if you don't trust Mozilla, but then again, if you don't trust Mozilla you might want to eyeball their code carefully first...
Post reply on HN