ietf-asrg
[Top] [All Lists]

Re: [Asrg] Summary/outline of why the junk button idea is pre-failed

2010-03-02 09:56:58
On Tue, Mar 02, 2010 at 08:40:33AM -0500, Daniel Feenberg wrote:
This message ignores the existence of TIS buttons on existing MUAs
for webmail operators, and the actual experience that those
operators have.

No, actually, it takes that into primary consideration.  It simply
extrapolates out to Internet scale by asking "what if everyone did this?"

Well, and then by extrapolating what we know of past spammer behavior
and current spammer capabilities.

Users are incompetent, that is why the existing systems use a single
hit on the TIS button only to affect mail to the user hitting the
button, and only affect mail to other users if a large number of
users hit the button.

A) it shouldn't even affect mail to that user and B) large numbers
of incompetent users -- which is what we have -- do not en masse
magically become competent.

Like I said, if the masses had even *minimal* competence, then
we would have a far smaller problem.  They're not.  We don't.

I can do spam at 1 second per message or less, and with the TIS
button I will get less spam, saving even that second.

You're not a typical user.  Not even close.  I can do that too,
and can even do so very reliably just by scanning Subject: lines.
(Especially since procmail pre-sorts all my incoming traffic.)
But this is *extremely* atypical.  Ordinary users can't do this,
and they're never going to be able to do this.  I think even
"5 seconds per" is extremely optimistic, based on a few
first-hand experiments and innumerable impromptu observations.

It is mere speculation that the existence of the button will cause
more clicks on malware - I don't see why it should [snip]

It's obvious on inspection, isn't it?  If you task users with classifying
spam-vs-not-spam, some of them will accept the task.  Then they'll try
to perform it.  Oops.

More generally that just this TIS-button discussion: every additional
second that a user spends with a spam up on their screen is an
additional risk.  We should be attempting to -- at every step --
*minimize* that time.

Please see Hanna Arendt "The Authoritarian Personality" for an
explanation of this claim. Really, if you reject all user influence
you will not have happy users.

A) I'm not trying to have happy users.  I'm trying to have to have
secure users (and systems and networks). 

B) At no point did I say that all user influence should be rejected.
What I said that is that user-initiated spam/abuse reports should be
reviewed by qualified personnel.  There's no technological substitute
for clueful eyeballs.  And to clarify/emphasize, those clueful eyeballs
should be local to the user, and should be reviewing everything before
it escapes the local operation.  (Doubly so given that in many operations
the abuse is coming from inside.)

I have never gotten a usefull spam complaint from a user, but it
isn't because the messages weren't spam. It was always because the
user didn't include the headers. All users find it difficult to
include headers with forwarded messages, and will always drop the
issue when asked to resend with headers. The TIS button solves this
problem.

A) I receive quite useful spam complaints from users because I find
that requiring them to clear the bar labeled "figure out how to send
the message with full headers" is an *extremely* good way to have
the modestly-clueful ones self-select.  Many, many years of this
practice have shown that there is a high correlation between the
accuracy of the reports provided and the user's ability to do this.

B) A far easier, less risky, more universally-useful solution to
the header problem is "strongly encourage MUA authors to provide
a very very simple and very very obvious method to display all headers".
This doesn't require the invention of anything, the standardization
of anything, the deployment of anything: in nearly all cases, it
just means "make pre-existing functionality much much more visible".
Yes, this undercuts (A) in part but it does still leave users with
the need to remember abuse(_at_)$MYDOMAIN and that has also proven itself
to be a reasonable vetting process for complaint accuracy.

Really, this is all supposition and there is no evidence that any
spammer cares. There are many claims that spammers must care, but no
examples of cases where they actually did care.

I suggest reading the archives of spam-l for example after example --
and those are just the ones publicly discussed and on just one list.

If even a small proportion of the TIS hits result in action, the
total traffic will decrease. If the proportion of hits resulting in
action is too small, then users will stop hitting the button and
there will be little traffic increase.

This is wrong: as I pointed out, abusers can generate an arbitrary
number of TIS hits.  Presuming that only (human) users will hit
the button is an error.

Has this happened on any of the services that currently offer TIS
buttons? How have they handled that?

You're missing the point.  It's probably not, as yet, worth the 
valuable time of attackers to do so.  That's because the TIS buttons
are isolated, they're not standardized, etc.  If I were an attacker,
I wouldn't trouble myself (much) to bother with them either.  But
if they were pervasive and standardized -- thus not only a far larger
target but one requiring much less programmatic effort to hit -- then
I probably would.

One of the repeated mistakes made in the anti-spam field over the
past twenty years -- and I'll admit to making it too -- is to presume
that just beause spammers aren't doing something today, that they can't
do it tomorrow.  Spammers have proven to us that once something starts
to catch on, they will invest the time to figure out if they can turn
it to their advantage.

As long as there are zombies, no anti-spam or indeed and security
related protocol is hopeless.

This is half-wrong and half-right.

A)  There are quite effective measures which can be used, and some of
them *are* being used: in particular (a) blacklisting (b) firewalling
(c) null-routing and (d) BOGUS'ing.  Used properly -- which is of
course the trick -- these are high-accuracy, low-cost, difficult-to-game,
difficult-to-repurpose-as-weapon tactics that provide excellent protection
not just against spam (directly) but against second-order attacks that are
auxiliary to spam.

B) While the zombie problem persists, nothing that comes from an
end-user system can really be trusted -- which is why it should never
be an input to any kind to an anti-spam or anti-abuse or security mechanism
UNLESS it is carefully reviewed by a human being before it goes anywhere.
We already have a massive abuse problem as a result of exactly that issue:
SMTP spam from zombies is just one component of it.  I think it's crazy
to believe for even a moment that the same abusers who've spent years
aquiring those zombies, organizing them into botnets, refining the code
that runs on them and makes more of them, will just sit on their hands
and do nothing if they're given this new capability.  Of COURSE they'll
use it.  And my guess is that -- given the ingenuity they've shown over
the past decade -- they'll use it for something even worse than the
things I can think up, and I can think up some fairly nasty stuff.

---Rsk
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg