> 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.
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.