The buck stops with the label on the cover... any problems are between YOU and the CUSTOMER.
Absolutely agree. So the remaining question is: aside from the ill-advised potshot, has Apple done right or wrong by those customers? Have they (a) disavowed all responsibility, told customers it's their problem, told them to go talk to the "podunk assembly plant in Hunan Province" if they need help, or (b) done everything they can to mitigate and prevent future recurrences of the problem?
Apple shouldn't have seemed to blame Microsoft, it's true. That's gotten the Windows partisans all riled up, although if you read what Apple wrote, they didn't explicitly blame Microsoft, just expressed annoyance -- and they expressed more annoyance with themselves for not noticing.
And everybody's blaming them for not noticing. But if you think about it, it was a pretty absurd thing for them to have had to "notice". As I understand it, the virus was implanted by one infected machine among a number of machines at a Chinese manufacturing shop they'd contracted iPod manufacture to. Apple said, "here's a thing that looks like an external disk: please put these bits on it for us". A simple and straightforward enough task, one would think -- but in a world where autorun exists and is or has been enabled by default, perhaps not so straightforward.
It's as if I had a letter to mail to 1000 of my customers, and I took one original down to my friendly print shop and asked them to make 1000 copies, and I or the print shop used an automated machine to fold the 1000 copies and stuff them in envelopes and mail them, and only after they were mailed out and opened by my customers did we start discovering that for some strange reason 1% of them had "FUCK YOU, ASSHOLE" overprinted on page 2. And then found out that the "strange reason" was that one of the copy machines at the print shop, among the several that the print shop divided my job among, was "infected" by a "virus".
If that happened to me, I'd be annoyed, too. (It'd be even more annoying if I were accused of ignorance for not having protected myself against this "obvious" threat, that evidently everybody else knows about and makes allowances for.) And I know my response would not be to ask the print shop to be more careful next time, or to run an "antivirus" soluton, or something. I'd take my business elsewhere, and more importantly insist that my future printing contractors use a different brand of copier, one that's not susceptible to preposterous failure modes like that, because even if there is some alleged way of papering over that particular flaw, who knows how many other equivalently egregious bizarre flaws it's got that haven't been discovered and papered over yet?
the behaviour of goofy users is neither Bill's, nor Steve's nor Linus's fault and there is not much they can do about it.
This is not merely false, it's dangerously false.
If users are predictably goofy -- as they are -- and if they cannot be trained otherwise (as about a decade of experience has amply taught us), then what you need to do is engineer the system to accomodate its fallible components, i.e., the fallible users.
People used to get maimed and killed a lot more in car crashes than they do now. The main reason for the change is not improved driver training, but rather, the fact that cars now have seat belts, air bags, crumple zones, and a host of other features explicitly targeted at making them safer in spite of the fact that drivers keep doing goofy things like crashing into trees and each other.
We didn't say, "crashes are inevitable" or "stupid drivers shouldn't crash so much". We fixed the problem. And that's an approach that would work with computer security, too. Blaming the users, on the other hand, manifestly does not work.
As long as you are connected to a network, you are not safe.
Sadly true, though it's just as true that as long as you're alive on planet Earth, you're not safe, either.
Get off this whole "my OS is more secure than your OS" crap.
But, um, some OS'es *are* more secure than others.
Realize that you are vulnerable and take the correct steps to protect yourself.
I'm curious to know what "correct steps" you have in mind.
If it's "use an antivirus scanner", that's a retarded or at least suboptimal strategy, because antivirus scanners are of course imperfect (they'll never make you perfectly safe, either), and at any rate all they do is patch over the fact that an OS that needs them has a fundamentally flawed security model.
If it's "disable all the services you're not using", that's a pretty retarded strategy, too, because they should have been turned off by default, and the advice should really be phrased "don't enable anything you're not using."
For me, one of the biggest "correct steps" is, "use OS'es that take security seriously and have a decent security model". So of course I don't use Microsoft OS'es. I'm sorry if that's an example of the "my OS is more secure than your OS" crap, but really: it's at least as valid a strategy as "use an antivirus scanner".
Actually, no, it's more like we have a horrible problem and someone is proposing a marginal workaround, but the reaction is, "well, it's only going to help in a minority of cases...
Wow. That's quite a gulf between us. What I think is a vital first step that would help in 95% of cases, you think is a "marginal workaround" that would hardly help at all. I wonder where the real truth lies.
You realize, of course, that Dick was advocating that not 'cause he thought the lawyers were scum, but because he was afraid they'd be righteous and unmasking of the atrocites that Cade and his rabble were contemplating...
I think the/. post got that part wrong. I think they're trying to hold him responsible for their fees in his little suit against them telling them to take his name off the big suit, or perhaps for their fees in their own suit against him for failing to participate, but not for their fees in the big suit against Apple. (That'd be completely insane!)
Presuming we can believe Jason's letter, these guys are mondo scumbags. The "anti-SLAPP" suit they filed is normally intended to protect "little guys" who are being legally harrassed by big companies. In filing one against him, they're implying that he's harrassing them. Lovely.
...is the PHP/MySQL/Linux triad not considered a "monoculture"?
This question, and most of the replies posted to it, completely miss the point of the term "monoculture".
"Monoculture" does not mean, "system susceptible to bugs, such that if the system suffers a bug, everyone who uses the same system is affected." That woul be a useless, tautological term, because when any kind of system suffers a bug, all that system's users are (obviously) potentially affected.
"Monoculture" means that everyone is using the same system. Microsoft Word is not a monoculture because it does or doesn't have bugs, but rather, because 80+% of people use it. PHP/MySQL/Linux is not a monoculture at all, because it's got piddling market share.
Avoiding monocultures doesn't mean avoiding all bugs. It's just an attempt to make sure that any bug, no matter how catastrophic, is catastrophic only to some subset of the population (such that the lucky remaining portion can pick up the pieces). What you don't want is the mega-catastrophe of the catastrophic thing affecting everybody (as, for example, famously happened in Ireland in the 1840's).
I do wish that most database API's offered a "read-only" mode...
Nice idea, although there's plenty of danger even in read-only-land. For example, the example at http://shiflett.org/archive/184 is of an attacker who tricks a login scheme into letting him log in without a password, and the query there is merely a read.
I agree that prepared statements can be cumbersome, but they're clearly much more the Right Thing to be doing than constructing ad-hoc queries by hand, with random strings pasted between single quotes.
Your mention of "Query-by-Example forms" is apropos. Anybody know how to do those Right?
You're some "middleware" code, with the user above you and a SQL database beneath you.
You've got this variable, $userinput, containing a string entered by the user.
And you want to build a database query along the lines of
select * from table where somecolumn = 'user input';
where you want to plug the user-entered string in there to search for the user's input in the obvious way.
How do you do this? The obvious (but naive) way is to construct your SQL query on the fly, using your language's form of string concatenation. (Here I'll use "+".)
$query = "select * from table where somecolumn = '" + $userinput + "';";
But what if $userinput happens to contain a single quote? That's the problem here.
The obvious (but naive) thing to do is to go through $userinput checking for single quotes and escaping them in some way. You can either do this by hand, or call a function in your language that might seem to do it for you. But you're skating on thn ice here; you're playing games you shouldn't have to play; there might be cases you haven't thought of. One of them is obvious enough: if you're looking for ' characters and escaping them with \, that also means that, oh yeah, you also have to look for existing \ characters so you can escape them with \. Or you can call a function like PHP's "addslashes" which might seem to do this for you. But it turns out -- this is what the fuss is all about -- that there are other problems, if the diddling you're doing with ' and \ characters interacts badly with the diddling the database layer is doing with multibyte character encodings.
So the much better thing to do -- from several standpoints! -- is not to do this funky ad-hoc concatenate-the-strings SQL query construction after all. Use a "prepared statement", which lets you tell the database engine where to plug in those strings you've already got lying around in variables. At first this seems more roundabout, at first it's a little harder to think about, but once you've got your head wrapped arond it, it feels better anyhow, not to mention the fact that it insulates you from attacks like this one.
But yes, in answer to your question, if you're using prepared statements you should be safe, as long as your language's implementation of prepared statements isn't broken underneath.
Finally, for those wondering why this is such a big deal, why unexpected ' characters don't just cause syntax errors and random failures, how it is that this can be turned from a bug into an actual exploit -- here's the deal.
Suppose that the $userinput string contained the text
foo' OR 'a' = 'a
Now, when the naive string concatenation is done, the resulting query is
select * from table where somecolumn = 'foo' OR 'a' = 'a';
But this query is always true! The user entering that string contrived to change the behavior of the query. Obviously the user needs to know or guess what the queries you're generating look like and how you're generating them, and the user may or may not acactually be able to subvert your query into doing something truly incorrect or destructive, but the possibility is very much there.
Whether it's an issue or not depends how PostgreSQL handles invalid UTF-8 sequences.
And the answer is: badly.
If you had a UTF-8 initial-byte character followed by a 7-bit character,
it was discarding both of them, and proceeding.
(Evidently they've fixed this now.)
Who knew multibyte character handling was going to be such a mess!
Writing proper error recovery (resynchronizing, etc.) is as hard as in a friggin' compiler!
I don't believe any current software automatically executes.exe files _by design_.
But they are easily executed. You're saying this is purely an accident?
Having to chmod +x a file is no different to such a dialog box. Having to copy a file into a location that isnt mounted noexec is no different to such a dialog box. Having to specifically grant permissions to something the user runs is no different...
To be blunt, you're simply wrong. Of course there's a difference between these things; it's obvious to anyone reading the words that they're different. And they are also, contrary to your implication, significantly different.
There are lots of different reasons for the security crisis, but one of them is this attitude, which is unfortunately widespread: we have a horrible, horrible problem, and someone proposes a solution, but the reaction is, "Oh, no, that would only solve 95% of the problem, it wouldn't be perfect, some cases would still slip through, so we have no choice but to sit on our hands and deal with the repercussions from 100% of the problem."
Traffic lights at intersections do not prevent all accidents, yet we still have them.
When an accident occurs, seat belts and air bags do not prevent all injuries, yet we still have them. By your argument, these countermeasures are "no different" than just reminding people to be more careful when they drive.
for a lot of people (most, these days, I'd wager) the ability to receive and execute "untrustworthy content" is one of (if not "the") the most important things their computer does.
If what you say is true, the current problem is utterly inevitable and utterly unfixable.
...many of them primarily use email and the web for silly little flash games and the like, or sending documents back and forth ?)
I'm not talking about Flash or Word docs. Those have their problems too, but they're generally bugs that can be fixed. I'm mostly talking about.exe's. Are you saying that the vast majority of users require the ability to send untrustworthy.exe's back and forth, and execute them automatically?
...unless you *completely* remove the ability to _ever_ execute "untrustworthy content" (which is to say, you would never be able to execute something that wasn't signed by some centralised authority...
There are a lot of plausible steps in between draconian central signing authorities (which, no, would not be workable) and the just about completely unfettered, promiscuous, ridiculously insecure situation we have today.
If you could elaborate on this, I'd really appreciate it.
How many users? And for what sorts of applications?
This is really the crux of the whole issue. I know there are some users like that, but I don't know the details. I've been saying for some time that today's computer security nightmare could be largely solved, at the cost of denying those users this thing they "want to do". But I don't know how many users we're talking about, or what other alternatives they might have.
what on Earth can we do so stop the spread of garbage like the above?... is safety a lost cause?
It's actually relatively simple. Unfortunately there are a million irrelevant arguments clouding the discussion, such that it's easy to lose the forest for the trees. But here's the bottom line:
Get rid of automatically-executable attachments.
Don't "disable" them. Don't try to "guard" them with bigger or redder or scarier "Are you sure?" prompts. Just don't have a mechanism for taking untrustworthy content and executing it as a program, at all.
This is the fundamental issue. A lot of those irrelevant arguments try to dance around or ignore or make apologies for this issue, but it's the biggie. As long as there are executable attachments, security will continue to be a nightmare. If we would just get rid of them -- in IE, in IM, in all the silly other places they've been implemented -- we'd have infinitely better security all around.
I realize there are some nifty-keen things that can be done with executable attachments, and that some people have become dependent on them for various reasons. I'm sorry, but those people need to lose this argument. Losing the ability to easily run untrustworthy content is the price we really do have to pay for any kind of reasonable security.
As long as people will click "yes" to install/run some random bit of software, Mac/Linux/*BSD/etc. are not going to be any better than Windows. These aren't holes in the OS, they are holes in the user.
False. The hole is that there is a way "to install/run some random bit of software", at all.
This is not just a hole, it's a gaping hole. And it is a hole in the OS, make no bones about it.
As long as the OS makes it straightforward to take a random, untrusted string of bits off the net and execute it as a full-fledged program, computer security will continue to be a nightmare. Trhying to "protect" that capability with a little yes/no dealog box is a superficial design flaw on top of a fundamental design flaw.
In fact, something like this ought to be the default. It just shouldn't be as easy to install new software on a PC as it is. It just staggers me that the adware problem is as bad as it is: what pack of brain-dead morons set out to deliberately set up an infrastructure -- I mean, they had to work at this -- such that merely visiting a webpage allows the webpage owner to pwn your machine?!?
You don't need Trusted Computing to do this, you just need common sense. The reason people are wary of Trusted Computing is that there'd be no escape from it: it wouldn't just prevent novice users from making innocent mistakes, it could also be used to prevent expert users from doing useful things, like writing their own software or manipulating their own data.
I'd like to do a social experiment and write a virus that pops up a window asking the question: "Install Virus?". The options are "No Thanks" and "yeah sure, pwn me".
That's a darn good idea. And, yes, some people would get pwned, and not necessarily because they're "stupid".
Accidentally hit RETURN instead of selecting "No thanks" button. (An easy mistake; anyone can make it.)
Perhaps the results of such an experiment would help to enlighten the gearheads-in-denial (you can spot 'em every time topics like this one come up)
who think problems like these are all the user's fault, or that they're fixable with just a little education. Wrongola, on both counts.
Slashdot Mirror
Absolutely agree. So the remaining question is: aside from the ill-advised potshot, has Apple done right or wrong by those customers? Have they (a) disavowed all responsibility, told customers it's their problem, told them to go talk to the "podunk assembly plant in Hunan Province" if they need help, or (b) done everything they can to mitigate and prevent future recurrences of the problem?
And everybody's blaming them for not noticing. But if you think about it, it was a pretty absurd thing for them to have had to "notice". As I understand it, the virus was implanted by one infected machine among a number of machines at a Chinese manufacturing shop they'd contracted iPod manufacture to. Apple said, "here's a thing that looks like an external disk: please put these bits on it for us". A simple and straightforward enough task, one would think -- but in a world where autorun exists and is or has been enabled by default, perhaps not so straightforward.
It's as if I had a letter to mail to 1000 of my customers, and I took one original down to my friendly print shop and asked them to make 1000 copies, and I or the print shop used an automated machine to fold the 1000 copies and stuff them in envelopes and mail them, and only after they were mailed out and opened by my customers did we start discovering that for some strange reason 1% of them had "FUCK YOU, ASSHOLE" overprinted on page 2. And then found out that the "strange reason" was that one of the copy machines at the print shop, among the several that the print shop divided my job among, was "infected" by a "virus".
If that happened to me, I'd be annoyed, too. (It'd be even more annoying if I were accused of ignorance for not having protected myself against this "obvious" threat, that evidently everybody else knows about and makes allowances for.) And I know my response would not be to ask the print shop to be more careful next time, or to run an "antivirus" soluton, or something. I'd take my business elsewhere, and more importantly insist that my future printing contractors use a different brand of copier, one that's not susceptible to preposterous failure modes like that, because even if there is some alleged way of papering over that particular flaw, who knows how many other equivalently egregious bizarre flaws it's got that haven't been discovered and papered over yet?
This is not merely false, it's dangerously false.
If users are predictably goofy -- as they are -- and if they cannot be trained otherwise (as about a decade of experience has amply taught us), then what you need to do is engineer the system to accomodate its fallible components, i.e., the fallible users.
People used to get maimed and killed a lot more in car crashes than they do now. The main reason for the change is not improved driver training, but rather, the fact that cars now have seat belts, air bags, crumple zones, and a host of other features explicitly targeted at making them safer in spite of the fact that drivers keep doing goofy things like crashing into trees and each other.
We didn't say, "crashes are inevitable" or "stupid drivers shouldn't crash so much". We fixed the problem. And that's an approach that would work with computer security, too. Blaming the users, on the other hand, manifestly does not work.
Sadly true, though it's just as true that as long as you're alive on planet Earth, you're not safe, either.
Get off this whole "my OS is more secure than your OS" crap.
But, um, some OS'es *are* more secure than others.
Realize that you are vulnerable and take the correct steps to protect yourself.
I'm curious to know what "correct steps" you have in mind.
If it's "use an antivirus scanner", that's a retarded or at least suboptimal strategy, because antivirus scanners are of course imperfect (they'll never make you perfectly safe, either), and at any rate all they do is patch over the fact that an OS that needs them has a fundamentally flawed security model.
If it's "disable all the services you're not using", that's a pretty retarded strategy, too, because they should have been turned off by default, and the advice should really be phrased "don't enable anything you're not using."
For me, one of the biggest "correct steps" is, "use OS'es that take security seriously and have a decent security model". So of course I don't use Microsoft OS'es. I'm sorry if that's an example of the "my OS is more secure than your OS" crap, but really: it's at least as valid a strategy as "use an antivirus scanner".
Ah, fair enough. (Good for Seth!) I stand corrected; I'll stop parroting the "Dick was indirectly praising them" argument.
Wow. That's quite a gulf between us. What I think is a vital first step that would help in 95% of cases, you think is a "marginal workaround" that would hardly help at all. I wonder where the real truth lies.
You realize, of course, that Dick was advocating that not 'cause he thought the lawyers were scum, but because he was afraid they'd be righteous and unmasking of the atrocites that Cade and his rabble were contemplating...
I think the /. post got that part wrong. I think they're trying to hold him responsible for their fees in his little suit against them telling them to take his name off the big suit, or perhaps for their fees in their own suit against him for failing to participate, but not for their fees in the big suit against Apple. (That'd be completely insane!)
Presuming we can believe Jason's letter, these guys are mondo scumbags. The "anti-SLAPP" suit they filed is normally intended to protect "little guys" who are being legally harrassed by big companies. In filing one against him, they're implying that he's harrassing them. Lovely.
This question, and most of the replies posted to it, completely miss the point of the term "monoculture".
"Monoculture" does not mean, "system susceptible to bugs, such that if the system suffers a bug, everyone who uses the same system is affected." That woul be a useless, tautological term, because when any kind of system suffers a bug, all that system's users are (obviously) potentially affected.
"Monoculture" means that everyone is using the same system. Microsoft Word is not a monoculture because it does or doesn't have bugs, but rather, because 80+% of people use it. PHP/MySQL/Linux is not a monoculture at all, because it's got piddling market share.
Avoiding monocultures doesn't mean avoiding all bugs. It's just an attempt to make sure that any bug, no matter how catastrophic, is catastrophic only to some subset of the population (such that the lucky remaining portion can pick up the pieces). What you don't want is the mega-catastrophe of the catastrophic thing affecting everybody (as, for example, famously happened in Ireland in the 1840's).
Nice idea, although there's plenty of danger even in read-only-land. For example, the example at http://shiflett.org/archive/184 is of an attacker who tricks a login scheme into letting him log in without a password, and the query there is merely a read.
I agree that prepared statements can be cumbersome, but they're clearly much more the Right Thing to be doing than constructing ad-hoc queries by hand, with random strings pasted between single quotes.
Your mention of "Query-by-Example forms" is apropos. Anybody know how to do those Right?
You're some "middleware" code, with the user above you and a SQL database beneath you. You've got this variable, $userinput, containing a string entered by the user. And you want to build a database query along the lines of
where you want to plug the user-entered string in there to search for the user's input in the obvious way.How do you do this? The obvious (but naive) way is to construct your SQL query on the fly, using your language's form of string concatenation. (Here I'll use "+".)
But what if $userinput happens to contain a single quote? That's the problem here.The obvious (but naive) thing to do is to go through $userinput checking for single quotes and escaping them in some way. You can either do this by hand, or call a function in your language that might seem to do it for you. But you're skating on thn ice here; you're playing games you shouldn't have to play; there might be cases you haven't thought of. One of them is obvious enough: if you're looking for ' characters and escaping them with \, that also means that, oh yeah, you also have to look for existing \ characters so you can escape them with \. Or you can call a function like PHP's "addslashes" which might seem to do this for you. But it turns out -- this is what the fuss is all about -- that there are other problems, if the diddling you're doing with ' and \ characters interacts badly with the diddling the database layer is doing with multibyte character encodings.
So the much better thing to do -- from several standpoints! -- is not to do this funky ad-hoc concatenate-the-strings SQL query construction after all. Use a "prepared statement", which lets you tell the database engine where to plug in those strings you've already got lying around in variables. At first this seems more roundabout, at first it's a little harder to think about, but once you've got your head wrapped arond it, it feels better anyhow, not to mention the fact that it insulates you from attacks like this one.
But yes, in answer to your question, if you're using prepared statements you should be safe, as long as your language's implementation of prepared statements isn't broken underneath.
Finally, for those wondering why this is such a big deal, why unexpected ' characters don't just cause syntax errors and random failures, how it is that this can be turned from a bug into an actual exploit -- here's the deal. Suppose that the $userinput string contained the text
Now, when the naive string concatenation is done, the resulting query is But this query is always true! The user entering that string contrived to change the behavior of the query. Obviously the user needs to know or guess what the queries you're generating look like and how you're generating them, and the user may or may not acactually be able to subvert your query into doing something truly incorrect or destructive, but the possibility is very much there.Exactly right.
Whether it's an issue or not depends how PostgreSQL handles invalid UTF-8 sequences.
And the answer is: badly. If you had a UTF-8 initial-byte character followed by a 7-bit character, it was discarding both of them, and proceeding. (Evidently they've fixed this now.)
Who knew multibyte character handling was going to be such a mess! Writing proper error recovery (resynchronizing, etc.) is as hard as in a friggin' compiler!
But they are easily executed. You're saying this is purely an accident?
Having to chmod +x a file is no different to such a dialog box. Having to copy a file into a location that isnt mounted noexec is no different to such a dialog box. Having to specifically grant permissions to something the user runs is no different...
To be blunt, you're simply wrong. Of course there's a difference between these things; it's obvious to anyone reading the words that they're different. And they are also, contrary to your implication, significantly different.
There are lots of different reasons for the security crisis, but one of them is this attitude, which is unfortunately widespread: we have a horrible, horrible problem, and someone proposes a solution, but the reaction is, "Oh, no, that would only solve 95% of the problem, it wouldn't be perfect, some cases would still slip through, so we have no choice but to sit on our hands and deal with the repercussions from 100% of the problem."
Traffic lights at intersections do not prevent all accidents, yet we still have them. When an accident occurs, seat belts and air bags do not prevent all injuries, yet we still have them. By your argument, these countermeasures are "no different" than just reminding people to be more careful when they drive.
If what you say is true, the current problem is utterly inevitable and utterly unfixable.
I'm not talking about Flash or Word docs. Those have their problems too, but they're generally bugs that can be fixed. I'm mostly talking about .exe's. Are you saying that the vast majority of users require the ability to send untrustworthy .exe's back and forth, and execute them automatically?
There are a lot of plausible steps in between draconian central signing authorities (which, no, would not be workable) and the just about completely unfettered, promiscuous, ridiculously insecure situation we have today.
If you could elaborate on this, I'd really appreciate it. How many users? And for what sorts of applications?
This is really the crux of the whole issue. I know there are some users like that, but I don't know the details. I've been saying for some time that today's computer security nightmare could be largely solved, at the cost of denying those users this thing they "want to do". But I don't know how many users we're talking about, or what other alternatives they might have.
You're joking, right?
Well, as the Wiki folks say, "sofixit"!
It's actually relatively simple. Unfortunately there are a million irrelevant arguments clouding the discussion, such that it's easy to lose the forest for the trees. But here's the bottom line:
Don't "disable" them. Don't try to "guard" them with bigger or redder or scarier "Are you sure?" prompts. Just don't have a mechanism for taking untrustworthy content and executing it as a program, at all.This is the fundamental issue. A lot of those irrelevant arguments try to dance around or ignore or make apologies for this issue, but it's the biggie. As long as there are executable attachments, security will continue to be a nightmare. If we would just get rid of them -- in IE, in IM, in all the silly other places they've been implemented -- we'd have infinitely better security all around.
I realize there are some nifty-keen things that can be done with executable attachments, and that some people have become dependent on them for various reasons. I'm sorry, but those people need to lose this argument. Losing the ability to easily run untrustworthy content is the price we really do have to pay for any kind of reasonable security.
Absolutely. So simple, and yet so little-known.
Firefox: get rid of the XPI install-from-web stuff.
What in the world is that? Presumably there's a good way to disable it?
(don't treat archives as "safe files",
Yeah. Sheesh.
(in fact there's a lot of ranting I could add here: http://www.scarydevil.com/~peter/io/rant.html
Say! Nice rant.
Apple: Don't "open safe files after downloading"... there are no "safe files".
Well, data files are a lot safer than executable files, but that line just keeps getting blurrier (as witness yesterday's story).
Why not just make it impossible to run an EXE from an IM or popup? (Seriously.)
False. The hole is that there is a way "to install/run some random bit of software", at all. This is not just a hole, it's a gaping hole. And it is a hole in the OS, make no bones about it.
As long as the OS makes it straightforward to take a random, untrusted string of bits off the net and execute it as a full-fledged program, computer security will continue to be a nightmare. Trhying to "protect" that capability with a little yes/no dealog box is a superficial design flaw on top of a fundamental design flaw.
If it isn't, it certainly ought to be.
In fact, something like this ought to be the default. It just shouldn't be as easy to install new software on a PC as it is. It just staggers me that the adware problem is as bad as it is: what pack of brain-dead morons set out to deliberately set up an infrastructure -- I mean, they had to work at this -- such that merely visiting a webpage allows the webpage owner to pwn your machine?!?
You don't need Trusted Computing to do this, you just need common sense. The reason people are wary of Trusted Computing is that there'd be no escape from it: it wouldn't just prevent novice users from making innocent mistakes, it could also be used to prevent expert users from doing useful things, like writing their own software or manipulating their own data.
That's a darn good idea. And, yes, some people would get pwned, and not necessarily because they're "stupid".
Perhaps the results of such an experiment would help to enlighten the gearheads-in-denial (you can spot 'em every time topics like this one come up) who think problems like these are all the user's fault, or that they're fixable with just a little education. Wrongola, on both counts.
Hear, hear.