MSC3144: Allow Widgets By Default in Private Rooms #3144
Conversation
dbkr
changed the title
dbkr
added
client-server
| It proposes to accomplish this by changing the `private_chat` preset on `createRoom` to send the | ||
| `m.room.power_levels` event with the `im.vector.modular.widgets` event at the `users_default` level | ||
| (ie. normally 0). |
There was a problem hiding this comment.
We can't reasonably specify that the spec include a vendor prefix in a preset, but there is nothing stopping a server from doing this. For the spec, this should be m.widget
There was a problem hiding this comment.
Mmm, true - what's the path to us changing this though? Is there any hope?
There was a problem hiding this comment.
Widgets are in a complicated state, but the short answer is m.widget is accepted into the spec but needs to be properly incorporated. There are larger questions about the structure of widgets which are preventing that spec PR from being written, and why clients like Element haven't yet started transitioning - if we're changing how widgets fundamentally work, there's not much benefit to having a transitional period for a legacy identifier.
|
|
||
| ## Security considerations | ||
|
|
||
| None forseen other than those detailed in 'potential issues'. |
There was a problem hiding this comment.
Widgets are inherently insecure pieces of a room. In larger private rooms (say, community watercooler) it opens the door to a number of phishing or exfiltration attacks that can be performed by untrusted individuals (untrusted because they will not have been graced with higher power levels).
There was a problem hiding this comment.
Yeah, private-but-untrusted rooms certainly exist (an all-company internal room, for example). Is this distinction important enough to make a separate managed_private_room preset? or putting this behaviour on a separate semi_trusted_private_chat (for want of a better name)? Or do we just let people start off with a private chat and tweak the settings appropriately?
There was a problem hiding this comment.
More presets I think is probably our best answer, particularly with usecases like Spaces asking questions like "is this for your team?" - the intricacies of the answer to this question is already more complex than a simple private_room preset.
or tldr: a preset which distinguishes team-like rooms from not-team-like rooms would be the way forward, I think
| 1. Room admins might later change the room to be a public room without realising that anyone can | ||
| edit widgets, resulting in an insecure configuration. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
we could also decouple conference calling from widgets, though this is a much harder technical feat.
There was a problem hiding this comment.
This is a possibility but allowing users to make widgets by default seems desirable too, in the sense that I asked Matthew and the convo went like this:
Dave: [...] it would have to apply for widgets too, which I assume would be ok
Matthew: yeah, very okay
There was a problem hiding this comment.
yea, that seems fair. Can some words about "or we decouple, but lolno because complexity" be added to the proposal? I don't think it needs to be overly detailed about what "decoupling" means, as that'd be a whole other proposal's problem.
turt2live
added
the
needs-implementation
Rendered