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.
Firefox Send: Private, Encrypted File Sharing
231–240 of 285 posts
Re: Firefox Send: Private, Encrypted File Sharing
#232Earlier 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.
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
#233Earlier 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…
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
#234Earlier 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.
Re: Firefox Send: Private, Encrypted File Sharing
#235Earlier 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.
Re: Firefox Send: Private, Encrypted File Sharing
#236Earlier 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.
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
#237Earlier 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?
Re: Firefox Send: Private, Encrypted File Sharing
#238Why 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.
Re: Firefox Send: Private, Encrypted File Sharing
#239Re: Firefox Send: Private, Encrypted File Sharing
#240Earlier 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…
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.