5 ms·

How far back should you be able to amend history? What if a malicious client adds messages to a conversation that happened in the past? Imagine for example I'm

by shawnz 2y ago

How far back should you be able to amend history? What if a malicious client adds messages to a conversation that happened in the past? Imagine for example I'm at work and notice a critical mistake that I missed, and so I retroactively add messages to the old conversation to make it look like I'm not liable, should that be permitted by the protocol?

glandium 2y ago
Matrix allow to edit weeks old messages, already.
- shawnz 2y ago
  But there's a flag which indicates they've been edited and you can see the edit history, right? So that's not useful for this scenario.
thomastay 2y ago
Obv it depends, but one way to "solve" this it is to show an edit history, or at least the latest edit timestamp along with some visual indicator that the message was edited recently
- shawnz 2y ago
  I'm not talking about edits, I'm talking about sending new messages which are backdated to appear as part of an older conversation
  - thomastay 2y ago
    icic, yeah that definitely shouldn't be allowed
deleted 2y ago
[deleted]
fastball 2y ago
You can amend displayed order for humans (what matters for 99% of usage), while still allowing anyone interested to see when the message actually arrived at the homeserver (making the suggested gambit impractical).
- shawnz 2y ago
  Then instead imagine this: the user really is innocent and just happened to coincidentally send the message right after the start of a long period of poor connectivity (like a flight, or a road trip, etc). If you just allow it to go through after an arbitrary delay, with only a log of the received time for liability purposes, then the user wouldn't have any indication of this scenario occurring. Wouldn't it be better in that case to show an error so that they can make sure the situation is addressed appropriately?
  - Spivak 2y ago
    You have when the client claims it was sent (so where it goes in the displayed history) and can see when it was received. What else could you possibly do?
    - shawnz 2y ago
      For example, you could reject the message and show the user an error but only if there's a discrepancy of >X minutes. But how much discrepancy should be allowed? I don't know, I only mean to show why I think the solution isn't as simple as it appears
      - lmm 2y ago
        > you could reject the message and show the user an error but only if there's a discrepancy of >X minutes No you can't, not in a federated and decentralised system like this. The sender can wait for a read receipt from a given receiver user, if the receiver is willing to make those public. But if the message left client A and didn't arrive at client B, there's no objective fact of the matter about whether the message "was sent" or not.
dataflow 2y ago
> How far back should you be able to amend history? What if a malicious client adds messages to a conversation that happened in the past? Imagine for example I'm at work and notice a critical mistake that I missed, and so I retroactively add messages to the old conversation to make it look like I'm not liable, should that be permitted by the protocol? I believe that's impossible? At least if you design it correctly. For ordering/interleaving purposes, what matters isn't the time you claim to send the message, it's the time the message is received by the server. If you want, you can display the claimed send timestamp beside the message (and prominently highlight it if it is e.g. out of order, or with a long delay, etc.), but that is irrelevant to the ordering. The point here is that there should be a single consistent order on the server, and that's what all clients ought be displaying. Any messages not yet acknowledged by the server should be displayed differently so that users are aware they haven't been seen yet, and any messages that arrive before those are sent would obviously get inserted above those.
- lmm 2y ago
  > what matters isn't the time you claim to send the message, it's the time the message is received by the server There's no "the" server here. If you use the time the message is received by the server, you'll get different views on different servers, and you may see messages from months ago appearing as new, if connectivity breaks down and is later restored.
  - dataflow 2y ago
    > There's no "the" server here. Can't you assign every conversation to a single authoritative server for handling? Also, how large of a time skew are you imagining would exist between different servers? That stuff ought to be accurate to at least milliseconds if not micro...
    - lmm 2y ago
      > Can't you assign every conversation to a single authoritative server for handling? The whole point of Matrix is to be decentralised. In particular people should be able to keep talking when on different sides of a netsplit, by design. > Also, how large of a time skew are you imagining would exist between different servers? That stuff ought to be accurate to at least milliseconds if not micro... The question isn't how much time skew there can be between server A and server B, it's how long they can be cut off from each other over the network, which could be hours at least. (And even when things are working well, a normal ping is a few hundred ms, which is enough to change the order of messages)
kelnos 2y ago
This shouldn't be an issue for systems where a server mediates communication: the server should be timestamping messages, not the clients. This could indeed be a potential problem for a decentralized system, or one where the server for some reason cannot (or cannot be trusted to) timestamp messages. In that case, I think the best behavior for a client would be to always display messages in the order they've arrived, regardless of any timestamp provided by the sender. But this problem shouldn't exist for a system like Matrix. Matrix is (somewhat) decentralized, but each homeserver can still decide on the message ordering it will present to its own clients.
- shawnz 2y ago
  If you don't allow the client to specify the time they sent the messages, then anyone who has a poor connection is going to be subject to an annoying behaviour where their messages are constantly going out of the intended order during busy conversations.
kiitos 2y ago
> How far back should you be able to amend history? If user U1 sends a message M1 at time T1, then U1 must be able to modify/delete that message M1, in some reasonable sense, at any conceivable time from T1 forwards. Any protocol that doesn't support some reasonable form of message modification/deletion in this sense, is a toy protocol, and will never be widely adopted.
- shawnz 2y ago
  I'm not talking about message editing but rather posting new messages with a backdated time.
  - kiitos 2y ago
    I suppose every message has a few timestamps, including - The timestamp that the user specified as part of the message - The timestamp of the server that the user submitted the message to, directly - The timestamp of the server that first received that message - Any additional timestamp(s) of additional server(s) that received that message The user can I guess backdate a time, but that would apply only to the first thing, and none of the others?
    - shawnz 2y ago
      The first one is the only one that can accurately describe where the user intended for the message to land in the conversation. All the others are subject to network delays, so if you order messages by anything other than the first one, you are going to get a bad experience if you try to participate in a busy conversation with a poor connection.
      - kiitos 2y ago
        The first one is entirely un-trustable, because the user-submitted timestamp can be at any arbitrary point in time, from t=0 to t=infinity. So the receiving system can use that timestamp as an important bit of signal, but it can't really treat it as strictly authoritative, at least not if it expects to maintain a coherent set of events overall.

by shawnz 2y ago

glandium 2y ago

Matrix allow to edit weeks old messages, already.

shawnz 2y ago
But there's a flag which indicates they've been edited and you can see the edit history, right? So that's not useful for this scenario.

thomastay 2y ago

Obv it depends, but one way to "solve" this it is to show an edit history, or at least the latest edit timestamp along with some visual indicator that the message was edited recently

shawnz 2y ago
I'm not talking about edits, I'm talking about sending new messages which are backdated to appear as part of an older conversation
- thomastay 2y ago
  icic, yeah that definitely shouldn't be allowed

deleted 2y ago

[deleted]

fastball 2y ago

You can amend displayed order for humans (what matters for 99% of usage), while still allowing anyone interested to see when the message actually arrived at the homeserver (making the suggested gambit impractical).

shawnz 2y ago
Then instead imagine this: the user really is innocent and just happened to coincidentally send the message right after the start of a long period of poor connectivity (like a flight, or a road trip, etc). If you just allow it to go through after an arbitrary delay, with only a log of the received time for liability purposes, then the user wouldn't have any indication of this scenario occurring. Wouldn't it be better in that case to show an error so that they can make sure the situation is addressed appropriately?
- Spivak 2y ago
  You have when the client claims it was sent (so where it goes in the displayed history) and can see when it was received. What else could you possibly do?
  - shawnz 2y ago
    For example, you could reject the message and show the user an error but only if there's a discrepancy of >X minutes. But how much discrepancy should be allowed? I don't know, I only mean to show why I think the solution isn't as simple as it appears
    - lmm 2y ago
      > you could reject the message and show the user an error but only if there's a discrepancy of >X minutes No you can't, not in a federated and decentralised system like this. The sender can wait for a read receipt from a given receiver user, if the receiver is willing to make those public. But if the message left client A and didn't arrive at client B, there's no objective fact of the matter about whether the message "was sent" or not.

dataflow 2y ago

> How far back should you be able to amend history? What if a malicious client adds messages to a conversation that happened in the past? Imagine for example I'm at work and notice a critical mistake that I missed, and so I retroactively add messages to the old conversation to make it look like I'm not liable, should that be permitted by the protocol? I believe that's impossible? At least if you design it correctly. For ordering/interleaving purposes, what matters isn't the time you claim to send the message, it's the time the message is received by the server. If you want, you can display the claimed send timestamp beside the message (and prominently highlight it if it is e.g. out of order, or with a long delay, etc.), but that is irrelevant to the ordering. The point here is that there should be a single consistent order on the server, and that's what all clients ought be displaying. Any messages not yet acknowledged by the server should be displayed differently so that users are aware they haven't been seen yet, and any messages that arrive before those are sent would obviously get inserted above those.

lmm 2y ago
> what matters isn't the time you claim to send the message, it's the time the message is received by the server There's no "the" server here. If you use the time the message is received by the server, you'll get different views on different servers, and you may see messages from months ago appearing as new, if connectivity breaks down and is later restored.
- dataflow 2y ago
  > There's no "the" server here. Can't you assign every conversation to a single authoritative server for handling? Also, how large of a time skew are you imagining would exist between different servers? That stuff ought to be accurate to at least milliseconds if not micro...
  - lmm 2y ago
    > Can't you assign every conversation to a single authoritative server for handling? The whole point of Matrix is to be decentralised. In particular people should be able to keep talking when on different sides of a netsplit, by design. > Also, how large of a time skew are you imagining would exist between different servers? That stuff ought to be accurate to at least milliseconds if not micro... The question isn't how much time skew there can be between server A and server B, it's how long they can be cut off from each other over the network, which could be hours at least. (And even when things are working well, a normal ping is a few hundred ms, which is enough to change the order of messages)

kelnos 2y ago

This shouldn't be an issue for systems where a server mediates communication: the server should be timestamping messages, not the clients. This could indeed be a potential problem for a decentralized system, or one where the server for some reason cannot (or cannot be trusted to) timestamp messages. In that case, I think the best behavior for a client would be to always display messages in the order they've arrived, regardless of any timestamp provided by the sender. But this problem shouldn't exist for a system like Matrix. Matrix is (somewhat) decentralized, but each homeserver can still decide on the message ordering it will present to its own clients.

shawnz 2y ago
If you don't allow the client to specify the time they sent the messages, then anyone who has a poor connection is going to be subject to an annoying behaviour where their messages are constantly going out of the intended order during busy conversations.

kiitos 2y ago

> How far back should you be able to amend history? If user U1 sends a message M1 at time T1, then U1 must be able to modify/delete that message M1, in some reasonable sense, at any conceivable time from T1 forwards. Any protocol that doesn't support some reasonable form of message modification/deletion in this sense, is a toy protocol, and will never be widely adopted.

shawnz 2y ago
I'm not talking about message editing but rather posting new messages with a backdated time.
- kiitos 2y ago
  I suppose every message has a few timestamps, including - The timestamp that the user specified as part of the message - The timestamp of the server that the user submitted the message to, directly - The timestamp of the server that first received that message - Any additional timestamp(s) of additional server(s) that received that message The user can I guess backdate a time, but that would apply only to the first thing, and none of the others?
  - shawnz 2y ago
    The first one is the only one that can accurately describe where the user intended for the message to land in the conversation. All the others are subject to network delays, so if you order messages by anything other than the first one, you are going to get a bad experience if you try to participate in a busy conversation with a poor connection.
    - kiitos 2y ago
      The first one is entirely un-trustable, because the user-submitted timestamp can be at any arbitrary point in time, from t=0 to t=infinity. So the receiving system can use that timestamp as an important bit of signal, but it can't really treat it as strictly authoritative, at least not if it expects to maintain a coherent set of events overall.