I cannot support anti-piracy controls that require use inside consumers homes.
DRM == Perpetual Motion Machines.
However, using some basic link-analysis to go after "well connected" nodes (in this case, the suppliers of the source) is much more intelligent and effective.
OK, MPAA. You can call it quits with anti-piracy DVD nonsense. You finally found a method that works. Leave John Q. Consumer alone.
Yes, if you did something stupid and your source code was available to the world, it could take less labor to discover your stupidity than if your source was closed.
OTOH, having source available for competent reviewers does increase the likelihood that your stupidity will get caught before it goes to market or, hopefully, shortly thereafter.
But that's just it: having the source available to competent reviewers. It has NOTHING to do with whether the source is open to everyone or not.
Open source != Better Security
Closed source != Better Security
This is as stupid as the ID vs Evolution argument. These are NOT mutually exclusive points. There are many open source projects that have sucky security because they don't have competent security analysis done by competent security analysts. Likewise, there are closed source products that have decent security because they invited competent security analysts to review the code. It's not whether your code is open/closed, it's all about who is reviewing your code.
Do you need an example? Try the NSA. They have code whose source is closed to the world, but is reviewed by competent analysts.
Nanny, nanny, boo-boo... My OS is better than yours. Oh wait, that's also the same stupid argument. Market-share, value of the information assets, etc., all play a role. Ask me for my opinion and I'll tell you they all suck, regardless of whether they're open or not. Why? Because the fundamental building blocks we're still depending upon are not reliable, e.g. ARP, DNS, DMA (where your USB thumb drive's driver can overwrite kernel code in memory thanks to DMA), etc.
--
The unfortunate reality is that it's seldom the best technology that is adopted, just the technology that is in the right place at the right time.
After all, haven't they gone through a couple world wars, plus smaller wars and disputes with only a "We're neutral, but if you give your money to our banks, we'll keep it safe" philosophy? This doesn't seem to fit that mindset at all.
For certain, I was aware of that limitation. From the beginning of my post, you can see I was aimed at an "org", meaning an enterprise, where (hopefully) there is a person who knows enough about what should and should not be run in their environment.
I have some ideas up my sleeve about how individuals might solve that problem...
How'd you want to create the "perfect" AV product?
Well, for starters, let's limit the attack surface significantly by blocking all executable code that is not on the guestlist (think "whitelist" or "default deny"). We'll certify apps we want on our systems and block everything else. That's the only way we can effectively eliminate all of the grayware and stop today's typical new virus variant (which, although not technically a zero-day, is similar in nature to the sysadmins since the AV signatures have to play catch up). An interesting by-product is increased adherence to strict change control practices. [Does the rate of new application adoption in your org have a curve like this?]
Second, let's have an OS that can separate data objects from executable objects in memory, thus preventing code insertion (buffer overruns). Not an optional kernel memory management function (nX), but a true requirement for all applications compiled to run on the platform.
Third, let's leave users in least privilege mode, so system-level malware is not possible. Again, the interesting by-product is better change control.
Fourth, let's use mandatory integrity levels (or something similar) to ensure that one application does not automatically affect other user-level data. This will prevent the threats that will happen as soon as the other 99% of sysadmins figure out the least privilege concept for their users-- malware will turn to exploiting userland processes and data.
Fifth, let's have applications (i.e. browsers) that follow the same principles the OS does and separate dynamic code objects from data objects as well as not allowing executable code from source A to run as if from source B (think XSS). While we're at it, make sure the applications are designed to not confuse data objects as executable code (think input sanitization).
Sixth, let's make sure the whole process from hardware init to boot up to userland apps is trustworthy. That probably means something along the lines of TPMs, and nixing the possibility of device drivers overwriting memory via DMA (think IOMMU or similar). [Why hasn't it been seen as a bad thing that your USB keyboard driver, regardless of whether it runs in kernel space, can overwrite kernel memory via DMA?]
Where does that leave us? Oh yeah... that combination does not exist on any platform yet!!! My thought on the religious wars debate (which inevitably pops up whenever the topic of malware comes up): they all suck! Maybe MINIX with IOMMU has a chance (also not available today).
Riiiight.
Because the old strategy of "throwing a dog a bone" doesn't apply to politics??? I think that mass-conspiracies are just as unlikely as the next guy (and I'm willing to agree that this doesn't look well for the Gov't), but how does one logically get from Step 1 "they're out to get me" to Step 2 "they're bumbling idiots that cannot do anything right". Ever stop to think that maybe they wanted that number leaked?
You'd be surprised how many of these devices are now coming out of the box with a "run me first" CD which auto-configures laptops & APs to talk at least WPA.
But the question I have is... Why aren't these APs/Wireless Routers coming with a built-in RADIUS server so that authentication can be stronger and more convenient than some random password/key. I bet everybody would like to be able to set up user accounts on their APs for friends/family, etc.
you need a language that is restrictive enough that you can actually run multiple, untrusted programs in the same address space
Trust is an action. By executing a program at all, you are trusting that program. I don't mean to be a stickler here, but this is a HUGE distinction that most everyone I know or have met confuses.
Trustworthy is an adjective, meaning that the trust placed on an object is valid.
Perhaps a better way of saying what you said:
... you need a language that is restrictive enough that you can actually run multiple, less trustworthy programs in the same address space...
See the difference? Millions of people trust untrusworthy code every day.
Yes, and don't forget that there is always the chance that some creative person might come up with alternative ways to generate the answers to CAPTCHAs... like serving porn on another site to people who can answer the CAPTCHA. It doesn't matter if the people are wrong or right, with enough traffic, you can automate correct answers and get your SPAM through, etc.
The primary mode of failure for laptops in this environment is hard drive failure since hard drives rely upon the viscosity of air to provide lubrication and damping among the moving parts
He should have sprung for one of the new flash memory drives. What's a couple hundred bucks when you're on top of the world?
At least get the analogies right. DRM and speeding tickets are opposites.
Speedings tickets does not prevent you from going as fast as you like. Though they may make you choose not to, as you'll hopefully get caught and punished for breaking the law.
Wrong. I said what I meant.
DRM is a perpetual motion device for the InfoSec world. It goes against the natural laws of security to say on one hand that Alice gives Bob some resource (at a distance, mind you) and then comes back to say, "oh yeah, you can't have that anymore" or "you're not supposed to use it do that with it".
If Apple continues with DRM in iTunes (which looks like won't be the case, but I digress), then we will have more of the last few years.... People buy music. And since iTunes gives those people access to the music in some form, somebody will figure out how to get just the music out and then create a tool so everyone's grandma can do it. Apple will figure out how they were beaten, and issue try #2, which will get broken, and so on. If you don't understand that DRM is nothing short of an arms race, you probably have no business posting on Slashdot.
Tell me how that's different than speeding tickets. Law enforcement is trying to control people at a distance. [If they were attempting control at close proximity, then there'd be cops driving everybody's cars around.] Fifty years ago, people would just get pulled over for "reckless driving", then it got more sophisticated, and now it's common practice that if you just speed 5-10 mph over on highways and major roads it's OK, except watch out for [insert place here] because the cops will pull you over at 1 mph over, or watch out in school zones, construction zones, etc.
Then entered radar detectors and the cops switched radar bands. Then came dual band radar detectors and the cops got laser speed guns, and then laser detectors are supposedly available. And then there's the obligatory flashing lights of an oncoming car telling opposing traffic to watch out for speed traps (those are the "information must be free" people in the analogy). And then the radar-gunners who radio ahead to other cops, the air-detection, etc., etc., etc.
DRM ettempts to make it impossible to break the law in the first place.
Speeding tickets attempt the same thing. The only way it could work with a very good approximation to 100% control at a distance would be to have significant surveillance (think sensor networks). And then that brings in everybody's favorite topic of discussion: privacy. Same thing for DRM. It would work if the "enforcers" (RIAA/MPAA, etc.) could surveil John Q. Public's computers, but that whole privacy thing gets in the way.
At the core, DRM & Speeding Tickets are the exact same problem.
"But wait!" you say. "Speeding tickets don't look like they're going anywhere-- that means your analogy sucks." Well, on that note, Speeding Tickets could learn from Steve Jobs new biz model for iTunes. Charge more ($1.29 for $.99) for DRM-free music. And if pirates start mass-distributing the music, we'll find you and litigate you out of existence. Law enforcement could track down the significant offenders as well. For example, "Sir, from our auto-accident forensic analsysts' report, you were travelling 120 mph when you wrecked into the side of that school bus, therefore we're trying you in court for a new type of felony manslaughter that carries with it a sentence between life in prison and the death penalty". IANAL, but you get the idea.
Won't this money-hungry company have to prove intricate knowledge of HOW to solve the security vulnerability? How can you do that effectively with (presumably) closed-source targets? It seems like this is a large task to take on: beating the vendors to the fixes to their security holes.
Now, in the case of holes in open source systems, they may be able to pull off staying ahead of the developers, but c'mon, it's open source-- how can they possibly expect to force people to pay up for patching open source?!?
And won't this put a whole new slant on the bounties for zero-day security holes? Imagine, if patents could force these vulnerable vendors to pay these pirates big dollars for patent compliance just to patch their software, there will suddenly be a HUGE black market for zero-day sploits. That's the last thing the world needs.
DRM is like Speeding Tickets. You can slow some people for awhile, but not forever. You can even get extra money out of them if they break the rules, but they'll view that as a small price to pay for doing what they want. You cause most good and safe people to slow down who could otherwise enjoy going faster and doing more.
But, in the end, everyone will see it for the profiteering racket that it really is.
It's stories like this and the FISMA scores that pushes me to contend that the Financial Vertical is still on top of the security pyramid. It mostly has to do with being able to quantify and measure risk.
"To measure is to know."
"If you can not measure it, you can not improve it."
Of course it's not intentional. However, this is completely avoidable.
This is evidence that it's time to wave goodbye to signature based anti-virus methods. If we had anti-malware techniques that actually weren't anti-malware, but actually pro-goodware (bonware?), we would never have this problem. Essentially, in a production environment, we want to split all executable code into two categories: 1) Certifed, and 2) Non-certified. If we had tools that would only allow certified code to execute, who cares about AV (or anti-spyware, anti-ransomware, anti-bloatware, anti-threat-du-jour-ware)?
This is starting to get insane. Look at F-Secure's latest rate of malware growth. The amount of bad software (non-Certified for the sake of consistency above) compared to good software is unreal. Essentially anti-virus software is the process of outsourcing the software inventory of one's environment for the purpose of determining trustworthiness, only we require our outsourcers (the AV vendors) to work backwards (defining bad, not good) and blind (guessing at what software lives on our systems). With this premise, it's no wonder these mistakes happen. AV Vendors, by their signature-nature, are forced to implement significant changes to our systems several times per day to maintain effectiveness. And when any changes on this level occur at this frequency, there are bound to be quality assurance issues like overlooking critical system files from alternate languages during the testing phases.
Slashdot Mirror
I cannot support anti-piracy controls that require use inside consumers homes.
DRM == Perpetual Motion Machines.
However, using some basic link-analysis to go after "well connected" nodes (in this case, the suppliers of the source) is much more intelligent and effective.
OK, MPAA. You can call it quits with anti-piracy DVD nonsense. You finally found a method that works. Leave John Q. Consumer alone.
... then Bill Gates will have to admit they're competitors!
Yes, if you did something stupid and your source code was available to the world, it could take less labor to discover your stupidity than if your source was closed.
... My OS is better than yours. Oh wait, that's also the same stupid argument. Market-share, value of the information assets, etc., all play a role. Ask me for my opinion and I'll tell you they all suck, regardless of whether they're open or not. Why? Because the fundamental building blocks we're still depending upon are not reliable, e.g. ARP, DNS, DMA (where your USB thumb drive's driver can overwrite kernel code in memory thanks to DMA), etc.
OTOH, having source available for competent reviewers does increase the likelihood that your stupidity will get caught before it goes to market or, hopefully, shortly thereafter.
But that's just it: having the source available to competent reviewers. It has NOTHING to do with whether the source is open to everyone or not.
Open source != Better Security
Closed source != Better Security
This is as stupid as the ID vs Evolution argument. These are NOT mutually exclusive points. There are many open source projects that have sucky security because they don't have competent security analysis done by competent security analysts. Likewise, there are closed source products that have decent security because they invited competent security analysts to review the code. It's not whether your code is open/closed, it's all about who is reviewing your code.
Do you need an example? Try the NSA. They have code whose source is closed to the world, but is reviewed by competent analysts.
Nanny, nanny, boo-boo
--
The unfortunate reality is that it's seldom the best technology that is adopted, just the technology that is in the right place at the right time.
After all, haven't they gone through a couple world wars, plus smaller wars and disputes with only a "We're neutral, but if you give your money to our banks, we'll keep it safe" philosophy? This doesn't seem to fit that mindset at all.
For certain, I was aware of that limitation. From the beginning of my post, you can see I was aimed at an "org", meaning an enterprise, where (hopefully) there is a person who knows enough about what should and should not be run in their environment.
...
I have some ideas up my sleeve about how individuals might solve that problem
Well, for starters, let's limit the attack surface significantly by blocking all executable code that is not on the guestlist (think "whitelist" or "default deny"). We'll certify apps we want on our systems and block everything else. That's the only way we can effectively eliminate all of the grayware and stop today's typical new virus variant (which, although not technically a zero-day, is similar in nature to the sysadmins since the AV signatures have to play catch up). An interesting by-product is increased adherence to strict change control practices. [Does the rate of new application adoption in your org have a curve like this?]
Second, let's have an OS that can separate data objects from executable objects in memory, thus preventing code insertion (buffer overruns). Not an optional kernel memory management function (nX), but a true requirement for all applications compiled to run on the platform.
Third, let's leave users in least privilege mode, so system-level malware is not possible. Again, the interesting by-product is better change control.
Fourth, let's use mandatory integrity levels (or something similar) to ensure that one application does not automatically affect other user-level data. This will prevent the threats that will happen as soon as the other 99% of sysadmins figure out the least privilege concept for their users-- malware will turn to exploiting userland processes and data.
Fifth, let's have applications (i.e. browsers) that follow the same principles the OS does and separate dynamic code objects from data objects as well as not allowing executable code from source A to run as if from source B (think XSS). While we're at it, make sure the applications are designed to not confuse data objects as executable code (think input sanitization).
Sixth, let's make sure the whole process from hardware init to boot up to userland apps is trustworthy. That probably means something along the lines of TPMs, and nixing the possibility of device drivers overwriting memory via DMA (think IOMMU or similar). [Why hasn't it been seen as a bad thing that your USB keyboard driver, regardless of whether it runs in kernel space, can overwrite kernel memory via DMA?]
Where does that leave us? Oh yeah
Riiiight.
Because the old strategy of "throwing a dog a bone" doesn't apply to politics??? I think that mass-conspiracies are just as unlikely as the next guy (and I'm willing to agree that this doesn't look well for the Gov't), but how does one logically get from Step 1 "they're out to get me" to Step 2 "they're bumbling idiots that cannot do anything right". Ever stop to think that maybe they wanted that number leaked?
Riiiiight.
Because the "WAP is open" defense works so well.
You'd be surprised how many of these devices are now coming out of the box with a "run me first" CD which auto-configures laptops & APs to talk at least WPA.
... Why aren't these APs/Wireless Routers coming with a built-in RADIUS server so that authentication can be stronger and more convenient than some random password/key. I bet everybody would like to be able to set up user accounts on their APs for friends/family, etc.
But the question I have is
Trustworthy is an adjective, meaning that the trust placed on an object is valid.
Perhaps a better way of saying what you said:
See the difference? Millions of people trust untrusworthy code every day.
Yes, and don't forget that there is always the chance that some creative person might come up with alternative ways to generate the answers to CAPTCHAs ... like serving porn on another site to people who can answer the CAPTCHA. It doesn't matter if the people are wrong or right, with enough traffic, you can automate correct answers and get your SPAM through, etc.
He should have sprung for one of the new flash memory drives. What's a couple hundred bucks when you're on top of the world?
Wrong. I said what I meant.
DRM is a perpetual motion device for the InfoSec world. It goes against the natural laws of security to say on one hand that Alice gives Bob some resource (at a distance, mind you) and then comes back to say, "oh yeah, you can't have that anymore" or "you're not supposed to use it do that with it".
If Apple continues with DRM in iTunes (which looks like won't be the case, but I digress), then we will have more of the last few years
Tell me how that's different than speeding tickets. Law enforcement is trying to control people at a distance. [If they were attempting control at close proximity, then there'd be cops driving everybody's cars around.] Fifty years ago, people would just get pulled over for "reckless driving", then it got more sophisticated, and now it's common practice that if you just speed 5-10 mph over on highways and major roads it's OK, except watch out for [insert place here] because the cops will pull you over at 1 mph over, or watch out in school zones, construction zones, etc.
Then entered radar detectors and the cops switched radar bands. Then came dual band radar detectors and the cops got laser speed guns, and then laser detectors are supposedly available. And then there's the obligatory flashing lights of an oncoming car telling opposing traffic to watch out for speed traps (those are the "information must be free" people in the analogy). And then the radar-gunners who radio ahead to other cops, the air-detection, etc., etc., etc.
Speeding tickets attempt the same thing. The only way it could work with a very good approximation to 100% control at a distance would be to have significant surveillance (think sensor networks). And then that brings in everybody's favorite topic of discussion: privacy. Same thing for DRM. It would work if the "enforcers" (RIAA/MPAA, etc.) could surveil John Q. Public's computers, but that whole privacy thing gets in the way.
At the core, DRM & Speeding Tickets are the exact same problem.
"But wait!" you say. "Speeding tickets don't look like they're going anywhere-- that means your analogy sucks." Well, on that note, Speeding Tickets could learn from Steve Jobs new biz model for iTunes. Charge more ($1.29 for $.99) for DRM-free music. And if pirates start mass-distributing the music, we'll find you and litigate you out of existence. Law enforcement could track down the significant offenders as well. For example, "Sir, from our auto-accident forensic analsysts' report, you were travelling 120 mph when you wrecked into the side of that school bus, therefore we're trying you in court for a new type of felony manslaughter that carries with it a sentence between life in prison and the death penalty". IANAL, but you get the idea.
Won't this money-hungry company have to prove intricate knowledge of HOW to solve the security vulnerability? How can you do that effectively with (presumably) closed-source targets? It seems like this is a large task to take on: beating the vendors to the fixes to their security holes.
Now, in the case of holes in open source systems, they may be able to pull off staying ahead of the developers, but c'mon, it's open source-- how can they possibly expect to force people to pay up for patching open source?!?
And won't this put a whole new slant on the bounties for zero-day security holes? Imagine, if patents could force these vulnerable vendors to pay these pirates big dollars for patent compliance just to patch their software, there will suddenly be a HUGE black market for zero-day sploits. That's the last thing the world needs.
DRM is like Speeding Tickets. You can slow some people for awhile, but not forever. You can even get extra money out of them if they break the rules, but they'll view that as a small price to pay for doing what they want. You cause most good and safe people to slow down who could otherwise enjoy going faster and doing more.
But, in the end, everyone will see it for the profiteering racket that it really is.
Time to defrag
It's stories like this and the FISMA scores that pushes me to contend that the Financial Vertical is still on top of the security pyramid. It mostly has to do with being able to quantify and measure risk.
"To measure is to know."
"If you can not measure it, you can not improve it."
-Lord Kelvin
Sounds like it's time to switch to Gmail. ;)
Of course it's not intentional. However, this is completely avoidable.
This is evidence that it's time to wave goodbye to signature based anti-virus methods. If we had anti-malware techniques that actually weren't anti-malware, but actually pro-goodware (bonware?), we would never have this problem. Essentially, in a production environment, we want to split all executable code into two categories: 1) Certifed, and 2) Non-certified. If we had tools that would only allow certified code to execute, who cares about AV (or anti-spyware, anti-ransomware, anti-bloatware, anti-threat-du-jour-ware)?
This is starting to get insane. Look at F-Secure's latest rate of malware growth. The amount of bad software (non-Certified for the sake of consistency above) compared to good software is unreal. Essentially anti-virus software is the process of outsourcing the software inventory of one's environment for the purpose of determining trustworthiness, only we require our outsourcers (the AV vendors) to work backwards (defining bad, not good) and blind (guessing at what software lives on our systems). With this premise, it's no wonder these mistakes happen. AV Vendors, by their signature-nature, are forced to implement significant changes to our systems several times per day to maintain effectiveness. And when any changes on this level occur at this frequency, there are bound to be quality assurance issues like overlooking critical system files from alternate languages during the testing phases.