Eliot,
Thanks for the detailed comments. Inline...
In Security Considerations in Section 5, I think it’s probably useful to talk about the risk of spoofed messages creating spoofed reactions, perhaps a lot of them. What mitigation techniques should be employed? One might be to look for a valid Authentication-Results header.Security Considerations is an opportunity with infinite possibilities. If anyone wants to supply text to add and others like it, then it should be added...
Here’s what I would suggest:
An attacker may transmit one, several, or many messages that lack any form of authentication, indicating one or more reactions, thus causing the MUA to mislead the reader into believing a general sentiment to be something other than what it is, or that a specific reaction is other than what it is. The ultimate appropriate remediation is to authenticate the sender of a reaction against a trusted authority. Short of that, MUA designers are advised to consider only processing reactions that pass a heuristic test as to their likely authenticity.
There are three, considerable problems with your suggestion:
1. In reality, it applies to /any/ content. Reactions are just one example.
2. You've made the popular assumption and assertion that authentication reduces deception
3. You made the popular assumption that recipients will be influenced by signals of authentication.
There is essentially no empirical evidence that authentication and signals associated with it, have much effect on average recipients.
That seems like heresy, because it is so completely counter-intuitive, but consider the failure of the Web's extended certification program. And the absence of a body of research showing efficacy of signals.
I can send a message from bad-actor@xxxxxxxxxxx, and have it
fully authentication. I can then have the body of the message
purport to be from the President of the company the recipient
works at, and the recipient is likely to believe it.
There are a variety of cognitive and behavioral explanations that seem to account for this, but the bottom line is that authentication has nothing to do with recipient behavior. Authentication provides a clean channel for filtering engines to use, when evaluating incoming mail. Period.
...Finally, what happens if the same source sends two reactions in two separate emails? Can one send a blank message to remove a reaction?What happens if the source provides two reactions in the /same/ email? Is that different from this? Because both are supported.
Trivial technical answer in the scope of this specification: Both are entirely legal.
Difficult usability answer, outside the scope of this specification: It will be interesting to see how and whether UI implementers support either or both of these.
There are really two possibilities: reactions are additive, or reactions are replacements.
Here’s my suggestion:
Adding to the responses about this already sent...
(and in case any misses the irony of my phrasing, this should make
clear it was intentional.)
People send multiple replies all the time. What are the
semantics of that? Why should a series of reactions have
different semantics?
MUAs with threading deal with multiple replies. We have no
standards about that. (One colleague, who might even be reading
this, long-ago commented that they'd learned to wait after I sent
a reply, because I often sent a second one that had a substantial
elaboration.)
It's entirely possible that MUA developers will handle receipt of multiple reactions in a single reply, or a series of individual reactions, in different ways. It will be interesting to see.
It is NOT reasonable for this specification to give direction about user interface design. Nor, IMO, to constrain the semantics of reactions sent in series.
I think these suggestions follow the principle of least astonishment, but I readily admit I could be wrong. I recognize that this requires a reaction database to implement. Yeah, that’s a small pain. THAT to me may be the real experiment here.
Perhaps.
d/
-- Dave Crocker Brandenburg InternetWorking bbiw.net
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
