There are things like Whatsapp and others that don’ t have that function and are you sure they can or are you presuming they can because you csn in other apps you use?
Just a polite reminder from your friendly neighbourhood moderator to keep the discussion civil, and generally cool, calm and collected. 
Debating Discourse features should not be a fraught experience. 
10 Likes
Being totally honest I wouldn’t have chosen Discourse as the base of the community I founded at the first time if I would have known about this bug/feature.
IMHO is unnaceptable from every point of view to have that enabled by default AND with a single click or tap of distance.
Freedom and privacy is all that really matters on Internet those days. And I hope core team can revise the workflow because I know that was not enabled for break the trust within Discourse but for good use cases!
The thread, as Jammy said, points to good discussing, not to being rude or take different opinions like personal
I don’t, and I use Mac only for play music or trivial things.
2 Likes
BTW, do you know quite big LMS-platform named Moodle? Yes, impersonating is one the tools. No one complains. I can act behalf of my customers on WordPress.
So… If impersonating is a dealbreaker there isn’t too many options left.
And you haven’t even discovered the “change post ownership” function yet! 
Puns aside. You want to ban knives in every household because it’s possible to kill people with them. It’s not about the tool, it’s about how it’s being used. If you’re part of a community, you need to trust the admins, for many, many reasons. If you cannot, then you need to leave the community. It’s harsh but it is simple as that.
Changing one line in the Discourse source code would allow an admin to silently collect all typed passwords, how about that? You can remove features all you want but you have no way to verify the code that’s running on the server. Trust is the only solution to this.
As someone who does a lot of troubleshooting on behalf of clients and their users, I can tell you that a “test account” does not cut it. There are so many options and settings that matter that impersonation is often the only way. That said, we have a data processing agreement in place that forbids us to misuse these features.
8 Likes
Then as you said yhis feature is only known to be in use and by choosing to use the platform are okay with it.
Really this topic has a lot of merit. Having a way to disable the function via Command line Root Server access makes perfect sense. Those whom want to use the function have it available for there per case use. Those whom want to not have the function enabled can turn it off. As often only a very limited number of Admins on a site have root access it can work well.
Much like we have to use a command line to enable creating custom badges that use scripts iirc.
It is s very dimple solution that can appease everyone’s PoV for &/or against the Function. A great compromise for an open forum platform. Default have it off with clear instructions on turning on or even have it a question during install to have it enabled or not with the detail on how to enable/disable via root.
3 Likes
And if anyone who believes Google, Facebook, Apple, and all others don’t do this stuff then I dunno what to say… 
So an Api key could be used in that case use. Iirc not sure if you had mentioned a solution for using an Api for designers to not have full complete admin access. But there was a good discussion on it.
Change Ownership sure could be used. But the function does not work say in the New Chat feature.
We really shouldn’ t use apple and oranges comparisons. While knives have no legal storage requirements, Guns. & ammunition do. Guns. & Knives do not kill ppl it is the person whom uses it for that purpose.
Any tools can be abused znd there is no harm in having optional safe guards in place.
1 Like
In any system there is always a group of people who have enough access and knowledge to impersonate others without their knowledge or consent.
It comes down to trust and responsibility, you have to trust your senior admin team or developers to act responsibly.
In the systems under my authority, if there’s an ‘impersonate user’ feature (which I agree is very helpful) our operating procedures for staff state that it can only be used after advising the user of its use and getting that user’s consent. Failure to do so would be considered a firing offense. Since it is almost always done to solve a problem, very few users have ever refused to give us that consent.
We do see occasional questions from users as to whether moderators or sysops can read their ‘personal’ messages. Our advice is that any system can be breached or hacked, so don’t put anything in personal messages that you wouldn’t want to have made public.
BTW, our legal advisors tell us that in the event of legal discovery procedures, EVERYTHING can be requested.
4 Likes
Sure they might as well as whatsapp whom clains otherwise. This is a clear issue of closed source software is your expected to trust there say so. With no way to verify like you could do eith open source.
Linus’s Dad grilled MS over that issue of no way anyone can audit the code to ensure no backdoors.
As I already explained, even if something is open source, you have no way of verifying what code is running on the server.
How do you envision that? I don’t understand how an API key can help me troubleshoot something a user sees or does not see.
Do you know what happens when there is no “impersonate user” feature or when it is hard to access? Support personnel will start asking users for their passwords again. You just threw the baby out with the bathwater.
5 Likes
Nop, sorry but that’s not what I’m asking for (and I don’t want anything).
Please, discuss.
1 Like
I was not ridiculing anything. I was looking for a comparison and found an example in knives, which are very useful and also very easy to misuse, yet everybody accepts that they’re around everywhere.
2 Likes
True as one can alter it prior to use.
Never said a full removal. An Api key could be used for temporary bestowing the option when needed for those whom need it.
As stated having an option to disable it via command line root access is an easy fix for those whom would prefer not to have it an open function. It could even be made so that the impersonate function could be set vis command line as an option to restrict it’s use to 1 admin for example.
I am surprised at the resistance being presented to simply have options to limit or disable the function as a choice. For example with your use of providing hosting services you would obviously not disable or even limit it’s use by choice of your needs.
Now if we want a direct option as well the system could simply email the user that they have been impersonated by x admin. Like 2fa it would create a layer of openess the function was used. To which the user being impersonated was already aware it was going to be used to solve a problem.
1 Like
My “resistance” is twofold:
- removing the feature or making it harder to access provides a false sense of security
- when such functionality is hard(er) to access support personnel finds their way around it, and sharing passwords is much worse, since that’s not logged, passwords can be kept around, and passwords can be valid for other services.
Someone with enough access could also stop that email from being sent.
And every email can be an attack vector as well (I know a specific example of a Discourse forum that was compromised by a fake “backup created” notification sent to an admin).
So you want to use an API key to unlock this. Now admins can create API keys which give them full access and when asked by other admins why they created / used an API key then can claim it was for troubleshooting.
1 Like
We are not talking about Google, Facebook or Apple. We are talking about Discourse that’s open-source and allow self-hosting.
That’s supposed to be the oppossite.
I totally understand it.
But the question is why is only at one-click distance when changing the title of trust levels implies the use of query explorer or managing the database manually?
EDIT: two posts unified.
1 Like
That applies to anything even safety protection devices like fall arrest. So should we abandoned ppe as it creates false sense of being completely safe if used?
Options are not absolutes. Simply optional settings for peace of mind even if anything can be circumvented. Sam did disclose while not easy to do even the encrypt plugin can like any encryption scheme can be broken.
3 Likes
Well, that’s not the point of the thread but you can open a new one if you want
IMO that is the point of the topic: can and should you trust the admins of the communities you participate in?
I don’t think there’s much new coming out of the conversation at this point… a malicious admin doesn’t need impersonate to do this, they could also make a post and change ownership of it. They could edit your existing posts and change your settings without impersonating you. They can also delete edit history to hide this fact to other non-admin users. An admin also doesn’t need to impersonate a user to see everything their account does, and they don’t need console access for that either.
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 can’t trust an admin out of fear that they’ll read your personal messages or alter what you post to harm you, you should not use the site.
10 Likes