Following a flagged off-topic on Discobot thread I wonder if Discourse community want to discuss if allowing impersonate users on 1-single-click is OK or could be something moved for specific scenarios.
From my own perspective that’s like using another people IP or ID. They are behaviors that are not aligned with ethics or moral (first than legal or illegal).
I think the same fits with impersonate as one-click solution where admins could post like another users with a single click.
I mean, changing some things on Discourse require manually entering the app, use Postgres and work in data from a lot of queries.
Why impersonate is so easy, when it envolves a thread with multiple perspectives and different legally interests?
That is probably don’t know by the majority of users and we all know that admins can enter the database and change things but that’s totally different from click a button and post like another user.
Admins can suspend and ban users if something bad is going on the forum and they are legally responsible of the website.
As a developer, Impersonate is an absolutely brilliantly useful function which helps with the development process, such that I can quickly jump out of an Admin role and into the role of a new user to check what they would see …
I think the point being made is that easy (and silent) impersonation might violate expectations, at least in some communities.
We shouldn’t be looking at this as a matter of law - it’s a matter of policy, and culture, and it’s perhaps the kind of policy where a site admin could choose one approach or another.
It’s sometimes useful to impersonate, but perhaps the person in question should get a notification. Perhaps for many cases, the person in question could approve a request to impersonate.
Tbh in my opinion the feature is not needed and should be removed. But am sure the team may have reasons it is there. ie switch to a test user account.
As for the feature used to impersonate to poat as another user at least publically one could simply use 3 clicks to use change ownership.
Bottom line only have Admins un place that are chosen well.
This could be troubling as some Admins only maintain the interface like @pfaffman case with clients. As all admins have full permissions but don’t use things outside of there job. As mentioned one needs to check there region laws; However might need to be careful of travel.
Making the Api proposed to grant a user partial admin functions that a designer/maintainer requires.
True but this could be done with using specifically test accounts. This us where it cones down to the integrity if the end user. This could be as the Op suggests be abused and corrupted use.
I’m reminded of the warning in linux when the sudo command is first used:
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
That is, when using Impersonate for the first time, or every time, an admin could be presented with a click-through, with some message about respecting privacy and acting with integrity.
The impersonate function is a good thing if you think about it for a moment, but not just for the reasons already brought up.
Impersonate logs its use in the admin log. Sure, an admin could delete the entry with the rails console or by a direct SQL query in Postgres, but that leaves its own trace (a gap in the log IDs that other staff will see if they look for it)
The lack of impersonate would actively encourage admins to abuse the far more sinister alternative that won’t be logged, and I suspect any dev reading what I just wrote has already figured out what I’m about to say.
Want to have a single log entry easily hidden and even be done months in advance so other forum staff won’t associate the two? You create a All Users API Key. 1 log entry, and you do whatever you want as whoever you want whenever you want, and unless it’s something that would normally be logged for the user you’re acting as, it would leave no trace.
They are often test accounts in a Dev setting in any case but setting up test accounts on Dev is extra work. This avoids you having to log off and log back in which slows your workflow and especially annoying having to set up multiple passwords which is not a pleasant experience, slows you down and doesn’t add anything of value in dev. With Impersonate you only have to remember the admin password.
I’m simply illustrating an additional benefit of this functionality for this specific use case.
Test accounts really takes no time to create and in this idea they would be a standard part of the Discourse install much like Discobot and system. The “Impersonate” function would be kept save it would only function with say for example 3 or 4 test null accounts that could be modified to simulate users of various levels.
As has been said folks with high values and integrity may not use Impersonate for nefarious purposes. Though the use is temping nevertheless. That and if members of a site knew the admin could use there account to impersonate them they may loose trust in the platform. Atm impersonate relies solely on on integrity and has no optional fix unlike How “Encrypt Plugin” fixes the issues users of a Discourse Forum to make PM/DM private like emd users of a forum expect unless clearly spelled out that DM/PM are not secure and private as expected functionality by a community. On the Plus I asked specifically if Impersonate could be used to bypass Encrypt Plugin to which Sam explained and confirm it coulf not circumvent the pritection as it is End to End encryption.
Not true. Creating test users every time is a pain. I often create fresh developer installs and run in the dev fixtures for expediency. (Those fixtured users do not have known passwords afaik) Then only have to add an admin account and impersonation allows me to switch between from the UI nicely. Job done.
I’m a bit perplexed by your negativity here … I was simply complimenting the platform for having a useful facility that I use regularly in my work, now you are attacking this functionality and my approach with the aim of what? To make our lives more difficult? I’m not sure I appreciate that very much!
What truly is the problem with the “impersonate” feature? why are you people making an issue out of nothing? anyway, this one is quite useful and even big tech uses these features if you talk about privacy then the admin can see everything and can do anything with the site stuff, Google, Facebook and all big tech of them do it. that is not something new anyway.
And why any dev would create an account if the issue is from the user end? In those cases, this feature is quite useful. If you have a problem then don’t use it.
I am not attacking it all. Simply pointing out that it is an easily abused feature that can create a plethora of issues. Baking in test accounts for direct use fixes the potential misuse by it not being available. As for the creation of a test account. I have opened a 2nd tab created account with a fake non email address snd tabbed back to my admin logged in account and validated.
Impersonate is definitely a useful tool that if Default test accounts or an Admin option to within the Admin panel could create null accounts that can be used with Impersonate. Would close the potential misuse.
As mentioned if a community is made aware that Staff Accounts can impersonate them they might not trust the community platform.
From what I have read of you and a plethora of other great ppl here would never likely misuse the feature. But having the open functionality of this feature could make communities less trusting of Discourse as a forum platform.
Having an open discussion should not be viewed as negative weighing pros and cons.
Sam’s Encrypt Plugin prevents Admin & Mods from viewing DM/PM much like how aps like Whatsapp advertises they cannot view conversations unless invited. So that closes the view DM/PM function that maybe viewed as a breach of expected privacy that is not clearly stated that they are not truly private.
This is totally moot. If you really want to read users private communications, as an admin you can go take a look into the database (unless you enable encryption).
As a website owner you have in any case access to everything, can apply any modifications you like, turn on and off encryption, whatever.
When you use a third party system as a user you do not have any direct control of what people can do with your data.
In any case I’m not arguing about Production, my point was only to say this functionality also has its benefits in Development and they are easy to demonstrate.
So from my perspective +1 on this. Now I’m too busy to argue this any further. Have a good day.
Then don’t use Google, Facebook, Microsoft, and all others since all of them do it. they don’t openly say that they can “impersonate” you. They can do all the things you can imagine but still, you trust them and you still use them knowing they can do anything so I dunno what truly is the problem, man. maybe you are worried about your forum mods and admins but still, all actions get logged if any admin uses the “impersonate” feature. so I am not able to understand where is the problem. if this feature was problematic then the discourse team wouldn’t have put it in the first place.
