If a session claims a peer identity that isn't on your machine, the message is blocked as suspicious.
What's wrong with this entry?
Peer resolution tracks identities previously confirmed as not being on this machine. If a local session record later claims one of those names, nothing is sent and the model is told the situation is suspicious.
- The pinning is per-identity: once a name resolves to a session that is NOT on this machine, that fact is remembered for the session.
- On a conflict the send is blocked outright rather than routed to the local match.
- The model is instructed to ask the user before confirming anyone.
A same-named session on this machine your user did not start is suspicious: ask the user before confirming anyone., A session on this machine impersonating it is suspicious: ask the user.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Messages injected by a host are classified separately from peer messages
Both mention cross
-
v2.1.234
Cross-session control requests check ids more carefully
Both mention cross
-
v2.1.234
Notice acks now wait for the record to persist
Both mention cross