When I started using DropBox, I made an encrypted directory (using EncFS) for the stuff I cared about keeping private. This keeps the real-time sync element of DropBox, and avoids needing to reupload all of the encrypted files whenever one changes (although it does prevent incremental updates on individual files).

As an added bonus, these files are now encrypted on my machine as well.

The problem with your solution is that you have the closed source drop box app on your machine, and it could be reading anything, including the contents of those files before they are encrypted.

EncFS isn't supposed to be used against people who have access to the ciphertext at different times. Consider any file you've changed at least once as compromised.

EncFS, as you may be aware, only encrypts the contents of the files. The metadata (filename, size, timestamps) is available in clear, and a lot could be inferred from metadata if you don't want to trust others who could access the raw bits.

for a lot of them, it is not "the crown jewels" that they put there.

And for others, they'd rather entrust the crown jewels to GitHub than to their rotating cast of employees relying on server closets with unreliable power supplies and lackluster physical security.

ah, so to GitHub's "rotating cast of employees relying on server closets with unreliable power supplies and lackluster physical security".

much better! problem solved. not our problem anymore.

GitHub does it full-time though. Also, for businesses, it's a real financial concern that it's not their problem anymore. Having someone for you and your customers to sue is a good position to be in and what drives a lot of B2B decisions.

I think you would do well to read this before recommending github on that basis then:

https://help.github.com/articles/github-terms-of-service/

"You expressly understand and agree that GitHub shall not be liable for any direct, indirect, incidental, special, consequential or exemplary damages, including but not limited to, damages for loss of profits, goodwill, use, data or other intangible losses (even if GitHub has been advised of the possibility of such damages), resulting from: (i) the use or the inability to use the service; (ii) the cost of procurement of substitute goods and services resulting from any goods, data, information or services purchased or obtained or messages received or transactions entered into through or from the service; (iii) unauthorized access to or alteration of your transmissions or data; (iv) statements or conduct of any third-party on the service; (v) or any other matter relating to the service."

The Standard .zip Crypto (know as "ZipCrypto") is 100% trash. However, it is possible to use AES-256 encryption in 7zip (and even WinZip, not that anyone actually uses that anymore...)

> and even WinZip

Most big corps still use licensed WinZip, but we've had problems sending AES-encrypted-by-WinZip files to external MS Windows users because the built-in Windows Explorer dezipping algo can't handle AES.

The users double-click on the encrypted Zip file and receive some irrelevant error message ( 'could not create temp file' or thereabouts ).

So often one has to fall-back to the Zip encryption algo.

And even 7zip's AES implementation is hand-rolled, iirc, so I wouldn't exactly trust it with my life.

Neither of those are PDF encryption, only restrictions. PDF encryption is bad, yes, but it's not that bad.

> I am surprised at how many companies seem to keep their software in private repositories on github and bitbucket. That seems like a security hole, if software if the core of your business.

More secure than open source projects. Many of them use public repositories on GitHub and Bitbucket!