Application blocking admins from reading member PMs

[Jordan Miller]

Hey there. Wondering... would anyone else be interested in an application / plugin that barred administrators from reading member's PMs?

I'm the only admin on my site currently, but it's just the principal of it.

I would feel more comfortable knowing that my member's had this step towards privacy in place.

I would never read my members' PMs, and have read the arguments here why this feature should still exist, but I personally would like to remove that capability out of principal.

Thoughts? 

[Daniel F]

There's no such feature in the core. The only way to read PMs would be by using the sql toolbox or allowing them to login as the user, so just don't give them the permission to use the SQL toolbox and to login as other users?! 

[Adriano Faria]

You just need to not browse a couple of tables in your database and if you login as the member, it’s enough to not go to the messenger. 

As I imagine other admins won’t have access to your database, you can probably restrict them in ACP profiles, so they won’t be able to login as any member.

Note: certainly there’s a admin restriction to login as a member but I don’t remember. So I would try that first. 

[CoffeeCake]

4 hours ago, breatheheavy said:

Wondering... would anyone else be interested in an application / plugin that barred administrators from reading member's PMs?

What's the thing you're trying to accomplish here? As @Daniel F pointed out, there's no built in mechanism to access private messages of anyone else (other than if the private messages are reported by a participant in the conversation).

• Are you trying to block the ability to report PMs?
• Are you trying to block the ability to "log in" as a user? This is a setting you can restrict in the Members > Administrators, as @Adriano Faria shared.
• Do you have some third party app that allows you to read member PMs?

I'm assuming you're trying to block this from a group of administrators that cannot install/uninstall/enable/disable applications.

[CoffeeCake]

Edit: I just re-read your post. I see it's a matter of principle now... missed that on the first read.

You have to ask principled questions, to which there are no "right" answers--whatever fits for your community:

• Do you want to be able to respond when a member is being harassed or spammed or something similar by another member via private messaging? If so, you probably want to keep the ability to report PMs enabled, and you probably want to read only those PMs in the report center.
• Do you want to make sure that no one can log in as another user? Turn off this option for your account, and don't extend it to anyone else.
• Do you want privacy protections above what is provided by IPS? You'd need to do something like encrypt PMs, transmit those encryption keys to members, and not store a copy of those encryption keys so that the data within the database is unreadable without the key and can only ever be decrypted by the member. This would make things rather user unfriendly, but maybe there's a need for you. This is probably a very large technical hurdle to cross.

At the end of the day, you are entrusted with user information as an administrator. You probably want to look into things like non-disclosure agreements if you bring in others that have elevated access.

[Jordan Miller]

1 hour ago, Paul E. said:

Edit: I just re-read your post. I see it's a matter of principle now... missed that on the first read.

You have to ask principled questions, to which there are no "right" answers--whatever fits for your community:

• Do you want to be able to respond when a member is being harassed or spammed or something similar by another member via private messaging? If so, you probably want to keep the ability to report PMs enabled, and you probably want to read only those PMs in the report center.
• Do you want to make sure that no one can log in as another user? Turn off this option for your account, and don't extend it to anyone else.
• Do you want privacy protections above what is provided by IPS? You'd need to do something like encrypt PMs, transmit those encryption keys to members, and not store a copy of those encryption keys so that the data within the database is unreadable without the key and can only ever be decrypted by the member. This would make things rather user unfriendly, but maybe there's a need for you. This is probably a very large technical hurdle to cross.

At the end of the day, you are entrusted with user information as an administrator. You probably want to look into things like non-disclosure agreements if you bring in others that have elevated access.

Appreciate the feedback, guys!

Yes, it's more of the ethics behind it. Imagine if you knew with 100% certainty Apple could read your text messages. They promise they won't, but they could.

I do like the ability to login as a user, because it's useful when debugging an issue, but something about having access to their PMs has always irked me. 

In my ideal world, admins can login as other members, but the system doesn't give access to PMs. If there is harassment etc then that will have to be dealt with another way (versus an admin going into the inbox and having a look for themselves).

Thoughts? 

Edited October 1, 2020 by breatheheavy

[christopher-w]

32 minutes ago, breatheheavy said:

Appreciate the feedback, guys!

Yes, it's more of the ethics behind it. Imagine if you knew with 100% certainty Apple could read your text messages. They promise they won't, but they could.

I do like the ability to login as a user, because it's useful when debugging an issue, but something about having access to their PMs has always irked me. 

In my ideal world, admins can login as other members, but the system doesn't give access to PMs. If there is harassment etc then that will have to be dealt with another way (versus an admin going into the inbox and having a look for themselves).

Thoughts? 

I agree with your sentiments. I’ve had my messages read by admins on more than one forum over the years and immaterial of a forum’s terms and conditions, if that happened to me today, given tighter control of privacy, I’d report it to the data protection authorities. 

Even if it was considered acceptable practice, and it never would to me, mail/pms that have been read should be marked as such - when it was read and by whom. Just as mail used to be when it was intercepted by the authorities and read in the interests of the authorities/government/country. 

Just another small point. The use of the term pm or personal message should be reviewed by those platforms that use it. It suggests communication is personal which of course, on boards that have the ability to read it, it most certainly isn’t.

So in summary if one is going to read mail/pms for whatever reason, state openly to members that admins might exercise that ability and if they do, the communication will be marked and time stamped to reflect it. 

Edited October 1, 2020 by christopher-w
Format

[Jordan Miller]

6 hours ago, christopher-w said:

So in summary if one is going to read mail/pms for whatever reason, state openly to members that admins might exercise that ability and if they do, the communication will be marked and time stamped to reflect it. 

I do think this is a good compromise for those that don't mind.

I also agree that PMs imply that it's private and it would be kept that way.  However, really, this is all an illusion of privacy. No one, not even the admin of the forum, should (in my opinion) have the ability to read private messages. 

Edited October 2, 2020 by breatheheavy

[CoffeeCake]

To address the language issue, you can use the translation feature to rename "Private Messages" or "Personal Messages" (or whatever it's called--we don't use private messaging, so.. no idea) to whatever you'd like it to be called instead.

8 hours ago, breatheheavy said:

However, really, this is all an illusion of privacy.

I think that you'll find that when you start to explore preventing this, you'll find that you're just adding layers to that illusion. The only way to achieve assurances that communications are private are to encrypt those communications in a way that you, and anyone with access to your site's infrastructure, cannot decrypt them. Maybe you create an extension that blocks access via the interface, but someone at your provider accesses the database directly? Maybe an admin turns off the modification to access messages and then back on? Where does it end?

You'd need to permanently encrypt the data in the messaging tables to prevent decryption even after the modification were removed. And now that you've done this, how do you address individuals using this functionality for illegal things? Are you now liable for providing a mechanism to do so? You can't address people reporting bad messages because you can't see them now that they're encrypted. Nothing within IPS can decrypt the messages in this hypothetical modification, so you're now just relying on the reports of those involved in the conversation.

As for logging and displaying logging, that's again dependent on no access to the database. Another illusion. Certainly it would address those with limited access, but you? Your web host?

I'd ask a lawyer lots of questions. As @christopher-w points out, make sure your disclosures are clear. Be clear with the technical limitations, set policies that are appropriate for your site, audit those policies regularly, and be clear with what your platform is not. Encourage people that want end-to-end encryption to take their conversations to a place that provides that and make the assurances someone else's responsibility so you can focus on your core audience. Turn off the native messaging feature in IPS and find a provider that will work with OAuth or similar to integrate.

[Jordan Miller]

2 hours ago, Paul E. said:

To address the language issue, you can use the translation feature to rename "Private Messages" or "Personal Messages" (or whatever it's called--we don't use private messaging, so.. no idea) to whatever you'd like it to be called instead.

I think that you'll find that when you start to explore preventing this, you'll find that you're just adding layers to that illusion. The only way to achieve assurances that communications are private are to encrypt those communications in a way that you, and anyone with access to your site's infrastructure, cannot decrypt them. Maybe you create an extension that blocks access via the interface, but someone at your provider accesses the database directly? Maybe an admin turns off the modification to access messages and then back on? Where does it end?

You'd need to permanently encrypt the data in the messaging tables to prevent decryption even after the modification were removed. And now that you've done this, how do you address individuals using this functionality for illegal things? Are you now liable for providing a mechanism to do so? You can't address people reporting bad messages because you can't see them now that they're encrypted. Nothing within IPS can decrypt the messages in this hypothetical modification, so you're now just relying on the reports of those involved in the conversation.

As for logging and displaying logging, that's again dependent on no access to the database. Another illusion. Certainly it would address those with limited access, but you? Your web host?

I'd ask a lawyer lots of questions. As @christopher-w points out, make sure your disclosures are clear. Be clear with the technical limitations, set policies that are appropriate for your site, audit those policies regularly, and be clear with what your platform is not. Encourage people that want end-to-end encryption to take their conversations to a place that provides that and make the assurances someone else's responsibility so you can focus on your core audience. Turn off the native messaging feature in IPS and find a provider that will work with OAuth or similar to integrate.

Good points! Renaming the private messages to anything else feels a little like a band-aid solution though, because messages in this fashion across the board are considered private. There's an expectation (imo) that these messages cannot be accessed.

I think if an admin starts snooping through database tables, then yea it ultimately doesn't solve the issue, however the accessibility in which one's messages are available at the moment is a little irky to me. 

I'm actually a little surprised at the pushback here (generally speaking, nothing against you in particular at all!). 

[CoffeeCake]

1 hour ago, breatheheavy said:

I'm actually a little surprised at the pushback here (generally speaking, nothing against you in particular at all!). 

Can't speak for anyone else, but want to make sure for those happening upon this, that it's not as simple a thing as it seems on its face. There are legal, technical, and policy factors to consider that make this a tough cookie to break, and if the goal is an assurance that the owner of the site cannot in any way read the data in any circumstance, end-to-end encryption where only the end users have the keys is the only viable solution and where no plain text data of those messages are stored.

[CoffeeCake]

3 hours ago, breatheheavy said:

the accessibility in which one's messages are available at the moment is a little irky to me

You may want to audit your administrator settings then. It can certainly be configured in such a way that you cannot see them through the interface.

• Turn this off: Members > Administrators > <Your Administrator Group> > Settings > Can sign in as members
• To stop the ability to report private messages: For each of your user groups, turn off "Can report Personal Conversations."
• Disable SQL Toolbox in Members > Administrators > <Your Administrator Group> > Support > SQL Toolbox to prevent direct, unfettered access to the database via Admin CP, a gaping security hole feature I didn't even know we had.

Those are the only two three ways (I'm aware of) you can see messages that are in another user's PMs via the web interface.

Edited October 2, 2020 by Paul E.
And then there were three.......

[CoffeeCake]

On 10/1/2020 at 10:06 AM, Daniel F said:

give them the permission to use the SQL toolbox

What is this?? I've never seen a SQL toolbox.

Edit: Never mind I just found it hidden as a link the support page. How on earth do you disable that? Is that considered part of diagnostic tools? That really should have a separate permission.

I would like to clear cache and such, but no access to SQL toolbox. I don't see a separate permission for it. This should totally have a separate permission.

Edited October 2, 2020 by Paul E.
oh noes. it does exist.

[Daniel F]

26 minutes ago, Paul E. said:

What is this?? I've never seen a SQL toolbox.

Edit: Never mind I just found it hidden as a link the support page. How on earth do you disable that? Is that considered part of diagnostic tools? That really should have a separate permission.

I would like to clear cache and such, but no access to SQL toolbox. I don't see a separate permission for it. This should totally have a separate permission.

This is already an own separate permission.

 

[CoffeeCake]

36 minutes ago, Daniel F said:

This is already an own separate permission.

That's what I get for translating the phrase "Support" 🤓

 

[Jordan Miller]

1 hour ago, Paul E. said:

You may want to audit your administrator settings then. It can certainly be configured in such a way that you cannot see them through the interface.

• Turn this off: Members > Administrators > <Your Administrator Group> > Settings > Can sign in as members
• To stop the ability to report private messages: For each of your user groups, turn off "Can report Personal Conversations."

Those are the only two ways (I'm aware of) you can see messages that are in another user's PMs via the web interface.

Appreciate the suggestion, thank you! 

 

1 hour ago, Paul E. said:

Can't speak for anyone else, but want to make sure for those happening upon this, that it's not as simple a thing as it seems on its face. There are legal, technical, and policy factors to consider that make this a tough cookie to break, and if the goal is an assurance that the owner of the site cannot in any way read the data in any circumstance, end-to-end encryption where only the end users have the keys is the only viable solution and where no plain text data of those messages are stored.

Now we're talking 😎 Yes, this is exactly what I'd love to see in the future. That members can be assured their private private messages are indeed private.  🙂 I don't know the logistics of it all, but this would be a step in the right direction concerning privacy. 🙏 

[CoffeeCake]

Updated with the third way I didn't realize IPS had.

6 minutes ago, breatheheavy said:

Now we're talking 😎 Yes, this is exactly what I'd love to see in the future. That members can be assured their private private messages are indeed private.  🙂 I don't know the logistics of it all, but this would be a step in the right direction concerning privacy. 🙏 

This would probably have a better user experience using something else, like an app, that would have the ability to store a key locally. For this to work, the end user would need to provide their decryption key somehow/somewhere when they'd want to access their messages.

I would strongly recommend looking into integration with a service that has figured this all out if important to your membership.

[christopher-w]

I had a look at our O365 Exchange account when I first came across this thread. It has snooping tools wrapped up in language that suggests corporations have the right to engage with any information created under its purview.

That’s what we are really discussing here - when a user interacts with a 3rd party entity, be that cloud platform, company system etc, that entity often claims the right to oversight and goes further in assuming, in specific cases, that it has the right to control. 

To my mind the only way to get round the scenario being discussed here is to employ a 3rd messaging platform that sets out to maintain complete privacy for the user. 

Hammer to crack a nut 

So I’m thinking one way forward for this is to develop an encrypted api level integration with one of the many 3rd party messaging systems - one that could also propagate alerts. Login would be handled on and with the client, making it effectively impossible for snoops to eavesdrop on pms. 

Failing this, I’d also look at third party email integration, again with everything handled on the client, with email username entered  during sign up and with password entry and message retrieval handled during client sessions. After all that’s what happens with billions of email clients everyday. No reason why the same system can’t be embedded in a 3rd party cloud system such as this. 

48 minutes ago, Paul E. said:

I would strongly recommend looking into integration with a service that has figured this all out if important to your membership.

Interesting. Our thoughts crossed.