Seriously, all of these comments which claims misuse and other stuff does not make sense to me, there is no point to disable this particular feature. An admin still can do everything as others pointed.
But then, still you don’t want to hear others and want to make an issue out of nothing. I still don’t understand what truly is the problem. You will lose your users? Or you have fear that your other admin will use this feature against you? If so, then you should not make admins whom you don’t trust as simple as that.
I will be perfectly honest Richard, you and @merefield have very valid positive use scenarios. But I feel you both are only seeing how changing elements with optional settings would impede yoyr workflows. Which it really wouldn’t as with if your providing hosting the feature would not change for either of you.
Save for example if I were to posted a problem I needed help with with agreements for monetary compensation or pro bono. You or Robert or anyone that offers help can layout the tools required from a self hosted Discourse.
ie. "Dan I can help you for $X to solve your issue. I will the need the following. To create an account on your site and granted Admin access, I will also need to access Impersonate( with a list of users okay to use the feature on so I can properly and efficiently diagnose and fix the issue… If you have Impersonate disabled you will need your root admin to enable it. If you agree to my terms we can get this process started. "
I’d automate that, so I’m not worried about that at all (in fact, I have a shell script that takes the host name and the username of a Discourse install hosted by us as an argument, and it gives me a login link (including 2FA and logging).
I’ve already explained my objections over two hours ago (but I’ll gladly repeat them to avoid further confusion about my motives)
In my best attempt to manually GPT-4 summarize what I’m reading:
Some want higher friction to impersonate
Some want the current level of low friction to impersonate
For those who want a little more friction (I’m in that camp, because I personally don’t want to be tempted to click the button, similar to Screen Time and other tricks on iOS to help me avoid temptation):
Add a very simple theme component to your site with the following CSS:
.btn-impersonate {
display: none;
}
Perhaps you want even more friction than that, and maybe someone could make a plugin or more advanced theme component to do it, but I want to try this out and see if it provides me enough friction to avoid any unwanted temptation.
To me, this is the main point. Admins can still “impersonate” users with the other available tools, literally a few clicks away.
But in the end of the day, Discourse is an open-source project with a plugin system, you can always make things work the way you think is right for your own community.
If you want a plugin, I would start with one overriding Guardian.can_impersonate?, it’s used by the serializer that determines the presence of the Impersonate button as well as by the backend checks. At least from a quick test on my dev instance, it worked:
# plugin.rb
after_initialize do
class ::Guardian
def can_impersonate?(target)
false
end
end
end
This is a fascinating topic, which seems to be mostly borne of misunderstandings.
This isn’t a discourse issue though, this issue permeates any online system where there’s no end to end encryption and digital signatures / validation on messages. Discourse has neither of those things out-of-the-box.
You’re not really debating either here, nor does this really relate to any decisions made by Discourse as a product or CDCK as a team. There are tons of misconceptions out there, you’re just learning that software can’t police the ultimate level of authority on a system- something that many of us have known to varying degrees for decades.
The reputation of a community doesn’t hinge on Discourse features, it boils down almost entirely to who you hand the keys to. If a bad actor admin does something that sets the community in uproar, nobody will care about how easy it was for them to commit said acts because ultimately it was you and not a particular button which empowered them to do so.
It sounds more as if people have become oblivious to the power admin has. Impersonate is the tip of the iceberg.
I appreciate how you’ve framed this, as yes, for me, I’ve been quite shocked (and often quite scared) to learn how much power I have as an admin.
Why I’ve often desired to have end-to-end encryption is precisely that: to reduce the power that I have as an admin and to reduce the fear of what might happen with that power (e.g., ability to read/change messages, legal responsibility of having to report what people say in the private conversations, etc.)
These aren’t problems which free and open software can easily solve though, even the kind which has been around for a decade.
At some point it all boils down to a balance of risk and trust between the applications your service comprises, and the people who hold the keys to said kingdom.
Being aware of the level of access you have is actually a good first step.
Do you have any experience with the massive amounts of engineering required to make those things appear simple and user-friendly?
Enough to know that I have mad respect for Signal engineers and a lot of fear to roll my own crypto I built an encrypted journaling app back in 2012/13 and that was one user talking with themselves on only one device…and it was still a pain, probably not that user-friendly, and I’m not sure how secure.
So, yeah, I agree, simple, user-friendly, and secure multi-user communication technology can be extraordinarily difficult to create and maintain. Maybe why I was so pleasantly surprised that the Discourse Encrypt plugin existed.
Regardless, your comments remind me that yes, this platform is free and open-source, which means that if the core team decides not to do something (e.g., chat encryption or banning impersonation) for whichever reason, I’m free to build a plugin myself or pay someone to build it—and that freedom to do it if I want is one of the things that I love so much about Discourse.
IMHO even moderators have a lot of power in discourse, but I’m coming from a phpbb3 environment where moderators had far fewer powers. (I’ve also run a Mailman site for over 20 years, which I am moving to Discourse as soon as I can figure out how to move 20 years of messages to discourse.)
I have been the sole system administrator of that phpbb3 site for over 15 years, even though I retired several years ago; I’m actually looking forward to that platform moving to discourse because I assume someone else will be the administrator and I don’t really want to even be a moderator there, just a participant. I’ve been advising the project leader on forum admin issues we’ve dealt with over the years, some of them may impact settings he chooses to use, others might impact policies that organization puts in place for users as well as staff.
That being said, having restrictions for who can use the impersonate button don’t strike me as a bad idea, just one that is largely symbolic once one is an experienced admin. And of course the development team or system admin (on a self-hosted system) can probably do anything if they want to put in enough effort.
Impersonating is an essential widespread tool for admins. I am in web hosting, and I impersonate (“Log in as”) customers A LOT in my billing panel. There are enough cases where a feature like this is crucial, now in this case the following scenarios may happen:
You are assisting the user and need to see what is happening on his side
You are troubleshooting a bug, that is not occurring for all your users
You need to see frontend from a user perspective
You are testing the user-experience/flow
Now Discourse is not a billing panel, but the use cases are somewhat similar. Admins may need to troubleshoot a bug or see how the forum looks from a specific group or user. I usually impersonate my own alt accounts which are in specific groups or have specific TL/mod/category mod status, to see how it all looks from their end and if I didn’t miss any obvious settings.
Or simply assisting the user with anything that is not possible without impersonating - not sure if there are user settings that can’t be accessed without impersonating?
Besides the fact, that any root admin can already access any information in the database. This is one of the access rights an admin has by nature. The impersonate feature is there to make the admin’s life easier, just like any other setting, they are there to make administrative tasks easy: from the /admin/ interface.
The only settings I know to be an issue I believe you can change as an admin, but it shows your settings instead of theirs in a few places. On the Interface tab, it shows your theme and color scheme settings instead of the user’s so you have to impersonate them to be certain you’re seeing the right values.
If you replace “Removing the impersonate button” with “Making the impersonate button less easily available”, the sentence will keep its meaning, won’t it?
Just want to remind:
Could it be that many people have actually forgotten the possibility of completely disabling admin impersonation by simply installing a tiny plugin of less than ten lines of code?
Maybe I think the impersonating function can have a switch in the site settings like all other functions, just like whispering, tagging, user-page, PM-accessing log, etc.
If that switch is in the site settings, then any admin can turn it back on, so now one-click becomes a few clicks. Not sure that resolves the problem in the minds of those who consider this a problem. But it might make it less of a temptation to use for snooping around.
I built an encrypted journaling app back in 2012/13 and that was one user talking with themselves on only one device…and it was still a pain, probably not that user-friendly, and I’m not sure how secure.