Re: [Last-Call] Last Call: <draft-crocker-inreply-react-06.txt> (React: Indicating Summary Reaction to a Message) to Experimental RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Mon, 2021-01-18 at 13:40 -0800, Ned Freed wrote:
> > As for the idea of using heuristics, the idea of having an open-ended
> > suggestion that implementors pick something, anything, for this
> > purpose is more than a little scary given past experience with the
> > things people use as spam tests. So absent something more specific I
> > don't think this is a good idea.  Although it is intriguing to think
> > about various checks and latching schemes and so on. But the siren
> > song of a hack in the making is kind of the problem, isn't it?

> I like the idea of reactions in e-mail, but any method of conveying
> information will be misused by pranksters and spammers, so I think it
> is useful to think about abuse.

Sure, but the basis of comparison always has to be against both existing email
systems which do not have a reaction facility as well as other messaging
systems that do. It's neither fair nor reasonable to look at this as a new
system operating outside of these contexts.

> point 1: there is no restriction on the number of emojis in your
> reaction.

> example:

>   🧚 🧚🏻 🧚🏼 🧚🏽 🧚🏾 🧚🏿 🧚‍♂️ 🧚🏻‍♂️ 🧚🏼‍♂️ 🧚🏽‍♂️ 🧚🏾‍♂️
> 🧚🏿‍♂️ 🧚‍♀️ 🧚🏻‍♀️ 🧚🏼‍♀️ 🧚🏽‍♀️ 🧚🏾‍♀️ 🧚🏿‍♀️ 🧚 🧚🏻 🧚🏼 🧚🏽
> 🧚🏾   🧚🏿 🧚‍♂️ 🧚🏻‍♂️ 🧚🏼‍♂️ 🧚🏽‍♂️ 🧚🏾‍♂️ 🧚🏿‍♂️ 🧚‍♀️ 🧚🏻‍♀️
> 🧚🏼‍♀️ 🧚🏽‍♀️ 🧚🏾‍♀️ 🧚🏿‍♀️

> obnoxious?  abusive?  it certainly would be a challenge to present this
> in a UI, I think.

Actually, the issues are reduced by having a well defined mechanism for
flagging reactions and linking them to the message being reacted to. As things
currently stand you can send such a message and nothing will prevent it from
simply being displayed as-is, with recipients them drawing their own, possible
incorrect, conclusions.

But if you know that it's a reaction the UA can check for this sort of thing
and handle it appropriately. I note that handling is unlikely to be to display
the message as-is, so tricks like this are unlikely to work all that well.

Of course it would be better if we were able to fully specify how all this
works down to the last detail. But we don't think we're up to the task, nor
do we think it's appropriate for us to try.

> would the functionality be hampered by specifying a
> limit on the number of emojis in a single Reaction?  or a limit on the
> number of (distinct) emojin from a single respondent?

What would a reasonable limit be? Slack allows each emoji to specified
exactly once. Medium, OTOH, has a limit of 50 repeats. I've seen BBSes
that impose no limits whatsoever.

> point 2: although the set of characters with the emoji property
> generally don't contain letters, there is bound to be creative spammers
> abusing those available.

> example:

> 🐴 🧲 ⭕ ❌ ‼️

> (the magnet looks like a C in the font I use.)

Once again the comparison needs to be against existing systems. Creative
spammers are more likely to acheive success by posting this sort of thing as a
regular message part, not a reaction. Any sort of  nontrivial reaction
processing is likely to mess this up.

I also question the need to worry all that much about traditional spammers in
these circumstances. Remember that for a reaction to be valid it has to link to
a previous valid message. So in order to do this you need access to a
valid previous message. In the case of interpersonal mail this means having
access to one of the mailvboxes or the mail system, in which case you
have much bigger things to worry about than spoofed reactions.

As for list mail, despite many dire predictions the willingness of spammers to
subscribe to lists in order to spam them haven't not been borne out. Reactions
seem unlikely to change this.

> point 3: since the spam message can be spread across more messages, the
> filtering is harder.  bear in mind the reactions can themselves be to
> the spammer's own message.

And once again you're talking about a problem with email in general that's
almost certainly made more difficult by calling out reactions and handling them
as such.

> point 4: should we disallow reactions coming from the author?

Existing practice for this is all over the map. Slack lets you react to your
own postings. Other systems don't. Others only let you react when you
haven't contributed to the thread, and wipe out your reactions if you
post a contribution.

More generally, you seem to be assuming the purpose of reactions is some sort
of voting. Sometimes a reaction is just a reaction, and it's entirely
reasonable to post a reaction to your own message as a form of emphasis.

					Ned

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux