On suing Marcy Hamilton for being a bimbo

[Thomas Shaddack]

On Sat, 4 Oct 2003, Major Variola (ret) wrote:

> So don't use their tools.

You don't know how much I'd love to. However, I have to live in the Real
World, and I have to interact with other people, which involves receiving
data from them. (If I could just ignore them, I'd do so and won't get
angry about the issue.)

I also have to share the Net with them, which - even if I do the best -
gets annoying when the network throughput goes down and the mailbox
overflows with the 'New Net Security Pack' or another Worm of the Week.
This is something I can't exactly choose to avoid, except by leaving the
Net, which is an unacceptable tradeoff. Sorry.

> Don't abuse the law against the maker of a tool which can be used
> improperly.

Which is designed to be used improperly by default.

> It is simply wrong to blame a gun or drill or code maker because some
> evildoer (virus propogator) used the tool against you.

Is it also wrong to blame a door maker when the lock that was marketed as
safe can be opened with a creditcard (which is then touted as convenience)?

> Let me guess: the State gets to decide how many bugs per line of code?

I don't have the answer here. I usually don't have accurate answers to
policy things.

> >intentionally wrong key architectural decisions,
>
> You mean decisions that don't fit *your* fancy. See below for others'
> possible motivations.

You know what's the worst? That it can be both convenient and reasonably
safe. See below for some examples.

> and keeping everything
> >and the kitchen sink on by default,
>
> Again, the maker's choice; your choice to purchase.

Not when I become collateral damage.

>> including services that next to nobody (except worms) needs - if the
>> users need it, they should be able to click on "Enable" on their own.
>
> You don't understand the convenience vs. security tradeoff too well.
> Or the importance of convenience to sales.

You don't have to always sacrifice a lot of convenience to get a
significant security gain. Why should the 135-139+445 (and others) ports
be exposed to everyone by default? To let the users easily share things
over their LANs?  The LANs have well-known IP ranges assigned. Why the
open-by-default ports shouldn't be open only for these ranges, and reject
connections from elsewhere, unless specified otherwise? Three or four A
and B class matches on accept() call won't hurt even a 386, in the most
optimal case it's a handful of assembler instructions - one byte
comparison for 10.*.*.*, one word for 192.168.*.*, one AND and then word
for the third one, and if we want to use the 169.254.*.* range, then
another word comparison. Plus one condition for disabling the safety
checks, set to false by default. This one simple measure could prevent a
whole class of attacks (*cough*Blaster*cough*), or at least greatly
mitigate their impact. Similar for rendering HTML in mails; I never saw a
SINGLE mail with javascript inside that won't be spam (where it's for
annoying but otherwise harmless effects) or worm (where it's actually
malicious and used for spreading), a boolean for call for scripting engine
to return without any action shouldn't be problematic.

>> Not even mentioning the tendency of the patches (and following patches
>> to patches) to break something else.
>
> And this doesn't happen with other OSes?  Please.

That happens everywhere. But only one major vendor so far managed to get
it from something exceptional to something expectational.

> And every version of *nix has always shipped with everything off,
> maximally locked down?  Right.

OpenBSD. (Though on the other hand there are opinions that its security is
based mainly on the difficulty of getting anything to work on it.)

Of course that everything is more or less vulnerable. But not everything
is a gaping security hole.

>> Can't remember when an upgrade of OpenSSH or OpenSSL or any other
>> contemporary bug breeder of the MS-alternative bombed any of my
>> systems.
>
> [Tech: Since when have MS SSL bugs had *anything* to do with worms and
> virii?

I use them as examples of notoriously buggy subsystems. Windows have MSIE
and IIS and some others.

> And does MS even support SSH? ]

Not. Another of my pet peeves, but not *that* critical, and there are
various third-party implementations, eg. Cygwin port of OpenSSH. Not
exactly stellar (or I didn't manage to configure something correctly), but
passable.

> There have been plenty of security and overflow bugs in Open* security
> apps.

Which is why I mentioned them. It makes no sense to talk about handling of
patches without using something that actually needs them as an example.

>> Or when I had to reboot instead of just restarting the updated service.
>
> Yawn.

I see you are familiar with "boot wait". Yes, it's boring.

>> If for nothing other than for running scripts in incoming mails by
>> default, MSFT deserves it. (Yes, I admit bias. Having to admin a couple
>> machines running their software should be enough to justify it.)
>
> Your bias is turning you into something dark.  I sort of expected
> this reaction, since I was defending MS's right to exist.
> But if MS is treated this way, so is Joe Coder.

I can ignore Joe Coder. I can't ignore MSFT. Joe Coder has no economical
power to ram his bugs down my throat, and the userbase of Joe's
Spreadexcrement Editor isn't wide enough to be likely that someone sends
me a table with critical data in its poorly documented .jst format AND
expect as a matter of course that I will be able to read it.

It takes some serious effort to get me so heavily biased.

> Caveat emptor.  Some folks buy cars with no airbags; others buy
> cars with a dozen.   Should everyone be forced to buy the safest
> car (as defined by the State, of course).

When I checked last, there were some baseline safety standards and crash
tests and stuff.

> If Marcy clicks on attachments, runs mail clients
> that run embedded scripts, basically spreads her legs and
> lets everyone in, how is this different from someone who
> rolls their SUV because they were clueless as to physics?

The analogy that would be more accurate is exploding tires. Marcy operates
the machine within vendor-suggested operational parameters (eg, defaults).

>> Though I am not sure if the personal-informations-disclosure venue is
>> the good one.
>
> Au contraire, I'm sure someone who asserts class-action status is
> interested in hearing from the public she is so kindly protecting.

Misunderstanding. I meant the law she's attempting to use as the base of
the lawsuit. Sorry for not being clearer. (I suppose her address is in the
court materials anyway; besides MSFT defenders are far less dangerous than
eg. $cientologists.)

> Its a real shame when (albeit deserved) MS-hostility/contempt biasses
> folks into immorality or irrationality.

Monopoly-like system reinforces itself and favors measures that would kill
their proponent if there would be several smaller players. (Eg,
nonstandard file format that no one else can read without problems should
make problems to its vendors instead to everyone else - once one of the
vendors has enough market share to be able to push their will on the
others and buy or ruin them if they are in the way, something is wrong.)

(There is a hope, though. Billy the Greed managed to be disliked by mostly
everyone. With some luck, a critical mass will be reached and the balance
tilted back, with the inevitable sound effects of MSFT management crying
"unfair". And the following drop of their share value, undermining
confidence in blue chips in general, drop of value of pension funds which
are quite significantly dependent on them, resulting social turmoil, and
general instability for next couple weeks/months/years. Billy himself
knows it has to come; it's likely not a coincidence he began diversifying
his personal portfolio.)

It's not *that* bad that they have bugs. What makes me see red is how easy
would be to mitigate the impact of a great number of them, and when I have
to suffer incompatiBILLities specifically designed to annoy me as a
non-user of the Holy and Only Correct Office Suite (even more accurately,
its Current Version).

An interesting and challenging problem (which I am not sure it has a
solution) is how to set up the market playing field to prevent such
situations by design, while being fair.

> Its like blaming the authors of the SMTP RFC for spam.

They at least knew it can happen; see RFC 706.