Add friction in some UI for better security

[surli]

Hi everyone,

I attended a presentation at FOSDEM this year entitled “Bad UX is bad security” and the main idea that I took from this presentation was “sometimes it’s interesting to add frictions in some UX to force users to take a few time to think about what they are doing”. One of the example the presenter was using is a pop up that shows up for confirming something and that users never read and they just click to proceed.

I caught my attention as this is the kind of thing we do have a lot in XWiki: I can think for example of all checks we have to force edition: force locks, force edit when the page is part of an extension, force retry request in case of problem with CSRF token etc.
I was thinking that maybe we should try to put a bit more frictions in those UI to make sure that people are taking the time to actually read the message and just not blindly click “force”. The first idea that came in my mind for this would be to not enable right away the button to force the action, but to have a small timer, that we would display, and that would enable the button only after e.g. 5 seconds.

So what do you think about the general idea of making a bit less easy to click on the primary button for that kind of important decision in XWiki? Would be interesting to have @tkrieck opinion on that.

[tkrieck]

Hey Simon, thanks for the heads up! I will take a look at the presentation, but I agree with the general idea, sometimes we need to protect users from themselves, lol =) . Of course, it seems a little harsh, but one of the usability heuristics from Nielsen is called “Error prevention”. In his words: "Good error messages are important, but the best designs carefully prevent problems from occurring in the first place." It seems to me that this fits perfectly in this situation.

Regarding the force editing, yesterday I was doing some test as a regular (simple) user on a local instance of XWiki and was presented with the “Force Editing” button. The regular Edit button was available on a System page (one of the indexes) which I found odd as it is a page that a regular user would not edit (maybe an admin would). The message was as follow:

---

" Editing this page may result in breakage because you are missing the following rights:

• script
• programming*

*: requires manual inspection, please see the details below."

---

In my opinion, for simple users, we could just remove the main Edit button in such cases.

We could also disable the button and show on a tooltip the reasons why it is disabled. I am not a big fan of this approach because we would need to retrieve the reason before page load every time OR on hover of the edit button, causing some lag on the tooltip hover.

Now, for advanced users, we could stay with the force editing concept but rework the message a little bit, introduce the delay like you’ve mentioned and change the prioritization of the buttons:

Example of a reworked message, we would need to see all the message variations that are in use today

---

You cannot edit this page because you don’t have the following permissions:

• script
• programming

You can force edit it, but doing so might break things on the page. Talk to your system administrator to get you the proper permissions.

[ Force Edit ] [ Cancel ]

---

The button Cancel would have the primary look (stronger emphasis), while the Force Edit would have the secondary one and, like you said, only appears after 5 seconds.

[vmassol]

Interesting topic.

Note that I don’t agree that “force editing” is a good use case for this (and I don’t think it provides better security). It’s not important enough and we shouldn’t make it harder for users for this use case IMO. The main reason is that we have a merge UI at save.

Quite the opposite, I believe we need to make it simpler for the user and remove that warning altogether. This is what we’re working towards with realtime editing for example. I’m referring to the standard use case of editing a page that is being edited by someone else (i.e. when there’s a lock).

@tkrieck

In my opinion, for simple users, we could just remove the main Edit button in such cases.

We could also disable the button and show on a tooltip the reasons why it is disabled. I am not a big fan of this approach because we would need to retrieve the reason before page load every time OR on hover of the edit button, causing some lag on the tooltip hover.

Yes. We discussed this in the past and one argument was that removing buttons is potentially not the best as it removes discoverability and presents user with a WTF situation (they don’t understand why a button supposed to be there is not there). A better approach is to still have the button but greyed out, with an explanation when you hover over it, that explains why it’s greyed out. But as you say, depending on the use case, this can affect performances. Another option is to allow clicking the edit button but forbid the action on the subsequent screen and explain why. That’s probably the best compromise and what we usually do. The part about “force edit” would only be displayed for advanced users.

I addition to all this, in XWiki, you have history and the ability to revert a breaking change you did or that someone did, so no edition is really critical since it can be fixed. Thus, I’m far from sure that we need to implement this delay, except for features where there’s no possible recovery (for example when deleting a wiki, which is nit recoverable - but there we ask to type the wiki name for confirmation).

Thx

[MichaelHamann]

@tkrieck

In my opinion, for simple users, we could just remove the main Edit button in such cases.

We’re currently working on this, as part of the document rights work, when a page will be marked as requiring script right, it won’t be possible to edit it anymore for users without script right. The current solution is an intermediate step towards that solution.

@vmassol

I addition to all this, in XWiki, you have history and the ability to revert a breaking change you did or that someone did, so no edition is really critical since it can be fixed. Thus, I’m far from sure that we need to implement this delay, except for features where there’s no possible recovery (for example when deleting a wiki, which is nit recoverable - but there we ask to type the wiki name for confirmation).

This warning is not just about possibly breaking the page, a similar warning is also the only warning you’ll get before a malicious script is executed with your rights that another user put on that page. And you might not be able to undo the effects of that script.

@vmassol

Yes. We discussed this in the past and one argument was that removing buttons is potentially not the best as it removes discoverability and presents user with a WTF situation (they don’t understand why a button supposed to be there is not there). A better approach is to still have the button but greyed out, with an explanation when you hover over it, that explains why it’s greyed out. But as you say, depending on the use case, this can affect performances. Another option is to allow clicking the edit button but forbid the action on the subsequent screen and explain why. That’s probably the best compromise and what we usually do. The part about “force edit” would only be displayed for advanced users.

As I’ve said, in the future, you just won’t have the permission to edit the page anymore - on the level of the authorization manager, not via some extra check that is only used in some cases. I know about that discussion of just disabling the edit button in this case. However, I wonder why it would be surprising in this case and not in another. In other words, why should we explain the user in this case why the user cannot edit anymore and not in another case where, e.g., a right on the page prevents editing. What I wonder is if we shouldn’t implement a generic way to explain a right outcome, though maybe only available to admins as a tool to understand why a certain user cannot edit a page.

[vmassol]

@MichaelHamann

This warning is not just about possibly breaking the page, a similar warning is also the only warning you’ll get before a malicious script is executed with your rights that another user put on that page. And you might not be able to undo the effects of that script.

Right, this is the case when you have script rights (and the page contains scripts). For this, I doubt that the button delay will help much. At least less so than presenting the info visibly show the scripts to the user so that he/she knows what will be executed. But it’s ok to delay the button in this case (ie for advanced user having script rights).

BTW I guess we only show the warning if the previous users was not the current editing user.

Do we also check if the previous authors made changes to a script before displaying the warning? Of course, it’s possible that an existing script would have some I condition based on, for example, a word being present in the content of the page and just changing that word would trigger some specific path execution of the script… In this case (which is probably an edge case), the editing user would need to review both the code of the scripts and the changes done previously…

@MichaelHamann

However, I wonder why it would be surprising in this case and not in another.

That’s easy. Imagine a page that someone can edit. It has no scripts. Someone else adds a script. Then the first person comes back and suddenly doesn’t see the Edit button anymore. I’m pretty sure they won’t understand why.

It’s true that the same would happen if an admin just changes the permission of the page. But it’s more obvious since asking the Admin would be enough to know the answer. Which is not the case in the former use case.

@MichaelHamann

What I wonder is if we shouldn’t implement a generic way to explain a right outcome, though maybe only available to admins as a tool to understand why a certain user cannot edit a page.

Yes, that would be nice but I wouldn’t restrict it to Admins but more to advanced users (it’s a pain to have to ask an admin why you can’t access a page). Some “Why cannot I edit this page?” link somewhere in a page menu (or some other name), that, when clicked, performs some computation to find the reasons and explains it.

Thanks

[MichaelHamann]

@vmassol

Right, this is the case when you have script rights (and the page contains scripts). For this, I doubt that the button delay will help much. At least less so than presenting the info visibly show the scripts to the user so that he/she knows what will be executed. But it’s ok to delay the button in this case (ie for advanced user having script rights).

Iirc there was some discussion and after that we decided to hide the scripts by default, but there is a button to show them. I think for document rights I’ll try again showing them all by default as this is a more explicit action.

@vmassol

BTW I guess we only show the warning if the previous users was not the current editing user.

Yes, or more precisely, we only show the warning if the rights change compared to the previous author, which is definitely not the case when the previous author is the current user.

@vmassol

Do we also check if the previous authors made changes to a script before displaying the warning? Of course, it’s possible that an existing script would have some I condition based on, for example, a word being present in the content of the page and just changing that word would trigger some specific path execution of the script… In this case (which is probably an edge case), the editing user would need to review both the code of the scripts and the changes done previously…

No. We do not compare to any older version to understand who actually authored the code. I agree that this would improve usability but for this we would also first need a way to track macros across versions.

@vmassol

It’s true that the same would happen if an admin just changes the permission of the page. But it’s more obvious since asking the Admin would be enough to know the answer. Which is not the case in the former use case.

In XWiki, any user can change the permissions of a page, not just admins. Edit right is enough to restrict or grant edit right for other users. As it won’t be possible to change document rights without (at least) script right and script right is not granted to all users, one could even argue that document rights can be changed by fewer users than standard permissions.

@vmassol

@MichaelHamann

What I wonder is if we shouldn’t implement a generic way to explain a right outcome, though maybe only available to admins as a tool to understand why a certain user cannot edit a page.

Yes, that would be nice but I wouldn’t restrict it to Admins but more to advanced users (it’s a pain to have to ask an admin why you can’t access a page). Some “Why cannot I edit this page?” link somewhere in a page menu (or some other name), that, when clicked, performs some computation to find the reasons and explains it.

I’m wondering if this wouldn’t reveal too much information in some cases. But it also depends on how we present the information - and I haven’t yet checked what we could compute. For example, when a right is denied because it has been granted to 10 other users, should we list all these users? I think currently it is not possible to access this information, but maybe I’m wrong.