MSC2209: Alter auth rules to check notifications in m.room.power_levels

proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md

@@ -0,0 +1,45 @@
+# Update auth rules to check notifications key in m.room.power_levels
+
+## Introduction
+
+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.
+
+[m.room.power_levels](https://matrix.org/docs/spec/client_server/r0.5.0#m-room-power-levels)
+[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:
+
+* 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
+
+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*
+
+* 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`.
+
+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:
+
+
+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.
+
+## 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.
+
+## 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.