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.
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). Security is important, and snake-oil solutions are worse than worthless.
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).
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.
As a Windows user I mostly use 7-zip for this purpose, or the encryption plugin in Notepad++ for text.
While I agree that doing it manually is the only reliable way if you're going to send it over an insecure channel, if the channel is secure then it's much easier for an end-user to just send it in the app.
You just need to trust. So what's wrong in trusting Mozilla, if you can easily trust your encryption/decryption software?
The reason for it, is that if you trust the site to be secure it might be devastating once security is compromised, but with no security you're typically more careful.
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 free to suggest it, of course.
The functionality should be built into Firefox, so that users can verify source code & protocols once and know that they are secure thereafter.
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.
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).
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.
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 pinning, the browser checks that this is true, and if finding a new deployment has occurred, the browser will refuse to accept it without deliberate consent and action from the user (something on par with invalid cert screen).
This means that for a subset of services (those whose business logic can run primarily on the client side), the users need not trust the server, they need only to trust the app, which can be audited.
When deploying updated resources, services SHOULD make the update well-advertised and accompany it with some notice out of band (such as a post about the new "release", its changelog, and a link to the repo), so the new deployment may be audited.
When new deployments occur, clients SHOULD allow the user to opt for continuing to using the pinned resources, and services SHOULD be implemented in such a way that this is handled gracefully. This gives the user continuity of access while the user (or their org) is carrying out the audit process.
Areas where this would be useful:
- HIPAA compliance
- Web crypto that isn't fundamentally broken
- Stronger guarantees for non-local resources used in Web Extensions—in fact, the entire extension update mechanism could probably be more or less rebased on top of the resource pinning policy
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 TLS handshake or something like that. Caches could even perform downgrade non-attacks.
Which is still a bad idea to trust, so I'd say that it is a logical extrapolation.
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.
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.
For most people your advice is quite plainly wrong. Most people should have everything on autoupdate.
Or you can auto-update to a version which is malicious. Then you are screwed. But your previous version you downloaded to start with might have contained the threat to start with. So just saying don't auto-update does not really protect you from malicious versions. Auto-updating does mean that you get updated security fixes making you less vulnerable.
The original non-updated version can be malicious even with a vendor you think you should be able to trust because it is a popular product used by many others:
https://www.piriform.com/news/blog/2017/9/18/security-notifi...
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.
Using in-web-page crypto gives users a false sense of security. This is, I believe, a very real problem.
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).
No, because I use the Debian Firefox, which means that I'm trusting the Debian Mozilla team. I feel much better about that than about directly trusting Mozilla themselves.
I don't trust auto-updates.
That's reasonably for a technically savvy user, but the vast majority of users do not use Debian. They use Windows or OSX and rely on trusted corporations like Apple, MSFT, Google, and Mozilla to keep their systems patched.
About the auto-updates. CCleaner recently had an incident where their version .33 something had a backdoor injected by some 3rd party. If you downloaded version 34 you were safe. If you loaded 32 and configured it auto-update you got the malicious update. But that didn't affect the auto-update setting as far as I know, so if you had it on you would in about 2 weeks time have gotten an automatically fixed clean version.
Point: The worst situation was if you did not have auto-updates on and downloaded v. 33. Then you were stuck with that until somebody told you you had malice on your machine.
You're damned if you do and damned if you don't.
https://www.piriform.com/news/blog/2017/9/18/security-notifi...
How could they do that easily? Their source code is public, and many third parties work on it and produce their own compiled versions - plus every security people tracking unexpected connections would catch it.
This is where IPFS could be useful. It's content addressed, so the address guarantees that you're getting the same, unmodified, content
Bear in mind they also make the web browser.
It's wildly different from a JS file that's loaded every time you visit the website.
Unless Firefox provides fully reproducible builds on your platform from an open source compiler, you have no guarantee that the binary you have is built from the public source code. You have to trust Mozilla.
Without reproducible builds, compiling the source yourself would be the way to go.
Anyway, I agree that it should be clear that this file sharing service, while convenient, essentially requires you to trust Mozilla with your data. The claim "Mozilla does not have the ability to access the content of your encrypted file..." is fragile.
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.
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 not trustworthy.
Info: http://www.draketo.de/light/english/freenet/effortless-passw...
Install: https://freenetproject.org
It can, however, easily be read via javascript, so mozilla needs to be trusted in any case.
Or you (and some friends from organizations like the EFF and FSF) can read the source code to see what it does, and even compile it yourself. If you do that, you only need to trust the compiler.
If you don’t trust Mozilla or you are sharing information that a nation-state attacker would coerce Mozilla into revealing, then you’re already set up to encrypt the file first yourself - at which point you can send it with any service, include Firefox Send.