Live data from Hacker News

Firefox Send: Free encrypted file transfer service

blog.mozilla.org

491–500 of 542 posts

Re: Firefox Send: Free encrypted file transfer service

#491
post #460

Earlier quoted context omitted.

Followup question: I have Signal running on my Linux computer and on my Android phone. On the Linux computer it doesn't have root access, but it does have access to its own files, so in theory there's nothing to prevent it from making a network request and updating itself. Additionally, I don't ever check Signal before installing a new update, I just blindly do it. On my Android device, I also have auto-update turned…

> On my Android device, I also have auto-update turned on, because my only option is to turn it on for every app or none of them. Open the Signal store page and click the dots in the top right of the screen and untick Automatic Updates.

Oh crud, thank you!

I didn't know that, and there are a few apps that I definitely want to use this with. Why on earth isn't this part of the general settings?

Re: Firefox Send: Free encrypted file transfer service

#492
post #446

Earlier quoted context omitted.

Followup question: I have Signal running on my Linux computer and on my Android phone. On the Linux computer it doesn't have root access, but it does have access to its own files, so in theory there's nothing to prevent it from making a network request and updating itself. Additionally, I don't ever check Signal before installing a new update, I just blindly do it. On my Android device, I also have auto-update turned…

Yes and no, depending on your threat scenario. I would assume Signal to have a proper signing infrastructure in place, so that the keys used to sign new releases are not available to the server hosting/deploying the actual update files (or providing them to Google/Apple for that matter). So simply taking over that server would not be enough, as malicious updates could not be installed. Assuming Moxie goes over to the…

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 on Windows without validating any kind of signature, could a compromised server even pull off the "send a malicious payload to only one IP address" attack that people talk about with the web?

Re: Firefox Send: Free encrypted file transfer service

#493

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 content-controlled code. You're probably somewhat less likely to have side-channel flaws if you use it, but in reality timing side-channels are more talked about than seen. Who would bother, when they can just deliver a script that exfiltrates secrets directly?

Re: Firefox Send: Free encrypted file transfer service

#494

Earlier quoted context omitted.

Thanks for sharing your solution! Not sure what is causing it (maybe it's OpenSSL binding related), and am currently not really targeting FreeBSD yet. I wasn't fully ready with this tool for the Firefox Send release to be honest, would have loved to be able to provide better binaries and packages for more platforms, which are a work in progress. If you believe you can improve the README with your solution, be sure to…

Is there an autotools equivalent in Rust land?

Depends on what you mean exactly.

Re: Firefox Send: Free encrypted file transfer service

#495

As I understand it, this "guarantees" privacy by embedding the key in the link-- if that's generated client-side, it never gets sent to Mozilla's servers (assuming they don't go out of their way to grab it via JavaScript) and you can have end-to-end encryption. But, if I'm logged in, it looks like Mozilla's storing that fragment on their servers: if I upload a file from one browser, then sign in on a different browse…

The data that's synced when you log in is also encrypted, with a unique key derived from your Firefox Account called a scoped encryption key. Your key changes when you change your password. We, (Mozilla) don't know your key (and don't want to know it). Disclosure, I implemented the sync feature of Send.

Re: Firefox Send: Free encrypted file transfer service

#496

I'm working on a file sharing product, for the niche use case of sharing documents between family and professional providers (lawyers, accountants, etc). Documents are mostly emailed to recipients at the moment (unless they're too large, in which case... um....). The main problem we see is that you end up storing documents in email attachments on your email provider, and using email search tools to try and find docum…

Why have a file transfer for imp docs when you can have a single authoritative source of truth for those docs, along with version history and who changed what.

So why not just use Google Drive (or dropbox)?

I feel with features like secure file sharing (though only with other ppl with google accounts), reasonably good security[1] and Inactive Account Manager[2] it should work for legal docs. Especially considering Google is going to be around for a while.

I would rather use a Mozilla offering but they don't really have too many things for regular consumers outside of firefox and send.

[1]: https://myaccount.google.com/security [2]: https://support.google.com/accounts/answer/3036546?hl=en

Re: Firefox Send: Free encrypted file transfer service

#497
This is cool, but I’m wondering if there is some sort of “secure drop box” equivalent. Basically I generate a set of GPG keys, anyone can post to a web form which encrypts the uploaded data, in browser, using my public key, and uploads it somewhere (my server, s3, Dropbox, doesn’t matter as the private is local on my computer). I could then download the files, decrypt them locally and use them.

We get a lot of customers who want to send us secure data (customer info, etc...) and I’d love a way to make it easy for the customer but still secure.

Does something like this exist, or is this still a pipe dream? Basically FF send, except I provide a known public key to use, rather than it being generated on the fly, requiring the user to find a way to send it to me out-of-band.

Re: Firefox Send: Free encrypted file transfer service

#498

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…

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 out and also update as circumstances warrant. I don't think I'm the only one who has learned a lot from reading you, but often felt myself wishing it had been dumbed down a shade for beginners.

Maybe the best argument for it is that blog posts remain mutable and you can add and expand as necessary, unlike these HN posts that are frozen in amber.

Re: Firefox Send: Free encrypted file transfer service

#499

Earlier quoted context omitted.

> Your points around a compromised JS bundle are still possible but that has more to do with a company’s deployment/change management setup than JS itself imo But that's the only point I intend to address here. If Pascal had been the language of the web then my question would have been about Pascal. Therefore I don't see how SubtleCrypto changes matters much. In short, if I get it right, the argument would be that in…

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

And how does that work with Firefox Send? Isn't the key somehow in the payload or the URL?

Re: Firefox Send: Free encrypted file transfer service

#500
post #460

Earlier quoted context omitted.

> On my Android device, I also have auto-update turned on, because my only option is to turn it on for every app or none of them. Open the Signal store page and click the dots in the top right of the screen and untick Automatic Updates.

Oh crud, thank you! I didn't know that, and there are a few apps that I definitely want to use this with. Why on earth isn't this part of the general settings?

If there’s a remote code execution vulnerability, normal users will update but you won’t. If you are voluntarily replacing automatic updates with manual processes, be sure to update Signal before using it each time, or a nation-state can tap a zero-day to infect all the experts who know better than to leave auto-update enabled.
Post reply on HN