Skip to content

Conversation

turt2live
Copy link
Member

@turt2live turt2live added proposal A matrix spec change proposal client-server Client-Server API kind:core MSC which is critical to the protocol's success labels Jul 2, 2022
@turt2live turt2live self-assigned this Jul 2, 2022
@@ -0,0 +1,40 @@
# MSC3842: Power levels on message (extensible) events
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought: when a client decrypts a message, it will need to determine if that event still meets the power levels, but with extensible events it's trivial to bypass "you can't send images" (for example) because you can just create a custom event type with m.image fallback.

If we solve the problem by making power levels apply to content blocks, we're potentially causing problems because an m.poll.start might be legal for senders, but m.image is ignored. Some clients would render the event while others wouldn't.

A potential solution might be dual consideration? If the event type is specifically listed in the power levels, assign that required PL to the event. If the event type isn't in the power levels, instead try to look for the implied events for fallback representations. If those implied event types are further not specifically listed, then the event is presumed allowed.

This would allow a room to support m.poll.start, for example, but prevent a malicious user from inventing an event type to spam images. There's still potential risk that a client doesn't support polls and therefore ends up picking the m.image representation, but presumably we can further have clients verify that the implied fallback representation's event type is also allowed, with m.text always being allowed for fallback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

client-server Client-Server API kind:core MSC which is critical to the protocol's success proposal A matrix spec change proposal

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant