Thoughts about impersonate user

[Stephen]

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.

@matenauta

From my perspective that probably validate that Discourse takes in mind about privacy and freedom.

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.

@jimkleiber

• Some want the current level of low friction to impersonate

It sounds more as if people have become oblivious to the power admin has. Impersonate is the tip of the iceberg.

[jimkleiber]

@Stephen

It sounds more as if people have become oblivious to the power admin has.

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.)

[Stephen]

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.

@jimkleiber

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.)

Do you have any experience with the massive amounts of engineering required to make those things appear simple and user-friendly?

They’re not omitted due to some simple oversight.

[jimkleiber]

@Stephen

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.

Thank you

[MikeNolan]

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.

[MarcP]

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:

1. You are assisting the user and need to see what is happening on his side
2. You are troubleshooting a bug, that is not occurring for all your users
3. You need to see frontend from a user perspective
4. 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.

[ClawdiaWolf (Claudia)]

@MarcP

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?

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.

[RGJ (Richard - Communiteq)]

Another one that is impossible without impersonation are the subscription settings Make u/username/billing/ accessible to admins

[matenauta]

@RGJ

that is impossible without impersonation

Nobody is talking about removing impersonation.

BTW, somebody want to reply the only question that my topic has opened from the beginning?

@matenauta

But the question is why is only at one-click distance?

That’s Discourse and that’s a clear decision.

[RGJ (Richard - Communiteq)]

I was merely responding to the question

@MarcP

if there are user settings that can’t be accessed without impersonating?

[Canapin (Coin-coin le Canapin)]

@matenauta

But the question is why is only at one-click distance?

Hasn’t this question already been answered?

@awesomerobot

Removing the impersonate button does nothing to make your account more secure. Everything impersonate enables can be done by an admin without the impersonate feature.

If you replace “Removing the impersonate button” with “Making the impersonate button less easily available”, the sentence will keep its meaning, won’t it?

[Lhc_fl (Linca)]

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?

@renato

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

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.

[MikeNolan]

@Lhc_fl

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.

[Heliosurge (Dan DeMontmorency)]

@jimkleiber

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.)

For the PM/DM Sam has created the excellent Emcrypt Plugin.

[Heliosurge (Dan DeMontmorency)]

I think on this it would be great to be able to configure which Admin(s) on the site via cmd line can access this feature. As you may have Admins that need the elevated access. Though even @jimkleiber simple idea of using css to hide the button to all except X+ would be sufgicient for most as it is only to remove the temptation of it being seen. Though the plugin serializer in the same idea would likely be better as imagine you could hit the invisible buton(?)

@MikeNolan

If that switch is in the site settings, then any admin can turn it back on, so now one-click becomes a few clicks

Indeed so in that case a root command line option. Though most would leave it if it is jsut a " temptation’ issue.

[sam (Sam Saffron)]

@Lhc_fl

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.

So much drama on this topic.

Here is a PR to a global setting to disable it. I think this is the correct fidelity. It is something the person installing and running the cluster wants to set cluster wide.

FEATURE: allow site owners to disable impersonation

[piffy]

Great PR! However I find that the ability to turn on and off the impersonation setting is a bit too easy to do with this new feature. I think most users would be uncomfortable to know that impersonation can be turned off and on at the whim of an admin!

Perhaps we should consider an additional setting that allows this new allow_impersonation setting to be turned off or on. That way I won’t be so easily tempted to set the allow_impersonation setting to “on”. Something like an allow_allow_impersonation setting. What do you think?

(this is a joke )

[HAWK]

When we are supporting customers we occasionally have an admin impersonate in strange situations to ensure the issue isn’t browser/OS/ad blocker related. In those cases it is very useful and unobtrusive- they don’t post on their behalf or have access to anything they couldn’t see anyway.

[Ed_S]

@sam

So much drama on this topic.

I see a lot of confusion between the technical and the social. The technical view is that impersonation is useful and switching it off does not prevent enough. The social view is that impersonation is too easy to use and in the culture of some forums violates the social contract.

Noting that impersonation is useful, or even essential, says nothing about the social utility or the messaging. And so we have people talking past one another - especially perhaps from those who are not used to thinking in terms of social expectations in different cultures.

Thanks for the global switch. (I still think an interstitial warning would be an improvement!)

[kynic]

Or it should be in the console to allow this setting. Or it should be in the source code to allow it. Or some warnings? Anyway the temptation still there what to do