The key `notifications` was added to the `m.room.power_levels` event after the finalisation of the auth rules specified in room version 1. This leads to the fact, that this dictionary is not subject to the same validation as other dictionaries in the event, such as `users` or `events`. This especially means that Alice is able to alter any entry within the dictionary including ones, that are above her own power level, which is inconsistent with the behaviour for the other two dictionaries.
The key `notifications` was added to the `m.room.power_levels` event after the
finalisation of the auth rules specified in room version 1. This leads to the
fact, that this dictionary is not subject to the same validation as other
dictionaries in the event, such as `users` or `events`. This especially means
that Alice is able to alter any entry within the dictionary including ones,
that are above her own power level, which is inconsistent with the behaviour
[room version 1](https://matrix.org/docs/spec/rooms/v1)
## Proposal
The auth rules regarding `m.room.power_levels` have been established in room version 1. The general idea here was that creators of a new `m.room.power_levels` event are only able to make changes to something that is equal to or lower than their own power level.
So, assuming a room with Alice (50), Bob(100), `m.room.power_levels` at 50, `m.room.name` at 75 and `m.room.topic` at 25 would mean the following:
The auth rules regarding `m.room.power_levels` have been established in room
version 1. The general idea here was that creators of a new `m.room.power_levels`
event are only able to make changes to something that is equal to or lower than
their own power level.
So, assuming a room with Alice (50), Bob(100), `m.room.power_levels` at 50,
`m.room.name` at 75 and `m.room.topic` at 25 would mean the following:
* Alice CAN alter `m.room.topic` to any power level up to her own, in this case 50
* Alice is NOT able to alter `m.room.name` since the current value is higher than her own (75 > 50)
* Alice is NOT able to alter the power level of Bob, since his current value is higher than her own (100 > 50)
* Alice is free to set the level for anything that has not been defined such as `org.alice.message` up to a maximum of 50
* Alice is NOT able to alter `m.room.name` since the current value is higher than
her own (75 > 50)
* Alice is NOT able to alter the power level of Bob, since his current value is
higher than her own (100 > 50)
* Alice is free to set the level for anything that has not been defined such as
`org.alice.message` up to a maximum of 50
Later on the key `notifications` was added to the `m.room.power_levels` event. It contains a mapping of notification keys to a power level, that is required for a user to trigger the specific notification. The most famous notification type is the `@room` notification.
Later on the key `notifications` was added to the `m.room.power_levels` event.
It contains a mapping of notification keys to a power level, that is required
for a user to trigger the specific notification. The most famous notification
type is the `@room` notification.
Going back to the original example because this key was added later on, the auth rules make no mention of it, which enables the following behaviour. *It is assumed that `@room` is at 75*
Going back to the original example because this key was added later on, the auth
rules make no mention of it, which enables the following behaviour. *It is assumed
that `@room` is at 75*
* Alice can add any key to the dictionary and set the value to any value she wants, including ones higher than her own.
* Alice can alter the value for `@room` to any value she wants, including ones that are higher than her own, even though her own value is lower.
* Alice can add any key to the dictionary and set the value to any value she wants,
including ones higher than her own.
* Alice can alter the value for `@room` to any value she wants, including ones that
are higher than her own, even though her own value is lower.
The proposed solution is to alter the auth rules and add the `notification` dictionary to the same rules that handle `events` and `users`.
The proposed solution is to alter the auth rules and add the `notifications` dictionary
to the same rules that handle `events` and `users`.
So the rule [10.d](https://matrix.org/docs/spec/rooms/v1.html) of the auth rules in room version 1 would be altered to:
So the rule [10.d](https://matrix.org/docs/spec/rooms/v1.html) of the auth rules in
room version 1 would be updated in a new room version to:
For each entry being added, changed or removed in events, users __and notifications__ keys:
For each entry being added, changed or removed in events, users __and notifications__
keys:
## Tradeoffs
The proposed solution would be a breaking change with current room versions and the alternative would be to leave the `notifications` key without any checks.
The proposed solution would be a breaking change with current room versions and
the alternative would be to leave the `notifications` key without any checks.
## Security considerations
This is likely to improve security because it prevents malicious users that were only given the right to emit `m.room.power_levels` so that they could alter a very specific key, such as, `invite` from altering the rules established for triggering notifications.
This is likely to improve security because it prevents malicious users that were
only given the right to emit `m.room.power_levels` so that they could alter a very
specific key, such as `invite`, from altering the rules established for triggering
notifications.
## Conclusion
The current spec conform behaviour regarding `notifications` is inconsistent with behaviour shown by the other dictionaries and room administrators are very likely expecting the `notifications` to work the same as them. The required change is minimal is and also in line with the general spirit of the auth rules regarding the `m.room.power_levels` event.
The current spec conform behaviour regarding `notifications` is inconsistent with
behaviour shown by the other dictionaries and room administrators are very likely
expecting the `notifications` to work the same as them. The required change is minimal
is and also in line with the general spirit of the auth rules regarding the
`m.room.power_levels` event. A new room version is, however, required. This can be
Luca Becker
5 years ago