alt Hacker NewsIt's amazing how often product decisions head this way for the purposes of 'removing friction'.
In security, friction is a GOOD thing. You want to have some ceremony to do things. It's pretty much inevitable that people will give up control for convenience.
Look at Artifacts for example.
Replies
Which is in turn why for convenience, security is a bad thing, making people who do not think about threat models in their sleep opt out.
Problem is striking the right balance, and auto-forwarding your agent to foreign machines is not the right balance. At least not without being able to filter and approve individual signing requests.
It's an inherent tension, and is also why so many things are insecure. People hate friction, and so they don't use secure stuff and turn security features off. Security abominations like "curl | bash" and package managers that traverse trees and download stuff and run scripts are popular for a reason.
It's true in the real world too which is why even in secure buildings a person can often slip in by coat-tailing someone. Stopping every single person to check ID is cumbersome and slows everyone down. People have stuff to do.
Truly high security environments are zero-tolerance, which makes them annoying and expensive to work in. I've talked to people who have worked in US military and CIA/NSA places and a very meaningful amount of time is spent complying with security and jumping through hoops. Even with all that, stuff gets leaked and stolen.
> In security, friction is a GOOD thing.
Oh boy, it isn't. Friction leads to frustration and therefore more likelihood to ignore the importance altogether.
I think this is another oppertunity for folks to think of security, especially technical folks. (And maybe even another market pricing differentiator): User account management systems should more widely allow users to make permission-restricted 'subaccounts'. In this bold new era where folks are delegating their machines to take actions on their behalf, we need a new way that is far more fine grained than "all, ask every time, or nothing".
Choosing how to sub-divide abilities, and allowing the user to manage that, will be an art unto itself, and depend largely on the system. Thinking a banking API with a rule like "Allow sub user to send payment to water utility once per month, not to exceed $200". The user only needs to intervene if something goes wrong and the amount goes over.