From ff5fd48edc73cabfe2f624229703af38a67a27fb Mon Sep 17 00:00:00 2001 From: Andy Balaam Date: Fri, 25 Mar 2022 17:16:48 +0000 Subject: [PATCH 01/38] Add 'Restricting who can overwrite a state event' --- ...ricting-who-can-overwrite-a-state-event.md | 115 ++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 proposals/xxxx-restricting-who-can-overwrite-a-state-event.md diff --git a/proposals/xxxx-restricting-who-can-overwrite-a-state-event.md b/proposals/xxxx-restricting-who-can-overwrite-a-state-event.md new file mode 100644 index 00000000000..0ae7016d586 --- /dev/null +++ b/proposals/xxxx-restricting-who-can-overwrite-a-state-event.md @@ -0,0 +1,115 @@ +# MSCxxxx: Restricting who can overwrite a state event. + +## Problem + +Currently there are three main ways to limit who can overwrite a state event: + + * If a user's PL is greater than the `m.room.power_levels` `state_default` field + * If a user's PL is greater than the `m.room.power_levels` `events` field for that event type + * If a state event has a state key which begins with an `@`, then the sender's mxid must match that state key. + +This is problematic if an unprivileged user needs to publish multiple state +events of the same type in a room, but would like to set access control so +that only they can subsequently update the event. An example of this is if a +user wishes to publish multiple live location share beacons as per [MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) +and [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672), for instance one per device. They will typically not want +other users in the room to be able to overwrite the state event, +so we need a mechanism to prevent other peers from doing so. + +[MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) originally proposed that the event type could be made variable, +appending an ID to each separately posted event so that each one could +separately be locked to the same mxid in the state_key. However, this is +problematic because you can't proactively refer to these event types in the +`events` field of the `m.room.power_levels` event to allow users to post +them - and they also are awkward for some client implementations to +manipulate. + +## Proposal + +Therefore, we need a different way to state that a given state event may only +be written by its owner. **We propose that if a state event's state_key *starts with* a matrix ID (followed by an underscore), only the sender with that matrix ID (or higher PL users) can set the state event.** This is an extension of the current behaviour where state events may be overwritten only if the sender's mxid *exactly equals* the state_key. + +We also allow users with higher PL than the original sender to overwrite state +events even if their mxid doesn't match the event's state_key. This fixes an abuse +vector where an unprivileged user can immutably graffiti the state within a room +by sending state events whose state_key is their matrix ID. + +Practically speaking, this means modifying the [authorization rules](https://spec.matrix.org/v1.2/rooms/v9/#authorization-rules) such that rule 8: + +> If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. + +becomes: + +> If the event has a `state_key` that starts with an `@`, and the substring before the first `_` that follows the first `:` (or end of string) does not match the `sender`, reject - unless the sender's powerlevel is greater than the event type's *required power level*. + +For example, to post a live location sharing beacon from [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672): + +```json= +{ + "type": "m.beacon_info", + "state_key": "@stefan:matrix.org_assetid1", // Ensures only the sender can update + "content": { + "m.beacon_info": { + "description": "Stefan's live location", + "timeout": 600000, + "live": true + }, + "m.ts": 1436829458432, + "m.asset": { + "type": "m.self.live" + } + } +} +``` + +Since `:` is not permitted in the localpart and `_` is not permitted in the domain part of an mxid (see [Historical User IDs](https://spec.matrix.org/v1.2/appendices/#historical-user-ids)), it is not possible to craft an mxid that matches the beginning of a state key constructed for another user's mxid, so state keys restricted to one owner can never be overwritten by another user. + +## Potential issues + +None yet. + +## Alternatives + +As originally proposed in [MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) and [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672), we can require +the use of a state key equal to the sender's mxid, but this means we can only +have one such event of each type, so those MSCs proposed using different types +for each unique event. + +An earlier draft of this MSC proposed putting a flag on the contents of the +event (outside of the E2EE payload) called `m.peer_unwritable: true` to indicate +if other users were prohibited from overwriting the event or not. However, this +unravelled when it became clear that there wasn't a good value for the state_key, +which needs to be unique and not subject to races from other malicious users. +By scoping who can set the state_key to be the mxid of the sender, this problem +goes away. + +Another option would be to include the `sender` (or a dedicated `state_subkey`) +as the third component of what makes a state event unique. This is, however, a +much bigger change and not justifiable for the goal meant to be reached with +this MSC. + +## Security considerations + +As this changes auth rules, we should think carefully about whether could +introduce an attack on state resolution. For instance: if a user had higher +PL at some point in the past, will they be able to abuse somehow this to +overwrite the state event, despite not being its owner? + +When using a state_key prefix to restrict who can write the event, we have +deliberately chosen an underscore to terminate the mxid prefix, as underscores +are not allowed in domain names. A pure prefix match will **not** be sufficient, +as `@matthew:matrix.org` will match a state_key of form `@matthew:matrix.org.evil.com:id1`. + +This changes auth rules in a backwards incompatible way, which will break any +use cases which assume that higher PL users cannot overwrite state events whose +state_key is a different mxid. This is considered a feature rather than a bug, +fixing an abuse vector where unprivileged users could send arbitrary state events +which could never be overwritten. + +## Unstable prefix + +None + +## Dependencies + +None From 610f244f14fc110af7d02f2b76ad428a29adc0e2 Mon Sep 17 00:00:00 2001 From: Andy Balaam Date: Fri, 25 Mar 2022 17:18:29 +0000 Subject: [PATCH 02/38] Rename MSC3757 to its proper number --- ...t.md => 3757-restricting-who-can-overwrite-a-state-event.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{xxxx-restricting-who-can-overwrite-a-state-event.md => 3757-restricting-who-can-overwrite-a-state-event.md} (99%) diff --git a/proposals/xxxx-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md similarity index 99% rename from proposals/xxxx-restricting-who-can-overwrite-a-state-event.md rename to proposals/3757-restricting-who-can-overwrite-a-state-event.md index 0ae7016d586..c016cb9fe94 100644 --- a/proposals/xxxx-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -1,4 +1,4 @@ -# MSCxxxx: Restricting who can overwrite a state event. +# MSC3757: Restricting who can overwrite a state event. ## Problem From bfde329e28cd703d506631c66a68cf65a25fc9de Mon Sep 17 00:00:00 2001 From: Andy Balaam Date: Thu, 31 Mar 2022 11:44:56 +0100 Subject: [PATCH 03/38] Clarify wording of comment Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index c016cb9fe94..601bd768d92 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -47,7 +47,7 @@ For example, to post a live location sharing beacon from [MSC3672](https://githu ```json= { "type": "m.beacon_info", - "state_key": "@stefan:matrix.org_assetid1", // Ensures only the sender can update + "state_key": "@stefan:matrix.org_assetid1", // Ensures only the sender or higher PL users can update "content": { "m.beacon_info": { "description": "Stefan's live location", From 344e87676c7510f8d32ce81f4e298f5dcc8be2f6 Mon Sep 17 00:00:00 2001 From: Andy Balaam Date: Thu, 31 Mar 2022 11:46:12 +0100 Subject: [PATCH 04/38] Add unstable room version Co-authored-by: Travis Ralston --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 601bd768d92..d6ccd949f12 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -108,7 +108,7 @@ which could never be overwritten. ## Unstable prefix -None +While this MSC is not considered stable, implementations should apply the behaviours of this MSC on top of room version 9 as `org.matrix.msc3757`. ## Dependencies From ccb7e52c5689eb3a0ce8df7da109dd4e92c9a281 Mon Sep 17 00:00:00 2001 From: Andy Balaam Date: Thu, 31 Mar 2022 11:48:31 +0100 Subject: [PATCH 05/38] Note that this requires a new room version --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index d6ccd949f12..7b0691a3321 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -90,6 +90,8 @@ this MSC. ## Security considerations +This change requires a new room version, so will not affect old events. + As this changes auth rules, we should think carefully about whether could introduce an attack on state resolution. For instance: if a user had higher PL at some point in the past, will they be able to abuse somehow this to From 1ce7e0e9410c0c09f783b0785b98fe678751f8c4 Mon Sep 17 00:00:00 2001 From: Andy Balaam Date: Thu, 31 Mar 2022 13:15:24 +0100 Subject: [PATCH 06/38] Refer to MSC3760 as an alternative --- .../3757-restricting-who-can-overwrite-a-state-event.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 7b0691a3321..5acfe94a6fa 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -83,10 +83,9 @@ which needs to be unique and not subject to races from other malicious users. By scoping who can set the state_key to be the mxid of the sender, this problem goes away. -Another option would be to include the `sender` (or a dedicated `state_subkey`) -as the third component of what makes a state event unique. This is, however, a -much bigger change and not justifiable for the goal meant to be reached with -this MSC. +[MSC3760](https://github.com/matrix-org/matrix-spec-proposals/pull/3760) +proposes to include the `sender` (or a dedicated `state_subkey`) +as the third component of what makes a state event unique. ## Security considerations From 6df6109046b2a163fa12dadd501d3ea5e2095ceb Mon Sep 17 00:00:00 2001 From: Andy Balaam Date: Thu, 31 Mar 2022 13:21:26 +0100 Subject: [PATCH 07/38] Re-word link to MSC3760 --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 5acfe94a6fa..a91c943cd51 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -84,8 +84,8 @@ By scoping who can set the state_key to be the mxid of the sender, this problem goes away. [MSC3760](https://github.com/matrix-org/matrix-spec-proposals/pull/3760) -proposes to include the `sender` (or a dedicated `state_subkey`) -as the third component of what makes a state event unique. +proposes to include a dedicated `state_subkey` as the third component of what +makes a state event unique. ## Security considerations From 6e108b35251ef247234f39ac9088d9acf8723fb5 Mon Sep 17 00:00:00 2001 From: Andy Balaam Date: Tue, 26 Apr 2022 11:53:30 +0100 Subject: [PATCH 08/38] Update to m.self to match latest thinking on MSC3672 --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index a91c943cd51..0e80d1d794f 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -56,7 +56,7 @@ For example, to post a live location sharing beacon from [MSC3672](https://githu }, "m.ts": 1436829458432, "m.asset": { - "type": "m.self.live" + "type": "m.self" } } } From bd4176fda7ca2f5795a78ad2335c99a6a4a3ebdd Mon Sep 17 00:00:00 2001 From: Andy Balaam Date: Wed, 11 May 2022 12:49:03 +0100 Subject: [PATCH 09/38] Remove the user of 'unprivileged' --- .../3757-restricting-who-can-overwrite-a-state-event.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 0e80d1d794f..5359ae7e5aa 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -8,7 +8,7 @@ Currently there are three main ways to limit who can overwrite a state event: * If a user's PL is greater than the `m.room.power_levels` `events` field for that event type * If a state event has a state key which begins with an `@`, then the sender's mxid must match that state key. -This is problematic if an unprivileged user needs to publish multiple state +This is problematic if a user needs to publish multiple state events of the same type in a room, but would like to set access control so that only they can subsequently update the event. An example of this is if a user wishes to publish multiple live location share beacons as per [MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) @@ -31,7 +31,7 @@ be written by its owner. **We propose that if a state event's state_key *starts We also allow users with higher PL than the original sender to overwrite state events even if their mxid doesn't match the event's state_key. This fixes an abuse -vector where an unprivileged user can immutably graffiti the state within a room +vector where a user can immutably graffiti the state within a room by sending state events whose state_key is their matrix ID. Practically speaking, this means modifying the [authorization rules](https://spec.matrix.org/v1.2/rooms/v9/#authorization-rules) such that rule 8: @@ -104,7 +104,7 @@ as `@matthew:matrix.org` will match a state_key of form `@matthew:matrix.org.evi This changes auth rules in a backwards incompatible way, which will break any use cases which assume that higher PL users cannot overwrite state events whose state_key is a different mxid. This is considered a feature rather than a bug, -fixing an abuse vector where unprivileged users could send arbitrary state events +fixing an abuse vector where users could send arbitrary state events which could never be overwritten. ## Unstable prefix From e352a1d21670e833a0ad2cddd8133777c117000d Mon Sep 17 00:00:00 2001 From: Andy Balaam Date: Wed, 11 May 2022 13:00:39 +0100 Subject: [PATCH 10/38] Add a note about allowed characters --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 5359ae7e5aa..ff08cd8ef52 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -29,7 +29,7 @@ manipulate. Therefore, we need a different way to state that a given state event may only be written by its owner. **We propose that if a state event's state_key *starts with* a matrix ID (followed by an underscore), only the sender with that matrix ID (or higher PL users) can set the state event.** This is an extension of the current behaviour where state events may be overwritten only if the sender's mxid *exactly equals* the state_key. -We also allow users with higher PL than the original sender to overwrite state +We also allow users with higher PL than the original sender to overwrite state events even if their mxid doesn't match the event's state_key. This fixes an abuse vector where a user can immutably graffiti the state within a room by sending state events whose state_key is their matrix ID. @@ -42,6 +42,8 @@ becomes: > If the event has a `state_key` that starts with an `@`, and the substring before the first `_` that follows the first `:` (or end of string) does not match the `sender`, reject - unless the sender's powerlevel is greater than the event type's *required power level*. +No additional restrictions are made about the content of the `state_key`, so any characters that follow the `sender` + `_` part are only required to be valid for use in a `state_key`. + For example, to post a live location sharing beacon from [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672): ```json= From 5e95ff329c6fd77b43285d4effb7a7c1c85fe509 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Wed, 4 Sep 2024 16:14:48 -0400 Subject: [PATCH 11/38] Reword proposed auth rule --- .../3757-restricting-who-can-overwrite-a-state-event.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index ff08cd8ef52..4e136fddb98 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -36,11 +36,14 @@ by sending state events whose state_key is their matrix ID. Practically speaking, this means modifying the [authorization rules](https://spec.matrix.org/v1.2/rooms/v9/#authorization-rules) such that rule 8: -> If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. +> 8. If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. becomes: -> If the event has a `state_key` that starts with an `@`, and the substring before the first `_` that follows the first `:` (or end of string) does not match the `sender`, reject - unless the sender's powerlevel is greater than the event type's *required power level*. +> 8. If the event has a `state_key` that starts with an `@`: +> 1. If the prefix of the `state_key` before the first `_` that follows the first `:` (or end of string) is a valid user ID: +> 1. If that user ID does not match the `sender`, and the `sender`'s power level is not greater than that of the user denoted by the ID, reject. +> 2. Otherwise, reject. No additional restrictions are made about the content of the `state_key`, so any characters that follow the `sender` + `_` part are only required to be valid for use in a `state_key`. From 68dc97f807ca824ae2e7cc60d1478dfa1820c73c Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Wed, 11 Sep 2024 11:08:34 -0400 Subject: [PATCH 12/38] Nitpick: always use formatted text for state_key --- ...tricting-who-can-overwrite-a-state-event.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 4e136fddb98..31b7d128941 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -18,7 +18,7 @@ so we need a mechanism to prevent other peers from doing so. [MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) originally proposed that the event type could be made variable, appending an ID to each separately posted event so that each one could -separately be locked to the same mxid in the state_key. However, this is +separately be locked to the same mxid in the `state_key`. However, this is problematic because you can't proactively refer to these event types in the `events` field of the `m.room.power_levels` event to allow users to post them - and they also are awkward for some client implementations to @@ -27,12 +27,12 @@ manipulate. ## Proposal Therefore, we need a different way to state that a given state event may only -be written by its owner. **We propose that if a state event's state_key *starts with* a matrix ID (followed by an underscore), only the sender with that matrix ID (or higher PL users) can set the state event.** This is an extension of the current behaviour where state events may be overwritten only if the sender's mxid *exactly equals* the state_key. +be written by its owner. **We propose that if a state event's `state_key` *starts with* a matrix ID (followed by an underscore), only the sender with that matrix ID (or higher PL users) can set the state event.** This is an extension of the current behaviour where state events may be overwritten only if the sender's mxid *exactly equals* the `state_key`. We also allow users with higher PL than the original sender to overwrite state -events even if their mxid doesn't match the event's state_key. This fixes an abuse +events even if their mxid doesn't match the event's `state_key`. This fixes an abuse vector where a user can immutably graffiti the state within a room -by sending state events whose state_key is their matrix ID. +by sending state events whose `state_key` is their matrix ID. Practically speaking, this means modifying the [authorization rules](https://spec.matrix.org/v1.2/rooms/v9/#authorization-rules) such that rule 8: @@ -83,9 +83,9 @@ for each unique event. An earlier draft of this MSC proposed putting a flag on the contents of the event (outside of the E2EE payload) called `m.peer_unwritable: true` to indicate if other users were prohibited from overwriting the event or not. However, this -unravelled when it became clear that there wasn't a good value for the state_key, +unravelled when it became clear that there wasn't a good value for the `state_key`, which needs to be unique and not subject to races from other malicious users. -By scoping who can set the state_key to be the mxid of the sender, this problem +By scoping who can set the `state_key` to be the mxid of the sender, this problem goes away. [MSC3760](https://github.com/matrix-org/matrix-spec-proposals/pull/3760) @@ -101,14 +101,14 @@ introduce an attack on state resolution. For instance: if a user had higher PL at some point in the past, will they be able to abuse somehow this to overwrite the state event, despite not being its owner? -When using a state_key prefix to restrict who can write the event, we have +When using a `state_key` prefix to restrict who can write the event, we have deliberately chosen an underscore to terminate the mxid prefix, as underscores are not allowed in domain names. A pure prefix match will **not** be sufficient, -as `@matthew:matrix.org` will match a state_key of form `@matthew:matrix.org.evil.com:id1`. +as `@matthew:matrix.org` will match a `state_key` of form `@matthew:matrix.org.evil.com:id1`. This changes auth rules in a backwards incompatible way, which will break any use cases which assume that higher PL users cannot overwrite state events whose -state_key is a different mxid. This is considered a feature rather than a bug, +`state_key` is a different mxid. This is considered a feature rather than a bug, fixing an abuse vector where users could send arbitrary state events which could never be overwritten. From 17890fddf4fb43e82c6e9a2c2c4cbaf82f063cd7 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Wed, 11 Sep 2024 11:08:47 -0400 Subject: [PATCH 13/38] Nitpick: remove trailing whitespace --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 31b7d128941..56fe8d99b44 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -80,7 +80,7 @@ the use of a state key equal to the sender's mxid, but this means we can only have one such event of each type, so those MSCs proposed using different types for each unique event. -An earlier draft of this MSC proposed putting a flag on the contents of the +An earlier draft of this MSC proposed putting a flag on the contents of the event (outside of the E2EE payload) called `m.peer_unwritable: true` to indicate if other users were prohibited from overwriting the event or not. However, this unravelled when it became clear that there wasn't a good value for the `state_key`, @@ -107,7 +107,7 @@ are not allowed in domain names. A pure prefix match will **not** be sufficient as `@matthew:matrix.org` will match a `state_key` of form `@matthew:matrix.org.evil.com:id1`. This changes auth rules in a backwards incompatible way, which will break any -use cases which assume that higher PL users cannot overwrite state events whose +use cases which assume that higher PL users cannot overwrite state events whose `state_key` is a different mxid. This is considered a feature rather than a bug, fixing an abuse vector where users could send arbitrary state events which could never be overwritten. From f962bf34cff635e76c2d43134debf61e40f6b296 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Wed, 11 Sep 2024 11:09:27 -0400 Subject: [PATCH 14/38] Change recommended room versions to apply on - Recommend version 10 as it is the current default - Allow higher versions as this MSC isn't tied to any single version --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 56fe8d99b44..8556532f990 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -114,7 +114,7 @@ which could never be overwritten. ## Unstable prefix -While this MSC is not considered stable, implementations should apply the behaviours of this MSC on top of room version 9 as `org.matrix.msc3757`. +While this MSC is not considered stable, implementations should apply the behaviours of this MSC on top of room version 10 or higher as `org.matrix.msc3757`. ## Dependencies From dd9b33e1fae0b93a5692545ac55928dcb6b77c65 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Tue, 24 Sep 2024 14:18:09 -0400 Subject: [PATCH 15/38] Mention that _ can't be in any form of server name --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 8556532f990..ce9f53e0327 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -103,7 +103,9 @@ overwrite the state event, despite not being its owner? When using a `state_key` prefix to restrict who can write the event, we have deliberately chosen an underscore to terminate the mxid prefix, as underscores -are not allowed in domain names. A pure prefix match will **not** be sufficient, +are not allowed in [any form of server name](https://spec.matrix.org/v1.11/appendices/#server-name) +(either a DNS name or IPv4/6 address, with or without a numeric port specifier). +A pure prefix match will **not** be sufficient, as `@matthew:matrix.org` will match a `state_key` of form `@matthew:matrix.org.evil.com:id1`. This changes auth rules in a backwards incompatible way, which will break any From eb0eed6d9200dc55a6b6ed80b32fd6443df4c476 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Tue, 24 Sep 2024 16:52:46 -0400 Subject: [PATCH 16/38] Add issue of incompatibility with long MXIDs --- .../3757-restricting-who-can-overwrite-a-state-event.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index ce9f53e0327..77ded265a9f 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -71,7 +71,11 @@ Since `:` is not permitted in the localpart and `_` is not permitted in the doma ## Potential issues -None yet. +As the spec enforces [a size limit of 255 bytes for both MXIDs and state keys](https://spec.matrix.org/unstable/client-server-api/#size-limits), +the set of available MXID-prefixed state keys is smaller for long MXIDs than for short ones, +with the worst case of none being available for MXIDs equal to the size limit. +Thus, long MXIDs are restricted from being used as state key prefixes to designate state ownership. +This issue could be solved by increasing the size limit for state keys. ## Alternatives From ac2451027484e7f4d0e4a858e3184c7b774f697a Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Tue, 24 Sep 2024 18:11:04 -0400 Subject: [PATCH 17/38] Add issue of underscores in domain names Also add sub-headers for each issue --- ...ricting-who-can-overwrite-a-state-event.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 77ded265a9f..703962e57ab 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -71,12 +71,31 @@ Since `:` is not permitted in the localpart and `_` is not permitted in the doma ## Potential issues +### Incompatibility with long user IDs + As the spec enforces [a size limit of 255 bytes for both MXIDs and state keys](https://spec.matrix.org/unstable/client-server-api/#size-limits), the set of available MXID-prefixed state keys is smaller for long MXIDs than for short ones, with the worst case of none being available for MXIDs equal to the size limit. Thus, long MXIDs are restricted from being used as state key prefixes to designate state ownership. This issue could be solved by increasing the size limit for state keys. +### Incompatibility with domain names containing underscores + +Although both [the spec](https://spec.matrix.org/unstable/appendices/#server-name) +and [RFC 1035 §2.3.1](https://www.rfc-editor.org/rfc/rfc1035#section-2.3.1) +forbid the presence of underscores in domain names, +there noneless exist resolvable domain names that contain underscores. +The proposed auth rule for parsing an MXID prefix from an underscore-separated state key would fail +on such domain names. + +Possible solutions include: +- using a different character to terminate an MXID prefix in state keys. The character must be one + that's known to be absent from domain names in practice, and must also not be any character that + the spec allows to appear in a server name. +- refining the proposed auth rule for parsing an MXID prefix such that it does not fail on domain + names that contain an underscore. One way to achieve this is to leverage the absense of + underscores from top-level domains. + ## Alternatives As originally proposed in [MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) and [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672), we can require From 9490cbdfcce66956d9095752026150d86275e851 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Tue, 24 Sep 2024 18:18:57 -0400 Subject: [PATCH 18/38] Fix typo --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 703962e57ab..504b7b7d7be 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -93,7 +93,7 @@ Possible solutions include: that's known to be absent from domain names in practice, and must also not be any character that the spec allows to appear in a server name. - refining the proposed auth rule for parsing an MXID prefix such that it does not fail on domain - names that contain an underscore. One way to achieve this is to leverage the absense of + names that contain an underscore. One way to achieve this is to leverage the absence of underscores from top-level domains. ## Alternatives From 486b0cd8c6eb649b7c9754aa076853fb0221f4e5 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Wed, 25 Sep 2024 23:06:50 -0400 Subject: [PATCH 19/38] Use device ID suffix in location beacon example --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 504b7b7d7be..4ea9f2df317 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -47,12 +47,12 @@ becomes: No additional restrictions are made about the content of the `state_key`, so any characters that follow the `sender` + `_` part are only required to be valid for use in a `state_key`. -For example, to post a live location sharing beacon from [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672): +For example, to post a live location sharing beacon from [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672) for one of a user's devices: ```json= { "type": "m.beacon_info", - "state_key": "@stefan:matrix.org_assetid1", // Ensures only the sender or higher PL users can update + "state_key": "@stefan:matrix.org_{deviceid1}", // Ensures only the sender or higher PL users can update "content": { "m.beacon_info": { "description": "Stefan's live location", From 590ff96ccba50873daf77ba3ba0b9736ec452068 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Thu, 26 Sep 2024 16:30:10 -0400 Subject: [PATCH 20/38] Increase state key size limit & set suffix limit - Update auth rules to enforce the suffix limit - Remove potential issue of long user IDs, as that is now solved --- ...ricting-who-can-overwrite-a-state-event.md | 24 ++++++++++--------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 4ea9f2df317..b15054aae24 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -29,6 +29,14 @@ manipulate. Therefore, we need a different way to state that a given state event may only be written by its owner. **We propose that if a state event's `state_key` *starts with* a matrix ID (followed by an underscore), only the sender with that matrix ID (or higher PL users) can set the state event.** This is an extension of the current behaviour where state events may be overwritten only if the sender's mxid *exactly equals* the `state_key`. +As the spec currently enforces [a size limit of 255 bytes for both user IDs and state keys]( +https://spec.matrix.org/unstable/client-server-api/#size-limits), +the size limit on state keys is increased to **511 bytes** to allow prefixing any currently-valid +state key with a maximum-length user ID (and a separator character). +Similarly, the size of a state key suffix after a leading user ID and the separator character is +limited to **255 bytes** so that any such suffix may follow any user ID without surpassing the total +state key size limit. + We also allow users with higher PL than the original sender to overwrite state events even if their mxid doesn't match the event's `state_key`. This fixes an abuse vector where a user can immutably graffiti the state within a room @@ -41,9 +49,11 @@ Practically speaking, this means modifying the [authorization rules](https://spe becomes: > 8. If the event has a `state_key` that starts with an `@`: -> 1. If the prefix of the `state_key` before the first `_` that follows the first `:` (or end of string) is a valid user ID: -> 1. If that user ID does not match the `sender`, and the `sender`'s power level is not greater than that of the user denoted by the ID, reject. -> 2. Otherwise, reject. +> 1. If the prefix of the `state_key` before the first `_` that follows the first `:` (or end of string) is not a valid user ID, reject. +> 1. Otherwise, if the size of the `state_key` without the leading user ID is greater than 256 bytes, reject. +> 1. Otherwise, if that user ID does not match the `sender`, and the `sender`'s power level is not greater than that of the user denoted by the ID, reject. + +Note that the size limit of 256 bytes after a leading user ID includes the separating `_`. No additional restrictions are made about the content of the `state_key`, so any characters that follow the `sender` + `_` part are only required to be valid for use in a `state_key`. @@ -71,14 +81,6 @@ Since `:` is not permitted in the localpart and `_` is not permitted in the doma ## Potential issues -### Incompatibility with long user IDs - -As the spec enforces [a size limit of 255 bytes for both MXIDs and state keys](https://spec.matrix.org/unstable/client-server-api/#size-limits), -the set of available MXID-prefixed state keys is smaller for long MXIDs than for short ones, -with the worst case of none being available for MXIDs equal to the size limit. -Thus, long MXIDs are restricted from being used as state key prefixes to designate state ownership. -This issue could be solved by increasing the size limit for state keys. - ### Incompatibility with domain names containing underscores Although both [the spec](https://spec.matrix.org/unstable/appendices/#server-name) From d9b149d8fc1eef74840fe7ec450ca369d71b08df Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Fri, 27 Sep 2024 09:22:34 -0400 Subject: [PATCH 21/38] Keep original size limit on unprefixed state keys --- ...tricting-who-can-overwrite-a-state-event.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index b15054aae24..c47e9a00100 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -33,9 +33,11 @@ As the spec currently enforces [a size limit of 255 bytes for both user IDs and https://spec.matrix.org/unstable/client-server-api/#size-limits), the size limit on state keys is increased to **511 bytes** to allow prefixing any currently-valid state key with a maximum-length user ID (and a separator character). -Similarly, the size of a state key suffix after a leading user ID and the separator character is -limited to **255 bytes** so that any such suffix may follow any user ID without surpassing the total -state key size limit. +The size of a state key suffix after a leading user ID and the separator character is limited to +**255 bytes** so that any such suffix may follow any user ID without the complete state key +ever surpassing the total state key size limit. +Similarly, the size of a state key without a leading user ID is limited to **255 bytes** so that any +state key without a leading user ID may be given one without ever surpassing the total size limit. We also allow users with higher PL than the original sender to overwrite state events even if their mxid doesn't match the event's `state_key`. This fixes an abuse @@ -48,10 +50,12 @@ Practically speaking, this means modifying the [authorization rules](https://spe becomes: -> 8. If the event has a `state_key` that starts with an `@`: -> 1. If the prefix of the `state_key` before the first `_` that follows the first `:` (or end of string) is not a valid user ID, reject. -> 1. Otherwise, if the size of the `state_key` without the leading user ID is greater than 256 bytes, reject. -> 1. Otherwise, if that user ID does not match the `sender`, and the `sender`'s power level is not greater than that of the user denoted by the ID, reject. +> 8. If the event has a `state_key`: +> 1. If the `state_key` starts with an `@`: +> 1. If the prefix of the `state_key` before the first `_` that follows the first `:` (or end of string) is not a valid user ID, reject. +> 1. Otherwise, if the size of the `state_key` without the leading user ID is greater than 256 bytes, reject. +> 1. Otherwise, if the leading user ID does not match the `sender`, and the `sender`'s power level is not greater than that of the user denoted by that ID, reject. +> 1. Otherwise, if size the `state_key` is greater than 255 bytes, reject. Note that the size limit of 256 bytes after a leading user ID includes the separating `_`. From ae17437ba9aab1ae6e101eb02e1d18984c533d6e Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Fri, 27 Sep 2024 13:28:31 -0400 Subject: [PATCH 22/38] Move paragraph to alternative section --- ...ricting-who-can-overwrite-a-state-event.md | 21 ++++++++----------- 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index c47e9a00100..67aa1d4c7c3 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -16,14 +16,6 @@ and [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672), fo other users in the room to be able to overwrite the state event, so we need a mechanism to prevent other peers from doing so. -[MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) originally proposed that the event type could be made variable, -appending an ID to each separately posted event so that each one could -separately be locked to the same mxid in the `state_key`. However, this is -problematic because you can't proactively refer to these event types in the -`events` field of the `m.room.power_levels` event to allow users to post -them - and they also are awkward for some client implementations to -manipulate. - ## Proposal Therefore, we need a different way to state that a given state event may only @@ -104,10 +96,15 @@ Possible solutions include: ## Alternatives -As originally proposed in [MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) and [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672), we can require -the use of a state key equal to the sender's mxid, but this means we can only -have one such event of each type, so those MSCs proposed using different types -for each unique event. +[MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) +and [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672) +originally proposed that the event type could be made variable, +with an ID appended to each separately posted event so that each one could +separately be locked to the same mxid in the `state_key`. However, this is +problematic because you can't proactively refer to these event types in the +`events` field of the `m.room.power_levels` event to allow users to post +them - and they also are awkward for some client implementations to +manipulate. An earlier draft of this MSC proposed putting a flag on the contents of the event (outside of the E2EE payload) called `m.peer_unwritable: true` to indicate From 8222738d6143b5086bc7c94a59711407fca91182 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Fri, 27 Sep 2024 13:30:11 -0400 Subject: [PATCH 23/38] Add alternative of state key arrays --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 67aa1d4c7c3..7163b687e48 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -117,6 +117,10 @@ goes away. [MSC3760](https://github.com/matrix-org/matrix-spec-proposals/pull/3760) proposes to include a dedicated `state_subkey` as the third component of what makes a state event unique. +As an extension to this idea, a comment in [the discussion of this MSC]( +https://github.com/matrix-org/matrix-spec-proposals/pull/3757#issuecomment-2099010555) +proposes allowing `state_key` to be an array of strings. +However, either proposal would alter the nature of state events and state resolution. ## Security considerations From 63955d723ab27cfd21c0e7269928f1f48d8023fd Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Fri, 27 Sep 2024 14:05:58 -0400 Subject: [PATCH 24/38] Add alternative of field for non-state events --- ...3757-restricting-who-can-overwrite-a-state-event.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 7163b687e48..176e4a826ce 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -122,6 +122,16 @@ https://github.com/matrix-org/matrix-spec-proposals/pull/3757#issuecomment-20990 proposes allowing `state_key` to be an array of strings. However, either proposal would alter the nature of state events and state resolution. +Another comment in [the discussion of this MSC]( +https://github.com/matrix-org/matrix-spec-proposals/pull/3757#discussion_r1103877363) +proposes an optional top-level field for both state and non-state events that designates ownership +of the containing event to a particular user. +This would provide ownership semantics for not only state events, but also message events, which may +be used to restrict event replacements / redactions to only the designated owner of an event. +However, it remains to be decided how using this top-level field for state events should affect +state resolution; namely, whether it is possible to set multiple events with the same `state_key` +but different owners. + ## Security considerations This change requires a new room version, so will not affect old events. From 07d784aba95b2d7e2aae85d411c4bf14a80d4a43 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Fri, 27 Sep 2024 14:07:18 -0400 Subject: [PATCH 25/38] Clarify state subkey/array relevance to user IDs --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 176e4a826ce..e1d804342fe 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -120,6 +120,8 @@ makes a state event unique. As an extension to this idea, a comment in [the discussion of this MSC]( https://github.com/matrix-org/matrix-spec-proposals/pull/3757#issuecomment-2099010555) proposes allowing `state_key` to be an array of strings. +Either proposal allows for effectively including an owning user ID in a state key without having to +string-pack the user ID with another string. However, either proposal would alter the nature of state events and state resolution. Another comment in [the discussion of this MSC]( From 99698eff36696bf6e08be5677bdc053e1b424761 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Fri, 27 Sep 2024 14:37:39 -0400 Subject: [PATCH 26/38] Fix formatting of auth rule's numeric list --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index e1d804342fe..3f9b0bd2687 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -43,11 +43,11 @@ Practically speaking, this means modifying the [authorization rules](https://spe becomes: > 8. If the event has a `state_key`: -> 1. If the `state_key` starts with an `@`: +> 1. If the `state_key` starts with an `@`: > 1. If the prefix of the `state_key` before the first `_` that follows the first `:` (or end of string) is not a valid user ID, reject. > 1. Otherwise, if the size of the `state_key` without the leading user ID is greater than 256 bytes, reject. > 1. Otherwise, if the leading user ID does not match the `sender`, and the `sender`'s power level is not greater than that of the user denoted by that ID, reject. -> 1. Otherwise, if size the `state_key` is greater than 255 bytes, reject. +> 1. Otherwise, if size the `state_key` is greater than 255 bytes, reject. Note that the size limit of 256 bytes after a leading user ID includes the separating `_`. From 9f4f31a8019e6bf0566033c52d99f9e435edc6bc Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Mon, 7 Oct 2024 15:19:04 -0400 Subject: [PATCH 27/38] Rephrase the current restrictions on state events --- ...3757-restricting-who-can-overwrite-a-state-event.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 3f9b0bd2687..97e315e2b3f 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -2,11 +2,13 @@ ## Problem -Currently there are three main ways to limit who can overwrite a state event: +Currently, there are two main restrictions on who can overwrite a state event, enforced by rules +7 and 8 of the [authorization rules](https://spec.matrix.org/latest/rooms/v11/#authorization-rules): - * If a user's PL is greater than the `m.room.power_levels` `state_default` field - * If a user's PL is greater than the `m.room.power_levels` `events` field for that event type - * If a state event has a state key which begins with an `@`, then the sender's mxid must match that state key. + * Only users with a power level greater than or equal to the "required power level" for a state + event type may send state events of that type. + * State events with a `state_key` that equals a user ID may be overwritten only by the user whose + ID matches the state key. This is problematic if a user needs to publish multiple state events of the same type in a room, but would like to set access control so From 75f03dadb699836bb7dcf62fd44a744592a983fc Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Mon, 7 Oct 2024 15:41:21 -0400 Subject: [PATCH 28/38] Better explain limitations of current restrictions Highlight that the current restrictions prevent being able to set multiple state events of the same type with exclusive write access --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 97e315e2b3f..a44685c9b59 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -10,6 +10,10 @@ Currently, there are two main restrictions on who can overwrite a state event, e * State events with a `state_key` that equals a user ID may be overwritten only by the user whose ID matches the state key. +With these restrictions, only a single piece of state for any state event type may have its write +access limited to a particular user (the state event whose `state_key` is set to the ID of the user +who has write access to it). + This is problematic if a user needs to publish multiple state events of the same type in a room, but would like to set access control so that only they can subsequently update the event. An example of this is if a From e833e8a4591d1f3c04a6a00251155b4a147ba670 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Mon, 7 Oct 2024 16:24:51 -0400 Subject: [PATCH 29/38] Reword and reformat - Use assertive language - Limit lines to ~100 characters - Improve consistency of terms --- ...ricting-who-can-overwrite-a-state-event.md | 83 +++++++++++-------- 1 file changed, 49 insertions(+), 34 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index a44685c9b59..c26bd892ff1 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -17,15 +17,19 @@ who has write access to it). This is problematic if a user needs to publish multiple state events of the same type in a room, but would like to set access control so that only they can subsequently update the event. An example of this is if a -user wishes to publish multiple live location share beacons as per [MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) -and [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672), for instance one per device. They will typically not want -other users in the room to be able to overwrite the state event, -so we need a mechanism to prevent other peers from doing so. +user wishes to publish multiple live location share beacons as per +[MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) and +[MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672), +for instance one per device. +They will typically not want other users in the room to be able to overwrite the state event, +so there ought to be a mechanism to prevent other users from doing so. ## Proposal -Therefore, we need a different way to state that a given state event may only -be written by its owner. **We propose that if a state event's `state_key` *starts with* a matrix ID (followed by an underscore), only the sender with that matrix ID (or higher PL users) can set the state event.** This is an extension of the current behaviour where state events may be overwritten only if the sender's mxid *exactly equals* the `state_key`. +**If a state event's `state_key` *starts with* a user ID followed by an underscore, only the user +with that ID or users with a higher power level then them may overwrite that state event.** +This is an extension of the current behaviour where state events may be overwritten only by users +whose ID *exactly equals* the `state_key`. As the spec currently enforces [a size limit of 255 bytes for both user IDs and state keys]( https://spec.matrix.org/unstable/client-server-api/#size-limits), @@ -37,12 +41,13 @@ ever surpassing the total state key size limit. Similarly, the size of a state key without a leading user ID is limited to **255 bytes** so that any state key without a leading user ID may be given one without ever surpassing the total size limit. -We also allow users with higher PL than the original sender to overwrite state -events even if their mxid doesn't match the event's `state_key`. This fixes an abuse +Users with a higher power level than a state event's original sender may overwrite the event +despite their user ID not matching the one in event's `state_key`. This fixes an abuse vector where a user can immutably graffiti the state within a room -by sending state events whose `state_key` is their matrix ID. +by sending state events whose `state_key` is their user ID. -Practically speaking, this means modifying the [authorization rules](https://spec.matrix.org/v1.2/rooms/v9/#authorization-rules) such that rule 8: +Practically speaking, this means modifying the +[authorization rules](https://spec.matrix.org/v1.2/rooms/v9/#authorization-rules) such that rule 8: > 8. If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. @@ -50,16 +55,21 @@ becomes: > 8. If the event has a `state_key`: > 1. If the `state_key` starts with an `@`: -> 1. If the prefix of the `state_key` before the first `_` that follows the first `:` (or end of string) is not a valid user ID, reject. -> 1. Otherwise, if the size of the `state_key` without the leading user ID is greater than 256 bytes, reject. -> 1. Otherwise, if the leading user ID does not match the `sender`, and the `sender`'s power level is not greater than that of the user denoted by that ID, reject. +> 1. If the prefix of the `state_key` before the first `_` that follows the first `:` (or end +> of string) is not a valid user ID, reject. +> 1. If the size of the `state_key` without its leading user ID is greater than 256 bytes, reject. +> 1. If the leading user ID does not match the `sender`, and the `sender`'s power level is not +> greater than that of the user denoted by that ID, reject. > 1. Otherwise, if size the `state_key` is greater than 255 bytes, reject. Note that the size limit of 256 bytes after a leading user ID includes the separating `_`. -No additional restrictions are made about the content of the `state_key`, so any characters that follow the `sender` + `_` part are only required to be valid for use in a `state_key`. +No additional restrictions are made about the content of the `state_key`, so any characters that +follow the `sender` + `_` part are only required to be valid for use in a `state_key`. -For example, to post a live location sharing beacon from [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672) for one of a user's devices: +For example, to post a live location sharing beacon from +[MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672) +for one of a user's devices: ```json= { @@ -79,7 +89,10 @@ For example, to post a live location sharing beacon from [MSC3672](https://githu } ``` -Since `:` is not permitted in the localpart and `_` is not permitted in the domain part of an mxid (see [Historical User IDs](https://spec.matrix.org/v1.2/appendices/#historical-user-ids)), it is not possible to craft an mxid that matches the beginning of a state key constructed for another user's mxid, so state keys restricted to one owner can never be overwritten by another user. +Since `:` is not permitted in the localpart and `_` is not permitted in the domain part of a user ID +(see [Historical User IDs](https://spec.matrix.org/v1.2/appendices/#historical-user-ids)), +it is not possible to craft a user ID that matches the beginning of a state key constructed for +another user's ID, so state keys restricted to one owner can never be overwritten by another user. ## Potential issues @@ -89,14 +102,14 @@ Although both [the spec](https://spec.matrix.org/unstable/appendices/#server-nam and [RFC 1035 §2.3.1](https://www.rfc-editor.org/rfc/rfc1035#section-2.3.1) forbid the presence of underscores in domain names, there noneless exist resolvable domain names that contain underscores. -The proposed auth rule for parsing an MXID prefix from an underscore-separated state key would fail -on such domain names. +The proposed auth rule for parsing a leading user ID from an underscore-separated state key would +fail on such domain names. Possible solutions include: -- using a different character to terminate an MXID prefix in state keys. The character must be one - that's known to be absent from domain names in practice, and must also not be any character that +- using a different character to terminate a leading user ID in state keys. That character must be + one known to be absent from domain names in practice, and must also not be any character that the spec allows to appear in a server name. -- refining the proposed auth rule for parsing an MXID prefix such that it does not fail on domain +- refining the proposed auth rule for parsing a leading user ID such that it does not fail on domain names that contain an underscore. One way to achieve this is to leverage the absence of underscores from top-level domains. @@ -106,7 +119,7 @@ Possible solutions include: and [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672) originally proposed that the event type could be made variable, with an ID appended to each separately posted event so that each one could -separately be locked to the same mxid in the `state_key`. However, this is +separately be locked to the same user ID in the `state_key`. However, this is problematic because you can't proactively refer to these event types in the `events` field of the `m.room.power_levels` event to allow users to post them - and they also are awkward for some client implementations to @@ -117,7 +130,7 @@ event (outside of the E2EE payload) called `m.peer_unwritable: true` to indicate if other users were prohibited from overwriting the event or not. However, this unravelled when it became clear that there wasn't a good value for the `state_key`, which needs to be unique and not subject to races from other malicious users. -By scoping who can set the `state_key` to be the mxid of the sender, this problem +By scoping who can set the `state_key` to be the user ID of the sender, this problem goes away. [MSC3760](https://github.com/matrix-org/matrix-spec-proposals/pull/3760) @@ -144,27 +157,29 @@ but different owners. This change requires a new room version, so will not affect old events. -As this changes auth rules, we should think carefully about whether could -introduce an attack on state resolution. For instance: if a user had higher -PL at some point in the past, will they be able to abuse somehow this to -overwrite the state event, despite not being its owner? +As this changes auth rules, the possibility of new attacks on state resolution must be considered. +For instance, if a user had higher power level at some point in the past, will they be able to +somehow abuse this to overwrite the state event, despite not being its owner? -When using a `state_key` prefix to restrict who can write the event, we have -deliberately chosen an underscore to terminate the mxid prefix, as underscores -are not allowed in [any form of server name](https://spec.matrix.org/v1.11/appendices/#server-name) -(either a DNS name or IPv4/6 address, with or without a numeric port specifier). +When using a leading user ID in a `state_key` to restrict who can write the event, the character to +terminate the leading user ID was deliberately chosen to be an underscore, as it is not +allowed in [any form of server name](https://spec.matrix.org/v1.11/appendices/#server-name) +(either a DNS name or IPv4/6 address, with or without a numeric port specifier) and thus cannot be +confused as part of the server name of a leading user ID (with one caveat mentioned as a +[potential issue](#incompatibility-with-domain-names-containing-underscores)). A pure prefix match will **not** be sufficient, as `@matthew:matrix.org` will match a `state_key` of form `@matthew:matrix.org.evil.com:id1`. This changes auth rules in a backwards incompatible way, which will break any -use cases which assume that higher PL users cannot overwrite state events whose -`state_key` is a different mxid. This is considered a feature rather than a bug, +use cases which assume that higher power level users cannot overwrite state events whose +`state_key` is a different user ID. This is considered a feature rather than a bug, fixing an abuse vector where users could send arbitrary state events which could never be overwritten. ## Unstable prefix -While this MSC is not considered stable, implementations should apply the behaviours of this MSC on top of room version 10 or higher as `org.matrix.msc3757`. +While this MSC is not considered stable, implementations should apply the behaviours of this MSC on +top of room version 10 or higher as `org.matrix.msc3757`. ## Dependencies From a4b40b55fc6a83525f874d70d7c75899ba38983d Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Mon, 7 Oct 2024 16:25:12 -0400 Subject: [PATCH 30/38] Remove redundant explanation for separating with _ as it is already discussed in two other sections --- .../3757-restricting-who-can-overwrite-a-state-event.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index c26bd892ff1..40798f6aea0 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -89,11 +89,6 @@ for one of a user's devices: } ``` -Since `:` is not permitted in the localpart and `_` is not permitted in the domain part of a user ID -(see [Historical User IDs](https://spec.matrix.org/v1.2/appendices/#historical-user-ids)), -it is not possible to craft a user ID that matches the beginning of a state key constructed for -another user's ID, so state keys restricted to one owner can never be overwritten by another user. - ## Potential issues ### Incompatibility with domain names containing underscores From a0da59bfd724ee519891cd4fef7ab1ef9256e98e Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Mon, 7 Oct 2024 16:27:07 -0400 Subject: [PATCH 31/38] Scope proposal to a future room version --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 40798f6aea0..a0cc6fd69ba 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -26,7 +26,8 @@ so there ought to be a mechanism to prevent other users from doing so. ## Proposal -**If a state event's `state_key` *starts with* a user ID followed by an underscore, only the user +In a future room version, +**if a state event's `state_key` *starts with* a user ID followed by an underscore, only the user with that ID or users with a higher power level then them may overwrite that state event.** This is an extension of the current behaviour where state events may be overwritten only by users whose ID *exactly equals* the `state_key`. From 5855a7faf85427d5cf287834e58873a0389d828f Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Tue, 8 Oct 2024 09:34:19 -0400 Subject: [PATCH 32/38] Elaborate on multi-component state key alternative --- ...57-restricting-who-can-overwrite-a-state-event.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index a0cc6fd69ba..a30cd2c4965 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -135,9 +135,15 @@ makes a state event unique. As an extension to this idea, a comment in [the discussion of this MSC]( https://github.com/matrix-org/matrix-spec-proposals/pull/3757#issuecomment-2099010555) proposes allowing `state_key` to be an array of strings. -Either proposal allows for effectively including an owning user ID in a state key without having to -string-pack the user ID with another string. -However, either proposal would alter the nature of state events and state resolution. +With either proposal of multi-component state keys, state events could be scoped to an owning user +by setting one of the components of the state key (either the `state_subkey` or an element of an +array `state_key`) to a user ID, instead of by prefixing the `state_key` string with a user ID. +Doing so would avoid having to parse user IDs out of `state_key` strings, +and would avoid needing to increase the size limit of the `state_key` field to give it enough room +to contain a leading user ID. +However, allowing state keys to be multi-component would change state key comparison from being a +string comparison to an array-of-strings comparison, which could be costly for existing server +implementations to migrate to. Another comment in [the discussion of this MSC]( https://github.com/matrix-org/matrix-spec-proposals/pull/3757#discussion_r1103877363) From deba3b827a429eb3801c48a233afa07a35a75921 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Tue, 8 Oct 2024 09:35:08 -0400 Subject: [PATCH 33/38] Add sub-headers to alternatives section --- ...3757-restricting-who-can-overwrite-a-state-event.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index a30cd2c4965..320138cc647 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -111,6 +111,8 @@ Possible solutions include: ## Alternatives +### Variable event types + [MSC3489](https://github.com/matrix-org/matrix-spec-proposals/pull/3489) and [MSC3672](https://github.com/matrix-org/matrix-spec-proposals/pull/3672) originally proposed that the event type could be made variable, @@ -121,6 +123,8 @@ problematic because you can't proactively refer to these event types in the them - and they also are awkward for some client implementations to manipulate. +### `m.peer_unwritable` flag + An earlier draft of this MSC proposed putting a flag on the contents of the event (outside of the E2EE payload) called `m.peer_unwritable: true` to indicate if other users were prohibited from overwriting the event or not. However, this @@ -129,6 +133,8 @@ which needs to be unique and not subject to races from other malicious users. By scoping who can set the `state_key` to be the user ID of the sender, this problem goes away. +### Multi-component state keys + [MSC3760](https://github.com/matrix-org/matrix-spec-proposals/pull/3760) proposes to include a dedicated `state_subkey` as the third component of what makes a state event unique. @@ -145,7 +151,9 @@ However, allowing state keys to be multi-component would change state key compar string comparison to an array-of-strings comparison, which could be costly for existing server implementations to migrate to. -Another comment in [the discussion of this MSC]( +### Owning user ID field + +A comment in [the discussion of this MSC]( https://github.com/matrix-org/matrix-spec-proposals/pull/3757#discussion_r1103877363) proposes an optional top-level field for both state and non-state events that designates ownership of the containing event to a particular user. From 8090f690a2e5a0c88f6aa0f73e6459ea34ef2777 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Tue, 8 Oct 2024 13:45:21 -0400 Subject: [PATCH 34/38] Propose sender-scoped state with ownership flag --- ...-restricting-who-can-overwrite-a-state-event.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 320138cc647..bb9fc4656fe 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -123,16 +123,26 @@ problematic because you can't proactively refer to these event types in the them - and they also are awkward for some client implementations to manipulate. -### `m.peer_unwritable` flag +### Event ownership flag An earlier draft of this MSC proposed putting a flag on the contents of the -event (outside of the E2EE payload) called `m.peer_unwritable: true` to indicate +event (outside of the E2EE payload) called `m.peer_unwritable: true` to +signify ownership of the containing event by its `sender`, which would indicate if other users were prohibited from overwriting the event or not. However, this unravelled when it became clear that there wasn't a good value for the `state_key`, which needs to be unique and not subject to races from other malicious users. By scoping who can set the `state_key` to be the user ID of the sender, this problem goes away. +One way to satisfy the need for unique and non-racing state keys with an event ownership flag +is to key state events by not only their event type and `state_key`, but also their `sender` +when the event ownership flag is set. +This would also provide state ownership semantics that could not by overwritten by any other user, +as an event's owner would be determined implicitly from whoever sent the event, +instead of from an explicit field set in the event. +If this were to be done, endpoints for setting/retrieving state events would need to +allow specifing the owner of the event to set/retrieve. + ### Multi-component state keys [MSC3760](https://github.com/matrix-org/matrix-spec-proposals/pull/3760) From 3a0d09570b6810020bb12981603e5de5719fd9a8 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Tue, 8 Oct 2024 14:02:46 -0400 Subject: [PATCH 35/38] Fix typo --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index bb9fc4656fe..8fb4f5bbd87 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -141,7 +141,7 @@ This would also provide state ownership semantics that could not by overwritten as an event's owner would be determined implicitly from whoever sent the event, instead of from an explicit field set in the event. If this were to be done, endpoints for setting/retrieving state events would need to -allow specifing the owner of the event to set/retrieve. +allow specifying the owner of the event to set/retrieve. ### Multi-component state keys From e16482ab0739cede5ef92790cb0d1cd4a7271da1 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Tue, 8 Oct 2024 14:07:25 -0400 Subject: [PATCH 36/38] Mention impact of sender-scoped state on servers --- proposals/3757-restricting-who-can-overwrite-a-state-event.md | 1 + 1 file changed, 1 insertion(+) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 8fb4f5bbd87..90e7b204459 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -142,6 +142,7 @@ as an event's owner would be determined implicitly from whoever sent the event, instead of from an explicit field set in the event. If this were to be done, endpoints for setting/retrieving state events would need to allow specifying the owner of the event to set/retrieve. +It would also require server implementations to change how they key state events. ### Multi-component state keys From 1ddddb62d522d263f759e2db30728ef16e501a02 Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Wed, 9 Oct 2024 11:52:49 -0400 Subject: [PATCH 37/38] Say how the ownership flag impacts administration --- .../3757-restricting-who-can-overwrite-a-state-event.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 90e7b204459..25549d606f3 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -140,7 +140,10 @@ when the event ownership flag is set. This would also provide state ownership semantics that could not by overwritten by any other user, as an event's owner would be determined implicitly from whoever sent the event, instead of from an explicit field set in the event. -If this were to be done, endpoints for setting/retrieving state events would need to +Notably, this applies to high PL users as well, leaving them with no way to replace state events +owned by lower PL users. Administration of such events would then be limited to redacting them. + +With this change to state keying, endpoints for setting/retrieving state events would need to allow specifying the owner of the event to set/retrieve. It would also require server implementations to change how they key state events. From fd87b8a0ace0f7226487196e25d9bbc6f2a1678c Mon Sep 17 00:00:00 2001 From: Andrew Ferrazzutti Date: Wed, 9 Oct 2024 22:57:49 -0400 Subject: [PATCH 38/38] Fix contradictions for flag alternative --- ...restricting-who-can-overwrite-a-state-event.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/proposals/3757-restricting-who-can-overwrite-a-state-event.md b/proposals/3757-restricting-who-can-overwrite-a-state-event.md index 25549d606f3..ad742f3b906 100644 --- a/proposals/3757-restricting-who-can-overwrite-a-state-event.md +++ b/proposals/3757-restricting-who-can-overwrite-a-state-event.md @@ -137,15 +137,16 @@ goes away. One way to satisfy the need for unique and non-racing state keys with an event ownership flag is to key state events by not only their event type and `state_key`, but also their `sender` when the event ownership flag is set. -This would also provide state ownership semantics that could not by overwritten by any other user, -as an event's owner would be determined implicitly from whoever sent the event, +This would set a flagged event's owner implicitly from whoever sent the event, instead of from an explicit field set in the event. -Notably, this applies to high PL users as well, leaving them with no way to replace state events -owned by lower PL users. Administration of such events would then be limited to redacting them. +To support this, server implementations would need to change how they key state events, and +the endpoint for retrieving state events would need to allow specifying the owner of the event to +retrieve (or no owner to retrieve un-owned state). +Additionally, the endpoint for setting state events may support a query parameter to specify +which user's state to overwrite, which would work only for senders with a power level higher than +that of the targeted user. +Otherwise, administration of owned events would be limited to redacting them. -With this change to state keying, endpoints for setting/retrieving state events would need to -allow specifying the owner of the event to set/retrieve. -It would also require server implementations to change how they key state events. ### Multi-component state keys