OpenBSD version: Not relevant here...
Arch:            ?
NSFP:            Well...

« Read proposition 2 <> Read proposition 4 »

In the last proposition, we already took a shot at the issue of centralization. Centralization meaning that by now, a few large operators–Google, Amazon, Facebook, Cloudflare, Akamai–and to a lesser degree smaller ones like Hetzner or Digital Ocean are ‘the place’ where most content is hosted. Instead of putting a machine up in a local datacenter or with a small hoster (or, even–gasp–at home!), you just go to one of the big ones and go for it.

This, of course does not stop at machines themselves (which, to be honest, remains a niche anyway), but especially concerns stuff that can come in the flavor of ‘Software-as-a-Service’. The leading example here is most likely email; Instead of running your own mail infrastructure for your own domain (or using another small and local email provider), you usually just end up with gmail. Similary, especially for corporations, Office 365 and cloud hosted MS Exchange are the way to go.

Now, email makes a really good example, because we already figured out that running email infrastructure is hard. Doing so securely is even harder. Specifically, when it comes to exchange, the whole thing got so complex that it is ‘organizational clownery’ to run a self hosted exchange; You are just insanely more likely to forget an update or do something stupid with this beast of a software, that will ultimately spill your userdata all over the Internet…

Hence, our next proposition is:

Proposition 3

“There is a tension between privacy and security pitting decentralization vs. centralization.”

Following the introduction, this point confunds several aspects of centralization and cloudification. One part is that a major component of centralization and migrating to centralized cloud infrastructures is the reduction of capital expenses in terms of knowledge. While this means that organizations become dependent as they no longer retain the ability to run their own infrastructure, it also hints at the issue of security being ‘easier’ for centralized clouds.

In general, doing things properly and more secure becomes easier with more control. Hence, security in itself is already easier in a centralized ‘walled garden’—simply because there is more knowledge on what is normal to work with and detect anomalies—it is also easier when there are the resources there to run systems properly. A dedicated security team is simply unrealistic for smaller organizations, let alone small communities. Still, for hypergiants, we usually talk about security teams. In addition, building a system that tolerates human error and lessens the impact of security misconfigurations needs a certain scale.

This boils down to the rather common knowledge that operating systems gets easier if you can treat them like cattle. This, in turn, needs scale to be feasible. And that’s were centralization bites its tail.

Polemically speaking, this ultimately creates a choice between the devil and the deep blue sea: Either you allow a selected hypergiant to—technically be able to—read your emails and their ‘walled garden’ and ability to scale operations will keep your mails and you secure. Or you host your own system and might be less able to deliver your mails to others, or may even find them leaked due to a configuration mistake.

The choice is yours… if there is one at all.