Their only alternative will be to not buy the films, shows, and music they want, and I don't see DRM becoming so restrictive that people will go to that extreme. Macrovision has circumvented our legal right to back up our physical property for well over a twenty years now, and there hasn't been a backlash.
Ah, then this is where our expectations differ. I can see DRM becoming so annoying that there is a massive consumer backlash.
Macrovision is mostly irrelevant, because few people try to back up their stuff anyway. OTOH, the average lifespan for a home computer is probably under five years, and I'm guessing most portable MP3 players and the like don't last that long before breaking. In a couple of years, the generation that bought lots of legal downloads recently will want to transfer them to a new toy. If they're told, "Sorry, you can't, your whole music collection is going to die with your iPod," then there are going to be a lot of very upset people around.
Likewise, if people who just spent four-figure sums on big, flashy HDTVs a couple of years ago go and buy new HD-DVD or Blu-Ray discs and then find that they're stuck with upsampled low-res displays because they don't have HDCP, there are going to be a lot of very upset people around.
The difference between this sort of thing and the crude "copy protection" technologies that have gone before is that the new generation of DRM will actively get in the way of things that typical users really want to do. Worse, it will do it only to users who are good customers, buying content from legal sources, while it will do jack to people who rip it - and someone, somewhere will always rip anything that's any good, and that rip will always be playable on systems that don't play ball with media megacorp DRM initiatives.
If this isn't a recipe for a serious consumer backlash, then I don't know what is, and I reckon this one will probably be accompanied by plenty of antitrust suits in the US, deceptive marketing claims in Europe, etc. It's just a matter of how long it takes before DRM stops inconveniencing a fairly small and mostly silent minority (Macrovision) and goes mainstream (HDCP, legal music downloads, etc.).
Why wouldn't those people just use different software on the same platform... or even different media formats on the same software?
Because the trend in DRM is necessarily towards incorporating it at a lower level than application software. See "Trusted Computing", et al.
If your operating system is based on a DRM-friendly core, it can restrict the device drivers it uses (for your protection, you understand) to those that work only with DRM-friendly hardware. Thus even if you run an application that doesn't care for DRM, it becomes awkward to get any non-DRM'd content to that application in the first place.
Temporarily, perhaps, but there is little honour amongst thieves. Sooner or later, a major player will realise that by offering products without DRM in a world that usually demands it, they can gain a competitive advantage in the marketplace. Others will then have to follow to compete, and DRM will become a direct danger to the corporate bottom line. Ask Sony.;-)
Then the public has no open market recourse, and government intervention is required.
And this is also possible, depending on how bad things get. Ultimately, campaign contributions don't vote, and the people do. Big business can always gain a certain amount of political force through bribery and corruption, but any administration that fails to address a problem that's seriously annoying a significant number of voters is unlikely to remain in power for very long.
As I implied before, it's unrealistic to expect either market forces or government intervention to fix the problems overnight. I have sometimes argued that we should encourage the media megacorps to employ the most restrictive possible form of DRM they can find, on the simple basis that the sooner the voting/buying public gets seriously annoyed, the sooner this sort of thing will go away.
You're damn right they are, and their choice was not an accident.
As I said, big business has rarely succeeded in holding the public hostage for very long, and the fastest way to debunk this sort of issue is to talk straight about it.
Ask not for the future of Linux without DRM, but for the future of DRM without Linux (or other free OSes, for that matter).
If DRM becomes as oppressive as the big media players seem to want it to be, then it will drive people away from platforms requiring it and towards platforms that circumvent it. Moreover, there are enough such people that attempting to legislate such platforms out of existence is unlikely to meet with success, at least not for very long.
History furnishes few examples of big business successfully forcing the people to accept something not in their interests for extended periods. Once the public get wise to something, it will stop.
I take your point, but I don't think it's fair to equate the risks.
Programmers can, and often do, forget to use non-automated tools like using or finally. Moreover, it is rare to find code analysis tools that are smart enough to detect this in routine use.
In contrast, if the default way to use your resources is via a class supporting RAII, as is commonplace in C++ both in the standard library and in numerous other high quality libraries from other sources, then it's actually anti-idiomatic to make the mistake. There are also idioms that library designers can employ to make sure you don't accidentally allocate an object dynamically, if they wish to do so. Even if you can and do make the mistake, it's easy to look for all uses of new, and check that they're all safe, as a semi-automatic QA mechanism to enforce coding standards.
Bottom line, how often have you really seen someone (a) manage to write
ifstream *is = new ifstream("file.txt");
(b) then fail to ensure proper destruction of the stream object and closure of the file, and (c) not had this noticed during code review or other QA processes? Personally, I've never seen that, but I've surely seen a few dangling resources in languages that use the less automatic idioms.
I'm not saying the RAII mechanism is a silver bullet, I'm just saying it's objectively and measurably better. So it may be with any language feature that removes or actively discourages a certain type of programmer error, hence the link to the DbC features of Eiffel.
You can easily write and consistently call a routine to cleanup after yourself whether or not a particular routine fails.
Easily write? Sure.
Consistently call? There's a whole programming world of evidence to suggest not, which is a big part of the reason the RAII idiom evolved in the first place.
Interesting page, but AFAICT "programming language hype index" would be a fairer characterisation of the information. It's based on the number of hits returned by popular search engines, rather than any objective metric to do with number of programmers currently using the language, rate at which new code is currently being written in the language, or similar.
Re:Eiffel Contracts are syntactic sugar
on
EiffelStudio Goes Open
·
· Score: 2, Insightful
You can acquire and release resources in many languages, too, but using the RIAA idiom in C++ you never forget the latter, while in languages that rely on finally or Dispose or whatever, you can.
I understand about making source code available helps in a secure system, but what if that code has evil code...made to look innocent upon inspection....written into it?
The "many eyes" theory can only work in practice if there are indeed many eyes reviewing the source code and those eyes can see any problems. That doesn't just mean accidental bugs, or portability/future-proofing concerns, or a poor choice of data structures and algorithms leading to a performance hit. It also means spotting the devious and subtle attacks.
Just imagine what would happen if a major OSS project like Apache or Linux accepted a "useful" patch that contained a backdoor that wasn't identified, and this then got distributed worldwide. A significant number of people believe, erroneously, that using OSS inherently makes them safer because of the many eyes theory. These people will happily download and build the updated code, or install prebuilt binaries with correct checksums, completely oblivious to the fact that they just stuck a major security hole in their system.
Thus it's important for those who review submissions to software development projects - OSS, commercial or otherwise - to be very aware of these possibilities, and likewise for anyone else who contributes to them so they can spot a problem if they come across it.
Not really. They're both sans-serif fonts with similar characteristics and overall appearance, but any trained typographer could tell you several differences between them.
<doubleplusgeek> In general, Helvetica is squarer at the ends of its lines: look at glyphs like 't', 'f', 'r', 'j', 'c', 's', 'Q' and '&'. It's also rounder in general: 'o' is almost circular, unlike Arial, and this also shows up in things like the '%' glyph. Finally, Helvetica has completely different designs for a small number of common glyphs, particularly 'a', 'R', 'G' and some of the digits.
You might just as well say that Verdana is the same as Arial, even though it's got a proportionately larger x-height, extends the lines on glyphs like 't', 'r', 'f' and 'Q', opens up glyphs like 'c', 'S' and '9', and adds features to glyphs like 'j', 'I', 'J', '1'. To the untrained eye, it's just another sans-serif font, but to many people, such changes make a dramatic difference to (in this case) on-screen readability. </doubleplusgeek>
It's not too difficult to create an encrypted, read-only database that stores a MD5 hash value for every file in the file system. Sweep the filesystem twice daily to detect changes and new files, and make the database writable only after sweeps to commit any updates. [Emphasis added]
That wouldn't exactly be a typical desktop system today, though, would it? As I said originally, you can't trust anything at the level of the compromise or above. Obviously you can run tools on a known good system, or boot from a known good CD, or restore from a database whose security was never compromised.
It seems we do indeed have a miscommunication somewhere, probably because I lazily used dashes to parenthesize. Rephrased, my intended claim is that you can't trust anything that runs at the level of the compromise or above, including any security tools or diagnostic information at those levels.
Even if I had punctuated more formally, I'm not sure I would personally have drawn the inference from my original comment that you did, but I agree that the comment was ambiguous and could be read with either "any" or "all" implicitly added.
In any case, I certainly didn't mean to write your grammatically incorrect alternative proposal, which makes no sense at all!:o)
Worms and other automated tools get a lot of scrutiny and are pretty well understood in terms of what they do to your system. If you keep up with the latest info on a given piece of malware, you know how to remove it.
Sure, but in doing so you're taking a risk that the thing you're removing really is that worm, and not some mutation with some shared symptoms, or potentially even something much nastier that deliberately masquerades as a well-known worm to make you think you're safe. If you're system's been compromised, how do you know you're really dealing with what you think you're dealing with?
Actually, this not completely true. You just run your tools on another machine known to be uncompromised. Also, there are hardware level recovery systems that will restore to a known, clean state.
In other words, you have to rely on systems below the level of the penetration - which, if you look carefully, is exactly what I said.:-)
Arguing that SELinux or OS X won't make a difference, even though both contain functionality designed to do just that, is simply incorrect.
I didn't say they wouldn't make a difference. I did imply that the general principles - the inability to trust anything at or above the level of the compromise, and the fact that doing so is a calculated risk - apply on any system, and I stand by that claim. You're talking about preventing a compromise in the first place, or preventing it from getting as deep within a system, and while these are obviously desirable goals, they don't contradict my point.
It's amazing that when at least half a dozen knowledgable posters have already pointed out the fallacy here, we still find a personal ad for "prompt and professional" repairs that relies on closing the stable door after the horse has bolted.
The professional thing to do would be to explain in simple terms why the system is no longer reliable, help the user to back-up what data they can, help them to clean the system and reinstall everything they need, and then help them to install defensive software to avoid getting hit again. And what's more, if your turnaround time is really 6-12 hours, this approach is probably at least as fast, too.
With anything else, you may think you've fixed the problem, but you'll never know for sure, and the people who later get hit by the DDoS worm you missed won't thank you for it.
You could never recover a compromised system reliably anyway. Once someone's got through your security to a certain level, you can't trust anything - including security tools and diagnostic information - that runs at that level or above. For a typical desktop PC or office server, that basically means you can't trust anything left on the system.
Any sort of virus removal or system clean-up after being cracked is just a calculated risk that the attack will have been completely removed, based on the fact that doing a complete rebuild of a system and restoring all the backed up data is expensive, and while not cleaning up 100% after an attack is potentially more expensive, the probability of this is low.
And no, running Linux or MacOS X instead of Windows doesn't change this, despite the number of people flippantly suggesting these alternatives. I'd have told you this earlier and saved a dozen posts, but apparently it's been 4 minutes since I last successfully posted a comment, so I can't post another one yet...;-)
They created an entire new division that ONLY deals with privacy and security issues, have institued a number of new policies, ALL employess now go through extensive background checks (causing my team to have to turn down a couple of otherwise good applicants due to irregularities that they couldn't explain) and a $10 million fine at the end of last year.
Sure, but were the various security improvements because of bad PR, or because they didn't want another $10M fine?
If the employee opts to not use their work e-mail for anything personal, the company knows that they now have the other added benefit of possible added productivity.
Because we all know that treating staff as machines, and expecting them to work constantly throughout the day without taking the odd couple of minutes as a break now and then or dealing with an important personal matter, is definitely the way to increase productivity, right?:-/
While it is important to offer penalties that are felt by the corporations or businesses, you likewise don't want to punish them so much that they go out of business.
I think you misunderstand me. Consider your example:
If a small company, perhaps 50 people, has a database of even just 50,000 credit card numbers stolen, the fines you suggest could easily ruin the company.
In this case, 50,000 lives have been affected, possibly rather seriously, by the negligence of some or all of those 50 people. If serious damage has been done to all 50,000 then I am entirely in favour of that company of 50 people ceasing to exist.
Believe me, if they are required to publicly disclose all breaches, the impact on their reputation and the cost of publishing the disclosure will be punishment enough.
Sorry, but no, I don't believe that.
There have been several cases in the past, mentioned here and elsewhere, of major leaks of personal data. Can you show me a single example where a leaker has compensated the affected individuals or taken significant steps to prevent a recurrence? Has any such offender suffered any significant damage to their bottom line? Not that I know of, certainly.
If they took reasonable care to encrypt their data effectively then I wouldn't object to that provision. However, if all they have to do is have their database engineers ROT13 all the names, this sounds like the gotcha where the new act actually improves things for businesses, as an earlier poster predicted.
Slashdot Mirror
Ah, then this is where our expectations differ. I can see DRM becoming so annoying that there is a massive consumer backlash.
Macrovision is mostly irrelevant, because few people try to back up their stuff anyway. OTOH, the average lifespan for a home computer is probably under five years, and I'm guessing most portable MP3 players and the like don't last that long before breaking. In a couple of years, the generation that bought lots of legal downloads recently will want to transfer them to a new toy. If they're told, "Sorry, you can't, your whole music collection is going to die with your iPod," then there are going to be a lot of very upset people around.
Likewise, if people who just spent four-figure sums on big, flashy HDTVs a couple of years ago go and buy new HD-DVD or Blu-Ray discs and then find that they're stuck with upsampled low-res displays because they don't have HDCP, there are going to be a lot of very upset people around.
The difference between this sort of thing and the crude "copy protection" technologies that have gone before is that the new generation of DRM will actively get in the way of things that typical users really want to do. Worse, it will do it only to users who are good customers, buying content from legal sources, while it will do jack to people who rip it - and someone, somewhere will always rip anything that's any good, and that rip will always be playable on systems that don't play ball with media megacorp DRM initiatives.
If this isn't a recipe for a serious consumer backlash, then I don't know what is, and I reckon this one will probably be accompanied by plenty of antitrust suits in the US, deceptive marketing claims in Europe, etc. It's just a matter of how long it takes before DRM stops inconveniencing a fairly small and mostly silent minority (Macrovision) and goes mainstream (HDCP, legal music downloads, etc.).
Because the trend in DRM is necessarily towards incorporating it at a lower level than application software. See "Trusted Computing", et al.
If your operating system is based on a DRM-friendly core, it can restrict the device drivers it uses (for your protection, you understand) to those that work only with DRM-friendly hardware. Thus even if you run an application that doesn't care for DRM, it becomes awkward to get any non-DRM'd content to that application in the first place.
Temporarily, perhaps, but there is little honour amongst thieves. Sooner or later, a major player will realise that by offering products without DRM in a world that usually demands it, they can gain a competitive advantage in the marketplace. Others will then have to follow to compete, and DRM will become a direct danger to the corporate bottom line. Ask Sony. ;-)
And this is also possible, depending on how bad things get. Ultimately, campaign contributions don't vote, and the people do. Big business can always gain a certain amount of political force through bribery and corruption, but any administration that fails to address a problem that's seriously annoying a significant number of voters is unlikely to remain in power for very long.
As I implied before, it's unrealistic to expect either market forces or government intervention to fix the problems overnight. I have sometimes argued that we should encourage the media megacorps to employ the most restrictive possible form of DRM they can find, on the simple basis that the sooner the voting/buying public gets seriously annoyed, the sooner this sort of thing will go away.
You're damn right they are, and their choice was not an accident.
As I said, big business has rarely succeeded in holding the public hostage for very long, and the fastest way to debunk this sort of issue is to talk straight about it.
Ask not for the future of Linux without DRM, but for the future of DRM without Linux (or other free OSes, for that matter).
If DRM becomes as oppressive as the big media players seem to want it to be, then it will drive people away from platforms requiring it and towards platforms that circumvent it. Moreover, there are enough such people that attempting to legislate such platforms out of existence is unlikely to meet with success, at least not for very long.
History furnishes few examples of big business successfully forcing the people to accept something not in their interests for extended periods. Once the public get wise to something, it will stop.
I take your point, but I don't think it's fair to equate the risks.
Programmers can, and often do, forget to use non-automated tools like using or finally. Moreover, it is rare to find code analysis tools that are smart enough to detect this in routine use.
In contrast, if the default way to use your resources is via a class supporting RAII, as is commonplace in C++ both in the standard library and in numerous other high quality libraries from other sources, then it's actually anti-idiomatic to make the mistake. There are also idioms that library designers can employ to make sure you don't accidentally allocate an object dynamically, if they wish to do so. Even if you can and do make the mistake, it's easy to look for all uses of new, and check that they're all safe, as a semi-automatic QA mechanism to enforce coding standards.
Bottom line, how often have you really seen someone (a) manage to write
(b) then fail to ensure proper destruction of the stream object and closure of the file, and (c) not had this noticed during code review or other QA processes? Personally, I've never seen that, but I've surely seen a few dangling resources in languages that use the less automatic idioms.
I'm not saying the RAII mechanism is a silver bullet, I'm just saying it's objectively and measurably better. So it may be with any language feature that removes or actively discourages a certain type of programmer error, hence the link to the DbC features of Eiffel.
Easily write? Sure.
Consistently call? There's a whole programming world of evidence to suggest not, which is a big part of the reason the RAII idiom evolved in the first place.
Blockquoth the AC:
Sorry, I must have been spending too much time around here slagging off certain organisations. :-)
Yes, I did indeed mean RAII.
Interesting page, but AFAICT "programming language hype index" would be a fairer characterisation of the information. It's based on the number of hits returned by popular search engines, rather than any objective metric to do with number of programmers currently using the language, rate at which new code is currently being written in the language, or similar.
You can acquire and release resources in many languages, too, but using the RIAA idiom in C++ you never forget the latter, while in languages that rely on finally or Dispose or whatever, you can.
Of course it can, hence the "OSS, commercial or otherwise" in my previous post. Touched a nerve there, did I? ;-)
And what exactly are Microsoft going to do to someone who's running Linux or MacOS X? :-)
The "many eyes" theory can only work in practice if there are indeed many eyes reviewing the source code and those eyes can see any problems. That doesn't just mean accidental bugs, or portability/future-proofing concerns, or a poor choice of data structures and algorithms leading to a performance hit. It also means spotting the devious and subtle attacks.
Just imagine what would happen if a major OSS project like Apache or Linux accepted a "useful" patch that contained a backdoor that wasn't identified, and this then got distributed worldwide. A significant number of people believe, erroneously, that using OSS inherently makes them safer because of the many eyes theory. These people will happily download and build the updated code, or install prebuilt binaries with correct checksums, completely oblivious to the fact that they just stuck a major security hole in their system.
Thus it's important for those who review submissions to software development projects - OSS, commercial or otherwise - to be very aware of these possibilities, and likewise for anyone else who contributes to them so they can spot a problem if they come across it.
Not really. They're both sans-serif fonts with similar characteristics and overall appearance, but any trained typographer could tell you several differences between them.
<doubleplusgeek> In general, Helvetica is squarer at the ends of its lines: look at glyphs like 't', 'f', 'r', 'j', 'c', 's', 'Q' and '&'. It's also rounder in general: 'o' is almost circular, unlike Arial, and this also shows up in things like the '%' glyph. Finally, Helvetica has completely different designs for a small number of common glyphs, particularly 'a', 'R', 'G' and some of the digits.
You might just as well say that Verdana is the same as Arial, even though it's got a proportionately larger x-height, extends the lines on glyphs like 't', 'r', 'f' and 'Q', opens up glyphs like 'c', 'S' and '9', and adds features to glyphs like 'j', 'I', 'J', '1'. To the untrained eye, it's just another sans-serif font, but to many people, such changes make a dramatic difference to (in this case) on-screen readability. </doubleplusgeek>
That wouldn't exactly be a typical desktop system today, though, would it? As I said originally, you can't trust anything at the level of the compromise or above. Obviously you can run tools on a known good system, or boot from a known good CD, or restore from a database whose security was never compromised.
It seems we do indeed have a miscommunication somewhere, probably because I lazily used dashes to parenthesize. Rephrased, my intended claim is that you can't trust anything that runs at the level of the compromise or above, including any security tools or diagnostic information at those levels.
Even if I had punctuated more formally, I'm not sure I would personally have drawn the inference from my original comment that you did, but I agree that the comment was ambiguous and could be read with either "any" or "all" implicitly added.
In any case, I certainly didn't mean to write your grammatically incorrect alternative proposal, which makes no sense at all! :o)
Sure, but in doing so you're taking a risk that the thing you're removing really is that worm, and not some mutation with some shared symptoms, or potentially even something much nastier that deliberately masquerades as a well-known worm to make you think you're safe. If you're system's been compromised, how do you know you're really dealing with what you think you're dealing with?
In other words, you have to rely on systems below the level of the penetration - which, if you look carefully, is exactly what I said. :-)
I didn't say they wouldn't make a difference. I did imply that the general principles - the inability to trust anything at or above the level of the compromise, and the fact that doing so is a calculated risk - apply on any system, and I stand by that claim. You're talking about preventing a compromise in the first place, or preventing it from getting as deep within a system, and while these are obviously desirable goals, they don't contradict my point.
It's amazing that when at least half a dozen knowledgable posters have already pointed out the fallacy here, we still find a personal ad for "prompt and professional" repairs that relies on closing the stable door after the horse has bolted.
The professional thing to do would be to explain in simple terms why the system is no longer reliable, help the user to back-up what data they can, help them to clean the system and reinstall everything they need, and then help them to install defensive software to avoid getting hit again. And what's more, if your turnaround time is really 6-12 hours, this approach is probably at least as fast, too.
With anything else, you may think you've fixed the problem, but you'll never know for sure, and the people who later get hit by the DDoS worm you missed won't thank you for it.
You could never recover a compromised system reliably anyway. Once someone's got through your security to a certain level, you can't trust anything - including security tools and diagnostic information - that runs at that level or above. For a typical desktop PC or office server, that basically means you can't trust anything left on the system.
Any sort of virus removal or system clean-up after being cracked is just a calculated risk that the attack will have been completely removed, based on the fact that doing a complete rebuild of a system and restoring all the backed up data is expensive, and while not cleaning up 100% after an attack is potentially more expensive, the probability of this is low.
And no, running Linux or MacOS X instead of Windows doesn't change this, despite the number of people flippantly suggesting these alternatives. I'd have told you this earlier and saved a dozen posts, but apparently it's been 4 minutes since I last successfully posted a comment, so I can't post another one yet... ;-)
Sure, but were the various security improvements because of bad PR, or because they didn't want another $10M fine?
Because we all know that treating staff as machines, and expecting them to work constantly throughout the day without taking the odd couple of minutes as a break now and then or dealing with an important personal matter, is definitely the way to increase productivity, right? :-/
I think you misunderstand me. Consider your example:
In this case, 50,000 lives have been affected, possibly rather seriously, by the negligence of some or all of those 50 people. If serious damage has been done to all 50,000 then I am entirely in favour of that company of 50 people ceasing to exist.
Sorry, but no, I don't believe that.
There have been several cases in the past, mentioned here and elsewhere, of major leaks of personal data. Can you show me a single example where a leaker has compensated the affected individuals or taken significant steps to prevent a recurrence? Has any such offender suffered any significant damage to their bottom line? Not that I know of, certainly.
If they took reasonable care to encrypt their data effectively then I wouldn't object to that provision. However, if all they have to do is have their database engineers ROT13 all the names, this sounds like the gotcha where the new act actually improves things for businesses, as an earlier poster predicted.