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.