Clarify that redaction events are subject to auth rules (#1824)

Signed-off-by: Matthias Ahouansou <matthias@ahouansou.cz>

changelogs/room_versions/newsfragments/1824.clarification

@@ -0,0 +1 @@
+Clarify that redaction events are still subject to all applicable auth rules.

content/rooms/fragments/v8-auth-rules.md

@@ -1,12 +1,6 @@
 
 Events must be signed by the server denoted by the `sender` property.
 
-`m.room.redaction` events are not explicitly part of the auth rules.
-They are still subject to the minimum power level rules, but should always
-fall into "10. Otherwise, allow". Instead of being authorized at the time
-of receipt, they are authorized at a later stage: see the
-[Redactions](#redactions) section below for more information.
-
 The types of state events that affect authorization are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
@@ -21,6 +15,18 @@ For example, mentions of the `sender`'s power level can also refer to
 the default power level for users in the room.
 {{% /boxes/note %}}
 
+{{% boxes/note %}}
+`m.room.redaction` events are subject to auth rules in the same way as any other event.
+In practice, that means they will normally be allowed by the auth rules, unless the
+`m.room.power_levels` event sets a power level requirement for `m.room.redaction`
+events via the `events` or `events_default` properties. In particular, the _redact
+level_ is **not** considered by the auth rules.
+
+The ability to send a redaction event does not mean that the redaction itself should
+be performed. Receiving servers must perform additional checks, as described in
+the [Handling Redactions](#handling-redactions) section.
+{{% /boxes/note %}}
+
 The rules are as follows:
 
 1.  If type is `m.room.create`:

content/rooms/v10.md

@@ -76,12 +76,6 @@ correctly structured are rejected under the authorization rules below.
 
 Events must be signed by the server denoted by the `sender` property.
 
-`m.room.redaction` events are not explicitly part of the auth rules.
-They are still subject to the minimum power level rules, but should always
-fall into "10. Otherwise, allow". Instead of being authorized at the time
-of receipt, they are authorized at a later stage: see the
-[Redactions](#redactions) section below for more information.
-
 The types of state events that affect authorization are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
@@ -96,6 +90,18 @@ For example, mentions of the `sender`'s power level can also refer to
 the default power level for users in the room.
 {{% /boxes/note %}}
 
+{{% boxes/note %}}
+`m.room.redaction` events are subject to auth rules in the same way as any other event.
+In practice, that means they will normally be allowed by the auth rules, unless the
+`m.room.power_levels` event sets a power level requirement for `m.room.redaction`
+events via the `events` or `events_default` properties. In particular, the _redact
+level_ is **not** considered by the auth rules.
+
+The ability to send a redaction event does not mean that the redaction itself should
+be performed. Receiving servers must perform additional checks, as described in
+the [Handling redactions](#handling-redactions) section.
+{{% /boxes/note %}}
+
 The rules are as follows:
 
 1.  If type is `m.room.create`:

content/rooms/v11.md

@@ -83,12 +83,6 @@ such events over the Client-Server API.
 
 Events must be signed by the server denoted by the `sender` property.
 
-`m.room.redaction` events are not explicitly part of the auth rules.
-They are still subject to the minimum power level rules, but should always
-fall into "10. Otherwise, allow". Instead of being authorized at the time
-of receipt, they are authorized at a later stage: see the
-[Redactions](#redactions) section below for more information.
-
 The types of state events that affect authorization are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
@@ -103,6 +97,18 @@ For example, mentions of the `sender`'s power level can also refer to
 the default power level for users in the room.
 {{% /boxes/note %}}
 
+{{% boxes/note %}}
+`m.room.redaction` events are subject to auth rules in the same way as any other event.
+In practice, that means they will normally be allowed by the auth rules, unless the
+`m.room.power_levels` event sets a power level requirement for `m.room.redaction`
+events via the `events` or `events_default` properties. In particular, the _redact
+level_ is **not** considered by the auth rules.
+
+The ability to send a redaction event does not mean that the redaction itself should
+be performed. Receiving servers must perform additional checks, as described in
+the [Handling redactions](#handling-redactions) section.
+{{% /boxes/note %}}
+
 The rules are as follows:
 
 1.  {{< changed-in this="true" >}}

content/rooms/v3.md

@@ -89,12 +89,17 @@ The complete structure of a event in a v3 room is shown below.
 
 ### Authorization rules
 
-{{< added-in this=true >}} `m.room.redaction` events are no longer
+{{% boxes/note %}}
-explicitly part of the auth rules. They are still subject to the
+{{< added-in this=true >}} `m.room.redaction` events are subject to auth rules in
-minimum power level rules, but should always fall into "11. Otherwise,
+the same way as any other event. In practice, that means they will normally be allowed
-allow". Instead of being authorized at the time of receipt, they are
+by the auth rules, unless the `m.room.power_levels` event sets a power level requirement
-authorized at a later stage: see the [Handling Redactions](#handling-redactions)
+for `m.room.redaction`events via the `events` or `events_default` properties. In
-section below for more information.
+particular, the _redact level_ is **not** considered by the auth rules.
+
+The ability to send a redaction event does not mean that the redaction itself should
+be performed. Receiving servers must perform additional checks, as described in
+the [Handling Redactions](#handling-redactions) section.
+{{% /boxes/note %}}
 
 <!-- set withVersioning=true so we get all the "new in this version" stuff -->
 {{< rver-fragment name="v3-auth-rules" withVersioning=true >}}

content/rooms/v6.md

@@ -40,12 +40,6 @@ in [room version 5](/rooms/v5).
 
 ### Authorization rules
 
-`m.room.redaction` events are not explicitly part of the auth rules.
-They are still subject to the minimum power level rules, but should always
-fall into "10. Otherwise, allow". Instead of being authorized at the time
-of receipt, they are authorized at a later stage: see the
-[Handling Redactions](#handling-redactions) section below for more information.
-
 {{< added-in this=true >}} Rule 4, which related specifically to events
 of type `m.room.aliases`, is removed. `m.room.aliases` events must still pass
 authorization checks relating to state events.
@@ -71,6 +65,18 @@ For example, mentions of the `sender`'s power level can also refer to
 the default power level for users in the room.
 {{% /boxes/note %}}
 
+{{% boxes/note %}}
+`m.room.redaction` events are subject to auth rules in the same way as any other event.
+In practice, that means they will normally be allowed by the auth rules, unless the
+`m.room.power_levels` event sets a power level requirement for `m.room.redaction`
+events via the `events` or `events_default` properties. In particular, the _redact
+level_ is **not** considered by the auth rules.
+
+The ability to send a redaction event does not mean that the redaction itself should
+be performed. Receiving servers must perform additional checks, as described in
+the [Handling Redactions](#handling-redactions) section.
+{{% /boxes/note %}}
+
 The rules are as follows:
 
 1.  If type is `m.room.create`:

content/rooms/v7.md

@@ -37,12 +37,6 @@ new point for `membership=knock` is added.
 
 Events must be signed by the server denoted by the `sender` property.
 
-`m.room.redaction` events are not explicitly part of the auth rules.
-They are still subject to the minimum power level rules, but should always
-fall into "10. Otherwise, allow". Instead of being authorized at the time
-of receipt, they are authorized at a later stage: see the
-[Redactions](#redactions) section below for more information.
-
 The types of state events that affect authorization are:
 
 -   [`m.room.create`](/client-server-api#mroomcreate)
@@ -57,6 +51,18 @@ For example, mentions of the `sender`'s power level can also refer to
 the default power level for users in the room.
 {{% /boxes/note %}}
 
+{{% boxes/note %}}
+`m.room.redaction` events are subject to auth rules in the same way as any other event.
+In practice, that means they will normally be allowed by the auth rules, unless the
+`m.room.power_levels` event sets a power level requirement for `m.room.redaction`
+events via the `events` or `events_default` properties. In particular, the _redact
+level_ is **not** considered by the auth rules.
+
+The ability to send a redaction event does not mean that the redaction itself should
+be performed. Receiving servers must perform additional checks, as described in
+the [Handling redactions](#handling-redactions) section.
+{{% /boxes/note %}}
+
 The rules are as follows:
 
 1.  If type is `m.room.create`: