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]

 



> In article <7f0531ae-9bee-8305-d919-38b6f0cf7640@xxxxxxxx> you write:
> >On 1/20/2021 2:49 PM, Kjetil Torgrim Homme wrote:
> >> On Wed, 2021-01-20 at 14:45 -0800, Dave Crocker wrote:
> >>>> "appropriately" is too vague, IMHO.  some guidance on how this
> >>>> should be presented is called for, I think.  otherwise this is no
> >>>> better than the "me too" or "*rofl*" messages we already had.
> >>>
> >>> Forgive me, but it is important that this specification NOT specify
> >>> or give substantial guidance about presentation choices.
> >>
> >> I don't mean very specific guidance, but some wording about whether the
> >> reactions should be aggregated or not?
> >
> >Even that level of guidance is, IMO, far too specific.  The simple
> >reason is that there is no empirical basis for it, and certainly not
> >enough to put it into a standard.

> I'm with Dave here. The IETF has a long history of guessing wrong
> about UX design.

I don't think this is quite fair or quite accurate. It's more like the IETF
ends up being, as the saying goes, "not even wrong".

What I mean by this is that all too often the UX concerns the IETF attempts to
address don't have much in common with the actual UX issues implementors end up
facing.

The concerns being expressed here about the things "spammers" will do that the
UX needs to guard against are a case in point. As you point out below, spammers
are interested in things that let them send lots of mail. A facility that lets
them tortuously create a false indication on a message by message basis don't
seem likely to be of much use, but in the unlikely event it is, it will be
through  a gap we don't currently see, and thus cannot advise against.

> > Efficacy is affected in fundamentally different ways.  Humans being
> > notably different than computers, and average humans being notably
> > different from engineers...

> > Having a section that raises concerns, rather than suggesting approaches
> > or solutions, seems entirely reasonable to me.

> I wouldn't put a lot of effort into it, since I don't see any reason
> to expect us to come up with useful concerns, either.

Exactly right.

I would suggest that the people who think such text would be helpful might 
want to try and craft something specific.

> >> it is well established that spammers will exploit just about any
> >> communication channel available to them.

> That's not true at all. They exploit channels that let them broadcast
> a lot of messages (counted at least in millions) at little or no cost.
> Even though it would be technically easy for spammers to subscribe to
> mailing lists and send spam, they don't because the return is too low.

And this is even harder: In order to spoof a reaction you need the
message-id of an original message, and that id along with avoiding
whatever other safeguards are in place only lets you fiddle with the
display attached to that one message.

Why bother?

				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