>> Secure by default. No file, network, or environment access, unless explicitly enabled. > Great, but we're talking about server software so the first thing a

>> Secure by default. No file, network, or environment access, unless explicitly enabled. > Great, but we're talking about server software so the first thing any project is going > to do is enable all of that. And it's not like you can trust this on the server, you'd > still need to sandbox to process if you truly want isolation. These are not intended to be quick fixes for the masses nor replace sandboxes. They contribute to strength in depth and frustrate attackers looking to make pivots. I'd recommend taking some time to consider the threat models that these measures are align to. There is evidence that making changes like this contributes to the overall security of an ecosystem. You have a smaller percentage of people who will go ahead and do the wrong thing initially (if you support them with proper guidance), but it's only over time that you have projects based on the platform. More importantly, a change is being made that can sustain a culture of security over the long-term. When you have to maintain systems that aren't built on platforms with support for measures like these it becomes difficult to retrofit any meaningful level of security, or there is too much obfuscation in the system to justify improving it without rewriting it. Here you can see that the original implementers have enabled privileges unnecessarily and there is a clear angle of attack. Along the way you can also revert all other kinds of bad practices and hacks that previous developers implemented (random calls to external services you don't expect, loading configs from disk that should be loaded another way, etc.) These are not uncommon experiences when technology gets into the hands of the mainstream.