[WIP] MSC3234: Send currently open room in client to bots

[LecrisUT]

Rendered

This MSC is closed in light of two aspects:

• Main issue: The original application for bridges falls apart when there are clients/users who do not subscribe to such tracking. If there are other applications this could be resolved. The discussion is in @penn5's review.
• Risk of abuse and tracking users via leaked metadata. The discussion is in @kevincox's review.

Please continue discussion there and re-open if there is new developments.

Signed-off-by: Cristian Le git@lecris.me

[LecrisUT]

This is my first attempt of an informal MSC so please be gentle :D

[MTRNord]

I would like to add (I honestly only read the title at this time) that this could be abused to track people which imho is a potential security issue. It needs some kind of user interaction for this to activate. the bot should not be able to activate this without user consent

[LecrisUT]

Indeed so. Would it be sufficient for the client to ask user interaction at the bot's initialization stage, or more regularly?

[MTRNord]

Indeed so. Would it be sufficient for the client to ask user interaction at the bot's initialization stage, or more regularly?

I think having something like what oauth shows like"bot xy wants to check in which room you are active" combined with a way to disable the feature again might make sense. How exactly the client UI/UX for this doesnt matter at this spec level but basically at start a user interaction and a way to disable it again should be fine imho.

[LecrisUT]

But spec wise I don't think there's anything special that needs to be added, but it's only on the client side. Wouldn't pointing out these shortcomings in the Security concerns be enough?

At the end of the day the client has full control over stopping this feature and they should make a transparent enough UX. IMO the best interface for these would be to have an extendible drop-down menu particularly at the bot user to show up some settings the client can support to change.

[MTRNord]

Well it atleast needs some kind of way of communicating this to the bot. apart from that how that gets displayed in UI doesnt matter here.

[erkinalp]

Fixes for matrix terminology & formatting fixes
Signed-off by: Erkin Alp Güney erkinalp9035@gmail.com

[kevincox]

It isn't clear to me this is a great solution. "Want read-receipts" and "Is looking at chat" are not equal. What if I have a client feature to notify me when a message is read?

Since this has serious privacy implications I would strongly prefer that we have a solid use case that can justify the downsides of leaking this information. Even if it is opt-in just adding that possibility opens up doors to abuse.

[LecrisUT]

What if I have a client feature to notify me when a message is read?

You could still encounter the race condition that the bridge is looking for read-receipts, while the other user is sending a reply and it is marked as read. You could argue that the bot should only look for read-receipts if last message is not marked read, so the user would not have enough time during this time-window. The counter to that is that people can quick-reply from notification without having the message marked read, so indeed this race condition can happen IRL, especially if the bridge is slow to switch activities.

The other use-case is that it greatly lessens the burden on the bridge to not have to check for all chat rooms periodically to get read-receipts, that is if the client does not have notification of message read or it is in many group chats. Particularly when the bridge has to manage multiple independent browser sessions for multiple users. This would strain both the network and the machine's resources.

Indeed it would be better to have more concrete examples where this might be useful. I have not considered where else this would be necessary or useful.

The possibility of abuse is indeed concerning, so we have to put our black hats and try to abuse it as much as possible. The only vector of attack for this is from a malicious bot so:

• Case 1 (Trivial): It tries to interact with a client that does not have this implementation. There would be no responses from the client so no risk there.
• Case 2 (Low): Client has this feature implemented, but the user does not want this ability. There is a possible attack there. The only prevention for that is opt-in, require user action and quick opt-out options. All are on the client's side burden to implement, and we cannot guarantee there would not be malicious/inadequate clients that do not include good privacy concerns, but at that point you have bigger problems.
• Case 3 (Low): Group chat with only a few willing users, or a user has multiple clients. The control is on the client side so in the end it's the same situation as case 1 and 2.
• Case 4 (Medium): The bot can leak information from the requests and/or not opting in some rooms. The bot only requests at the registration stage, everything else is on the client responsibility. The client could leak some information from unencrypted or regularity of the pings.
  • For the former, yes you have situations where you want to send unencrypted messages but do not wish to send regular presence. At the very least the information about which client could be omitted, but there is still activity information leaking. For this we need more time to think and discuss.
  • For the latter, even if it's encrypted, you can deduce the type of information from the regularity. At the very least it would only be sent when user is active, which is not the majority of time. A potential safe-guard is to add a random delay and add random data in the package, the first one being the client's burden again and the second could be added in the protocol itself.
• Case 5 (Trivial): The room or server can leak information from saving this feature. This is only an agreement between the bot's presence in a room and client, so there is no information to leak on the server side.
• Case 6 (Low): The bot can leak information from stored information. The only stored information needed by the bot is if client agrees or not, not the activity. At this point you have bigger problems anyway.

That's all I can think for now, I will edit and add additional comments when I can think about it more. Please add as many case concerns as you can find even if they seem trivial. We should discuss how abusive this can become.

[kevincox]

You could still encounter the race condition that the bridge is looking for read-receipts

My point was that the given example could break your provided use case as I would not be notified as I was not looking at the chat whereas I would expect to be notified. Not that this could solve the problem.

The other use-case is that it greatly lessens the burden on the bridge to not have to check for all chat rooms periodically to get read-receipts

IIUC this is an alternative to read-receipts for matrix users? That is interesting but I think that it would be better to approach this by describing the flaws in the current system and why this system is better. Furthermore this doesn't seem to need quite as invasive of a protocol as it only needs one notification per message. Also I'm not sure about your bandwidth concerns but the Matrix sync APIs shouldn't require polling every room individually.

The attack concerns mentioned seem to be fairly reasonable. But one thing is to remember that if a feature exists people will be tricked into using it. We can't completely protect users from themselves, but that is why I think solid use cases are important justification.

[LecrisUT]

My point was that the given example could break your provided use case as I would not be notified as I was not looking at the chat whereas I would expect to be notified. Not that this could solve the problem.

Oh I understand the confusion there. The question is would you want pinging notification on all rooms, or only the ones you currently have open by the client. This would only send notifications to the latter and that is basically what I was referring as "Is looking at chat", the current room that is being active and/or if the client is in the foreground or not. You have a point that the foreground/background would not be desired so this could be toggled by the client, I can see the user wanting either way.

The race condition would still hold if the bot was looking at all chats, the risk being higher the more 1-on-1 chat you got being monitored.

IIUC this is an alternative to read-receipts for matrix users?

It's better viewed as bridging read-receipts from bridged-app to matrix room. It's not an issue of the matrix read-receipts, but on the capabilities of the bridged-app. The example bridge that this was being based on is Frair's matrix-puppeteer-line which requires a chrome extension in order to interface with LINE.

LINE makes it visible the user's messages read-receipts which can only be checked in the chrome extension by opening the chat and checking the status, unlike matrix or other more sensible systems that can poll and receive without having to open a chat window. The race condition comes when the bridge enters the room and checks the receipt, while at the same time the other user has sent a message so it is being marked as read already, and in a worst case scenario the message is not being forwarded due to the bridge's logic.

Currently the bridge does not know which room it needs to check for (apart from internal memory and logic) and what room the user is interested in seeing, so it has to be setup so that it polls periodically in which case the race condition as above happens. This protocol would mitigate it so that the checks are only done on the room that the user currently has open.

but that is why I think solid use cases are important justification.

I have come to agree with that, and the discussion down below with penn5 highlighted how this use-case has a fundamental flaw, so for now we can leave it as it is until a new use-case appears that might want to pick it up again.

PS: In writing this I just came to the obvious realization that the bridge would only need to poll which room the user last accessed (that the bridge was managing) and keep track internally. Probably this can already be implemented if the user's initial request for the rooms can be forwarded to the bot.

[penn5]

Surely if even one user in a room rejects to send 'view receipts', it defeats the entire purpose of the MSC, since the bot has to resort to polling all the time again?

[LecrisUT]

Hmm, great point. It would depend on the application so let's consider the bridge example and two scenarios:

• Case 1: one bridged user with multiple clients and only a few are willing.
  • If the user uses an untracked device and there are no periodic polling of read-receipts, would it affect the users intended functionallity? Yes, the user might still want read-receipts while keeping the device in incognito or the client doesn't support. For the former thr user could choose to manually allow for a fixed time period when strictly needed so the functionality is still as intended, but including the latter there's a conondrum.
  • There is also the presence metadata, but I don't think it includes the client information for similar security concerns as this.
  • How detremental is it for the user, and does it force the user to opt-in? Pretty much so.
  • The downside of resorting to time-based polling is still the potential race condition and resource cost.
• Case 2: multi-bridged users only a few willing.
  • The implementation could be setup that as long as there's one willing client it starts polling by activity, but thats would still affect the other users intended experience, not to mention case 1.
  • If there is a solution to case 1 it might be adapted here, but it is a more extreme usage to case 1.
  • It is slightly saved that you are using read-receipts between matrix users to also trigger, but it's still not enough.
  • The downside of a timer-based polling is less prominent because it is distributed across matrix users, so it could just as well switch for these rooms

Overall I agree, and I can't find a solution to this. If we have another application maybe it would change the discussion. Hopefully there's more feedback to get a clearer picture, but I'm swaying towards closure after this revelation.