I can't see your landing page without accepting tracking cookies for "live chat"? This is probably a GDPR violation. There's no consent without choice.
I should also point out that "Docker hosting" is rather ambiguous. I had to scroll way down the page to figure out whether you are storing Docker images (like DockerHub) or running them (like ECS or fly.io).
Yeah, just the cookie banner on its own doesn't inspire trust.
Post-GDPR rules in the EU are clear about the Cookie Banner, providers must make it as easy to refuse cookies as it is to accept them.[1] Also, as you said, livechat cookies are definitely not required when visiting the website, but they make it impossible to opt out. I assume they cut this corner because it was too much work for them to conditionally include their livechat javascript.
If the authors moved fast and broke things on basic stuff, my first thought is "what kind of other corners did they cut when deploying/running docker?" There is a lot of security and isolation options/configuration involved when one runs docker in a secure environment, which are not enabled by default.
[1] https://www.edpb.europa.eu/system/files/2023-01/edpb_2023011...
> rules in the EU are clear about the Cookie Banner
The linked doc is 8 pages of rules about layout, placement, color, contrast, function, etc. of components in a cookie banner. Said document references (without quote or link in most cases) various EU statutes, directives, regulations, and opinions.
Even with all that, the doc carries a disclaimer that it is not to be considered authoritative and various other requirements and interpretations may also govern said banners.
Telling people that this is "clear" is perhaps you saying that you have developed an uncommon expertise in this area. For which: that is great for you.
But let's be absolutely straight about this: none of this is clear to a person who does not possess the uncommon expertise you have.
Can you point me in the direction of documentation for isolating docker containers more judiciously? I have a few applications running on my Synology NAS and know less than I'd like to admit about what risks I'm taking running untrusted code on the same machine as my backups.
It's hard to point to a canonical documentation, it's more institutional knowledge that is gained over years of practice. It's a little bit as if you asked "could you point at the documentation to secure a linux server?"
There is none really. Usually, some beginner wrote a blog post that basically says "install fail2ban" and that's how many people consider their linux server "secured". But there is much more than that. For example, "put your entire firewall to DENY, and only open what is really necessary." Or "put SSH behind spiped[1] or wireguard". Or "Harden the maximum of your systemd units"[2]. Or "don't do chmod 777, try to understand why it doesn't work." And so on and so on...
For docker, it's the same, I'm not a docker fan, as I mostly use podman, which allows to runs container as different users. In general for security, I would recommend podman running as non-root, but if you insist to run Docker, here are a few places where you could start to harden it:
* Look into enabling and enforcing SELinux policies or Apparmor profiles on your host: https://www.mankier.com/8/container_selinux or https://docs.docker.com/engine/security/apparmor/
* Look into root-less docker daemon: https://docs.docker.com/engine/security/rootless/
* Make sure you don't run any priviledged container, if you do, look into alternatives to run them in non-priviledged mode
Docker has a page about security, it looks like they echo a lot of things I'm saying: https://docs.docker.com/engine/security/ . Avoid GRSEC though, it's basically security theater. They mention docker seccomp profiles[3], which I've never used, but is definitely a good idea when hardening untrusted code.
Also, hardening the OS that you're running docker on (using the things I mentioned earlier about Linux) won't hurt.
[1] https://www.tarsnap.com/spiped.html
[2] https://ruderich.org/simon/notes/systemd-service-hardening
Thanks for taking the time. I recently switched to a CentOS/SELinux box for tunneling traffic to my homeserver and appreciate knowing that nothing happens unless explicitly allowed. I'll take a look at how I might set that up on the container side of things too.
> I assume they cut this corner because it was too much work for them to conditionally include their livechat javascript.
No, just stupid and wasn't aware. Fixing that right now!
Yes I think you're right, going to fix that asap! And yes I agree, we need to work on our messaging. Thanks for the feedback :)