Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox Send: Free encrypted file transfer service

blog.mozilla.org

Post reply on HN
Print view View original

461–470 of 542 posts

Re: Firefox Send: Free encrypted file transfer service

#461

Post by cyphunk »

skrebbel wrote: post #368

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…

There are many use cases where compromise through code-interdiction after warrant is a perfectly acceptable risk. Also considering what it replaces may further increase the weight of privacy gain. Absolutism is definitely not the way to go, and looking at the state of the tech community (eg. npm, apt, pip, pacman, check that sha256 sum) we left the design-it-right-first a long time ago. A valid argument, though I wouldn't defend it to the death, is that we need to work slowly back toward more secure behaviors rather than chasing absolutely secure technologies. I think send.firefox is a step back from dropbox for some.

Re: Firefox Send: Free encrypted file transfer service

#462

Post by ksec »

I keep seeing comments about Search Revenue and keeping this free. It would be useful if Mozilla is getting more Firefox users out of it, but it likely won't be in any significant number.

So what happen once this get popular and waiting to be abused? Just like Mega. Who is going to continue and foot the bill?

Re: Firefox Send: Free encrypted file transfer service

#463

Post by cyphunk »

ksec wrote: post #462

I keep seeing comments about Search Revenue and keeping this free. It would be useful if Mozilla is getting more Firefox users out of it, but it likely won't be in any significant number. So what happen once this get popular and waiting to be abused? Just like Mega. Who is going to continue and foot the bill?

most abuse mitigated by their limits on the number of downloads allowed and how many days it can stay online. Currently at 7 days max and 100 downloads. If they see abuse they could reduce this further.

about revenue, there are so many valuable directions this can go. It could undercut competitors in ways they cannot sufficiently respond to. (google responding in kind would leave them less reason to not add encrypted storage for drive) By stabilizing this platform they can start to build new privacy-enhancing apps on top. Calendar, contacts, etc. With more dependency on the platform, they will find areas where more storage, longer retention, will be income generating.

privacy may be the only frontier that can displace google,apple,microsoft.

Re: Firefox Send: Free encrypted file transfer service

#464

Post by fastball »

skrebbel wrote: post #368

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…

Not relevant to me as all of my sites are entirely secured with SSL.

Re: Firefox Send: Free encrypted file transfer service

#466

Post by _rlx_ »

old-gregg wrote: post #438

If relevant Mozilla people are here: Send does not work if "Delete cookies and site data when Firefox closes" checkbox in FF preferences is checked. Even the page doesn't load [1]. It surely is a bug, because I am not closing Firefox. That checkbox is #1 reason I only use Firefox. [1] Developer console log output: "Failed to register/update a ServiceWorker for scope ‘ https://send.firefox.com/’ : Storage access is re…

This is a current Firefox restriction: https://bugzilla.mozilla.org/show_bug.cgi?id=1413615

Re: Firefox Send: Free encrypted file transfer service

#467

Post by RJIb8RBYxzAMX9u »

old-gregg wrote: post #438

If relevant Mozilla people are here: Send does not work if "Delete cookies and site data when Firefox closes" checkbox in FF preferences is checked. Even the page doesn't load [1]. It surely is a bug, because I am not closing Firefox. That checkbox is #1 reason I only use Firefox. [1] Developer console log output: "Failed to register/update a ServiceWorker for scope ‘ https://send.firefox.com/’ : Storage access is re…

You should be able to whitelist https://send.firefox.com/ with the "Manage Permissions..." button right next to that option.

I block _all_ cookies except for a small list of sites (like HN...).

Re: Firefox Send: Free encrypted file transfer service

#468

Post by brennebeck »

danShumway wrote: post #442
Rebelgecko wrote: post #386

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…

You can absolutely disable app and OS auto-updates on iOS.

Re: Firefox Send: Free encrypted file transfer service

#470

Post by coolspot »

NKCSS wrote: post #227
bjt2n3904 wrote: post #225

Earlier quoted context omitted.

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.

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

Yes, the mega.co.nz . End-to-end encrypted dropbox analog.
Post reply on HN