매우 유감입니다. 많은 분들이 PM 시스템에 존재하는 이 일종의 '빈틈(loophole)'을 인지하지 못하고 있을 것 같습니다.
저는 해당 메시지를 이동하거나 수정하는 Customization > Theme component 를 사용해 왔습니다. 저는 많은 분들이 PM을 열람하는 것이 얼마나 쉽고 유혹적인지(특히 전체 권한이 없는 경우 관리자만 가능)를 모르고 있다고 생각합니다.
제안 : 저처럼 자신이 초대받지 않은 PM을 열람하기 전에 한 단계 더 확인하는 절차를 원하시는 관리자를 위해, 메시지/경고 프롬프트/옵션을 비활성화(숨김)할 수 있는 사이트 설정을 추가하면 어떨까요?
추가로, 열람 중이 있을 때 ‘좋아요’ 버튼을 숨기는 것도 좋은 방법입니다. PM 트리/대화를 확인하는 과정에서 실수로 누르기 매우 쉬우기 때문입니다. 대화에 참여하지 않는 멤버가 누군가가 PM에 '좋아요’를 눌렀다는 것을 보면 당황할 수 있습니다. 저도 한 사용자가 저에게 독성(toxic)을 보일 때 이런 일이 있었습니다. 당시 한 모드가 사이트 정책에 대해 그 사용자를 가스라이팅하고 있었으며, 저는 클라이언트의 지시에 따라 그 모드의 과도한 반응(부적절하게 침묵/정지 조치)을 되돌리고 있었습니다. 그 모드는 제가 그의 과도한 행동을 되돌리는 것에 대해 불만을 품고, 다른 멤버들을 가스라이팅하여 제가 사용자를 BAN하라고 요구하거나 그의 상급자에게 제에 대해 불평하도록 조종하려 했습니다.
다행히 제가 실수로 '좋아요’를 눌렀다가 취소한 사용자는 이해해 주었지만, 처음에는 PM이 예상과 달리 실제로는 비공개가 아니라는 사실에 꽤 충격을 받았습니다. 그렇지 않았다면 커뮤니티 전체에 신뢰 위반으로 인해 큰 파장이 일어났을 수 있습니다.
End-to-end encryption is a pretty complex solution for that problem, and brought with it a ton of other UX problems. So it would be much better if we can resolve that ‘accidental staff access’ concern in a simpler way.
We have this site setting which we’ve been developing for a while. I just went ahead and un-hid it so it’ll be available in the admin UI:
This will suppress topics and PMs from the UI for admins, unless they are participants. Please note though: it is not a security feature. Admins can still access anything. It’s just a bit of extra friction to mitigate with the ‘accidental’ cases you described.
At which places are PMs suppressed?
I just activated the setting and created a category which I limited to a group I am not a member of. That worked as described. I don’t see that category in the categories list.
I also noticed that clicking on a link to a PM takes me to the “this page is private” page. But I am still able to read parts of PMs at other places. So I guess I misunderstood the feature.
For example, I can read the beginning of the message when checking which posts a user liked or reacted to, which I often do (except when I am an admin).
This is quite positive move. However if I may if it is not setup this way. Make this setting require logging into the server and command line.
I appreciate the complexity of end2end encryption and suspect after recent issues the Telegram founder has had over it being arrested in France. That the End to End will not be as secure as it once was there
I do also understand some per case uses really need to have Direct Messages (personal messages really can be confused with private) may need to be monitored
Ie
Schools, companies using it as a platform for employees resource say for company specific. Etc .
So as a suggestion. A cmdline setting to enable Admin wide access to pm)group messages etc .
With options
Full enable perm while on
Enable for target admin. No other admins have ability. Good if some admins are there for Theme & theme component management.
Time limit option hour=x after x reverts to previous state of off.
maybe an option to target specific user or group for investigating an unreported suspected abuse or request from law enforcement with necessary court order maybe?
Yup, those are both places where this setting suppresses the content
Indeed, this site setting is just a bit of extra friction to prevent accidental access in the most common places. It does not cover all parts of the UI, and it is not considered a security feature.
Admins having full access to all content is very deeply-engrained in Discourse’s source code. Changing that will not be trivial.
In its current form, it is not a security feature, so restricting it to the console wouldn’t make a difference to security either way.
I realise you are both asking for a more fully-fledged version of this feature, which is a completely valid request. It might be something we do in future, but I’m afraid we don’t have any plans to prioritise it in the near-term.
The user’s activity page is a quite common place for me; I frequently use it as a user. And it’s one of the places where it’s very difficult to notice that you also read PMs there as an admin.
Maybe the settings description is promising too much, as it says “in the admin UI” rather than “in some common places of the admin UI”.
Suppress topics and PMs from the admin UI unless they are participants. This is not a security feature: admins can always access all content on the site if needed.
Well this is where we as site staff ourselves also need to recognize and appreciate as the adage goes “Rome wasn’t built in a day”
It requires time and resources. You sharing the team’s progressive update introducing this very positive first steps is fantastic. And while we are providing feedback/critiques. It is only to help foster the real needs to have this eventually more complete.
In @Canapin 's topic that was made long ago There was a clear example if a community discovers the use of this feature/exploit can really damage a community. In that example a member here mentioned a competitor who had used this and was discovered and exposed lost the trust of the community resulting in a fair number leaving that forum and joined theirs.
Having being involved with Discourse for over 7+ years I have observed the team rethink their position on a variety of things they were flatly opposed to implementing. Like the option for users to block others. While it is a start on that. There is still much needed parity with other platforms that have proven a more complete block)/ignore user is needed and dies not actually interfere with having good discussion in a topic where users have used the block that is mutual. The current form is more like a personal shadow ban. The blocked user can still responses to a user who has blocked them.
That’s fair. How about this as an improvement to the description?
Suppress private topics and PMs in some parts of UI for admins. Content will still be visible in some places. This is not a security feature: admins can always access all content on the site.
we really welcome this feature as we are running an 100% pseudonymous community and don’t allow users to post any real names or addresses etc.
One challenge that we have to is to enable a secure way to exchange shipping addresses for the contests in our community. Before, we used the E2E encryption to make sure, that users can send their address via PM to the sponsor without admins or mods having access.
For our particular use case, we would love to see group-based permission setting. That way only actual participants can send a PM which admins/mods don’t have access to.
: 저처럼 자신이 초대받지 않은 PM을 열람하기 전에 한 단계 더 확인하는 절차를 원하시는 관리자를 위해, 메시지/경고 프롬프트/옵션을 비활성화(숨김)할 수 있는 사이트 설정을 추가하면 어떨까요?
