[WIP] MSC4299: trusted users

[nexy7574]

Rendered

[JadedBlueEyes]

What mechanism exists to enforce this? Otherwise it doesn't really make sense to specify 'must' for this.

It also conflicts with the idea of using this as 'per-user settings' that Emma floated - for something like hiding a user's avatar in mutual rooms. Perhaps that works better as a different MSC, given it doesn't match the semantics of 'trusted users', though

[nexy7574]

The server should enforce it, i.e. refuse to update the trust account data if there's a conflict with the ignored users

It also conflicts with the idea of using this as 'per-user settings' that Emma floated - for something like hiding a user's avatar in mutual rooms. Perhaps that works better as a different MSC, given it doesn't match the semantics of 'trusted users', though

I agree. Keeping ignores at all kinda conflicts with this, since something like {"trusted_users":{ "@bad:example.com": {"ignored": true } } } would probably better, but as noted in the "Alternatives" section, this would be an expensive and high-friction endeavour, which is most likely suited for a different MSC entirely.

[JadedBlueEyes]

Is there an API clients can use to do this atomically?

[nexy7574]

That would be an implementation detail, but I'm pretty sure adding a new API endpoint would take this MSC out of "just another specced account data type" and into an actual API update, which brings its own set of challenges. I'd like to avoid that if possible.

To add - generally, clients already have the ignore list to hand anyway, and in this case will also have the trusts - checking for conflicts before sending any events wouldn't be difficult

[JadedBlueEyes]

What it does have over this one is the ability to define whole servers - I'm not sure that makes sense for this MSC given its semantic role, and I think they co-exist well enough, a tough some thought should be given to their interaction (does being trusted override being filtered by this/are trusted users added to the allowlist?)

[nexy7574]

The argument for whole-server trusts could be made (I'd want to trust timedout.uk, nexy7574.co.uk, and transgender.ing for example, since I know all users on there are good & trusted users), but does add additional complexity, and is way less applicable in practice than specific user IDs.

The wording could be changed from users to entities though, which opens us up to setting trust levels for both users and servers, and potentially even glob patterns, which would also be quite powerful. I'll think on that.

[nexy7574]

does being trusted override being filtered by this/are trusted users added to the allowlist?

I think in this case, user trusts would be the implicit default, with any explicit definitions in MSC4155 overriding it (i.e. if a user is trusted but explicitly blocked in 4155, the result would be blocked, and vice-versa). But that's just my two cents, I've only lightly linked it to 4155.

[JadedBlueEyes]

Other alternatives

• semantically 'per-user settings' rather than trusted, perhaps with a m.trusted key

Also to think about, defining the default settings for behaviours specified by keys when they are unset for a particular user. Ie a 'trusted_user_default_settings' map

[nexy7574]

Defining "defaults" is difficult given the followup MSCs I have in mind don't exist yet. imo followup proposals that aim to add trust features should tune their expectations to having their value as a false-y/nil/null/whatever value, since defining and updating defaults seems difficult in this context.

[kegsay]

Needs "Security Considerations" as per https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/0000-proposal-template.md#security-considerations

The problem with adding a general concept ("trusted users") is that it's hard to gauge whether it is fit for purpose until there are actual use cases which use it. Different MSC authors may see "trusted users" in different ways and have different non-overlapping sets of requirements. For this reason, I don't think adding this concept is a good idea at this time.

Random comments whilst reviewing:

• It's not possible to express groups of users. This limits the applicability of this proposal: companies/organisations likely won't be able to use this. For example, you can't whitelist a server (e.g everyone on :element.io) or a space (e.g everyone who is a member of this space). Similarly, the inability to express groups means this list is going to grow very large, which will add significant overhead to an initial sync (we already see this with push rules in account data which has per-room settings).
• It's not cryptographically secure. The notion of "trust" in Matrix is general grounded in whether we trust the other user's cryptographic keys. This is not what is happening here. The server can modify this list at will. This limits the applicability of this proposal: you can't use trusted users for security-sensitive operations. For example, the MSC proposes to allow URL previewing from trusted users, but since the set of trusted users is controlled by the server, this is not safe.

[nexy7574]

Hm, when drafting this up I did not really consider any security considerations to be of note. I was under the assumption that people would only be using servers they trust, but considering server-side manipulation is considered a CVE I'll bring that back to the drawing board.

It's not possible to express groups of users.

In a prior comment I considered changing it from explicitly users, to "entities", which would allow for users, server names, glob patterns, and I could presumably also work rooms (spaces) into that. Hopefully, that will tick off that checkbox.

The notion of "trust" in Matrix is general grounded in whether we trust the other user's cryptographic keys.

Assuming the issue here comes down to the wording, do you have any suggestions on what better terminology would be? I'm hesitant to use anything like "friends", as that implies that there's an agreement between the entites, but something like "known" is too vague and "safe" might be misleading. Especially if we're considering that the server could tamper.

[JadedBlueEyes]

I assume the issue is if this ended up controlling any cryptography-related functions. That's not the use we're intending, though, although it should be kept in mind.

If we need to cryptographically secure the list, we do have the cross signing/back up key that we could use to authenticate the text. This does conflict with the idea of companies having a preset trusted list for accounts on the server though.

Regarding expressing groups of users, I'm not entirely sure how well that fits in with the metaphor of a contact list. It would end up with this being closer to an LDAP directory in mental model. That's a thing for email (I know both Outlook and Apple Mail can read contacts from directories), but it's not something that will be familiar to mobile users, more used to WhatsApp-like messaging.

That, plus the crypto concerns, raises the question as to what extent those ideas should be mixed. Having a secure contact list would also require that a method like spaces isn't supported, because that can be manipulated by the server. It would make sense to leave that kind of stuff to a dedicated MSC.

this list is going to grow very large, which will add significant overhead to an initial sync

This depends on how people use this. My own contacts list, for example, has around 300 cards (most of them representing people I've met and exchanged numbers with IRL) - this is pretty high compared to my peers. I imagine a lot of people will only have ~10 trusted users on the list, and a limited few will have automation that add thousands of users. I'm not sure to what extent we want to support the latter case.
If it is something we want to support, we can explore ideas to allow pulling down parts of the list at a time and checking with the server if specific accounts are on it.

[nexy7574]

I don't believe this proposal is remotely suitable for anything to do with cryptography, either existing bands should be used for what's relevant, or someone far smarter than me should open another proposal with this in mind if necessary.

This depends on how people use this.

It's best to consider most usecases. I'd like to add all of my servers and all of my accounts as "trusted users" for example, and I know people who would find some way to stuff policy lists into this. Having wider targets is a net-gain either way.

[JadedBlueEyes]

The notion of "trust" in Matrix is general grounded in whether we trust the other user's cryptographic keys.

I also think this is a confused way of putting this - we've verified the user, we trust that the channel is secure, we do not inherently trust a verified user.

[nexy7574]

"trust" is heavily referenced in MSC4161, which should be kept in mind. Specifically, "Verified User" references it a lot.

[JadedBlueEyes]

I'm only seeing it in MSC4161 in instructing to not use the TOFU terminology, and in terms of 'trusted device,' which makes sense. From what I'm reading, it instructs the usage of the 'verified user' terminology that I used.