Privacy plugin that makes it more difficult for admins to read PMs

Continuing the discussion from Admins can clearly see all private messages of all users:

A while ago, the team has addressed privacy concerns by not allowing moderators to read other users PMs. Requests for adding “administrative friction” to when admins access these PMs have so far been turned down.

My intention with this topic is not to try and change their minds but to inquire whether such a functionality could be added via a plugin and if so, to specify what such a plugin should look like.

To start with, I would like to keep it as simple as possible and here is my suggestion how in very broad terms:

  1. Disallow admins from reading PMs
  2. Specify Super-admins who are allowed to read PMs

(Personally, the way I would use this on my site is that I create a separate super-admin account which I will only use to access PMs in those cases where it is necessary.)

So, how to implement this?

Step 1 should not be a problem, but if system user or discobot need to read access, it may get a bit tricker.

Step 2 should obviously not be possible via the UI but will need to be hardcoded into the plugin source code so that adding or revoking super-admin privileges will require upgrading the plugin.


My question is this: Why is this a problem. Keep in mind as an admin – I can just as easily go into the database and read your PMs if I wanted to…if you don’t trust your admins…why are they admins in the first place?

Admins should NOT be reading PMs unless they have a reason to do so.


I am hesitant to get back into that discussion as that question has been treated in a number of topics and for me the conclusion from those debates is that such a feature apparently makes sense for some communities but not for others. I don’t want to convince anybody that they need this, but I do think that there are a number of reasons what you or a community might want this.

Here are some examples (quickly selected, so I may have missed some important ones):

My aim here, however, is to see if and how this can be implemented as a plugin.

1 Like

I mean one way to do this – would be to log when this happens in the audit trail.

That’s a sane approach.


I believe that is already being done.

1 Like

Has it? I haven’t seen it…


Hm, you seem to be right. I think when I read this, I simply assumed that this has meanwhile been implemented:

But while an audit trail would be good, I don’t think it could replace the plugin proposed here. They are complementary. The logic of the audit trail is that of the panopticon: it disciplines people because they know that they can be watched so they have to assume that they are always watched. The logic of the plugin is more like the requirement in organizations that a payment order always has to be signed by two people or, well, disallowing moderators to read PMs (which is already implemented), or perhaps like locking your car even though you can see it from the kitchen window.

1 Like

I…guess but the larger problem of not being able to trust admins is still a HUGE issue here.

A plugin that forbids reading someone else’s messages should be easy to make. Look at the “guardian” classes.


I good start would be forking and modifying this plugin


Some additional historical context in this topic (not the original topic title):


I don’t know about the OP request. But on the topic of trusting admins, some day I’d like to see another level of privs between mods and admins, for designers/configurators who don’t need to have full access to ssh, backups, private messages etc, but would be able to access some sections that mods can’t, including admin settings, customizations and logs.

These are people who come in from time to time to help out with setting up discourse and are not really part of the community, and wouldn’t even show up on the staff page. They don’t need god privileges.

1 Like

I think the ideal implementation would be something like this:

  • create a special User wrapper in Guardian that works like the AnonymousUser pseudoclass, except its only change is making admin? / is_admin? return false
  • call the can_see? method twice, the second time with the wrapper around the user
  • if the response is true, false - i.e., the reason they can see the post is because they’re an admin - show interstitial before rendering thread

required test: a category with permissions of admins: see does NOT result in interstitials - this should only affect literal is_admin? checks in Guardian
required: on dismissing the interstitial, store now + 4 hours, do not show interstitial if stored time is after now (see chrome’s SSL warnings research)


How much time would you estimate this plugin would take to create?

Is it possible to add encryption to the PMs like the plugin for vbulletin does? Private Messages Enhancements - PMCrypt - Private Message Encryption - Forum

Admins in this context are functional admins, not technical admins.
In a hosted solution the system administrator is a totally different person than the forum administrator.

Without data explorer there is no database access for forum admins.


Î would treat that as a separate plugin, because:

1 Like

Ok. I know thats how we stopped this in VB when we used it. If anyone does want to look at that plugin, I have it for anyone to view on how it worked. Wasnt hard from what the developer told me.

1 Like

They can get backups, unless that is disabled which has ethical problems.


I’m curious. If it is not the Admin that is entrusted with the responsibility to be ethical and not “snoop”, who would have the ability to check accusations of PM misuse?

It sounds like what is wanted here is a role other than moderator - admin - dev
Something like “lead moderator” that is the sole “guardian of the PMs”