And just to tack on a specific anecdote about my own use of containers and how what you're saying just isn't true, I found once when trying to run Chrome in a c

And just to tack on a specific anecdote about my own use of containers and how what you're saying just isn't true, I found once when trying to run Chrome in a container that it failed for some reason related to sandboxing. So I tried to disable sandboxing with --no-sandbox and saw that it worked, then went back and googled to find out the implications of what I had done. The first advice I found was from core docker maintainers saying clear as day "don't run chrome with --no-sandbox". The problem was a missing kernel flag for USERNS support. This feature provided by the kernel is the piece that allows to create a virtual root user that only has root access inside of his namespace (only inside of the container, then.) This is a service provided by the kernel. Just to rebut your position, in my experience there is no "throw up your hands" attitude towards security in the Docker dev team and containers ecosystem. Now certainly the thread parent shows this is not the case everywhere, but I can tell you in my opinion from limited experience that I am not AT ALL surprised this happened at IBM. I was exposed to their BlueMix platform at a hackathon in Buffalo, and putting it gently I was not impressed. More directly, important things like authentication and continuous deployment were obviously broken as soon as you scratched the surface. The judge from IBM did not respond well when we told him we found their platform was severely broken, and we had decided at 1am that we'd needed to switch our efforts to targeting Heroku deployment instead. (We did not win the prize, if you're still wondering.)