PC-Admin/redlight
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update readme/technical documents

Browse Source
This commit is contained in:
PC-Admin 2023-08-16 04:32:01 +08:00
parent ea4c93d07c
commit b02d68f02f
2 changed files with 11 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -6,11 +6,11 @@
_"The red light means STOP!"_
An advanced abuse management tool. It's a Synapse module that allows server owners to either run a "redlight server", or to act as a "redlight client" to prevent their own users from accessing abusive rooms. It's designed to block child sexual abuse material (CSAM) and other abusive content on the Matrix network.
An advanced abuse mitigation tool. It's a Synapse module that allows server owners to either run a "redlight server", or to act as a "redlight client" to prevent their own users from accessing abusive rooms. It's designed to block child sexual abuse material (CSAM) and other abusive content on the Matrix network.
This software attempts to resolve the complex problem of how to share pointers to rooms containing abusive content in order to block or report activity. These room lists are sensitive and sharing them can not only aid people in blocking this content but also direct bad actors to said content.
The goal of this tool is to block abusive content across many small to medium sized servers without exposing the sensitive room_ids in the "source list" to those servers/users. It will also "freeze" abusive accounts and provide real-time alerts about their activity to homeserver owners.
The goal of this tool is to block abusive content across many small to medium sized servers without exposing the sensitive room_ids in the "source list" to those servers/users. It will also "freeze" abusive accounts and provide real-time alerts about their activity to the homeservers owners.
## Features
@ -26,7 +26,7 @@ The goal of this tool is to block abusive content across many small to medium si
"Redlight servers" will be trusted homeservers that are modified, they'll cache the source list in memory while providing an API interface to "Redlight clients". Redlight servers will pick their own "content tags" that they are filtering, which by extension will allow clients to pick a level of filtering that suits them.
Redlight clients will be untrusted homeservers that are whitelisted by their desired Redlight server. When a user on a client homeserver attempts to join a room, the hashes of the user_id and room_id will be sent to the redlight server, which will confirm or deny if the room is abusive, the client then denies the user entry to that room if it is flagged. If a user attempts to access abusive rooms multiple times their account will be "frozen" and attempts to access any further rooms will be denied. Real-time alerts about users accessing abusive rooms or account freezes will also be sent to an alert room on the redlight clients server.
Redlight clients will be untrusted homeservers that are whitelisted by their desired Redlight server. When a user on a client homeserver attempts to join a room, the hashes of the user_id and room_id will be sent to the redlight server, which will confirm or deny if the room is abusive, the client then denies the user entry to that room if it is flagged. If a user attempts to access abusive rooms multiple times their account will be "frozen" and attempts to access any further rooms will be denied. Real-time alerts about users accessing abusive rooms or account freezes will also be sent to an "alert room" on the redlight clients server.
For a more detailed description of how it will work please consult the [Technical Specification](./technical_spec.md).

10
technical_spec.md
View File

@ -67,7 +67,7 @@ Blocking not monitoring, to avoid scope creep the point of this system will only
Client homeserver privacy, by double hashing the user_ids and room_ids before sending them to redlight server, analysis and collection about the rooms accessed by a redlight clients users is limited.
~~Config-driven and stateless, ideally redlight clients and servers will be "stateless", so no data will persist between reboots and their behaviour will be defined entirely in configuration files.~~
~~Config-driven and stateless, ideally redlight clients and servers will be "stateless", so no data will persist between reboots and their behaviour will be defined entirely in configuration files.~~ A database is probably needed for redlight servers.
## LJS-4.draft: Abuse Lookup API V1
@ -86,7 +86,8 @@ return either `200 OK` to signify a match or `204 No Content` to signify no matc
```js
{
"room_id_hash": "5dd9968ad279b8d918b1340dde1923ed0b99f59337f4905188955bf0f1d51d9f",
"user_id_hash": "6123512760887c37bb7b550a1a3caa8b8cd954706f4cc7fe934cb42611132627"
"user_id_hash": "6123512760887c37bb7b550a1a3caa8b8cd954706f4cc7fe934cb42611132627",
"api_token": "Um05ULjUngjVbibdgtipo96VUSrEexOi8z7F8HfK"
}
```
@ -119,4 +120,9 @@ More then 10 join requests in a minute might seem suspicious... (What about bots
API tokens, certificate-based authentication, or domain whitelisting?
API tokens seems like the move.
- What other methods could be used to secure the source list and prevent interception/leaking?
TPM/secure enclaves?
Encrypted in memory?