Security must, by its very nature, prevent you from doing insecure things. This manifests as an obstacle to users, so they end up choosing the insecure route (writing down passwords etc etc).
Decentralised systems tend to lose to centralised ones because there's no money locus for advertising, development or curation.
It's not totally doomed; the popularity of Snapchat suggests there is demand for services that don't make everything saved and visible forever.
> Security must, by its very nature, prevent you from doing insecure things.
Disagree. In practice security as a guarantee must do so (e.g. the OpenBSD opinion), but security as a gradient need not (e.g. the web opinion).
If Browser X defaults to the TLS version of a page regardless of what the user requested, but gracefully falls back to the unsecured page without action but with a yellow banner across the URL, does this not increase user security without preventing them from doing insecure things?
The objective is not perfect security but rather increased herd security.
If the minimum security threshold (specifically with respect to encryption) is raised, then we all benefit. Decentralized vs centralized and the feasibility of each are an argument for farther down the road (as long as we don't lock ourselves into one or the other). There's much lower-hanging fruit!
This conflates "security" in the sense of requirements and "security" in the sense of technology. Users already have security requirements; security technology ought to be enabling them.
For instance, encryption lets me back up files to cloud services that I don't trust. Without the technology of encryption, my security requirement would have me not backing up files at all. I wouldn't just decide "oh, whatever" and back up unencrypted files.
SSL lets me access my bank safely (enough) from a coffeeshop wifi connection. Without SSL, I'd walk into a physical bank or ATM. I wouldn't decide "probably nobody's trying to hack me" and connect to my bank in cleartext.
Bad technologies manifest as an obstacle to users, yes. But passwords are pretty much the epitome of bad technology in the security field. (It's a legitimately hard problem, so I'm not claiming that people should be doing other things, but we also shouldn't let ourselves think that passwords are good.)
SSL, for all that the implementation sucked and still sucks, enabled the e-commerce revolution of the mid-'90s.
>encryption lets me back up files to cloud services that I don't trust
Any recommendation on an accessible, audited, client for Windows users? Running some company's random binary, especially when you log in and they can identify you, implies a fair amount of trust. Tarsnap's the best one I know of and it's not really accessible for most users.
Not sure what you mean by "accessible", so I'll go from easiest to least easy:
Truecrypt has been audited, works on Windows, and appears to offer an encrypted file container that you can attach to a Windows drive letter.
What you could do is create the container, let DropBox (or whatever) sync the file containing the container, then perform your file operations within the container.
Depending on your needs, there's also GPG4Win, which comes recommended by the GPG project maintainers. AFAIK, GPG hasn't been subject to an extensive audit, but it is venerable, open source, and developed in the open. (Yeah, so was OpenSSL, I know. ;) )
I don't know that there's a way to make a transparently encrypted container with GPG as there is in TrueCrypt, so I suspect that you'd have to:
* Copy your encrypted files
* Decrypt them
* Edit them
* Reencrypt them
* Copy them to the sync directory.
Sounds like a bit of work to me.
If you were on Linux, you could probably use dm-crypt on a loop device, and just sync the underlying encrypted file, but -again-, I have no idea how much auditing has been done on the underlying code (and this fails your "for Windows users" requirement).
Oh, BTW, I replied to our Erlang thread. If you're interested in taking a second look at Erlang, I link to a few things in the comment that might be interesting to you.
Dropbox isn't audited. They have a poor track record for security (lying about internal access then trying to downplay). So even if you encrypt with truecrypt, you're running the Dropbox binary for uploading, and it can do anything - in short, you're trusting them.
I've not found an open source tool that does block level backups with diff/compression support. Getting the client experience right is hard and not a whole lot of fun, so I'm guessing there's little incentive for companies to open source that valuable part.
Edit: I would ask "How hard could it be to solve 90% of the problem?", but various BigCos have had spectacular failures in recent memory, so I guess the problem is pretty damn hard.
I wonder how terrible using git as the backbone for one's sync software would be.
I had heard about git-annex before, but never had looked into it. This sounds pretty neat! I wonder what its horrifying data-eating failure modes are! :D
Passwords could easily be both strong and memorable if we got rid of ridiculous anti-secure constraints like "password must be at most length X", "password cannot contain a space", etc.
I've heard somewhere of military organizations having people trained to go in an office and search the places people "hide" their password sticky-notes...
You're referring to the limitations imposed by security as a spectrum versus usability (more secure to more usable). I don't think many people consider a lack of privacy to be a "feature" in the usability sense -- that's typically desirable by 3rd parties, not the users.
I do agree with your profit motive. I consider that a potential opportunity rather than a problem.
What we see in practice with all extant implementations of blockchains is increasing centralisation. Because computing hashes is the sort of computation whose efficiency per watt greatly increases with more and more specialised hardware. Thus the Bitcoin situation, where the promise of everyone being able to mine a few coins has become a small number of Chinese mining pools; altcoins do no better.
Most altcoins are Proof of Stake, where mining via computing hashes doesn't take place. "Blockchains" isn't limited to Proof of Work, you can even get non-PoS/PoW blockchains such as Hyperledger.
Decentralised systems tend to lose to centralised ones because there's no money locus for advertising, development or curation.
It's not totally doomed; the popularity of Snapchat suggests there is demand for services that don't make everything saved and visible forever.