Live data from Hacker News

Firefox Send: Private, Encrypted File Sharing

send.firefox.com

91–100 of 285 posts

Re: Firefox Send: Private, Encrypted File Sharing

#91
post #76

Earlier quoted context omitted.

So, three systems which all require a central service?

What about something like Tor. You can run a hidden service to get an onion address that any Tor client can access. Would that meet the requirements without being a "central" service?

That's exactly how Onionshare works. https://onionshare.org/

Re: Firefox Send: Private, Encrypted File Sharing

#92
post #59

Earlier quoted context omitted.

Thanks. I was just looking at the screenshots and didn't seen any hashes, but when I tried it out and copied to the clipboard I saw the form " https://send.firefox.com/download/xxxxx/#yyyyy" .

#yyyyy would be the encryption key. The webserver end never sees it. It can, however, easily be read via javascript, so mozilla needs to be trusted in any case.

> It can, however, easily be read via javascript, so mozilla needs to be trusted in any case.

Or you (and some friends from organizations like the EFF and FSF) can read the source code to see what it does, and even compile it yourself. If you do that, you only need to trust the compiler.

Re: Firefox Send: Private, Encrypted File Sharing

#93
I've just checked the code. It indeed deletes the file once a download has been completely consumed, so it can't really replace other file-sharing services. BUT I wonder how does it deal with race conditions ? My guess is that if many people start a download at the same time, they'll all be able to complete it before the file goes away. At least that's how I'd see it working with S3 or local storage.

You could abuse it by sending the same file many times in order to create lots of download links; but there's little to gain in bandwidth savings: you might as well run your own server. The only advantage I'd see is hiding your IP address, but then you could also run a tor hidden service. The other would be bandwidth amplification by synchronizing all the clients (for big files).

Re: Firefox Send: Private, Encrypted File Sharing

#94
post #72

Earlier quoted context omitted.

Both parties would have to be online for any p2p solution to work. And if they are online, there are plenty of ways to create a p2p link. It is complicated by things like NAT though. However, that is the less common case. In most cases, the receiver isn't going to be online. So you need an intermediate server, and that's how you end up with third party solutions.

Yeah, the "being online" detail seems like the problem. It would be best if the encrypted data were distributed (something like IPFS) but then why would peers host files that aren't for them.

You would need a seedbox to function as a cloud. Then when you send a file, send to seedbox simultaniously. This approach might also increase dl speed for the reciever.

Re: Firefox Send: Private, Encrypted File Sharing

#95
post #74
post #33

Earlier quoted context omitted.

The key is the hash, which isn't sent over the wire when loading a page. Now granted it's accessible via location.hash in the client, but one has to trust Mozilla not to do that.

> one has to trust Mozilla not to do that. Exactly. One has to trust Mozilla every time one visits the page . They could easily configure it to be malicious one time out of a million (say); what are the odds that they would be caught? Web-page-based crypto is fundamentally insecure, and Mozilla is committing an extremely grave error in encouraging users to trust it (as they also do with their Firefox Accounts). Secur…

> They could easily configure it to be malicious one time out of a million (say); what are the odds that they would be caught?

How could they do that easily? Their source code is public, and many third parties work on it and produce their own compiled versions - plus every security people tracking unexpected connections would catch it.

Re: Firefox Send: Private, Encrypted File Sharing

#96
post #90

It really is a shame that there still isn't a easy way (A person whose computer knowledge extends to using facebook), that I know of, of sending arbitrarily large files that isn't tethered to a specific cloud service and is also reliable (can tolerate connection dropping). It seems that bitorrent protocols are pretty close, but I don't think there is a seamless client that allows for "magical" point to point transact…

file.pizza is pretty solid, but uses webrtc so ive had failures when sending to some iOS users. Apparently webrtc is included in safari 11 though.

thanks for sharing this - very cool.

Re: Firefox Send: Private, Encrypted File Sharing

#98
post #93

I've just checked the code. It indeed deletes the file once a download has been completely consumed, so it can't really replace other file-sharing services. BUT I wonder how does it deal with race conditions ? My guess is that if many people start a download at the same time, they'll all be able to complete it before the file goes away. At least that's how I'd see it working with S3 or local storage. You could abuse…

So, I just tested, and the race-condition method does work. I was able to download a 200M the encrypted file three times, and they match. You could imagine a site operator with hundreds of users uploading a file once every hour or so and lots of synchronized users downloading it for each generated link.

Re: Firefox Send: Private, Encrypted File Sharing

#99

1 download limit looks really problematic to me. Some times download just do not start or get aborted and then everything need to be done again. Something like 3 downloads limit would make this more usable!

These services get extremely abused, they'd be 99% piracy within minutes. But 3 is reasonable

Re: Firefox Send: Private, Encrypted File Sharing

#100

1 download limit looks really problematic to me. Some times download just do not start or get aborted and then everything need to be done again. Something like 3 downloads limit would make this more usable!

No, this is only deleted if all the file has been transferred.
Post reply on HN