This is why I believe it to be an "unpopular opinion" these days as most computing platforms move towards being more locked down and less extensible; for security or complexity reasons these kinds of things seem to get little love or are even axed completely. Usually, the hard part is not security per se, but identifying user intent. You want to come up with a process that ensures that the user who enables potentially dangerous interfaces knows what they are doing. Preventing the user from doing this entirely is an easy but fairly disappointing "solution" to this problem.

> Preventing the user from doing this entirely is an easy but fairly disappointing "solution" to this problem.

For sure. And if individuals are happy with trading some security for some functionality/flexibility in their software, I'll support their right to make that choice.

It gets more complex when the people affected by that choice aren't the people making the choice. Which is more likely in the case of network programs.

> Usually, the hard part is not security per se, but identifying user intent. You want to come up with a process that ensures that the user who enables potentially dangerous interfaces knows what they are doing.

Indeed. I'd add identifying developer intent to that as well. What functionality am I trying to enable v.s. what else am I actually enabling? Coming up with that process is the herculean task there.

Usually in the case of network programs you want users to have a way to control their view of the shared backend/database/whatever, which means providing things like REST APIs and hackable clients.

"Those with nefarious purposes find them extremely useful too"

Whilst I don't disagree with this point, it has all to often been used as an argument against open software, and ultimately leads to more closed and less secure software.