Counseling not to use Windows (was Re: Anonymoussurfing my ass\!)

[full-disclosure () lists netsys com (Raju Mathur)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > > > > "Ron" == Ron DuFresne <dufresne () winternet com> writes:

    Ron> [snip]

    Ron> You hit on the duality of the issue<s> beofre trying to
    Ron> refine it into a plurality issue.  The *real* problem is
    Ron> vendors relasing bugy code with insecure defaults which
    Ron> *promotes* users remaining clueless.  take a look at the
    Ron> wireless issues spewing into the airwaves now, and look at
    Ron> not only the default installs of the products available for
    Ron> playing with wireless toys and trikets, but, take a serious
    Ron> look at the documentation and how much is devoted to the
    Ron> issue of securing the toys.
    Ron> [more snip]

I agree that vendors are responsible for security issues to quite an
extent.  As far as I can see, there are three real issues for security
from the vendor point of view:

1.  Insecure defaults.  Many vendors will sacrifice security in favour
of usability.  This, for some reason, seems to be even more true in
the Windows world than in Linux/*BSD/Unix, where vendors try to at
least make things usable but with as good an underlying security layer
as possible.  Redmond doesn't appear to give a d*mn about end-user
security, as long as the user has a `clean, comfortable, easy usage
experience'.  Definitely the vendor's responsibility.

2.  Insecure design and coding.  IMO open source/free software has an
edge here, since most of the developers don't have to work against
release deadlines, unlike the proprietary software vendors.  I don't
accuse MS (or anyone else) of deliberately making insecure software.
I do accuse them of bowing to marketing pressure and hence sacrificing
due diligence in making software secure.

Further, the free software model encourages reuse of components, and
my uneducated guess is that as time passes the more secure components
automatically float to the top of the heap whenever reuse becomes
necessary.

Of course, this conveniently ignores the remote exploit in AIM which
AOL itself exploited to remotely upgrade users' AIM's whenever they
(AOL) upgraded the protocol (i.e. whenever someone else managed to
reverse engineer the protocol and bring out a compatible III-party
client :-)

3.  Retrofitting security.  It's is completely impossible to envisage
two scenarios when designing and developing software:

- - How it is going to be used
- - How it is going to be attacked

I'm a software writer from time to time, and all I can do as a
developer is *try* to ensure that the software and protocols I develop
are secure, to the best of my vision and ability.  This problem is not
new: earlier it was said that it was impossible to make software
idiot-proof, since idiots are so smart; today I'd say that it is
impossible to make software and protocols crack-proof, since crackers
are too smart and varied.

Until it becomes possible to project in advance all possible scenarios
in which a software could be used we will never see a `secure' product
or environment.  Instances of security being retrofitted in this sort
of situation abound: AUTH and STARTTLS extensions to SMTP, the
uncountable patches from software and OS vendors, HTTPS extentions to
HTTP, encryption extensions to IPv4, etc.

The depressing conclusion I come to is that it will become
increasingly difficult to lock down applications, protocols and
operating systems; we will just have to learn to live in insecure
environments.

Regards,

- -- Raju
- -- 
Raju Mathur          raju () kandalaya org           http://kandalaya.org/
                     It is the mind that moves
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard <http://www.gnupg.org/>

iEYEARECAAYFAj0zfAQACgkQyWjQ78xo0X95+QCgl46cqfviPVDMoH55o96WDpWk
B1wAni0wxt/AMiiSI5Lva8HshIdc0QET
=Q7bh
-----END PGP SIGNATURE-----