I’m not sure I agree. What I think is really happening here is people are using a system they do not fully trust (or fully trust the staff/company that maintains said system). In which case, don’t use it. This is the Internet, if you are not 100% okay with someone else potentially reading what you wrote, find a different mechanism that you do trust.
7 Likes
Yes, I admit, this topic does feel like a rehash of the older “private isn’t private” discussions. To me, as long as the action is logged accountability is possible.
5 Likes
I think that in order to understand why there are so different perspectives on this question, we need to acknowledge the huge variety of different use cases for discourse and the tacit assumptions that come with each of these. Each of us surely is aware of a number of different communities using discourse, but I believe that none of them captures the whole variety that exists out there.
For example, in certain contexts it is probably right to point out that “If you don’t like it or don’t trust it, don’t use it.” But in other settings people don’t have much of a choice: if they want to participate in the life of a specific group of people (say, fellow students at department X), they will need to sign up to that discourse forum that everybody else is using, just like it is difficult these days to not “be on Facebook”.
Another thing that I think is worth considering is that what is at stake with privacy is not just the “big things” which, if they are made public, can create big scandals, but also the trivial and seemingly small things. Like when user A sends a PM to user B making a joke about user X or complaining about moderator Y. Not a big deal, one might say, if an admin reads these (whether by mistake or as “collateral damage” or illegitimately out of curiosity). But small causes can have big effects and even small effects can be big for those directly involved. The main threat to privacy, is probably not that some highly confidential information is revealed (because it would be stupid to send it via PM in the first place) but that seemingly non-confidential information is revealed simply because that is the kind of information that admins can expect to find in PMs, thus making it a minor offence to take a peek.
Finally, when it comes to the reasons why a particular forum comes to implement a higher level of privacy, I think we should distinguish between reasons coming from the community (i.e. users) and reasons coming from admins. We cannot assume that it is always the users who are demanding more privacy. It may well be admins/site owners who want to be able to tell their users that, yes, they can read their PMs but, no, it is not so easy that you could do it accidentally or casually. Why would they want to say that? For example to attract new users who don’t know the community or the admins yet.
For the time being, viewing PMs is not being logged in discourse.
3 Likes
That seems to fall under, my if you don’t trust it, don’t use it though. If you are concerned about something you say in a PM to another user because it is about someone at the same site with a higher status, then don’t say it there. Go elsewhere to say it.
To be honest, I get there are many circumstances for wanting this, I just disagree that adding encryption, or limiting admin use is going to solve your problems/concerns. Take creating a plugin to implement a change to the Guardian for limiting admins from viewing the PM. What does that solve? As an admin, I can download yesterday’s backup, restore the database, and browse to my own content through all of the PMs. It accomplished nothing.
Encryption, sure that could work… until technology catches up and makes the encryption used trivial to break.
In the end, you are just trying to make something less convenient, but that something is still possible to achieve.
This logic doesn’t work for Facebook or Google (Gmail) to relieve them of their duty to always reasonably try to build sufficient audit trails in admin processes. Indeed:
So instead of lobbying for a plugin that provides a false sense of security perhaps start by lobbying for extra auditing and funding that 
For the record, it is “sort of logged” in that you will have topic tracking state for the PM you don’t have explicit permission to view. I can quite easily make a data explorer query for this.
7 Likes
How will this work in practice? Say user X who reads this topic wants to tell you “Don’t bother discussing with Christoph, I’ve tried it before”. How can user X contact you except via PM?
And, taking the admin rather than the user perspective, what if I, as the admin of a forum, don’t want my users to run away to some other tool, just because I’m higher status?
I really appreciate you saying that because I often get the impression that trying to “lobby” for a feature that has already been discussed is not a good idea… 
But seriously, I see both features as complementary. One doesn’t exclude the other and since the team has already announced that this will come while it has rejected any further friction for admins, I thought it makes more sense to explore the plugin option.
That hardly seems like something a good admin would concern themselves with (if the inadvertently read it).
Good luck with that. Might as well make them all relocate to a fortified city that you control the gates on too.
The point is, you can put all the controls you want in there, it is simply a false sense of security. You are better off updating your privacy policy to let your users know what data you have, how and when you will access said data, and ask for a stronger auditing log or a query that will let you see who has viewed what recently (when it comes to PMs).
The one thing I’ve yet to see from a single request in this area is exactly how you would expect limiting control to resolve the issue of the admin downloading a backup and viewing the data that way (encryption comes closest to solving this). Again, if the pure thought is, make it less convenient, that really doesn’t resolve any trust issues users may have with expressing themselves in PMs and an Admin potentially reading it.
The only thing I can think of that might work would require more complex separation of roles. eg.
System Admin - access to CLI, backups, plugins
Admin - access to setting options
Moderator Admins - handle day to day moderation decisions
MA-1 messages MA-2 saying “I need to check a PM because _____, please log in at 5PM and go to ____”
Code checks if(MA-1 && MA-2) and if both are there grant read.
The “regular” Admin and Moderators could not read PMs
The “moderator” Admins could, but only when both agree the action has probable cause.
The “system” Admin could always see the database
All this would do is shift the trust issue on to the “system” Admin, not obviate the concern entirely.
IMHO it would be a lot of work with no real gain.
If someone can think of a way to trust someone to do things they don’t trust them doing I would be interested, but it seems like a paradox to me.
2 Likes
I agree that the sense of security would be false, but I fail to understand why such a plugin would even create a sense of security.
The end user has no way of actually checking what permissions admins have. As long as the PM is in the system, it’s technically possible that an admin could read it; whether the way for the admin to actually do it is simple or made complicated by a plugin the admin claims to have installed.
The only thing that can provide a sense of security is a strict privacy policy, because it has an effect measurable for the end user: It makes reading the PMs illegal, with no way for an admin to circumvent this (legal) fact.
1 Like
Someone has to be able to read PMs, however onerous that process is made. Perhaps the underlying issue here is one of user expectation. If users know from their first PM that it can be accessed by admins then they can act accordingly and not feel like there has been a breach of implicit trust. It might even make some users feel more secure to know that they can’t be assailed behind closed doors.
Having said that, it is currently very easy for an admin to start idly perusing messages intended for another audience. Adding a level of friction might just give an appropriate level of gravitas to the act of transgressing on what we are, after all, still calling a Private Message.
2 Likes
I’m honestly shocked there is no audit log when people read PMs…
Read Sam’s remark, there technically is, you just have to write a query in Data Explorer to get to the data (query to be defined).
I do agree with this, though I don’t think that anything more than a client-side only click-through screen is required. Just, “Hey, you’re about to start using your admin powers, k?”
Pulling out the network response, downloading the database, and impersonating the user all have a certain sense of purpose / intent to them that clicking on someone’s link to a PM topic they are in doesn’t.
3 Likes
I think if the prompt could make mention of the fact that the action will be audited it should make an Admin pause to consider. It flips the rationale from do I want to read other peoples’ PMs to can I justify reading them. Ultimately every user is at the mercy of the site admin but a gentle prod to the conscience here and there can’t hurt.
1 Like
So, let me try to summarize the discussion so far. I see three basic proposals to improve privacy on discourse:
- Improve the audit trail, i.e. add the reading of others PMs to /admin/logs/staff_action_logs (this is, I believe, on the team’s todo list)
- Add a modal or a click-through screen when accessing others’ PMs so that the Admin is reminded that this should only be done in justified cases and that this action will be logged. I might add a somewhat more restrictive version 2c where the admin is prompted to re-enter their password before being granted access to the PMs.
- Add another admin level under the current one which does not have access to PMs (and possibly not the database either). A more sophisticated version 3b of this is to allow the lower admins to access PMs if two of them do it simultaneously (or perhaps synchronicity is not necessary and it would suffice if one other admin gives their consent.
I think any of these would be an improvement, but my aim would still be #3, mainly because it creates a situation like with most email providers (or most cloud service for that matter): it is clear that someone has access to everything, but that someone are not necessarily the admins active in the forum. It really makes it clear to users that PMs are accessed in very exceptional cases only.
One possibility that has not yet been mentioned is to make the audit trail public (for logged in users). The audit trail could then include a reason for the action which the admin would be asked to fill in on the click-through screen in #2. This version of #2 is aso somewhat intriguing to me, but I suppose it would be much more complicated to implement.
Edit: Please remember that (apart from #1) all of these are proposals for one or more plugins.
2 Likes
My thoughts on your list.
- Regardless of anything else in this topic, this should happen. I agree 110%.
- Not against this. It adds more work to viewing PMs, but perhaps I’m just not understanding why an admin would be going to look at a PM without already having a reason. I think this could simply be an added annoyance.
- I’m absolutely against this. Unless permissions between the 3 staff roles are going to be changeable on a per-site basis, I don’t support adding another staff role into the mix that removes powers from Admins. Access to the Database and viewing PMs are very different tasks. Viewing PMs is needed for moderation reasons, the Database for system administration stuff. Discourse isn’t meant to be for private, secret, secure communications. It’s a discussion platform, not a secure messaging client.
As much as I disagree with #3, I’m even more strongly against this. Admin actions should not be public. Besides the fact that all users now know that someone has been sending PMs (which just became less private), site admins who are investigating something should not need to worry about their investigation being public before they want it to be. If two users are fighting over PM, the entire site doesn’t (and shouldn’t) need to know that an Admin is investigating this.
3 Likes
Of course permissions should be changeable (though maybe I don’t understand what you mean by that?).
If you don’t see much use in the plugin, what does it mean to be against it’s features?
I meant changing what the super admin, admin, and moderator could do - not who has each role.
Totally missed that this was proposed to be a plugin…
2 Likes
Although my priority in this plugin would still be the added friction, it occurs to me that an extended version of a privacy plugin could also address this issue (or parts of it):
1 Like