Could be social and/or cultural and I try to share my thoughts -not judging anyone- because of that.
Some people are living in countries that are resistant to changes and fully censored (so they could normalize things that are directly attacking freedom from different perspectives or cultures).
But Discourse wants to be the forum top platform over the world and I think that discussing around this kind of topics is always a good thing for everyone.
Thanks for the space. I hope it could be revised for not harm the use cases but neither the trust on Discourse from users and communities concerns
We are talking about to prevent eventually very bad uses in large communities and not harming the trust that users give to Discourse.
We are not talking about blind forums or prevent admins have the data because thatās impossible from the centralized base that uses a single database.
I think that question fits very well in āYES butā and not into āYES or NOā debate.
Sorry but thatās not the point of my topic. You can open another one and ask whatever you want.
Removing impersonate does not prevent this, itās just as easy without it. The primary effect of removing impersonate would be making it harder to troubleshoot account specific issues.
You should spin up a demo and try some of the admin features, you donāt need database access or impersonate to change someoneās words or read their messages.
If itās one click or a dozen clicks, it makes little difference, it is still possible. I know someone who works from home frequently and has to go through about a half dozen passwords, two-factor IDs and other rigamarol to get into his companyās internal systems, but it only takes him a few minutes to do it.
Either you and your users trust the developers and administrators, or you/they donāt. And if you donāt trust the system, then how you use it will likely change.
You need to go back and read my last few posts before responding again, admins can still do all of this without impersonate or database access. Impersonate and most admin actions are already logged in the event that an other admin needs to have a trail to find a malicious admin.
Or simply close that open function with the Encrypt plugin. At the end of the day having options on functions ppl might find problematic is a good thing. False sense of security, safety etcā¦ Only secure system to Quote Adama is an offline terminal that os not networked to other systems.
All the pros for and m cons against have valid PoV. Compromise is the best solution for all parties. Encrypt Plugin I imagine was developed to appease the desire and in some places a possibly a requirement to have a layer of privacy to the PM/DM subsystem.
Perhaps if not put into Core as an option maybe a plugin that accomplishes the desired effect for those say Self Hosted systems that want the peace of mind.
One could say the script for making custom badges does not need be disabled as only the Admin has direct access to make them. However this has to be enabled from Root unlesd that has changed.
I agree in perfect ideal circumstances ppl should be able to trust ppl in positions. Unfortunate trust is at times misplaced and only found on discovery.
Thatās a performance measure, to make sure that hosted customers on a shared environment cannot bring each others site to its knees. It makes it possible to distinguish between the server admin and the forum admin.
Clicking once or dozen seems to be similar but is not the same and because of that a lot of corporations loose a lot of money for not enabling a simple button saying āUnsubscribe meā.
We probably are talking about the opposite but from moral and ethics PoV.
Iām using Discourse as admin from 4 years ago and I know what you are talking (totally different cases from impersonating users).
What you said not enable the possibility to post like another with one single click. Thatās like using a third party IP or ID and is different than editing their posts for moderation.
BTW I hope that encryption stop and breaks the possibility to read users PMs but thatās for another thread and Iām waiting for updates for test
Iāll quote this again as it looks like youāve gone and got slow mode addedā¦
Iāve been toying with the idea of some practical examples of āchange ownershipā and/or āedit your post and hide the revisionā to demonstrate that this is mainly a moot argument as to the method used to make it look like you said something you didnāt without touching the impersonate button, but I have decided against it.
But there are certainly more than a few ways I could be an absolute arse with all the magic buttons I have just in the UI, let alone playing with the rails console. I think a lot relies on the trust of the community, not just the admin as lots of these features are available at TL4/catmod/mod level as well. I think in general the āstaffā group generally donāt go out of their way to be destructive with any of the tools as it would be an act of self-sabotage on their own community.
As such, I donāt know why the impersonate feature itself is being singled out as unethical?
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
