From a05c1739a79b5f5921efdeb52ac2d34f583592c4 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Wed, 2 Oct 2024 14:48:11 +0100 Subject: [PATCH] Link up MSC --- ...entity.md => 4205-sha256-policy-entity.md} | 21 +++++++------------ 1 file changed, 8 insertions(+), 13 deletions(-) rename proposals/{0000-sha256-policy-entity.md => 4205-sha256-policy-entity.md} (70%) diff --git a/proposals/0000-sha256-policy-entity.md b/proposals/4205-sha256-policy-entity.md similarity index 70% rename from proposals/0000-sha256-policy-entity.md rename to proposals/4205-sha256-policy-entity.md index ad9900331b1..461539a29f1 100644 --- a/proposals/0000-sha256-policy-entity.md +++ b/proposals/4205-sha256-policy-entity.md @@ -1,4 +1,4 @@ -# MSC0000: Hashed moderation policy entities +# MSC4205: Hashed moderation policy entities Currently, moderation policies describe the entity they are targeting by including a literal identifier in the `entity` field. @@ -10,7 +10,7 @@ This is problematic for multiple reasons. The literal entities can propagate abuse. For example, if the user `@i.hate.example.com:example.com` is banned, then the -mxid will be embded in the policy. +mxid will be embedded in the policy. Additionally, users have been known to embed or masquerade URLs into their mxids. @@ -63,7 +63,7 @@ None considered. It's important for policy curators to understand that this proposal does not prevent published hashes from being reversed. The mechanism that allows moderators to reveal banned users (by encountering them in -their community) is effectively a dicationary attack against the +their community) is effectively a dictionary attack against the policy list. This is how the proposal works by design. But this means that a third party that collects a sufficient amount of data on the Matrix ecosystem can reverse the hashes in the same way that a @@ -72,23 +72,18 @@ clear text. It's important to note that the hashes are only there for obscuration purposes, to provide an indirect means to address entities. In order -to hide abuse embeded directly within the identifiers. If attackers +to hide abuse embedded directly within the identifiers. If attackers have to go elsewhere to view the list or go through extensive data collection to reveal all the hashes, then this is a secondary success. ## Unstable prefix -*If a proposal is implemented before it is included in the spec, then implementers must ensure that the -implementation is compatible with the final version that lands in the spec. This generally means that -experimental implementations should use `/unstable` endpoints, and use vendor prefixes where necessary. -For more information, see [MSC2324](https://github.com/matrix-org/matrix-doc/pull/2324). This section -should be used to document things such as what endpoints and names are being used while the feature is -in development, the name of the unstable feature flag to use to detect support for the feature, or what -migration steps are needed to switch to newer versions of the proposal.* +`org.matrix.msc4205.hashes` -> `hashes` ## Dependencies - While not a dependency, the example shows the `m.takedown` - recommendation, which is described in MSC0000 where is it FIXME - AAAAAAAAAAa. + recommendation, which is described in [MSC4204 `m.takedown` + moderation policy + recommendation](https://github.com/matrix-org/matrix-spec-proposals/pull/4204).