2 ms·

Third Room itself looks very cool, and I hope to try it in VR whenever that's possible. However... I've grown increasingly disillusioned with ACL-based permiss

Third Room itself looks very cool, and I hope to try it in VR whenever that's possible. However... I've grown increasingly disillusioned with ACL-based permissions systems for distributed social applications like this. Matrix is very strongly oriented towards ACLs/user identity, and the result is that applications like this which could operate without access to much of my existing account data nevertheless run effectively as me and can thus do everything I can. That's super dangerous when I'm the admin of a few rooms, because e.g. granting another user admin privileges in a room is irrevocable. There have been plenty of cases when I've wanted to try out a Matrix-based app, but every time I do that I'm handing over the keys to my account to the app, which may or may not be trustworthy. And the consequences of mistakenly trusting a malicious app are severe.

Arathorn 4y ago
One of the really cool things about Third Room is that it’s the first Matrix client to natively launch with OIDC for auth. This means you will be able to grant it access to specific auth scopes in future if you don’t want to give it access to your main account, and I think solve precisely the problem you’re talking about here. Check out the OIDC section of https://matrix.org/blog/2022/08/15/the-matrix-summer-special-2022/ https://matrix.org/blog/2022/08/15/the-matrix-summer-special... for more details
- ryukafalz 4y ago
  That's better than the current state of things, but I think still not as fine-grained as it should be, at least not without a lot of work and standardization. Among other things: - This requires that any time you want to be able to selectively grant a subset of your account's authority, it requires standardizing new scopes to do so if there aren't already some that are suitable - If I'm not mistaken, only the application is able to define which OIDC scopes are requested, and if the application requests more access than you'd like to give it, your options are limited - If I'm not mistaken, OIDC scopes can only be requested at authentication-time, so there's no way to grant additional access later on at runtime To be clear, none of this is specific to Matrix; most webapps seem to work this way! I just happen to be of the opinion that most webapps have way more access than they need. :)
  - Arathorn 4y ago
    We’re intending to spec very finely granular scopes. Eg “this client is allowed to read but not send these sort of events in this set of rooms, and shouldn’t be sent keys for other rooms”.

Arathorn 4y ago

One of the really cool things about Third Room is that it’s the first Matrix client to natively launch with OIDC for auth. This means you will be able to grant it access to specific auth scopes in future if you don’t want to give it access to your main account, and I think solve precisely the problem you’re talking about here. Check out the OIDC section of https://matrix.org/blog/2022/08/15/the-matrix-summer-special-2022/ https://matrix.org/blog/2022/08/15/the-matrix-summer-special... for more details

ryukafalz 4y ago
That's better than the current state of things, but I think still not as fine-grained as it should be, at least not without a lot of work and standardization. Among other things: - This requires that any time you want to be able to selectively grant a subset of your account's authority, it requires standardizing new scopes to do so if there aren't already some that are suitable - If I'm not mistaken, only the application is able to define which OIDC scopes are requested, and if the application requests more access than you'd like to give it, your options are limited - If I'm not mistaken, OIDC scopes can only be requested at authentication-time, so there's no way to grant additional access later on at runtime To be clear, none of this is specific to Matrix; most webapps seem to work this way! I just happen to be of the opinion that most webapps have way more access than they need. :)
- Arathorn 4y ago
  We’re intending to spec very finely granular scopes. Eg “this client is allowed to read but not send these sort of events in this set of rooms, and shouldn’t be sent keys for other rooms”.