Subject: contest: win valuable Microsoft stock!

From: "James P. Salsman" <[email-masked]>
Date: Sun, 7 May 2000 21:39:36 -0700 (PDT)

Keith Moore wrote:

>...  I do think there is some culpability on the part of the
> software vendor.  and from a purely pragmatic perspective, it's a
> lot easier for the vendor to make software that is less susceptible
> to such things, than it is to get rid of the virus writers.
>
> and if the folks who sell such software would just fix this, we
> wouldn't need to care so much about culpability.  but I'm not
> holding my breath waiting for this to happen.

I fully agree and have decided to sponsor a contest to correct
the situation.  I will give one share of Microsoft stock to the
first person who posts, to this IETF Discussion list, a draft
shareholder resolution that would, in the opinion of Keith Moore
or his designated alternate, correct the situation if it were
adopted by Microsoft Corporation as we currently know it.

Moreover, as a fellow shareholder, I will second the resolution 
in communication with Microsoft's corporate secretariat.  
Furthermore, I'll pay Keith or his designate $10 to judge the entries.
I am doing this because I've been unable to communicate successfully 
with Microsoft as a customer, shareholder, and erstwhile employee.  
This will at least give me a fresh perspective, and with luck might 
get something done.  If it doesn't, we have legal recourse with the 
antitrust remedy proceedings.

Here's your chance to hone your shareholder proposal-writing skills!  
Be the first to post a resolution that passes muster with Keith 
and win a valuable share of Microsoft stock!

Cheers,
James

-- 
IMS Q&TI Editor project description: http://www.bovik.org/imsqtied.html
Open-source development:  http://sourceforge.net/project/?group_id=3308

---

From: Garreth Jeremiah <[email-masked]>
Date: Mon, 8 May 2000 06:38:06 -0400

> > holding my breath waiting for this to happen.

I think the issue is one of bounds.  What is off bounds and what is ok for an
internet client, such as an email reader, to have access to on any system.  If
the requirements of these bounds could be clearly defined in temrs of what is
allowed, then by default dissalow access to everything else.  Do not make this
a configurable option.  We have to remember that he who giveth CANNOT taketh
away, so we must ensure that the flexability of scripting languages remains (
although I'd love to shut down their access ) as some people are now reliant on
certain functionality.  

The "Java" sandbox idea in my mind is a great one.  When code is run from an
internet client,  constant bounds checking must occur.  Whenever the code steps
over the mark we either stop it in it's tracks, clean up and offer to send a
potential virus alert, or we thow some alarm hoping that the user is actually
able to read and understand the potential dangers.

The core issue is certainly not a new one, however it is wearing a different
hat.  Attempting to get programming teams to impliment security, such as bounds
checking, input validation ( not just "is it a number etc. ) and various other
forms of development/coding technices is nothing new.  It is here however that
we must focus our attentions.  It is the fault directly, of the designers of
the software.  It is these designers that think almost solely about the
functionality of the code rather than necessary robustness and security.  Once
the designers have been - re-aligned - it is the turn of the programmers.  To
educatie them in the kinds of attacks people are perpetrating through their
code and how they should be writing code to avoid this.  For both parties, the
process of peer revies is important.  This peer revieew is where I have
personally found a good deal of discovery occurs.  Certain nuances taat one
persone may overlook another may not.

In summary.  Re-education for designers and programmers.  Peer review.  Require
solid definitions for what an internet client can do.  On execution of internet
based code, bounds checking must occur constantly.  Bounds execption actions
must be agreed, defined and predictable.

Garreth J Jeremiah,
"If the light is on, but no one is home.......we simply left the light on"
"The light at the end of the tunnel could be a train"