Emacs is powerful, but the complexity overhead of managing a custom trust layer could easily become a major maintenance bottleneck for average users. Worth considering, but the friction point is significant.
Towards trust in Emacs
21–30 of 36 posts
Re: Towards trust in Emacs
#22The article is still missing the most important point about a "trust system" -- you have to explain what it is and convince me that I even care about the problem you're trying to solve. It's my machine, what is a "trusted" or "untrusted" file? If people just force security "solutions" on me without asking me whether I understand or agree with their problem diagnosis then I will immediately disable the protection if I can or blanket accept all prompts without thinking.
This is good, but it doesn't go far enough:
> ... the problem with security measures that cause too much friction is that users tend to disable them in order to get on with their work. To fulfill its security purposes, a good trust system needs to stay out of your way.
Re: Towards trust in Emacs
#23> ... the problem with security measures that cause too much friction is that users tend to disable them in order to get on with their work. To fulfill its security purposes, a good trust system needs to stay out of your way. I wish this was understood clearly by more security engineers, but, alas...
At my work when our IT sec org tighten the screws harder and harder, people just have to get "creative" to do their job effectively. For us this meant that some of my coworkers started using their own machines to write code making the whole setup much more unsafe and prone to breaches.
But I definitely feel there's a huge missing part in our setup and lack of accountability in the It sec org when it comes to not hurting productivity unnecessarily. They can just keep putting up barriers without any real consideration to the impact and side effects they may have.
Re: Towards trust in Emacs
#24> ... the problem with security measures that cause too much friction is that users tend to disable them in order to get on with their work. To fulfill its security purposes, a good trust system needs to stay out of your way. I wish this was understood clearly by more security engineers, but, alas...
This is how I felt about macOS for my workflow. It was like living in a house where every room autolocks every time you leave the room, great for security but horrible if you need to move from room to room constantly.
Re: Towards trust in Emacs
#25The one problem I have with the trusted files thing is that I have no way to trust non-file-visiting buffers. Why is *scratch* untrusted!? *scratch* should always be trusted, without me having to configure anything, ideally. Though a setting to automatically trust non-file-visiting buffers would be nice. I just ended up stopping using the scratch buffer because of that issue.
Because the Emacs trust model is incoherent.
Re: Towards trust in Emacs
#26> ... the problem with security measures that cause too much friction is that users tend to disable them in order to get on with their work. To fulfill its security purposes, a good trust system needs to stay out of your way. I wish this was understood clearly by more security engineers, but, alas...
At my work when our IT sec org tighten the screws harder and harder, people just have to get "creative" to do their job effectively. For us this meant that some of my coworkers started using their own machines to write code making the whole setup much more unsafe and prone to breaches. But I definitely feel there's a huge missing part in our setup and lack of accountability in the It sec org when it comes to not hurt…
It’s blame shifting. If the security people are allowed to make it impossible to work without breaking the rules, they’ve successfully moved all blame for anything that goes wrong away from themselves. “Oh, you turned your computer on? Well, the security guidelines clearly state that’s not allowed, so that’s your fault.”
Re: Towards trust in Emacs
#27I tried AI, and i never could/dared to actually push anything to prod. The code seems ok, but i always have a gut feeling somethings off. I guess the most valuable thing you loose is the "what" and "how". You cant learn these things from just reading code, because the mental model just is not there. Also i dislike code reviews, it feels "like a waste of time" because sure i can spot some things, but i never can give…
Do you not work with others in a code base?
I do, but in this case some one else did the writing, not AI. I can always drop them a PM about how/why something is like it is. I cant do this with AI, and when trying you cant trust the real reason, and the answer will pretty much change depending on how you ask it.
Re: Towards trust in Emacs
#28I'm a newb to Emacs, I've been using unstraightened Doom Emacs and have never been prompted to trust a project I've opened. Should I be worried?
Re: Towards trust in Emacs
#29It's getting so very old - all I want out of a process is code autocomplete, but I have to grant it read & write permission to my entire disk and network. When do we get good permissions and sandboxing and isolation? This can't go on.
It's exhausting because the model that underpins the whole concept is broken
Re: Towards trust in Emacs
#30It's getting so very old - all I want out of a process is code autocomplete, but I have to grant it read & write permission to my entire disk and network. When do we get good permissions and sandboxing and isolation? This can't go on.
It's exhausting because the model that underpins the whole concept is broken
Everyone got the point the last two times you posted this.