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

Firefox Send: Private, Encrypted File Sharing

send.firefox.com

Post reply on HN
Print view View original

171–180 of 285 posts

Re: Firefox Send: Private, Encrypted File Sharing

#171

Post by zeveb »

giaour wrote: post #88
zeveb wrote: post #74

Earlier quoted context omitted.

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

I don’t think the second paragraph is a logical extrapolation of the first. If this is using the WebCrypto API (which it appears to be doing), then trusting this browser-based solution isn’t fundamentally different from trusting an installed application that can update itself.

Using WebCrypto doesn't defend against the insecurity: their JavaScript code can send a copy of the file anywhere it likes. Mozilla can, if it wishes or if it is compelled to, deliver malicious JavaScript which does exactly that to a single targetted IP address, or just every once in awhile in order to find potentially interesting files.

Using in-web-page crypto gives users a false sense of security. This is, I believe, a very real problem.

Re: Firefox Send: Private, Encrypted File Sharing

#172

Post by soapdog »

superkuh wrote: post #147
programmarchy wrote: post #61

Earlier quoted context omitted.

Not sure how true that is anymore. They seem to by trying hard to squander their reputation. First their MITI officially signaled they now consider themselves a political force, then the whole Cliqz debacle following shortly after showed their willingness to sacrifice their principles.

Don't forget their switch to a walled garden for extensions in order to protect users from themselves.

That is FUD and also a lie. You can still distribute your extensions on whatever site you want, you just need to sign them on AMO.

The workflow is:

1 - Build webextension 2 - Upload to AMO 3 - Choose "distribute on AMO" or "sign and distribute on your site"

Re: Firefox Send: Private, Encrypted File Sharing

#174

Post by Aissen »

AgentME wrote: post #164
ge0rg wrote: post #116

Earlier quoted context omitted.

The sender could open a download connection and stall it as far as possible (maybe keep the download rate shaped to some bytes/second, to prevent an inactivity timeout). That would open a large time window for further downloads.

I assume the file would be deleted as soon as any client finishes downloading. (If the files are backed by regular files on a unix-like system, then the existing open handles to the file will keep working, allowing currently-connected clients to finish downloading, but preventing any new clients from starting the download.)

Indeed, I tested this too, but forgot to mention. That's how it works.

Re: Firefox Send: Private, Encrypted File Sharing

#175

Post by hollander »

lucb1e wrote: post #173

Let me guess, with free Pocket® integration? Mozilla blew it for me recently in so many ways, I am taking them about as seriously as I would Facebook right now.

How can you compare the Pocket thing with Facebook? The good kid messed up this time. And you can simply ignore it, don't have to use it. Yes like you can decide not to use Facebook, but then all your friends and family use it, or use Instagram of Whatsapp and force you to use it. That includes uploading your complete contact list two or three times.

Do you have to use Firefox because your family uses it? I don't think so.

How do those two compare?

Re: Firefox Send: Private, Encrypted File Sharing

#176

Post by rmc »

zeveb wrote: post #74
KwanEsq wrote: 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…

> Exactly. One has to trust Mozilla every time one visits the page

This is where IPFS could be useful. It's content addressed, so the address guarantees that you're getting the same, unmodified, content

Re: Firefox Send: Private, Encrypted File Sharing

#177

Post by eugeniub »

the8472 wrote: post #162
Vinnl wrote: post #138

Earlier quoted context omitted.

> one has to trust Mozilla not to do that Well, the advantage of the client is that you can inspect the source, so you can verify that it doesn't actually access location.hash.

But software loaded from webpages are not immutable. They could be manipulated at any given time. So even if someone audits the code you still cannot trust it because all the audit would show is that the specific downloaded version which the auditor saw was non-malicious. As long as websites have no fingerprints that encompasses all loaded resources and can't be pinned to that fingerpint crypto in the webbrowser is n…

In that case, wouldn't an alternative like OnionShare always be safer? The code is open source, it's a desktop app, and the source code is obviously immutable on your computer.

Re: Firefox Send: Private, Encrypted File Sharing

#178

Post by ukyrgf »

mapgrep wrote: post #107
microtonal wrote: post #67

Earlier quoted context omitted.

Resilio Sync (formerly Bittorrent Sync) pretty much offers that. They use relays in case both peers cannot pierce NAT, but the relays only see ciphertext. They also have apps for Android and iOS, making transfers to mobile devices also possible. Since it is closed-source software, it's up to you to decide whether you trust the software. SyncThing is a free software alternative, but I wouldn't say that it is usable (y…

I used BitTorrent Sync for a couple of years and loved it. Has it evolved much under the Resilio banner?

I keep mine updated to the latest version and still love it. The 'Ignore' file that is in the top-level of each share alone is worth the admission (similar to .gitignore). Dropbox/OneDrive/etc. all lose their damn minds if you try to sync a folder with 'node_modules' or 'vendor' to the share.

Re: Firefox Send: Private, Encrypted File Sharing

#179

Post by SubiculumCode »

ElijahLynn wrote: post #102

One thing that could be improved with this is to have an option for a human readable/typeable link. I wanted to quickly transfer a file from my desktop to my phone. Used Send and realized I didn't want to type that cryptographic URL. I ran the Send link through Typer.in (specializing in hand-typed urls) and it worked as I initially expected. However, it would be nice if Send had this functionality by default.

Yes. My workflow is to get the link from Firefox Send (which I love btw), email the link, open email on other device, click link.

There are I suppose two use-cases. 1) To send to yourself. 2) To send to others. The second use-case, is fine under the current workflow, but the first use-case the workflow is annoying.

If using Firefox Sync, perhaps the link could be synced over, maybe?

Re: Firefox Send: Private, Encrypted File Sharing

#180

Post by idle_zealot »

carussell wrote: post #149
Yoric wrote: post #80

Earlier quoted context omitted.

Send is meant to be an improvement on Dropbox & co for a specific use case. Is it perfect? No, it isn't. But it is still a considerable improvement. If you have a better solution in mind for the average user crowd, feel free to suggest it, of course.

Spec out and implement resource pinning, already. Like RFC 8246, but authored more with the user's interests in mind, rather than the service's. As a show of nothing-up-the-sleeve, a service asserts that it's in a stable state and will continue to serve exact copies of the resources as they exist now—that they will not change out from beneath the client in subsequent requests. When a user chooses to use resource pinn…

This sounds a lot like Beaker [1], a browser based off on Dat [2]. It allows creation of shared resources (web pages) with immutable version tracking, among other things.

1: https://beakerbrowser.com/ 2: https://datproject.org/

Post reply on HN