...there is a big difference between having no AV at all and having AV that is running but has definitions that are two weeks or a month old...
I'm not sure there's that much of a difference.
Pattern-based antivirus software is reactive, and that's one of the reasons it doesn't work very well.
A well-engineered virus exploiting a brand-new vulnerability can spread very, very fast.
If (say) 90% of users are running antivirus software that hasn't been updated in two days or more,
a new virus can (and will) have devastating effect.
If you're going to base your security in any large part on reactive antivirus software,
you really do have to keep it religiously up-to-date, on a daily or even hourly basis.
Otherwise you're basing your security on a race between the spread of a new virus and the spread of the new rules to detect it, and that's a race you're going to lose sooner or later.
If I was EXTREMLY lucky, I could persuade them to go out and buy the software from Staples, bring it back to us, and we'd install it on thier new machine before it ever left our store and it's own defenses.
But this is just *Madness*!
This is like a car salesman saying, "If I was extremely lucky, I could persuade them to go out and buy some seatbelts from AutoZone down the street, bring them back to us, and we'd install it them in their new car before they even drove it off the lot."
Or a tool salesman selling a circular saw without any protective guards and trying to get the prospective customer to goo off and buy them separately.
Or a steam boiler salesman trying to sell a boiler without a safety valve.
Or a developer trying to sell a new house without any circuit breakers or fuses, and trying to get the buyer to have an electrician install them before actually living in the house.
(Why couldn't your store at least have had the antivirus software on sale right there?)
Microsoft should never escape having their product explicitly associated with the malware it hosts.
The rest of the IT industry does not deserve the wide-ranging implication that this is a "computer virus". This is a Windows virus.
Most users use things out-of-the-box, as-is.
They assume that the default configuration,
as designed by the manufacturer, is "good enough".
This is true of any product, not just computer operating systems.
And it's not actually a bad assumption -- or shouldn't be.
You shouldn't need an external firewall to protect your machine from hostile incoming connections --
your machine shouldn't be listening on ports it doesn't need to,
and when it does listen, it shouldn't be possible for incoming connections to subvert it.
You shouldn't need add-on antivirus software -- your machine should have a basic "immune system"
of its own and shouldn't be vulnerable to the effects of running untrusted external code.
It is possible to design operating systems that are inherently secure in these ways.
One of the larger crimes committed by the designers of the currently-popular consumer-grade operating systems
is to have convinced large swaths of the population, via ubiquitous, crashing mediocrity, that it's somehow an "impossible"
problem. It was largely a solved problem 20 years ago, if anyone had listened.
Previous posters have addressed ad nauseam the fact that the "threat" discussed has nothing to do with the camera part of the digital camera, and everything to do with the USB-atttachable removable storage part.
But did anybody read the article's list of "steps that can be taken to reduce rogue behaviour" in the last paragraph?
"Passwords that employ both letters and numerals"? What's that got to do with anything?
Total nonsense.
Memo to self: pay no attention to "iT Observer" in future.
By the way, I found a picture of the showerhead...
(I didn't read the article there, just found the picture.)
If you had read the article, you would have learned that despite the fact that
"The owner is an electrician by trade, so it is properly installed",
the picture shows a bunch of exposed connections,
and the tenant has occasion to report that
"there is no experience like being shocked with 110 volts, while standing wet and naked on a tile floor",
and that even after he learned not to touch the controls he was still being
"shocked regularly by the water pipes" until he marked his calendar to remind him to water the heater's own outside ground stake every couple of weeks. Sheesh. If the only thing that keeps you from getting shocked is a low-resistance alternate ground path, it means that there's waste leakage current flowing through that alternate ground path all the time...
Attachments are evil. If you want to transfer files, use FTP.
And of course FTP can be pretty evil, too.
(Unless you restrict yourself to anonymous use of it, never typing a real password.)
Personally, I'm no great fan of attachments, either, but if Billy is going to send Aunt Mabel an email with a picture of his dog Spot, is Billy really supposed to set it up on an ftp server somewhere, and is Aunt Mabel really supposed to switch from her email client to her FTP client, download the image, then switch to her JPEG viewer to look at it?
I know that's the way us techies used to have to do it and sometimes still choose to, but I'm not sure it'll fly in the real world...
We dislike "solutions" with obvious flaws...
We recognize the need for stop-gap measures, but we hate to see stop-gap turned into permanent "solutions"...
Yet I don't hear you complaining when this approach gives you stable and secure software.
Nope. You don't.
Trying to decide how "perfect" is perfect enough, or whether it's time to settle for merely "good enough",
is a tough, tough question.
And it's one you definitely can't take a slippery-slope, all-or-nothing approach to resolving, either way.
Sometimes the good is the enemy of the great, but
sometimes the speculative great stands in the way of ever getting anything done.
That's the difference between engineering and everything else.
Actually, no, it's not.
Your point is well-taken: when people shortsightedly accept something drastically short of perfection,
that's a problem, anywhere, in engineering or any other field.
But engineering (any kind of engineering) is all about finding appropriate, cost-effective solutions.
I hate to sound like I'm arguing against perfection (because I'm a dreadful perfectionist myself),
but no engineer can afford to seek 100.00000% perfection.
Our bridges and our skyscrapers are not 100.00000% safe, either -- sometimes they do fall down.
If we tried to make them 100.00000% effective we couldn't afford them,
and if we held out waiting for perfection we'd still be sitting in the mud.
Yes, I agree, 90% solutions are often no good.
Yes, I agree, solutions that are less perfect than the state-of-the-art would allow
but that are nevertheless chosen out of laziness or ignorance or shortsighted penny-pinching,
those are Evil and Wrong.
But when the state-of-the-art doesn't exist yet, or when you simply can't afford it, sometimes,
a 90% (or even a 50% or a 10%) solution is appropriate, because it's better than nothing.
(And sometimes it's not; sometimes it is better to do without than to delude yourself.)
Trying to choose the appropriate solution, when real-world factors like cost begin to impinge on theoretical notions of achievability or perfectability, can be an extremely difficult problem. But it's the essence of engineering, and of many other tough decision-making processes as well.
No, the childish thing was clambering up on the soapbox to make an off-topic rant at all.
The throwaway line about "rescuing my karma" was just that.:-)
...Cohen's engine is far from the only tool used to find pirated BitTorrent
files online. A handful of other online engines can search BitTorrent-specific
sites, and ordinary search engines can also be used to find BitTorrent files.
There's an old saying, "the squeaky wheel gets the grease".
The big copyright holders will always go after the highest-profile
"choke points" first,
and in general
(i.e. when solving problems of any kind, regardless of how you feel
about the studios' motives ion solving this particular "problem"),
it can be a perfectly appropriate, effective strategy.
Techies often have a bad habit of adopting a sort of slippery-slope,
sky-is-falling, all-or-nothing approach to problem solving
(especially if it's a problem they don't really want to solve).
"This proposed solution has a hole in it and is not guaranteed to
be 100% effective, therefore it is no solution at all
and is foolish to pursue."
Not necessarily true.
You don't always need to find a perfect solution;
sometimes a 90% solution is good enough,
especially if the alternative is sitting on your hands doing nothing
wishing you had a 100% perfect solution.
(Off-topic, but to rescue my karma
before I'm accused of siding with the studios here:
the same thought processcan act in all sorts of other situations,
not just copy protection.
For example, if you suggest that a great way of reducing the threat
of e-mail vuruses would be to redesign mail clients so that they don't
make it easy to click on executable attachments and run them,
while still allowing users to click on data attachments and view them,
you'll receive all sorts of "objections" from techies
who think they know better,
pointing out that your solution "won't work" because of the
possibility of e.g. JPEG and Word viruses.)
>> It would be impossible for you to get your hands on the unencrypted bits.
> If you can get your eyes and ears on the unencrypted signals, then you can always get your hands on them.
I said "bits", not signals.
>> The only way to rip audio would be to re-digitize the audio output from your speakers
> But once you did successfully redigitise it, that copy -- and every copy you made from it -- would be unprotected, and further copying would not incur any loss of quality.
Sure, but -- rightly or wrongly -- the music industry is much,
much more worried about verbatim original digital copies than
they are about analog copies. (And, let's face it, people who
copy music prefer verbatim original digital copies, too, if only
for the convenience.)
>> The only way to rip video would be to aim a camera at the screen.
> Or to use the "fake CRT" device I have described before, which connects to an existing monitor in place of the real CRT...
There was a story recently -- I don't remember where, perhaps
slashdot -- about an amendment to one of the new HDTV or DVI
standards which was designed to prohibit exactly this. I think
it involved a cryptographic exchange between the video card and
the HD monitor, such that the video card could, should, and would
refuse to emit video signals encoding protected content if an
approved monitor was not connected. (And before you suggest it:
the same amendment specified that the new connector had to be
tamper-resistant, too.)
> LCDs ought to be even easier to deal with, since the signal is sent pixel-by-pixel;
Actually, as I understand it, the signal to an LCD monitor
involves exactly the same kind of back-and-forth scan as to a
conventional CRT.
>> The only way to evade these "impossibilities"... would involve electron microscopes and micromachining techniques.
> Again, once it was done, it would be done for all time; instantly rendering every penny ever spent on the project a penny wasted.
That's not clear. You might have broken your
computer for all time (though even that's not clear), but that
doesn't mean you'd have broken everyone else's for them.
At any rate, it's clear that none of this stuff will deter
serious pirates, nor is it clear that it's even the intent.
Massive for-profit counterfeiters can be gone after with
conventional legal techniques, and it would be sure be nice if
the movie and record industries would concentrate their efforts
there instead of pursuing all these invasive technological
approaches against the rest of us.
What they're worried about, though, is indeed the individual.
For any single, identifiable "choke point", such as a major
counterfeiter or a major filesharing hub, the copyright holders
have lots of tools they can use. What they don't want is for
every Ma and Pa Kettle to be able to be a pure-digital
filesharer; they'd really rather not haul every Tom, Dick, and
Harry who ever shares a file into court; they've done that (I
assume) only as a last resort.
Don't get me wrong; I'm not trying to defend the media companies in
any of this, and I agree that copying in some form will always be possible.
But if the TCPA or something like it goes through, it
will make casual copying much more difficult, and
what's worse, it is also likely to make all sorts of other
casual activities -- activities that aren't by any stretch of the
imagination illegal and shouln't be restricted -- much more
difficult, too.
I think the biggest backlash to come is versus the security companies.
I personnaly uninstalled Norton Security from my computer as it's now clear
that they can not protect me from emerging threats.
The answer, I think, as to why the security companies fell down so unanimously
on this one is that they're all afraid of the DMCA.
So we have yet another crystal-clear example of the DMCA's overly far reach
and unintended consequences:
it legitimizes malware,
as long as the malware takes the form of "copy protection".
...just how reluctant the labels are to change their business model...
...rather than adopting technological methods to try to stop unauthorized copying of music, record companies need to do more to remove the incentive for piracy...
Precisely.
A question I'd love to ask the record industry
(slashdot interview, anyone?:-) )
would be:
"Would you rather sell X million CDs per year with a 0% piracy rate,
or 2X million with a 30% piracy rate?"
(They still wouldn't "get it", of course, but it'd be fun to ask.)
Well, yes, but it's practically possible. It's very, very hard,
but it's being worked on.
With a complete TCPA/Palladium deployment of the kind Microsoft and the big media companies
are dreaming about, it would be possible to come out with new CD and DVD formats which were encrypted
in such a way that only your computer could decrypt them, and then only to play audio waveforms through
your speakers or show images on your screen. It would be impossible for you to get your hands on the unencrypted bits. It would be impossible for you to write code to do your own decryption of the media.
The only way to rip audio would be to re-digitize the audio output from your speakers, and that'd be a lower-quality, non-bitwise copy. The only way to rip video would be to aim a camera at the screen.
The only way to evade these "impossibilities" -- to get at the bits, or obtain the keys you'd need to perform your own decryption -- would involve electron microscopes and micromachining techniques. You'd have to disassemble and probe the TCPA chip on your motherboard which enables all this -- and it would be explicitly designed to make such disassembly very, very difficult.
Buncha people said this already, but:
they'll become mainstream when they're not burdened down by cumbersome features that nobody wants, chief among them being oppressive DRM. Cory Doctorow's got some very nice words on the general subject of unwanted features in section 5 of the talk he gave at Microsoft, and he talks about e-books specifically in section 4: "The hardware-dependent ebooks, the DRM use-and-copy-restricted ebooks, they're cratering. Sales measured in the tens, sometimes the hundreds....when you're selling copies by the ten, that's not even a business, it's a hobby."
So you are saying we should write code without bugs and holes? What a great idea that is? why did no-one think of saying that before?
Everybody says it, what Marcus is saying is that we should actually do it.
It is possible, you know.
The first step is to drop your tragic preconception that all these problems are inevitable, that there's nothing we can do about them. People like Marcus Ranum can tell you what to do about them -- if you'll only listen.
In fact, I can tell you, too.
Here are two philosophies:
Bugs are inevitable. You find 'em, you fix 'em, life goes
on; anyone who tells you it's possible to write bug-free code is
a dreamy ivory-tower idealist.
Bugs need not be inevitable, and can be reduced to acceptably
low levels (and the effects of the remaining ones mitigated) if
we're scientific about it.
I'm here to argue for #2.
Like any scientific process, the key to actually reducing bugs is
to do some measurement. (It doesn't have to be formal.)
If, over time, your bug counts go down, if the new strategies you
adopt in response to the bugs you had yesterday keep you from
having as many bugs tomorrow, you're doing something right.
But if you keep having bugs, despite claiming that you're trying
to learn from them and trying to be more careful, you're still
doing something wrong. In particular, simply trying to "be more
careful" doesn't always work. There are some mistakes you can
train yourself not to make, but there are some that are
inevitable, meaning that sometimes you have to adopt a
significantly different
methodology where that particular too-easy-to-make mistake simply doesn't
have a chance to happen.
But, at the same time, yes, you have to admit that some bugs will
still slip through. So you also have to think about, and spend
time actually implementing, strategies to limit the damage
caused by any remaining bugs in production code.
For some reason, people who dismiss the notion of
"writing code without bugs and holes" also dismiss the notion of
trying to limit the damage caused by those bugs and holes.
It's as if they imagine that bugs are inevitable in newly-written
code, but that they can somehow all be eradicated from shipped,
production code.
(Or perhaps they're resigned to the fact that production code will always be full of bugs, too, and that users will just have to live with them. How sad. Good thing the engineers who design buildings and bridges and airplanes don't have the same attitude.)
So...tell me just how you'd send something to someone in an attachment, and all they had to do was click to open it?
Not sure what you're saying.
If the attachment is a data attachment (text, document, spreadsheet, image, audio, video, whatever), the recipient clicks on it and it opens, using the appropriate viewing app (an app which, of course, was already installed on the machine and is presumably trusted.)
But if the attachment is an executable, when the recipient clicks on it either nothing happens, or a dialog offers to save it to disk, but the point is that it is dignificantly difficult (if not impossible) to just go and run that attachment.
One of the points basically comes down to "write perfect code".
Nowhere does he say that; what he's saying is that we should try -- try! -- to do better. In fact, one of the things people who take security seriously realize is that their code will not be perfect -- and then figure out ways to limit the damage.
Well, duh, why didn't I think of that before?
The "duh" is on you, I think.
You, like most of the software industry, regard bugs and rampantly imperfect code as inevitable, and you pooh-pooh anyone who dares to suggest that we could do better. You refuse to take seriously models other than "default permit" and "reflexively patch", models which guarantee an escalating arms race and a neverending stream of vulnerabilities and an epidemic of real, actual, time-wasting and money-costing and data-losing security problems.
I can't say that you're wrong, because so much of the industry agrees with you, which is why computer security is the horrible mess it is.
But it doesn't have to be that way.
The single biggest security problem with desktop windows is having system administrator be the default user
That's a biggie, but I think it's one of the two biggest problems.
The other is that, by default, it is maximally easy to run (at all, as any user) even the most breathtakingly untrustworthy code, i.e. that which arrives as an e-mail attachment from a unknowable source. There have been various attempts to patch this, but the main line of defense still seems to be that the poor user is ultimately responsible for deciding which attachments are safe to open and which are not -- and this has been more than amply shown to just plain not work.
If the one-click-to-open-an-attachment model did not mean, for an executable attachment, to execute the attachment, email viruses would be a minor problem, not a sweeping epidemic.
(Realistically: how often does anyone receive a legitimate executable program in the mail and expect to be able to run it right out of their mailbox?)
Mod parent up! (Oh, it looks like someone already did.)
These are all very, very, very good points:
It is possible to write secure software...
If you approach a programming project with the attitude that you and your programmers are fallable...
...design your system from the outset to contain the damage...
...most pointy-haired bosses... want to... solve the immediate problem... in the least amount of time...
Programmers...have a natural tendancy to assume that their code will work perfectly...
It takes discipline to consistantly design systems that will compensate...
Unfortunately, most managers tend to encourage programmers' optimisim...
If more programmers, and programming managers, really understood and valued these points, the software world would be a much, much different place.
How does reading plain text let someone into your computer?
It doesn't, but this case -- like most of "modern" computing -- has nothing to do with plain text.
For the vast majority of computer users today, "plain text" is as foreign and obsolete a concept as a buggy whip. There is no such thing as "pure information" encoded by open, lowest-common-denominator means. Everything is a "document" in a "format" that you have to "open" by "clicking" on it. Furthermore, since clicking is also how you chase links and run programs, users who are accustomed to doing nothing as they interact with their computers but click on things all day are infinitely vulnerable -- and always will be -- to every sort of e-mail virus and phishing scam and e-card swindle.
Actually, the submitter probably didn't.
Those links aren't in the actual article;
they're glommed on after the fact by vibrantmedia's "intellitxt", which flexbeta.net has evidently installed. Turn off JavaScript, and those links go away.
Slashdot Mirror
I'm not sure there's that much of a difference.
Pattern-based antivirus software is reactive, and that's one of the reasons it doesn't work very well.
A well-engineered virus exploiting a brand-new vulnerability can spread very, very fast. If (say) 90% of users are running antivirus software that hasn't been updated in two days or more, a new virus can (and will) have devastating effect.
If you're going to base your security in any large part on reactive antivirus software, you really do have to keep it religiously up-to-date, on a daily or even hourly basis. Otherwise you're basing your security on a race between the spread of a new virus and the spread of the new rules to detect it, and that's a race you're going to lose sooner or later.
But this is just *Madness*!
This is like a car salesman saying, "If I was extremely lucky, I could persuade them to go out and buy some seatbelts from AutoZone down the street, bring them back to us, and we'd install it them in their new car before they even drove it off the lot."
Or a tool salesman selling a circular saw without any protective guards and trying to get the prospective customer to goo off and buy them separately.
Or a steam boiler salesman trying to sell a boiler without a safety valve.
Or a developer trying to sell a new house without any circuit breakers or fuses, and trying to get the buyer to have an electrician install them before actually living in the house.
(Why couldn't your store at least have had the antivirus software on sale right there?)
The rest of the IT industry does not deserve the wide-ranging implication that this is a "computer virus". This is a Windows virus.
Excellent points.
You shouldn't need an external firewall to protect your machine from hostile incoming connections -- your machine shouldn't be listening on ports it doesn't need to, and when it does listen, it shouldn't be possible for incoming connections to subvert it. You shouldn't need add-on antivirus software -- your machine should have a basic "immune system" of its own and shouldn't be vulnerable to the effects of running untrusted external code.
It is possible to design operating systems that are inherently secure in these ways. One of the larger crimes committed by the designers of the currently-popular consumer-grade operating systems is to have convinced large swaths of the population, via ubiquitous, crashing mediocrity, that it's somehow an "impossible" problem. It was largely a solved problem 20 years ago, if anyone had listened.
You're joking, right? It's always Windows.
Previous posters have addressed ad nauseam the fact that the "threat" discussed has nothing to do with the camera part of the digital camera, and everything to do with the USB-atttachable removable storage part. But did anybody read the article's list of "steps that can be taken to reduce rogue behaviour" in the last paragraph? "Passwords that employ both letters and numerals"? What's that got to do with anything? Total nonsense.
Memo to self: pay no attention to "iT Observer" in future.
(I didn't read the article there, just found the picture.)
If you had read the article, you would have learned that despite the fact that "The owner is an electrician by trade, so it is properly installed", the picture shows a bunch of exposed connections, and the tenant has occasion to report that "there is no experience like being shocked with 110 volts, while standing wet and naked on a tile floor", and that even after he learned not to touch the controls he was still being "shocked regularly by the water pipes" until he marked his calendar to remind him to water the heater's own outside ground stake every couple of weeks. Sheesh. If the only thing that keeps you from getting shocked is a low-resistance alternate ground path, it means that there's waste leakage current flowing through that alternate ground path all the time...
And of course FTP can be pretty evil, too. (Unless you restrict yourself to anonymous use of it, never typing a real password.)
Personally, I'm no great fan of attachments, either, but if Billy is going to send Aunt Mabel an email with a picture of his dog Spot, is Billy really supposed to set it up on an ftp server somewhere, and is Aunt Mabel really supposed to switch from her email client to her FTP client, download the image, then switch to her JPEG viewer to look at it? I know that's the way us techies used to have to do it and sometimes still choose to, but I'm not sure it'll fly in the real world...
We dislike "solutions" with obvious flaws...
We recognize the need for stop-gap measures, but we hate to see stop-gap turned into permanent "solutions"...
Absolutely agree. No argument there at all.
Nope. You don't.
Trying to decide how "perfect" is perfect enough, or whether it's time to settle for merely "good enough", is a tough, tough question. And it's one you definitely can't take a slippery-slope, all-or-nothing approach to resolving, either way.
Sometimes the good is the enemy of the great, but sometimes the speculative great stands in the way of ever getting anything done.
Actually, no, it's not.
Your point is well-taken: when people shortsightedly accept something drastically short of perfection, that's a problem, anywhere, in engineering or any other field.
But engineering (any kind of engineering) is all about finding appropriate, cost-effective solutions. I hate to sound like I'm arguing against perfection (because I'm a dreadful perfectionist myself), but no engineer can afford to seek 100.00000% perfection.
Our bridges and our skyscrapers are not 100.00000% safe, either -- sometimes they do fall down. If we tried to make them 100.00000% effective we couldn't afford them, and if we held out waiting for perfection we'd still be sitting in the mud.
Yes, I agree, 90% solutions are often no good. Yes, I agree, solutions that are less perfect than the state-of-the-art would allow but that are nevertheless chosen out of laziness or ignorance or shortsighted penny-pinching, those are Evil and Wrong. But when the state-of-the-art doesn't exist yet, or when you simply can't afford it, sometimes, a 90% (or even a 50% or a 10%) solution is appropriate, because it's better than nothing. (And sometimes it's not; sometimes it is better to do without than to delude yourself.)
Trying to choose the appropriate solution, when real-world factors like cost begin to impinge on theoretical notions of achievability or perfectability, can be an extremely difficult problem. But it's the essence of engineering, and of many other tough decision-making processes as well.
No, the childish thing was clambering up on the soapbox to make an off-topic rant at all. The throwaway line about "rescuing my karma" was just that. :-)
There's an old saying, "the squeaky wheel gets the grease". The big copyright holders will always go after the highest-profile "choke points" first, and in general (i.e. when solving problems of any kind, regardless of how you feel about the studios' motives ion solving this particular "problem"), it can be a perfectly appropriate, effective strategy.
Techies often have a bad habit of adopting a sort of slippery-slope, sky-is-falling, all-or-nothing approach to problem solving (especially if it's a problem they don't really want to solve). "This proposed solution has a hole in it and is not guaranteed to be 100% effective, therefore it is no solution at all and is foolish to pursue." Not necessarily true. You don't always need to find a perfect solution; sometimes a 90% solution is good enough, especially if the alternative is sitting on your hands doing nothing wishing you had a 100% perfect solution.
(Off-topic, but to rescue my karma before I'm accused of siding with the studios here: the same thought processcan act in all sorts of other situations, not just copy protection. For example, if you suggest that a great way of reducing the threat of e-mail vuruses would be to redesign mail clients so that they don't make it easy to click on executable attachments and run them, while still allowing users to click on data attachments and view them, you'll receive all sorts of "objections" from techies who think they know better, pointing out that your solution "won't work" because of the possibility of e.g. JPEG and Word viruses.)
> If you can get your eyes and ears on the unencrypted signals, then you can always get your hands on them.
I said "bits", not signals.
>> The only way to rip audio would be to re-digitize the audio output from your speakers
> But once you did successfully redigitise it, that copy -- and every copy you made from it -- would be unprotected, and further copying would not incur any loss of quality.
Sure, but -- rightly or wrongly -- the music industry is much, much more worried about verbatim original digital copies than they are about analog copies. (And, let's face it, people who copy music prefer verbatim original digital copies, too, if only for the convenience.)
>> The only way to rip video would be to aim a camera at the screen.
> Or to use the "fake CRT" device I have described before, which connects to an existing monitor in place of the real CRT...
There was a story recently -- I don't remember where, perhaps slashdot -- about an amendment to one of the new HDTV or DVI standards which was designed to prohibit exactly this. I think it involved a cryptographic exchange between the video card and the HD monitor, such that the video card could, should, and would refuse to emit video signals encoding protected content if an approved monitor was not connected. (And before you suggest it: the same amendment specified that the new connector had to be tamper-resistant, too.)
> LCDs ought to be even easier to deal with, since the signal is sent pixel-by-pixel;
Actually, as I understand it, the signal to an LCD monitor involves exactly the same kind of back-and-forth scan as to a conventional CRT.
>> The only way to evade these "impossibilities" ... would involve electron microscopes and micromachining techniques.
> Again, once it was done, it would be done for all time; instantly rendering every penny ever spent on the project a penny wasted.
That's not clear. You might have broken your computer for all time (though even that's not clear), but that doesn't mean you'd have broken everyone else's for them.
At any rate, it's clear that none of this stuff will deter serious pirates, nor is it clear that it's even the intent. Massive for-profit counterfeiters can be gone after with conventional legal techniques, and it would be sure be nice if the movie and record industries would concentrate their efforts there instead of pursuing all these invasive technological approaches against the rest of us.
What they're worried about, though, is indeed the individual. For any single, identifiable "choke point", such as a major counterfeiter or a major filesharing hub, the copyright holders have lots of tools they can use. What they don't want is for every Ma and Pa Kettle to be able to be a pure-digital filesharer; they'd really rather not haul every Tom, Dick, and Harry who ever shares a file into court; they've done that (I assume) only as a last resort.
Don't get me wrong; I'm not trying to defend the media companies in any of this, and I agree that copying in some form will always be possible. But if the TCPA or something like it goes through, it will make casual copying much more difficult, and what's worse, it is also likely to make all sorts of other casual activities -- activities that aren't by any stretch of the imagination illegal and shouln't be restricted -- much more difficult, too.
I personnaly uninstalled Norton Security from my computer as it's now clear that they can not protect me from emerging threats.
Indeed. Bruce Schneier discussed this very question in a Wired News article, also discussed on slashdot, also discussed on Schneier's weblog.
The answer, I think, as to why the security companies fell down so unanimously on this one is that they're all afraid of the DMCA. So we have yet another crystal-clear example of the DMCA's overly far reach and unintended consequences: it legitimizes malware, as long as the malware takes the form of "copy protection".
Precisely.
A question I'd love to ask the record industry (slashdot interview, anyone? :-) )
would be:
"Would you rather sell X million CDs per year with a 0% piracy rate,
or 2X million with a 30% piracy rate?"
(They still wouldn't "get it", of course, but it'd be fun to ask.)
Well, yes, but it's practically possible. It's very, very hard, but it's being worked on.
With a complete TCPA/Palladium deployment of the kind Microsoft and the big media companies are dreaming about, it would be possible to come out with new CD and DVD formats which were encrypted in such a way that only your computer could decrypt them, and then only to play audio waveforms through your speakers or show images on your screen. It would be impossible for you to get your hands on the unencrypted bits. It would be impossible for you to write code to do your own decryption of the media. The only way to rip audio would be to re-digitize the audio output from your speakers, and that'd be a lower-quality, non-bitwise copy. The only way to rip video would be to aim a camera at the screen. The only way to evade these "impossibilities" -- to get at the bits, or obtain the keys you'd need to perform your own decryption -- would involve electron microscopes and micromachining techniques. You'd have to disassemble and probe the TCPA chip on your motherboard which enables all this -- and it would be explicitly designed to make such disassembly very, very difficult.
Buncha people said this already, but: they'll become mainstream when they're not burdened down by cumbersome features that nobody wants, chief among them being oppressive DRM. Cory Doctorow's got some very nice words on the general subject of unwanted features in section 5 of the talk he gave at Microsoft, and he talks about e-books specifically in section 4: "The hardware-dependent ebooks, the DRM use-and-copy-restricted ebooks, they're cratering. Sales measured in the tens, sometimes the hundreds. ...when you're selling copies by the ten, that's not even a business, it's a hobby."
Everybody says it, what Marcus is saying is that we should actually do it. It is possible, you know. The first step is to drop your tragic preconception that all these problems are inevitable, that there's nothing we can do about them. People like Marcus Ranum can tell you what to do about them -- if you'll only listen.
In fact, I can tell you, too. Here are two philosophies:
- Bugs are inevitable. You find 'em, you fix 'em, life goes
on; anyone who tells you it's possible to write bug-free code is
a dreamy ivory-tower idealist.
- Bugs need not be inevitable, and can be reduced to acceptably
low levels (and the effects of the remaining ones mitigated) if
we're scientific about it.
I'm here to argue for #2.Like any scientific process, the key to actually reducing bugs is to do some measurement. (It doesn't have to be formal.) If, over time, your bug counts go down, if the new strategies you adopt in response to the bugs you had yesterday keep you from having as many bugs tomorrow, you're doing something right. But if you keep having bugs, despite claiming that you're trying to learn from them and trying to be more careful, you're still doing something wrong. In particular, simply trying to "be more careful" doesn't always work. There are some mistakes you can train yourself not to make, but there are some that are inevitable, meaning that sometimes you have to adopt a significantly different methodology where that particular too-easy-to-make mistake simply doesn't have a chance to happen.
But, at the same time, yes, you have to admit that some bugs will still slip through. So you also have to think about, and spend time actually implementing, strategies to limit the damage caused by any remaining bugs in production code.
For some reason, people who dismiss the notion of "writing code without bugs and holes" also dismiss the notion of trying to limit the damage caused by those bugs and holes. It's as if they imagine that bugs are inevitable in newly-written code, but that they can somehow all be eradicated from shipped, production code. (Or perhaps they're resigned to the fact that production code will always be full of bugs, too, and that users will just have to live with them. How sad. Good thing the engineers who design buildings and bridges and airplanes don't have the same attitude.)
Not sure what you're saying.
If the attachment is a data attachment (text, document, spreadsheet, image, audio, video, whatever), the recipient clicks on it and it opens, using the appropriate viewing app (an app which, of course, was already installed on the machine and is presumably trusted.) But if the attachment is an executable, when the recipient clicks on it either nothing happens, or a dialog offers to save it to disk, but the point is that it is dignificantly difficult (if not impossible) to just go and run that attachment.
But you're hip-deep in the mud.
One of the points basically comes down to "write perfect code".
Nowhere does he say that; what he's saying is that we should try -- try! -- to do better. In fact, one of the things people who take security seriously realize is that their code will not be perfect -- and then figure out ways to limit the damage.
Well, duh, why didn't I think of that before?
The "duh" is on you, I think. You, like most of the software industry, regard bugs and rampantly imperfect code as inevitable, and you pooh-pooh anyone who dares to suggest that we could do better. You refuse to take seriously models other than "default permit" and "reflexively patch", models which guarantee an escalating arms race and a neverending stream of vulnerabilities and an epidemic of real, actual, time-wasting and money-costing and data-losing security problems.
I can't say that you're wrong, because so much of the industry agrees with you, which is why computer security is the horrible mess it is. But it doesn't have to be that way.
That's a biggie, but I think it's one of the two biggest problems. The other is that, by default, it is maximally easy to run (at all, as any user) even the most breathtakingly untrustworthy code, i.e. that which arrives as an e-mail attachment from a unknowable source. There have been various attempts to patch this, but the main line of defense still seems to be that the poor user is ultimately responsible for deciding which attachments are safe to open and which are not -- and this has been more than amply shown to just plain not work.
If the one-click-to-open-an-attachment model did not mean, for an executable attachment, to execute the attachment, email viruses would be a minor problem, not a sweeping epidemic. (Realistically: how often does anyone receive a legitimate executable program in the mail and expect to be able to run it right out of their mailbox?)
These are all very, very, very good points:
It is possible to write secure software...
...design your system from the outset to contain the damage...
...most pointy-haired bosses... want to... solve the immediate problem... in the least amount of time...
If you approach a programming project with the attitude that you and your programmers are fallable...
Programmers...have a natural tendancy to assume that their code will work perfectly...
It takes discipline to consistantly design systems that will compensate...
Unfortunately, most managers tend to encourage programmers' optimisim...
If more programmers, and programming managers, really understood and valued these points, the software world would be a much, much different place.
It doesn't, but this case -- like most of "modern" computing -- has nothing to do with plain text.
For the vast majority of computer users today, "plain text" is as foreign and obsolete a concept as a buggy whip. There is no such thing as "pure information" encoded by open, lowest-common-denominator means. Everything is a "document" in a "format" that you have to "open" by "clicking" on it. Furthermore, since clicking is also how you chase links and run programs, users who are accustomed to doing nothing as they interact with their computers but click on things all day are infinitely vulnerable -- and always will be -- to every sort of e-mail virus and phishing scam and e-card swindle.
Actually, the submitter probably didn't. Those links aren't in the actual article; they're glommed on after the fact by vibrantmedia's "intellitxt", which flexbeta.net has evidently installed. Turn off JavaScript, and those links go away.
Watch out who you callin "we", white man!