Live data from Hacker News

Firefox Send: Free encrypted file transfer service

blog.mozilla.org

441–450 of 542 posts

Re: Firefox Send: Free encrypted file transfer service

#441

Earlier quoted context omitted.

To my knowledge, the link is only invalidated if the person actually downloads the file. Simply viewing the link does not invalidate it. I can recall a couple of times emailing a Send link to my brother, then checking it in the morning to see if he had grabbed him or not. It was still viewable, so I deduced that he hadn't grabbed it yet, sent him a follow-up e-mail ("Hey you lazy bastard, grab the damn file before it…

> To my knowledge, the link is only invalidated if the person actually downloads the file. I've used one-time-link services sometimes, and posting the link to Slack causes Slack to make an HTTP fetch looking for metadata, which then invalidates the link.

The easy solution is for the link to lead to an interstitial that shows "do you want to view the content? It will be the only time you can do so.", and make the underlying HTTP resource unpredictable (e.g. different ID to the link) so that it cannot be directly addressed.

It's a very common and easy to anticipate issue, I'm surprised that there are any one-time-link services left that suffer from it.

Re: Firefox Send: Free encrypted file transfer service

#442

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…

Some of those points are relevant and some aren't. For logging in to a website, "just use SSL/TLS instead" makes sense, but not for this use case. There's better options nowadays for doing crypto in the browser, but I wouldn't be surprised if they were at least theoretically vulnerable to side channel attacks from JS running in another tab. The main thing is that unless you're paying really really close attention to…

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, because my only option is to turn it on for every app or none of them. So there's nothing to prevent Signal from updating itself and changing the crypto. If I were on an iOS device, I wouldn't even have that option -- to the best of my knowledge you can not turn off app auto-updates on an iPhone, but maybe someone can correct me if I'm wrong. In any case, it doesn't matter that Signal is updated "rarely". An attacker only needs to install one back door, they don't need to update it a hundred times.

So for an extremely typical user like me, who has been taught for as long as I can remember that the most secure thing you can do on an OS is install updates as they come in when they come in, doesn't Signal have the exact same problems as Mozilla? If someone compromises Signal's servers, can't they add a side-channel just as easily?

In theory, I could disable auto-updates and only update Signal when I looked at the source code, just like in theory I could examine the JS that I'm executing every time I connect to a site. But in practice, I don't.

When I read tptacek's rant nowadays, the immediate thing I can think is, "The web is malleable? Literally every single computing environment and device I own is malleable." It feels like if I were to take tptacek's advice to its logical conclusion, I would just conclude that ETE encryption in general is dead.

Re: Firefox Send: Free encrypted file transfer service

#443
post #432

Earlier quoted context omitted.

The encrypted file is stored in the cloud. The recipient downloads it from there and decrypts it. P2P would be much better, but this isn't that.

Wasn't it initially P2P and based on the WebRTC protocol?

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.

Re: Firefox Send: Free encrypted file transfer service

#444

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.

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

Re: Firefox Send: Free encrypted file transfer service

#445

Earlier quoted context omitted.

To my knowledge, the link is only invalidated if the person actually downloads the file. Simply viewing the link does not invalidate it. I can recall a couple of times emailing a Send link to my brother, then checking it in the morning to see if he had grabbed him or not. It was still viewable, so I deduced that he hadn't grabbed it yet, sent him a follow-up e-mail ("Hey you lazy bastard, grab the damn file before it…

> To my knowledge, the link is only invalidated if the person actually downloads the file. I've used one-time-link services sometimes, and posting the link to Slack causes Slack to make an HTTP fetch looking for metadata, which then invalidates the link.

Which is why you put a trivial password on the file, which isn't included as part of the link.

Then, any automated system which sees the link cannot accidentally cause the file to be "downloaded" which would cause the link to be invalidated. They can see the link itself, but they don't have the password, therefore they can't download the content to scan it.

I have used onetimesecret.com a number of times in this way.

Re: Firefox Send: Free encrypted file transfer service

#446

Earlier quoted context omitted.

Some of those points are relevant and some aren't. For logging in to a website, "just use SSL/TLS instead" makes sense, but not for this use case. There's better options nowadays for doing crypto in the browser, but I wouldn't be surprised if they were at least theoretically vulnerable to side channel attacks from JS running in another tab. The main thing is that unless you're paying really really close attention to…

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 dark side, however, you are screwed. There's nothing stopping your Signal app from bundling all your plaintext messages once you've entered your password and sending them off to China, save maybe a firewall you have in place. Google or Apple might stop such an update during their reviews, but I wouldn't bet on it.

Re: Firefox Send: Free encrypted file transfer service

#447

In one of their videos, the URL is www.send.firefox.com - the others drop the www - is this intentional, a mistake? Why would someone use www before a sub domain like that?

Because some people just don't recognize a Web address if it does not start with www. I see that all the time with our subdomains.

Re: Firefox Send: Free encrypted file transfer service

#448

Why does it have upload limits at all? Your client encrypts it, the data is sent over your internet connection to someone else's, their client decrypts it. Why would the data pass through Mozilla's servers?

Wouldn't you need both clients to be online at the same time to do that?

Yes, but most people are online 24/7 anyway, and that number approaches 100 percent for "two people who need to move a file from one to the other right now". Hosted upload file sharing services are a dime a dozen now. How is this better than slapping something on Dropbox or Mega to send someone?

Re: Firefox Send: Free encrypted file transfer service

#449
post #435

Open source peer-to-peer solution in the browser using WebRTC: https://file.pizza/

Wow that's really neat. Downside is it only works while the page stays open on the uploader's machine, while send.firefox.org uploads the file for a limited time to a central server so you can close the tab before the recipient downloads it.

Re: Firefox Send: Free encrypted file transfer service

#450
post #19

Neat! How do they handle abuse though? Like, people using it to host, say, pirated TV shows? Maybe a max download limit that makes it impractical for that use case?

2.5GB file limit is a bit small for good quality TV shows (and especially movies).

winrar and 7-zip can break up files into chunks of any size you specify.
Post reply on HN