Live data from Hacker News

Firefox Send: Private, Encrypted File Sharing

send.firefox.com

231–240 of 285 posts

Re: Firefox Send: Private, Encrypted File Sharing

#231

Earlier quoted context omitted.

Inspect network traffic. Or more arduously, analyze the JS.

There are a lot of bytes moving around. I mean, I basically trust mozilla, but if they were a bad actor, it could easily be hidden steganographically.

And if your client is compromised then you're basically hosed in any secure application.

Re: Firefox Send: Private, Encrypted File Sharing

#232
post #79
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…

The way this gets solved in the real world is through contracts - they have a certain contract with you, and if they break it, they can get sued and lose a lot of money. This is one of the goals of the legal system - make it so we usually trust each other. There are no real long-term technical solutions to this problem. So if you want to make sure you're safe, read their EULA or equivalent.

Or you can design a system (like any number of crypto systems) that aren't vulnerable to these sorts of attacks. A compromised CDN could cause this problem, which now means that Mozilla would be liable for things that they don't administer. And resolving technical problems through the legal system never works well. If you can design something so users don't have to constantly trust you, then that's a much better solution.

Not to mention that Send likely doesn't have a warranty (like most software under a free software license).

Re: Firefox Send: Private, Encrypted File Sharing

#233
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. Browsers update themselves,

Not if you're using a Linux distribution's browser packages (we patch out the auto-update code because you should always update through the package manager). And distributions build their own binaries, making attacks against builders much harder.

While people might trust auto-updating applications, they really shouldn't. And there are better solutions for the updating problem.

Re: Firefox Send: Private, Encrypted File Sharing

#234
post #228

Earlier quoted context omitted.

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.

Reproducible builds effectively solve this problem, by making it possible to actually verify that you got the same binary (from the same source) as everyone else. Not to mention that if you're on Linux, distributions build Firefox themselves and so attacks against users need to be far larger in scale for 1/n attacks.

They're both important steps, but neither solves the problem. Most users don't verify the reproducibility of their builds and don't use Linux.

Re: Firefox Send: Private, Encrypted File Sharing

#235
post #211

Earlier quoted context omitted.

https://developer.mozilla.org/en-US/docs/Web/Security/Subres... can help verify everything loaded is what it's supposed to be. However you'd still need to verify that the set of things loaded is the set of things you expect, not just that the things are the things, and that requires having an out-of-band checklist or extension...

SRI alone is insufficient. Maybe a strict CSP policy that exclusively allows hash sources and forbids eval could serve as an indicator that the scripts executed on a page are immutable. Probably needs some further conditions to make it airtight.

If you don't trust Mozilla, how do you trust them not to strip the CSP header whenever they want to serve malicious javascript?

Re: Firefox Send: Private, Encrypted File Sharing

#236
post #228

Earlier quoted context omitted.

Reproducible builds effectively solve this problem, by making it possible to actually verify that you got the same binary (from the same source) as everyone else. Not to mention that if you're on Linux, distributions build Firefox themselves and so attacks against users need to be far larger in scale for 1/n attacks.

They're both important steps, but neither solves the problem. Most users don't verify the reproducibility of their builds and don't use Linux.

It solves the problem for users that use Linux. If other operating systems cared about making software distribution sane, they could also use package managers. It's a shame that they don't. As for verifying reproducibility, if you're using a package manager then this verification is quite trivial (and can be done automatically).

Solving the problem for proprietary operating systems that intentionally have horrific systems of managing the software on said operating system is harder due to an artificial, self-inflicted handicap. "Just" switching people to Linux is probably easier (hey, Google managed to get people to run Gentoo after all).

Re: Firefox Send: Private, Encrypted File Sharing

#237
post #39

Earlier quoted context omitted.

Those services are for the initial peer discovery and SDP exchange, which can be done by other means (using any other side-channel). Ongoing work is happening, for example by the webtorrent folks, to remove this constraint.

Yeah, it's initial peer discovery and connection setup (if behind NAT) I'm talking about. Once you've found the other PC and got a connection set up then all is well ;-) Do these services also act as connectors in case of double NAT?

STUN allows all sorts of hole-punching for cases where both peers are behind NATs. For cases where the hole-punching doesn't work (a user behind two NATs might be one case), you can use TURN which is a dumb UDP or TCP relay.

Re: Firefox Send: Private, Encrypted File Sharing

#238
post #209
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…

Because browsers have evolved beyond applications to serve up static web pages, and convenient features like this are a selling point. Google has created an entire "OS" ecosystem built on a port of their web browser, and they've been pushing people to use it for years. I think I'll give Firefox a pass at adding some super neat and useful features from time to time.

This isn't a browser feature, it's a webapp

Re: Firefox Send: Private, Encrypted File Sharing

#240
post #236

Earlier quoted context omitted.

They're both important steps, but neither solves the problem. Most users don't verify the reproducibility of their builds and don't use Linux.

It solves the problem for users that use Linux. If other operating systems cared about making software distribution sane, they could also use package managers. It's a shame that they don't. As for verifying reproducibility, if you're using a package manager then this verification is quite trivial (and can be done automatically). Solving the problem for proprietary operating systems that intentionally have horrific sy…

To repeat myself, for real world impact the only metric that counts is how many actual people benefited, not how many people benefit in ideal circumstances.

If your solution is to switch the entire world to Linux then you may want to figure out how to do that. Many have tried and failed before. Good luck.

Post reply on HN