Sorry about that :) But you get the credit for spotting the problem! Thanks for that!

I don't think so, does it sound weird? Not a native speaker, so maybe it does :)

Thanks, I will go and double check, I am sure there are more typos!

I honestly didn't think at all about the use of checkmarks/crosses and the fact that it can be misinterpreted, I will add a disclaimer.

A bigger issue IMO is how you describe email encryption in transit as a matter of fact, but according to Google transparency report[1] there are still domains that do not support in transit encryption, and, what’s worse, when you send an email you can’t tell if it will be encrypted or not.

you are right. The reason why I took that for granted is because I assumed the scenario in which people use the "mainstream" providers. I was looking at data and I think Outlook and Gmail alone make up more than 50% of the market share. I made an assumption which I considered fair, as 99%+ of the users do not need to worry about this at all. However, this is interesting data and I might add a note about it as well, so thanks!

Thanks a lot! Hopefully at least someone finds it helpful!

Also hypervisors get escape vulnerabilities every now and then. I would say that in a realistic scale of difficulty of escape, a good container (doesn't matter if using Docker or something else) is a good security boundary.

If this is not the case, I wonder what your scale extremes are.

A good container has very little attack surface, since it can have almost no code or tools available, a read-only fs, no user privileges or capabilities whatsoever and possibly even a syscall filter. Sure, the kernel is the same but then the only alternative is to split that per application VMs-like) and you move the problem to hypervisors.

In the context of this asked question, I think the gains from reducing the attack surface are completely outweighed from the loss in functionality and waste of resources.

Completely agree, which is why I do the same.

Additional bonus: proxies that interact with the docker API directly (I think also caddy can do it) save you from exposing the services on any port at all (only in the docker network). So it's way less likely to expose a port with a service by mistake and no need for arbitrary and unique localhost ports.

Yep, I like bunny in fact. It didn't have all the features I needed back then, but it's a very good product, I heard very good things.

I also agree about the pricing. I ended up not using desec.io, but if I did, I would have probably set a 1-2 Euros recurring donation, as I feel that's a totally acceptable price.

As for why people use GoDaddy well... I feel personally attacked as that's exactly how I ended up there, when I didn't know better.

That's a very interesting gotcha. They don't seem to support address ranges either. Unless once you add the whitelist the requests still work from any address (their documentation is ambiguous). This is even more confusing.

Not OP, but they are comparable efforts, especially since it's a relatively infrequent activity. You can rent dedicated boxes with off-the-sheld hardware almost instantly, if you don't want to deal with the hardware procurement, and often you can do that via APIs as well. And of course both options are much, much, much cheaper than the Cloud solution.

For sure speed in general is something Cloud provide. I would say it's a very bad metric though in this context.

cognito auth

But then at that point you are already vendor-locked, right? At that point, running on bare ec2 instances and taking more control in your hands (vs using even more AWS-specific services) is going to help very little, when your whole user management is now tied to a specific provider.

This post must be fun with that one... 150+ instances in various contexts of "cloud".

I have seen this post and decided to respond via a separate blog post. https://loudwhisper.me/blog/containers-isolation/

The short answer is that yes, they do. And yes lowering the privileges of the user helps in avoiding container escapes, which basically makes the other advantages for containers valid. You can, however, achieve the same using (relatively obscure, imho) systemd settings, running with flatpak etc. Namespaces + Cgroups + Seccomp + Capabilities = better security. Containers make it easy to use all of the above.