Live data from Hacker News

Firefox Send: Private, Encrypted File Sharing

send.firefox.com

191–200 of 285 posts

Re: Firefox Send: Private, Encrypted File Sharing

#191
post #88

Earlier quoted context omitted.

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.

> trusting this browser-based solution isn’t fundamentally different from trusting an installed application that can update itself. Which is still a bad idea to trust, so I'd say that it is a logical extrapolation.

We trust applications like that all the time. Browsers update themselves, and we trust them to secure our communication with banks, governments, health providers, etc. Most browsers now also store passwords in an encrypted secret repository. If you're on Windows or OSX, your OS is also constantly updating itself with closed-source binary blobs.

I mean, sure, you can never use an auto-updating application again and always manually review system updates before installing them. But realistically, I don't see anyone besides Richard Stellman adopting that lifestyle.

Re: Firefox Send: Private, Encrypted File Sharing

#192
post #171
post #88

Earlier quoted context omitted.

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

It's true; you're trusting Mozilla to deliver secure code. You'd be placing a similar amount of trust in Mozilla by using Firefox, since browsers automatically update themselves these days.

What WebCrypto guarantees is that it is truly Mozilla's code that you're trusting, since the WebCrypto APIs are only available in a secure context (HTTPS or localhost).

Re: Firefox Send: Private, Encrypted File Sharing

#193
Why do the Mozilla people keep doing this sort of thing? Aren't they supposed to be making a good browser?

I remember them telling me they are now going back to their core competences. I think it was after Firefox OS failed.

Not trying to piss on anyone's parade here, just wondering how this kind of thing keeps happening. I was wondering the same thing when Mozilla added Pocket and now Cliqz to Firefox.

What is the rationale here? Do they have leftover money they need to spend before January 1st or something?

Re: Firefox Send: Private, Encrypted File Sharing

#194
post #193

Why do the Mozilla people keep doing this sort of thing? Aren't they supposed to be making a good browser? I remember them telling me they are now going back to their core competences. I think it was after Firefox OS failed. Not trying to piss on anyone's parade here, just wondering how this kind of thing keeps happening. I was wondering the same thing when Mozilla added Pocket and now Cliqz to Firefox. What is the r…

The engineers on the product are listed as two interns. There are eight people on it total, and I bet most of them aren't working on it full time. This hardly seems like a massive waste of resources.

https://testpilot.firefox.com/experiments/send

Re: Firefox Send: Private, Encrypted File Sharing

#195
post #193

Why do the Mozilla people keep doing this sort of thing? Aren't they supposed to be making a good browser? I remember them telling me they are now going back to their core competences. I think it was after Firefox OS failed. Not trying to piss on anyone's parade here, just wondering how this kind of thing keeps happening. I was wondering the same thing when Mozilla added Pocket and now Cliqz to Firefox. What is the r…

I have to agree with your concerns. All they have to do is make a good web browser and they have the funds to do that. It concerns me that they are wasting time, energy, and money chasing rabbits.

Re: Firefox Send: Private, Encrypted File Sharing

#196
post #193

Why do the Mozilla people keep doing this sort of thing? Aren't they supposed to be making a good browser? I remember them telling me they are now going back to their core competences. I think it was after Firefox OS failed. Not trying to piss on anyone's parade here, just wondering how this kind of thing keeps happening. I was wondering the same thing when Mozilla added Pocket and now Cliqz to Firefox. What is the r…

I think this is for free advertisment.

Re: Firefox Send: Private, Encrypted File Sharing

#197
post #191

Earlier quoted context omitted.

> trusting this browser-based solution isn’t fundamentally different from trusting an installed application that can update itself. Which is still a bad idea to trust, so I'd say that it is a logical extrapolation.

We trust applications like that all the time . Browsers update themselves, and we trust them to secure our communication with banks, governments, health providers, etc. Most browsers now also store passwords in an encrypted secret repository. If you're on Windows or OSX, your OS is also constantly updating itself with closed-source binary blobs. I mean, sure, you can never use an auto-updating application again and a…

> We trust applications like that all the time

Sure, nobody ever said otherwise. But that doesn't mean it's a good idea.

The software I use is open-source, so I can see what I'm running, and what updates I get. I also don't use any auto-updates. The web is inherently different in that I can't really guarantee that the code I get is going to be the same code that you are getting.

Re: Firefox Send: Private, Encrypted File Sharing

#198
post #146
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.

> But it is still a considerable improvement. When it's secure, it's an improvement; if Mozilla, a Mozilla employee or a government which can compel Mozilla employees chooses to make it insecure, then it's worse than insecure. At least with something like Dropbox users (should) know that they are insecure and should not transmit sensitive files. > If you have a better solution in mind for the average user crowd, feel…

And re-check them after every update?

And trust that Mozilla won't randomly distribute a backdoor to 1/n of users?

The means you're suggesting aren't possible to implement for most people today. If you care about real-world impact I would recommend thinking of other strategies.

Re: Firefox Send: Private, Encrypted File Sharing

#199
post #163

Earlier quoted context omitted.

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

Power users can use unsigned add-ons in Dev Edition. Regular users would be exploited by any middle ground solution in the main release. It's unfortunate the web is a dangerous place for the average user.

Asking people to use beta as a main driver is part of the reason why people think,

>They seem to by trying hard to squander their reputation.

The other part of it is Mozilla building the browser for the lowest common denominator at the price of user control.

Re: Firefox Send: Private, Encrypted File Sharing

#200

Earlier quoted context omitted.

This would also have the added bonus that one could reload such pinned resources from anywhere once you got the pin. Even without TLS setup or having to trust certificate chains. Caching proxies would suddenly become viable again because only the first download has to through HTTPS while "I don't have this in the local cache anymore, can you serve me this content" requests could go through sidechannels or outside the…

How many pins would you expect a browser instance to have? I feel like most of the time the pinned content could fit in the browser cache and make this variety of proxy-side caching pointless.

Immutable content is a prerequisite for pins. The caching benefits mostly fall out of the immutability, not the pinning. So as long as the hypothetical standard would allow one to be used without the other additional uses could fall out of that stack.
Post reply on HN