MSC3757: Restricting who can overwrite a state event

[andybalaam]

Rendered

Implementations:

• Support MSC3757: Restricting who can overwrite a state event element-hq/synapse#17513
• rtc: Handle non-MXID call member event state keys matrix-rust-sdk#3836
• Loosen type of call member event state keys ruma/ruma#1885

Written by @ara4n , with contributions from @Johennes and @andybalaam .

FCP tickyboxes

[ShadowJonathan]

One nit, else this looks sound.

[richvdh]

I find this a confusing way of phrasing the current restrictions.

I'd say that there are essentially two current restrictions, imposed by rules 7 and 8 in the auth rules.

In short:

1. The user's PL must not be less than the "required power level" for that event.
2. In addition, if a state event has a state key which begins with an @, then the sender's mxid must match that state key.

The spec for m.room.power_levels defines required power level, but in summary, it is determined by the setting in m.room.power_levels events field for that event type if present; otherwise, it is determined by the state_default field.

[richvdh]

I think this is actually derestricting who can overwrite a state event.

Suggested change

	# MSC3757: Restricting who can overwrite a state event.
	# MSC3757: Relaxing the restrictions on who can overwrite a state event.

[AndrewFerr]

That's true for MSC3779, but not as much for this one; the former bypasses PL restrictions for setting state that belongs to the sender (where "belongs to" = the state key starts with the sender's MXID), but this MSC does not.

The restriction proposed by this MSC is to prevent state that belongs to a particular user from being overwritten by other, equally-powerful users.

The only PL restriction that's relaxed by this MSC is for allowing more powerful users to overwrite state that doesn't belong to them, for the sake of having a tool against state graffiti.

[richvdh]

You're right. Still, I find the title a bit confusing. How about:

Suggested change

	# MSC3757: Restricting who can overwrite a state event.
	# MSC3757: Extending the set of write-protected state keys

or something

[AndrewFerr]

TBH I informally refer to this MSC as "the owned state MSC" despite that being the title of MSC3779 😉

Since one of the distinguishing differences of this MSC over 3779 is the ability for admins to manage others' state, maybe we could call it

Suggested change

	# MSC3757: Restricting who can overwrite a state event.
	# MSC3757: State event ownership (with admin management)

?

[richvdh]

Last time we changed the auth rules, there was a lot of discussion around "let's never do this again without test vectors for the auth rules" (cf matrix-org/matrix-spec#1710, matrix-org/matrix-spec#1642).

The apparent confusion over what the current auth rules mean, and what they should say after the change, makes me think that we should start some progress in that direction.

[AndrewFerr]

The Complement tests should be a step in the right direction.

[richvdh]

I remain concerned that this MSC opens the door to a proliferation of state events that we cannot delete, and that faster-joins can't help with. I would like to see some discussion of this in the MSC.

Admittedly, we have this problem to some extent today, in that there is nothing stopping users creating lots of state events with different types, but:

• (a) such behaviour is currently restricted to room moderators, because it relies on their power level being state_default or higher. This MSC would change that, by allowing any user to (say) create millions of m.beacon_info events.
• (b) there is currently no specced usecase that requires multiple state events per user, and introducing one feels like a step-change. Arguably that is not a problem of this MSC per se (and rather MSCs that make use of it such as MSC3672), but I think we'll need to at least set some expectations here.

This is not a veto from me, but I do think we need to consider this properly and at least set out guidelines for future MSCs that build on this.

[AndrewFerr]

• (a) ... This MSC would change that, by allowing any user to (say) create millions of m.beacon_info events.

This is what MSC3779 proposes, not this one.

To clarify, the effective auth rule changes proposed by this MSC are to:

• grant write access on state events with state keys of the form <sender>_<anySuffix> to all users
  • N.B. <sender> is the MXID of the user sending the state event
• grant write access on state events with state keys of the form <mxid> & <mxid>_<anySuffix> to users whose PL is greater than that of <mxid>'s PL
  • N.B. <mxid> is any MXID

The event-sending restrictions imposed by m.room.power_levels remain in effect.

What this MSC does allow is creating lots of state events with different state key suffixes -- but that would be limited to room moderators, just like how creating lots of state events with different types currently is.

• (b) there is currently no specced usecase that requires multiple state events per user, and introducing one feels like a step-change.

As a start, MSC4143 makes an explicit mention to this one (namely, in the section regarding MatrixRTC room state), and is what has driven interest in this MSC.

[richvdh]

@mscbot concern changes to auth rules are unclear
@mscbot concern issue of state event proliferation requires discussion

[clokep]

@mscbot concern Does not work with all MXIDs

[clokep]

@mscbot concern Does not work with all MXIDs

Reposting due to matrix-org/mscbot-python#26 not yet being deployed.

[deepbluev7]

While the spec specifies a grammar for server names, are we SURE that servers verify that grammar? While officially underscores are invalid in domain names and you can't order a TLS certificate for it nowadays, such domains still exist in the wild and wildcard certificates even allow using TLS with them. For example: https://my_sarisari_store.typepad.com/

I think relying on underscores as a separator is a rather scary trap and I wouldn't bet on all currently developed Matrix servers rejecting such server names.

[AndrewFerr]

ac24510 adds this to the "Potential issues" section.

[AndrewFerr]

How about using @ as the separator? Since the separator will never be the first character in the state key, it shouldn't be possible to confuse it with the user ID sigil.

[AndrewFerr]

| could also be a good separator.

[turt2live]

Quick process note: there appear to be several lengthy comments not contained to threads on this MSC. I haven't reviewed those because github makes it difficult to track replies - please move them to the MSC text or into a thread for better visibility.

---

On the Apache voting scale, I'm at a -1.0 for how the MSC is currently written. A stronger rationale for why this is needed now and strong discounting of a top-level ACL structure would change this to a -0.9 (sorry, I'm just not in favour of string packing here).

[turt2live]

MSC3489 and MSC3672 are not prioritized for inclusion right now, which raises questions about why this MSC is put up for FCP if we're not going to use it for a while. A question around whether the implementation is suitably deployed also comes to mind, though I'm not certain enough to raise that as a FCP-blocking concern.

An update to the introduction to better list out all the features which benefit from this MSC feels needed.

[erikjohnston]

I'll let @AndrewFerr talk more about his use case, but broadly I think its for per-device call state within a room.

[AndrewFerr]

its for per-device call state within a room.

That's correct; more precisely, it's for per-device call membership state (as a user can join a call from multiple devices at once).

Currently, the call membership state is an array, with one element per participating device. The problem is that updating that state array is prone to race conditions, as adding/removing an entry to the array is dependent on the current value of the array.

This MSC allows for using one state event per device, which each device can freely update without risk of any other device (or user, for that matter) overwriting it at the same time.

[turt2live]

Proposal language should generally be assertive: "The state_key restrictions are changed to..." rather than "The state key should be fixed". This would also resolve a question about who 'we' is.

(please also limit lines to ~100 characters for easier review)

[turt2live]

I find the @ prefix restriction a bit questionable, for the record. The only specified state event which uses it is m.room.member, which the auth rules validate state_key well before the restriction is checked. Non-spec usage of the state key already applies tricks like prefixing user IDs with _ to ensure they aren't hit by the restriction, and I'm not really convinced that location sharing/beacons need to pack a user ID into the state key anyways (see https://github.com/matrix-org/matrix-spec-proposals/pull/3757/files#r1103877363 ).

This has me leaning towards removing the @ prefix restriction entirely, but I recognize that's not exactly a helpful opinion for this MSC to tackle. Creating stronger arguments for why the dependent features require the user ID in the state key I think would help, though.

[turt2live]

The mention of requiring a new room version should be at the top of the Proposal section. How I've done this in the past is literally:

In a future room version...

[actual proposal]

[turt2live]

@mscbot concern Introduction does not sufficiently list benefiting MSCs/features.
@mscbot concern Insufficient implementation - Complement tests are required for this MSC.
@mscbot concern Alternatives section is missing some alternatives.
@mscbot concern Specific alternative of top-level access control is not sufficiently discounted.

[AndrewFerr]

@mscbot concern Insufficient implementation - Complement tests are required for this MSC.

Complement tests are added by matrix-org/complement#733.

[AndrewFerr]

There've been some issues/concerns raised about the state key string-packing:

• MSC3757: Restricting who can overwrite a state event #3757 (comment) (ownership semantics may benefit non-state events, too)
• MSC3757: Restricting who can overwrite a state event #3757 (comment) (danger of using an underscore as the string-packing delimiter)
• MSC3757: Restricting who can overwrite a state event #3757 (review) (danger of long post-packed state keys)

Adding a top-level event field to signify the "owner" of an event would help solve these issues, and is akin to the idea of state sub-keys proposed by MSC3760.

However, that approach was dismissed by https://github.com/matrix-org/matrix-spec-proposals/pull/3757/files#r848454293 & #3757 (comment) due to the friction of redefining state events & state resolution.

So it seems like either option (string-packed state keys vs a top-level owner field) has problems. Should the goal be to decide which option is less problematic, or to arrive at a compromise / a different option?

[kegsay]

Use cases need more fleshing out, particularly to justify why arbitrary bytes as a suffix are a good idea (they likely aren't). Assuming the reasons are "flexibility", then at the very least we should be aggressively restricting which arbitrary bytes we allow, e.g [a-z0-9].

[kegsay]

Is it valid to have an empty string as the suffix? E.g @kegan:matrix.org_? What about having arbitrary unicode characters? Null bytes? Please let's be sensible and force sensible restrictions on this new user-defined variable, lest we end up in another hell of poor validation causing problems for clients/servers.

I would suggest a very strong restriction of [a-z0-9] unless there are good reasons to allow other characters (there almost certainly are not).

[AndrewFerr]

Allowing an empty suffix probably won't hurt. I can imagine cases of the suffix being a property that may take on an empty/nullish value.

For a device ID to be usable as a suffix, the suffix charset must include all characters that can be used as a device ID. Unfortunately, there's no specced device ID charset that I can find, and in practice it is quite broad:

• Device IDs generated by QR code logins (at least on Element X Android) can contain / and +.
• /_matrix/client/v3/login allows setting a custom device ID of any string, and the Synapse implementation allows all sorts of characters (and lets me set a device ID of a b ?!@#$%^&*()-=_+/).

So if we want device ID suffixes now, maybe defining a suffix charset is premature, unless this MSC also defines a stricter device ID charset. But that raises the issue of what to with existing device IDs that don't follow the charset...

[kegsay]

This is surely too literal though. You can map device IDs deterministically to a valid character set, at its most basic SHA256(device_id).

[AndrewFerr]

That's a good idea. I was worried that the input size of device IDs would be too large to safely hash, but the point is to avoid hash collisions, the chance of which should still be small.

Then, this MSC can do away with trying to define a suffix length / charset that can fit a raw device ID.

I will still propose a few non-word characters to be in the suffix charset, because it may be handy to have a suffix containing multiple properties that are easy to separate with a non-word character (eg. @user:hs_prop1_prop2_prop3). The spec already uses a charset of [0-9a-zA-Z.=_-] for email login secrets/tokens, and would be a decent charset to use here as well.

[AndrewFerr]

On second thought, a handy consequence of not restricting the suffix charset is the ability to prefix any existing state key with a user's MXID to scope its ownership to that user. With a restricted suffix charset, there may be some state keys that would be invalid as a suffix.

IMO as long as the charset of state keys in general is left unrestricted, there's little benefit in restricting the suffix charset, unless doing so is a step towards restricting the general state key charset.

[tulir]

I agree that there's no point in restricting these specific state keys when all other state keys are still arbitrary strings. To take advantage of this MSC, you must give users permission to send state events of certain types. That means users will be able to send unprefixed state keys too, which will not have any character set restrictions.

Restricting state keys in general might be a good idea to do in combination with MSC2828

[kegsay]

I don't agree with the attitude of "we don't have good validation, so let's not add validation". There's zero reason to punt this down the line to another MSC. It's absolutely trivial to expand the character set or length limits in another MSC. It's very difficult to restrict it once there are client implementations in the wild relying on there being no restrictions. Validation is important to reduce the attack surface of any newly added features. The suffix string will be stored in new places where the state key is not (e.g DBs will likely either have this as a column, or indexed in such a way to allow efficient ordered lookups), which means there will be new code written to read this input. Validate the input, please.