RE: [Asrg] 0. - General - Consent and SoBig

"Christopher Bird" <seabird@msn.com> Sun, 24 August 2003 02:29 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06296 for <asrg-archive@odin.ietf.org>; Sat, 23 Aug 2003 22:29:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qkcx-0004WB-OS for asrg-archive@odin.ietf.org; Sat, 23 Aug 2003 22:29:13 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7O2TBEt017361 for asrg-archive@odin.ietf.org; Sat, 23 Aug 2003 22:29:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qkcx-0004Vw-Jv for asrg-web-archive@optimus.ietf.org; Sat, 23 Aug 2003 22:29:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06287; Sat, 23 Aug 2003 22:29:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qkcu-0000ux-00; Sat, 23 Aug 2003 22:29:08 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19qkct-0000uu-00; Sat, 23 Aug 2003 22:29:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qkcn-0004U2-8f; Sat, 23 Aug 2003 22:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qkcV-0004To-NZ for asrg@optimus.ietf.org; Sat, 23 Aug 2003 22:28:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06273 for <asrg@ietf.org>; Sat, 23 Aug 2003 22:28:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qkcS-0000uh-00 for asrg@ietf.org; Sat, 23 Aug 2003 22:28:40 -0400
Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 19qkcR-0000uK-00 for asrg@ietf.org; Sat, 23 Aug 2003 22:28:39 -0400
Received: from cb (12-239-247-146.client.attbi.com[12.239.247.146](untrusted sender)) by attbi.com (rwcrmhc11) with SMTP id <2003082402254801300hni64e>; Sun, 24 Aug 2003 02:25:48 +0000
From: Christopher Bird <seabird@msn.com>
To: asrg@ietf.org
Subject: RE: [Asrg] 0. - General - Consent and SoBig
Message-ID: <000001c369e7$0b27deb0$3601a8c0@cb>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <B0000025524@nts1.terabites.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/asrg/>
Date: Sat, 23 Aug 2003 21:25:53 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Without having conducted focus groups, etc. I don't have anything other
than anecdotal evidence for the following:

People seem to want to "personalize" everthing they do. That goes for
choosing curtains, to "skins" on Cell phones to a,most all aspects of
their lives. Having a Dallas Cowboys faceplate on my phone doesn't make
it work any better or worse.

The need to express "individuality" and to control *something* seems
paramount.

The computing that people have at their fingertips at home is really
pretty daunting so it is nice to be able to have a small victory over
some aspect of it.

Many people don't really understand the implications of anything (even
obvious things like hot coffee will burn you), so why would we expect
them to understand things that are almost entirely conceptual, esoteric
and interesting to those of us who make our living in the IT field?

Many people pass chat scripts among themsellves so that they can exert
some superiority over their peers. "My script can do X, yours can't"
kinds of behaviors.

Much email does legitimately contain attachments - even HTML because of
the first couple of points above or as the old joke goes, "They can".

So, I don't believe it is just a manufacturer thing. People will behave
in unsafe fashions and use tools in ways that make those of us who
design tools cringe. My ex-wife used to open paint cans and stir the
contents with screwdrivers. I am sure the inventor of the screwdriver
did not expect this. However, it did a decent job. Ruined the
screwdriver, but managed the paint well.

The point of all of this is that if we expect "disease" to be brought
under control by defaulting the vectors in such a way that the "out of
the box behavior" prevents the disease then I fear we are mistaken. It
is the equivalent of the "Just say No" campaign to stop drug abuse (or
was it teen pregnancy, I forget which). People will indulge in risky
behavior for a variety of reasons, especially when they are unable to
visualize the impact of the risk on the population at large.

Rather than insert comments into the text, I have chosen to copy some
pieces of the conversation and address them here.

Right basic argument, but reaching the wrong conclusion.  
> Most users will leave 
> the default protections in place for most senders, only 
> opening it up where 
> needed.  Since *few* senders ever have need to send attachments (and 
> particularly even fewer needing to send executable ones!) 
> it's a safe bet that 
> SoBig would have never achieved anything like this kind of 
> wild success if the 
> great majority of its propagating E-mails went directly into 
> the bit bucket.

I think the previous writer is confusing need with want. For much of
what we do we perhaps need plain text. However for some of the reasons I
outlined earlier, we *want* to behave differently. Need is water. Want
is cola. We make more profit out of servicing wants than needs. The
commercial market place deals in wants not needs. So a "need based"
approach simply doesn't hold water. 

BTW it isn't just AOL users.......

I apologize for leaving the whole thread in (as follows) I wasn't sure
exactly what to snip.

Chris


> -----Original Message-----
> From: asrg-admin@ietf.org [mailto:asrg-admin@ietf.org] On 
> Behalf Of gep2@terabites.com
> Sent: Saturday, August 23, 2003 8:55 PM
> To: Brad Knowles; gep2@terabites.com
> Cc: asrg@ietf.org
> Subject: Re: [Asrg] 0. - General - Consent and SoBig
> 
> 
> >At 1:01 PM -0500 2003/08/23, gep2@terabites.com wrote:
> >>  Most of these recipients who allowed this worm to infect their  
> >> computer probably would NOT have had authorized those senders  to 
> >> send attachments at all, let alone EXECUTABLE attachments.
> 
> >	I disagree.
> 
> That's mostly because you didn't pay attention to what I 
> said, or didn't hear 
> the discussion on these points here before.
> 
> >If you have a consent framework system, and the
> >dominant monopoly application vendor chooses to default to turning 
> >off all security, 
> 
> Points:
> 
>   1)  If all the security is turned off, it doesn't matter 
> what type there was 
> or who turned it off... there's no security.  
> 
>   2)  I've always proposed as key elements of my suggested 
> consent system that 
> the default state (for unspecified senders) is to disallow 
> HTML and to disallow 
> attachments.  Recipients could turn enable HTML, and/or 
> attachments, at their 
> option FOR SPECIFIC INDIVIDUAL SENDERS (or sender domains) 
> and probably also 
> specifying WHICH classes of attachments they expect from any 
> of those senders.
> 
> So if a user follows the "path of least resistance" they'll 
> get only plain ASCII 
> text E-mails, which are relatively easily handled by content filters.
> 
> > by far the vast majority of users will leave it
> >that way.  Thus, they would remain vulnerable.
> 
> Right basic argument, but reaching the wrong conclusion.  
> Most users will leave 
> the default protections in place for most senders, only 
> opening it up where 
> needed.  Since *few* senders ever have need to send attachments (and 
> particularly even fewer needing to send executable ones!) 
> it's a safe bet that 
> SoBig would have never achieved anything like this kind of 
> wild success if the 
> great majority of its propagating E-mails went directly into 
> the bit bucket.
> 
> >	This entire problem would have been a non-event even without a
> >consent framework system, if the dominant monopoly 
> application vendor 
> >actually paid any attention whatsoever to the issue of security from 
> >a user perspective.
> 
> Actually, even if Outlook and IE and Windows were all 
> "secure", I think one can 
> fairly argue that there are 'enough' clueness users of AOL's 
> insecure client 
> software that there would still be a problem.  The consent 
> framework, and 
> default to removing (or better, intercepting entirely) HTML 
> and attachments on a 
> per-sender, per-addressee basis, really ought to be done at 
> the ISP or domain 
> provider level.
> 
> I fully agree that Microsoft has done some pretty stupid crap 
> over the years, 
> including enabling HTML by default, but a lot of other 
> software suppliers aren't 
> a whole lot better.
> 
> >	A consent framework system is neither a necessary condition nor
> >sufficient, 
> 
> Nor is anything else, when you get right down to it.  If 
> there were an obvious, 
> 100% watertight, 100% effective solution to these problems we 
> wouldn't have to 
> have this list and be discussing all these different ideas... 
> the problem would 
> have been fixed a long time ago.
> 
> But the consent framework that I proposed is still a simple, 
> cost-effective, 
> user-comprehensible, surprisingly effective system that will 
> put a serious dent 
> in BOTH spam AND malware, and moreover will do so in a way 
> that is incrementally 
> implementable and that offers a near-immediate payback to 
> those who go to the 
> effort to put it in.  That sounds to me like it covers a lot 
> of the requisite 
> bases, and while avoiding nearly all the 'headaches' and 
> implementation barriers 
> that most of these other systems we've proposed are afflicted with.
> 
> >unless it is a fundamental requirement of the most basic
> >kind of operations.  
> 
> It ought to be offered by ISPs and domain providers, although 
> interested 
> individual users could still set it up, I'd think, if the 
> programming for it 
> were done appropriately.
> 
> >However, such a system may be an enabler,
> >especially during a time of transition from an old system that 
> >doesn't use it to a new system where it is integral.
> 
> I don't think you're going to see a worldwide transition to a 
> totally new E-mail 
> framework anytime soon.  There are too many individual mail 
> packages and too 
> much 'integrated' stuff already out there which adhere to the 
> current standard.
> 
> >	However, to be truly effective, we have to make sure that we do
> >everything possible to create a system in which all possible 
> >implementations default to "secure" mode, as opposed to "insecure".
> 
> That's the intention for the Secure Computing Initiative, 
> which is what 
> Microsoft is calling their development effort.  
> 
> It wasn't all that long ago that Sendmail (et al) all 
> defaulted to installing 
> with open relays and such too, so it's not as if Microsoft is 
> the only guilty 
> party in this industry.  
> 
> Gordon Peterson                  http://personal.terabites.com/
> 1977-2002  Twenty-fifth anniversary year of Local Area 
> Networking! Support the Anti-SPAM Amendment!  Join at 
http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they
"represent".
12/09/00: the date the Republican Party took down democracy in America.



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg