| I work at one of these "larger firms". You might be surprised at how much even basic things like security response or considerations are valued at "larger firms", or inconsistently applied (in part because of their size), or don't accord with the users' interests. It's typical for "larger firms" for example to have a vulnerability evaluation process that pretty much boils down to "can we avoid responding to this vulnerability at all?" and if there's any way to avoid it, they do--because even patching will cost money. Across a big service with a variety of components? Potentially even "real" money. And the mistakes these companies make, when they make them, are often huge (like Sony storing plaintext passwords), even when they're elementary mistakes. Put something on encrypted storage and served by a reasonably-configured OpenBSD server? That's probably quite a bit safer from compromise, when considering all threats, than Flickr or Google Drive or whatever. What it's not safer from, probably, are corruptions and loss (like from bad hardware, mistaken deletion, key loss, and so forth). So I use both services and self-hosted things--but it's certainly the case for my "sensitive files" that they don't go within sniffing distance of a "larger firm" cloud service but are stored and backed up with my own encryption, using tools like OpenBSD and the utilities stemming from it. As for whether it's "tech independence", perhaps it's more about being able to make the choice for yourself about where that line is drawn, rather than being forced to accept serfdom because you don't know any better. If someone takes this as a first step, moving cloud providers could be their second, or DNS registrars; or maybe revision 2 of the script (or someone else taking inspiration from it) can describe how to host your own nameservers and MTA. But there has to be some place to start, and an opinionated cookbook is not a bad one. |