D12732: Implement a more user-friendly run-as-root-or-sudo behavior

Nathaniel Graham noreply at phabricator.kde.org
Wed May 9 14:15:59 BST 2018


ngraham added a comment.


  I have to agree with Mark. Life is full of risks that we trade off. It rarely makes sense to mitigate a risk by destroying our ability to do the potentially risky thing in the first place.
  
  I brought up the example of a compromised door lock before; the current approach taken here is akin to nailing your door shut so nobody can enter it--yourself included--even if they've gotten the key. Security measures that burden or even destroy an important use case aren't actually security at all: they're developer laziness.
  
  Consider the following dialogue:
  
  Developer: "Oh this feature is dangerous, I'll turn it off."
  User: "Okay, what do I use instead of that feature?"
  Developer: "Nothing; its replacement hasn't been implemented yet."
  User: "Um, what's the timeframe for implementing it?"
  Developer: "I don't know, I'm not involved with that project and don't plan to contribute to it."
  User: "Okay, then could you consider delaying turning it off until the replacement is ready?"
  Developer: "No, the security threat is too great."
  User: "So what am I supposed to do if I want or need to USE that feature?"
  Developer: "Not my problem."
  User: "I angry!"
  Developer: "I don't see why; I've protected you from a terrible security vulnerability."
  User: "But in the process, you removed a feature that I use!"
  Developer, "Not my problem."
  
  Surely Mark and I are not the only ones who see the absurdity in this. Security measures that damage the user experience are the laziest kind. I mean, we could all could be far more secure from the thread of online malware if you disabled the web browser, right? Surely we can do better than this.

REPOSITORY
  R318 Dolphin

REVISION DETAIL
  https://phabricator.kde.org/D12732

To: ngraham, #dolphin, graesslin
Cc: kfm-devel, rikmills, emmanuelp, zzag, nicolasfella, elvisangelaccio, Fuchs, mmustac, markg, spoorun, navarromorales, isidorov, firef, andrebarros
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20180509/115c2843/attachment.htm>


More information about the kfm-devel mailing list