Let's assume that GPS evidence becomes generally admissible in court. It's already worked a few times. Besides the case I mentioned, there has been a similar case in Australia (my thanks to two anonymous commenters for the pointer).
So how is this going to work? I get busted for speeding. I bring a printout to court from my GPS saying I was doing the speed limit. The judge says "and how do I know you didn't just fabricate this?" That's not going to work.
On the other end, we have the case I first mentioned, where the GPS coordinates are getting beamed back to some third party for perusal. The GPS itself is presumably tamper-resistant. I'm presuming this because the evidence stood up in court, and because there are existing GPS applications, such as monitoring commerce and monitoring people under house arrest, where tamper-resistance is at a premium.
That ought to work just fine, but who wants to run around with a GPS reporting their every move, just to get out of a possible speeding ticket? The stepson in the case certainly didn't. He just didn't have much choice.
Fortunately, there's a middle ground. A tamper-resistant (and probably tamper-evident) unit that can provide its logs if asked (ideally with proper authentication), but doesn't just broadcast them. As far as I can tell (and again I haven't done the legwork here), that's what happened in the Australian case.
This seems like a decent paradigm for Trusted-Computing-like devices that use techniques like strong encryption and special hardware to try to ensure that everything is what it appears to be. As with the music/video case, the trusted device performs a specialized function and doesn't need to be highly upgradeable.
Unlike the classic TC scenario, the trusted device is not in frequent communication with the mothership. Its job is to hold sensitive data and divulge it only when I ask. Or more accurately, when someone who can prove they know a particular secret asks. Much like a personal datastore.
Showing posts with label trusted computing. Show all posts
Showing posts with label trusted computing. Show all posts
Tuesday, November 13, 2007
Saturday, November 10, 2007
Trusted computing: What could be better?
The fundamental tension behind trusted computing is over programmability. Someone sending out protected content wants to be sure that it can only be accessed on a restricted set of particular devices. This is a lot easier of the devices in question are not highly programmable. In the case of a portable music player or set-top box, the keys involved can be kept in special tamper-resistant hardware and otherwise protected from exposure or modification.
If your playback device is a general-purpose computer, the game becomes a lot harder. I could send you a player application with a key branded into it, but there are any number of ways to get such a player to yield up its secrets, or yield up the unprotected content without having to uncover the secrets themselves.
The trusted computing model tries to combat this by restricting access to the information on a given computer and tightly controlling all modification to such an otherwise-programmable device. In other words, the vendor asserts control over programmability. It is this idea, not the idea that the creator of content should have control over the content, that fundamentally conflicts with the ideas (and ideals) of personal computing in general and free software in particular.
The TC model, depending on tight control of all possible modifications, is inherently fragile. Compare it to the models used in modern cryptography (on which it heavily relies). In modern cryptography, one makes extremely pessimistic assumptions about what will happen in practice.
For example, in designing a cipher, one typically assumes an adaptive chosen-plaintext attack. This means that the attacker can repeatedly choose a message to be encrypted, look at the resulting ciphertext, choose another message to be encrypted and so on. This did not come about by accident. There are various ways a real-world attacker can perform such an attack on a real-world cipher.
Cipher design, and robust engineering in general, assumes that anything that can go wrong will. This generaly means minimizing the number of dependencies and moving parts. The RSA cipher, for example, consists of raising a number representing the message to a known power and taking the remainder against a large number, called the modulus. The modulus (along with a second exponent used to decrypt the message) is derived from two large, randomly-chosen prime numbers by a simple recipe.
That's it. That's one of the most secure ciphers known. But even with that simple recipe there are known subtleties in choosing a good key and in preparing messages for encryption in order to avoid various attacks.
Trusted computing relies on five key technologies, which interact in various ways to provide the full model. You need hardware support in several places to even have a chance at making it all work. There are legitimate questions about how all this will affect basic system functions like backup. It's quite clear that any TC system will be actively attacked by hackers in both senses (I shouldn't get started on this, but I still like to think of "hacker" as meaning someone who does clever things with technology for the sake of learning and having fun; the more popular meaning is someone who tries to break into systems).
It doesn't seem like a good bet.
Trying to prevent or control modifications to a general-purpose computer is swimming upstream. The main driver here is to protect content like music and video. That requires a tamper-resistant decoder (and faith that this is a worthwhile exercise, despite analog reconversion). From this point of view, TC tries to enable general-purpose computers to become decoders by first making them tamper-resistant.
The alternative is not to try to make general-purpose computers into decoders. If my computer has an encrypted-bits-to-sound-and-video decoder attached to it, then I can reprogram my computer all I want, and I can make as many copies of protected content as I want. When I want to play a song or video, I send it to my decoder, which has all the attributes TC wants: it's tamper-resistant, non-programmable and has a private key embedded in it as tightly as modern technology will allow.
I can use my favorite software to index the content that I've bought the rights to, to sequence it, to dispatch it to the various decoders I own and so forth. I can use my favorite non-media software without having to worry about what measures my OS vendor is taking to control my use of the content I bought the rights to.
This is not to far from how current content-delivery systems like cable and satellite boxes work, as I understand it. Given that, it's not clear to me how much farther we need to go down the TC road.
If your playback device is a general-purpose computer, the game becomes a lot harder. I could send you a player application with a key branded into it, but there are any number of ways to get such a player to yield up its secrets, or yield up the unprotected content without having to uncover the secrets themselves.
The trusted computing model tries to combat this by restricting access to the information on a given computer and tightly controlling all modification to such an otherwise-programmable device. In other words, the vendor asserts control over programmability. It is this idea, not the idea that the creator of content should have control over the content, that fundamentally conflicts with the ideas (and ideals) of personal computing in general and free software in particular.
The TC model, depending on tight control of all possible modifications, is inherently fragile. Compare it to the models used in modern cryptography (on which it heavily relies). In modern cryptography, one makes extremely pessimistic assumptions about what will happen in practice.
For example, in designing a cipher, one typically assumes an adaptive chosen-plaintext attack. This means that the attacker can repeatedly choose a message to be encrypted, look at the resulting ciphertext, choose another message to be encrypted and so on. This did not come about by accident. There are various ways a real-world attacker can perform such an attack on a real-world cipher.
Cipher design, and robust engineering in general, assumes that anything that can go wrong will. This generaly means minimizing the number of dependencies and moving parts. The RSA cipher, for example, consists of raising a number representing the message to a known power and taking the remainder against a large number, called the modulus. The modulus (along with a second exponent used to decrypt the message) is derived from two large, randomly-chosen prime numbers by a simple recipe.
That's it. That's one of the most secure ciphers known. But even with that simple recipe there are known subtleties in choosing a good key and in preparing messages for encryption in order to avoid various attacks.
Trusted computing relies on five key technologies, which interact in various ways to provide the full model. You need hardware support in several places to even have a chance at making it all work. There are legitimate questions about how all this will affect basic system functions like backup. It's quite clear that any TC system will be actively attacked by hackers in both senses (I shouldn't get started on this, but I still like to think of "hacker" as meaning someone who does clever things with technology for the sake of learning and having fun; the more popular meaning is someone who tries to break into systems).
It doesn't seem like a good bet.
Trying to prevent or control modifications to a general-purpose computer is swimming upstream. The main driver here is to protect content like music and video. That requires a tamper-resistant decoder (and faith that this is a worthwhile exercise, despite analog reconversion). From this point of view, TC tries to enable general-purpose computers to become decoders by first making them tamper-resistant.
The alternative is not to try to make general-purpose computers into decoders. If my computer has an encrypted-bits-to-sound-and-video decoder attached to it, then I can reprogram my computer all I want, and I can make as many copies of protected content as I want. When I want to play a song or video, I send it to my decoder, which has all the attributes TC wants: it's tamper-resistant, non-programmable and has a private key embedded in it as tightly as modern technology will allow.
I can use my favorite software to index the content that I've bought the rights to, to sequence it, to dispatch it to the various decoders I own and so forth. I can use my favorite non-media software without having to worry about what measures my OS vendor is taking to control my use of the content I bought the rights to.
This is not to far from how current content-delivery systems like cable and satellite boxes work, as I understand it. Given that, it's not clear to me how much farther we need to go down the TC road.
Labels:
copy protection,
cryptography,
DRM,
Intellectual Property,
iPod,
trusted computing
Monday, November 5, 2007
Trusted Computing: The darker side
So far, I've painted a fairly benign picture of Trusted Computing, even suggesting that a couple of prominent criticisms of it may go too far. For example, I argued that using hardware to enforce copyrights on music -- assuming this will actually work -- is not unreasonable in and of itself. But in doing this, I haven't mentioned (except indirectly) some of potentially darker aspects of TC. So here goes.
Before I get into details, let me give my gut reaction: The concerns are legitimate. Several aspects of TC are potentially obnoxious, open to abuse or both, and those who promote it don't necessarily have their interests aligned with mine or yours. On the other hand, the problems in question are really legal and ethical problems. Nor are they particularly new or unique to TC.
As such, there are already significant counterbalances that will tend to prevent the nightmare scenarios -- particularly if people are generally informed of the dangers. For this reason, I'm very happy to see people like Vixie and Stallman voicing their concerns. If it turns out they're wrong, it will be in part because they -- and many others in the FSF, the EFF and elsewhere -- raised the alarm. And if they're right, we need every bit of firepower working on the solution we can get.
With that in mind, here are some of the objections I've seen:
Constant contact with the mothership: In order to make sure that the hardware is running the right firmware/software and not some hacked version, to push out updates and enhancements and to update access rules, a given hardware device will communicate frequently with the vendors of the various software it runs. This communication can potentially include all sorts of information stored on the device, whether it's any of the vendors' business or not.
But this is pretty much what's happening now. The major OSs have been converging for some time now, and one thing they've converged on is frequent automatic updates. Updates that call back to the mothership, send you digitally signed modifications to your software -- including your kernel -- and ask you to give an administrator password or otherwise grant permission. It's not just OSs either. Browsers update themselves and ask you to install plugins. So do at least some of those neat desktop widgets.
Does this communication include sensitive information about what's on my disk and what I do with my computer? To the best of my knowledge, no. How do I know this? Basically the vendors say so and no one seems to say they're lying. If someone does start leaning over the line, we hear about it. Just as we're hearing about the potential for abuse of TC.
Unique ids on everything: In order to make sure that a given piece of content can only be accessed on a particular device, you need to know what exact device is trying to read it. In the TC world, every device includes a unique "endorsement key" -- a private cryptographic key that allows anyone who knows the corresponding public key (which will generally be anyone) to send it messages only it can read. It also allows the device to prove that it has that key and since no one else can do so, it uniquely identifies the device.
Unique ids have been around for some time now. In the physical world they're called serial numbers. Network interfaces have MAC addresses. Every bluetooth device has a unique address, and so on.
Neither are digital keys and signatures new. The problem is more that, with an unforgeable ID, a given device, and its usage history if it chooses to record that, can be strongly tied to a given system and from that generally to a given person. If the system is in frequent contact with the mothership, then that information can easily be uploaded and used for any purpose the vendor sees fit.
Again, the problem is not the unique ID per se, but what may and may not be done with the information associated with it. This is a legal and ethical problem, and analogous cases already exist, for example cell phone records (and land line records before them).
Disappearing ink: If I send you a file encrypted to your private key (using your public key), once you decrypt it it's yours to do with as you please. If I send you a file encrypted with some secret key and give you the key, it's the same deal. But suppose I give you a file encrypted to some key that I don't know, and you don't know, but some black box installed on your system does know. That box is set up never to reveal the actual bits I sent you directly, but it will allow you to view the contents on your screen (or play them on your headphones, or whatever).
Then when and whether you can read that file is up to the black box. If the black box is under my control, then so is the file, effectively. This leads to several worrisome possibilities. In order of (IMHO) decreasing likelihood:
In cases where protecting data is important, there will be market pressure against closed solutions. If I'm, say, a bank or insurance company, I don't want to depend on a particular vendor's device still working twenty years from now -- or that vendor not having folded and taken its keys with it -- when I want to retrieve data from a storage medium that doesn't even exist today.
The plausible deniability problem is ancient. There have always been and almost certainly always will be ways of telling someone to do something without actually coming out and saying it. There will always be a legitimate need for secure, untraceable communication, whether it's sending a protected email or calling someone into an empty room out of sight and earshot. This ability will always be open to abuse.
In order for the worst nightmare scenarios to happen, TC has to be pervasive and mandatory. Right now we're several steps from that. In the US, at least one bill trying to require TC for internet access has died in committee, due in part to the efforts of the FSF, EFF and others, but also to the ability of at least some senators to understand the free speech implications. Again, the problems are more legal and ethical than technical.
Except ...
No unauthorized modifications: If you want to make sure that a system can be trusted (for whatever we're trusting it to do), you also have to make sure it stays that way, particularly when you have a mechanism for automatically delivering updates. Asking the user for authorization is not enough. Very, very few people have the expertise and time to examine every single update that comes across.
A trusted system will only accept updates with the proper credentials, using strong digital signatures. If I try to install my own word smasher or OS, the system will refuse.
This is, of course, a topic near and dear to Stallman and the free software community in general. The whole reason that free software exists outside a small group of dedicated individuals is that it fulfills an important need. It's a counterbalance to commercial software's tendency to lock people in.
Free software says "Here's exactly how the system you're running works. If you don't like it, you're free to rewrite it or (more likely) find a better version or hire someone who can write you one." TC says, "Hey, buddy, you can't change that unless the people who made the system know they can trust you" and that, of course, directly conflicts with the whole "if you don't like it fix it" principle.
There's a case to be made for TC or something like it in special-purpose content-delivery systems like music players and set-top boxes. The question is whether this is the first step toward TC everywhere whether we want it or not.
One of the main sources of concern is whether we will reach some sort of tipping point, where so many systems are TC-enabled that you effectively have to protect your data in order to exchange it at all.
This is not a problem on the sending end. If I'm sending from an open system to a TC system, I can always make my own copy of whatever I send before I armor-plate it. Or can I? The trusted system I'm sending to might be so heinous as to accept only messages produced by a particular trusted word smasher, and not just random files that happen to be properly encrypted. That would be pretty heinous, but who knows?
It's definitely a problem on the receiving end. Just as people sometimes insist on sending attachments in proprietary format, they could choose to send messages in protected form, so that I need a particular trusted black box in order to view them. If practically everyone they correspond with has such a box, then it's most convenient for them to send everything that way and conversely there will be great pressure for anyone without such a box to get one. In other words, I have the choice of receiving a message written in (potentially) disappearing ink, or no message at all.
The $64,000 question is, will people stand for this? I can see such a system being put in place inside a large company in order to, say, enforce document retention policies. It's harder to see it evolving among companies or groups of individuals. Postel's principle that one should be liberal in what one accepts and conservative in what one produces seems particularly applicable here.
In short, the situation definitely bears watching. My guess is that better alternatives will arise to solve the problems, such as copyright protection and malware, that TC is trying to address. The climate doesn't seem particularly threatening at the moment, but if this should change, we should all be ready.
Before I get into details, let me give my gut reaction: The concerns are legitimate. Several aspects of TC are potentially obnoxious, open to abuse or both, and those who promote it don't necessarily have their interests aligned with mine or yours. On the other hand, the problems in question are really legal and ethical problems. Nor are they particularly new or unique to TC.
As such, there are already significant counterbalances that will tend to prevent the nightmare scenarios -- particularly if people are generally informed of the dangers. For this reason, I'm very happy to see people like Vixie and Stallman voicing their concerns. If it turns out they're wrong, it will be in part because they -- and many others in the FSF, the EFF and elsewhere -- raised the alarm. And if they're right, we need every bit of firepower working on the solution we can get.
With that in mind, here are some of the objections I've seen:
Constant contact with the mothership: In order to make sure that the hardware is running the right firmware/software and not some hacked version, to push out updates and enhancements and to update access rules, a given hardware device will communicate frequently with the vendors of the various software it runs. This communication can potentially include all sorts of information stored on the device, whether it's any of the vendors' business or not.
But this is pretty much what's happening now. The major OSs have been converging for some time now, and one thing they've converged on is frequent automatic updates. Updates that call back to the mothership, send you digitally signed modifications to your software -- including your kernel -- and ask you to give an administrator password or otherwise grant permission. It's not just OSs either. Browsers update themselves and ask you to install plugins. So do at least some of those neat desktop widgets.
Does this communication include sensitive information about what's on my disk and what I do with my computer? To the best of my knowledge, no. How do I know this? Basically the vendors say so and no one seems to say they're lying. If someone does start leaning over the line, we hear about it. Just as we're hearing about the potential for abuse of TC.
Unique ids on everything: In order to make sure that a given piece of content can only be accessed on a particular device, you need to know what exact device is trying to read it. In the TC world, every device includes a unique "endorsement key" -- a private cryptographic key that allows anyone who knows the corresponding public key (which will generally be anyone) to send it messages only it can read. It also allows the device to prove that it has that key and since no one else can do so, it uniquely identifies the device.
Unique ids have been around for some time now. In the physical world they're called serial numbers. Network interfaces have MAC addresses. Every bluetooth device has a unique address, and so on.
Neither are digital keys and signatures new. The problem is more that, with an unforgeable ID, a given device, and its usage history if it chooses to record that, can be strongly tied to a given system and from that generally to a given person. If the system is in frequent contact with the mothership, then that information can easily be uploaded and used for any purpose the vendor sees fit.
Again, the problem is not the unique ID per se, but what may and may not be done with the information associated with it. This is a legal and ethical problem, and analogous cases already exist, for example cell phone records (and land line records before them).
Disappearing ink: If I send you a file encrypted to your private key (using your public key), once you decrypt it it's yours to do with as you please. If I send you a file encrypted with some secret key and give you the key, it's the same deal. But suppose I give you a file encrypted to some key that I don't know, and you don't know, but some black box installed on your system does know. That box is set up never to reveal the actual bits I sent you directly, but it will allow you to view the contents on your screen (or play them on your headphones, or whatever).
Then when and whether you can read that file is up to the black box. If the black box is under my control, then so is the file, effectively. This leads to several worrisome possibilities. In order of (IMHO) decreasing likelihood:
- Lock-in: If that black box is the only way you can view the content I sent you, then it's going to be hard to switch to a different brand of black box. You would most likely need me to either re-send the file, or give your black box permission to hand it over to the new black box (it seems possible that you could require me to include some sort of transfer permission with the file when I send it, but that has its own problems).
- Plausible deniability run amok. I'm your boss. I send you an order to do something bad. You do it. I tell your black box to get rid of the order. Effectively, I never told you anything. The authorities come a-knocking. You hang and twist in the wind. You sent a copy of the order to the press? Too bad they can't read it. I retire to a sunny tropical isle.
- Outright censorship: If all systems are "trusted", then anything published is under the control of whoever controls the black boxes. You write something I don't like. I tell every black box I control to refuse to show it. If I'm an OS vendor or the government, that could be quite a few boxes. In the worst case, it could be every legal box. You never said anything, and Oceania has always been at war with Eurasia.
In cases where protecting data is important, there will be market pressure against closed solutions. If I'm, say, a bank or insurance company, I don't want to depend on a particular vendor's device still working twenty years from now -- or that vendor not having folded and taken its keys with it -- when I want to retrieve data from a storage medium that doesn't even exist today.
The plausible deniability problem is ancient. There have always been and almost certainly always will be ways of telling someone to do something without actually coming out and saying it. There will always be a legitimate need for secure, untraceable communication, whether it's sending a protected email or calling someone into an empty room out of sight and earshot. This ability will always be open to abuse.
In order for the worst nightmare scenarios to happen, TC has to be pervasive and mandatory. Right now we're several steps from that. In the US, at least one bill trying to require TC for internet access has died in committee, due in part to the efforts of the FSF, EFF and others, but also to the ability of at least some senators to understand the free speech implications. Again, the problems are more legal and ethical than technical.
Except ...
No unauthorized modifications: If you want to make sure that a system can be trusted (for whatever we're trusting it to do), you also have to make sure it stays that way, particularly when you have a mechanism for automatically delivering updates. Asking the user for authorization is not enough. Very, very few people have the expertise and time to examine every single update that comes across.
A trusted system will only accept updates with the proper credentials, using strong digital signatures. If I try to install my own word smasher or OS, the system will refuse.
This is, of course, a topic near and dear to Stallman and the free software community in general. The whole reason that free software exists outside a small group of dedicated individuals is that it fulfills an important need. It's a counterbalance to commercial software's tendency to lock people in.
Free software says "Here's exactly how the system you're running works. If you don't like it, you're free to rewrite it or (more likely) find a better version or hire someone who can write you one." TC says, "Hey, buddy, you can't change that unless the people who made the system know they can trust you" and that, of course, directly conflicts with the whole "if you don't like it fix it" principle.
There's a case to be made for TC or something like it in special-purpose content-delivery systems like music players and set-top boxes. The question is whether this is the first step toward TC everywhere whether we want it or not.
One of the main sources of concern is whether we will reach some sort of tipping point, where so many systems are TC-enabled that you effectively have to protect your data in order to exchange it at all.
This is not a problem on the sending end. If I'm sending from an open system to a TC system, I can always make my own copy of whatever I send before I armor-plate it. Or can I? The trusted system I'm sending to might be so heinous as to accept only messages produced by a particular trusted word smasher, and not just random files that happen to be properly encrypted. That would be pretty heinous, but who knows?
It's definitely a problem on the receiving end. Just as people sometimes insist on sending attachments in proprietary format, they could choose to send messages in protected form, so that I need a particular trusted black box in order to view them. If practically everyone they correspond with has such a box, then it's most convenient for them to send everything that way and conversely there will be great pressure for anyone without such a box to get one. In other words, I have the choice of receiving a message written in (potentially) disappearing ink, or no message at all.
The $64,000 question is, will people stand for this? I can see such a system being put in place inside a large company in order to, say, enforce document retention policies. It's harder to see it evolving among companies or groups of individuals. Postel's principle that one should be liberal in what one accepts and conservative in what one produces seems particularly applicable here.
In short, the situation definitely bears watching. My guess is that better alternatives will arise to solve the problems, such as copyright protection and malware, that TC is trying to address. The climate doesn't seem particularly threatening at the moment, but if this should change, we should all be ready.
Labels:
Jon Postel,
Paul Vixie,
Richard Stallman,
trusted computing
Sunday, November 4, 2007
Stallman on Trusted Computing and DRM
I previously mentioned Paul Vixie's speech to the Commonwealth Club about (among other things) one's continued free access to one's own data. Of course, he's not the only one so concerned. Along with other prominent people, Richard Stallman has been beating this drum for some time now, for example in Can you trust your computer?.
This essay takes aim at trusted computing, which Stallman calls "treacherous computing" and which I'll refer to here as "TC". It's the same initiative that Vixie mentions, though not by name. Given the history involved it's no surprise Stallman should take the position he does, but when not one but several of the major pioneers of the net as we know it are sounding a caution, it's a good idea to think particularly carefully about what they're saying.
Reading Stallman's piece, I feel a bit of dissonance that I'm not completely sure how to resolve. My particular viewpoint coming in includes these basic tenets:
On the other hand, I don't find the arguments Stallman advances against initiatives like TC particularly satisfying either. Thence the dissonance.
Let's back up a bit and look at what TC is. There are two basic components:
Personally, I don't have a problem with this scenario per se. I'm fine with pay-per-view movies on TV, for example. I don't feel I have some basic right to store and copy any collection of bits that happens to enter my house. The movie I watch on PPV isn't mine. I didn't write it, direct it, produce it or act in it. My cable provider is selling me the opportunity to watch that movie at home during a given time period. That seems fair.
Whether you approve of the particular way my $4 gets distributed among the cable operator, the studio, the creative people involved, their agents, the catering truck on the set and so forth is a separate, non-technical issue.
I believe this is one source of dissonance. To check this, I went back and re-read the GNU Manifesto. If you haven't read it in a while (or ever), please do so and take a moment to appreciate how much it got right over twenty years ago and to consider how much of today's landscape was shaped by it. I'm writing this using Firefox running on Ubuntu, for example. If you work for, say, Red Hat, in a real sense you owe your job in part to this document.
[FSF's position on copyrights is more sophisticated than what I describe next. I had originally tried to fix the text up, but later realized that it's more bloggish just to let the text stand as written (or as close as I could un-fix it) and continue the conversation, as for example here. -- DH 18 Nov 2007]
One of the bases of GNU is that software copyrights are not only not useful, but inherently harmful. One reason given is that a piece of software is fundamentally different from a book, play, musical composition or what-have-you. Another is that network technology has changed the economics of copying.
It's an easy extrapolation from this second point to the notion that copyrights are not only inapplicable to software but to anything else as well. For centuries, copyrights could be enforced (logically enough) by limiting the means of copying. That avenue is open to serious challenge now, and TC as applied to DRM is clearly an attempt to put the genie back into the bottle.
I'm skeptical of genie-bottling exercises in general, but I'm not ready to give up on the idea of copyrights as a legal and economic construct. Much of the backlash against TC, however, seems to be based on the idea that copyrights in general are harmful -- at least when used in particular ways. Stallman says as much in a footnote, and others have mentioned it more prominently:
This is fairly complete control over the physical realization of an author's ideas, and this is the current law, not a revolutionary break from it. So what's different in the digital world? My guess is that in the physical world, copyright is quite tightly controlled when it comes to large publishers -- a magazine publishing plagiarized work will be subject to major lawsuits and a seriously damaged reputation -- but pretty lax once you enter the home.
Who hasn't made a mix tape/CD? No one cares, even though an anthology is a "derived work", at least as far as I understand US law. TC has the potential to seriously disrupt this. It is not the idea of authors retaining control that is new and unsettling. It is the high degree of automated, fine control. TC can impose restrictions like "you can only listen to this song at these precise times on this particular player, and the player can report any attempt to get around this" as opposed to "if you try to make and sell a lot of copies of this song, you'll be in big trouble if we catch you." At the very least, this will require a lot of further hashing out in the courts and the markets.
There is a lot more to be said here. I haven't even touched on the very legitimate concerns about civil liberties and Orwellian nightmares. Again, I don't believe the problems are quite as new as they might seem nor the world quite as unprepared, but these too bear careful scrutiny. More to follow, I hope.
This essay takes aim at trusted computing, which Stallman calls "treacherous computing" and which I'll refer to here as "TC". It's the same initiative that Vixie mentions, though not by name. Given the history involved it's no surprise Stallman should take the position he does, but when not one but several of the major pioneers of the net as we know it are sounding a caution, it's a good idea to think particularly carefully about what they're saying.
Reading Stallman's piece, I feel a bit of dissonance that I'm not completely sure how to resolve. My particular viewpoint coming in includes these basic tenets:
- Information is hard to constrain. I don't believe there's some undefinable essence in information itself that causes it to thwart restrictions, but as a practical matter, anything that appears on the net unencrypted has the potential to spread very far very fast (whether anyone will pay attention is a different matter, one of human bandwidth).
- Technology is largely neutral. As the lady said, any tool is a weapon if you hold it right. The converse also holds. Apparent controversies about technology often turn out to be controversies about law, society and ethics.
- It's hard, and often counterproductive, to fight market forces; market forces, like technology, are largely neutral.
On the other hand, I don't find the arguments Stallman advances against initiatives like TC particularly satisfying either. Thence the dissonance.
Let's back up a bit and look at what TC is. There are two basic components:
- Content -- whether music, email, code or whatever -- is strongly encrypted.
- The keys needed for decryption are tightly tied to particular physical pieces of hardware (using a combination of hardware support, further encryption and digital signatures).
Personally, I don't have a problem with this scenario per se. I'm fine with pay-per-view movies on TV, for example. I don't feel I have some basic right to store and copy any collection of bits that happens to enter my house. The movie I watch on PPV isn't mine. I didn't write it, direct it, produce it or act in it. My cable provider is selling me the opportunity to watch that movie at home during a given time period. That seems fair.
Whether you approve of the particular way my $4 gets distributed among the cable operator, the studio, the creative people involved, their agents, the catering truck on the set and so forth is a separate, non-technical issue.
I believe this is one source of dissonance. To check this, I went back and re-read the GNU Manifesto. If you haven't read it in a while (or ever), please do so and take a moment to appreciate how much it got right over twenty years ago and to consider how much of today's landscape was shaped by it. I'm writing this using Firefox running on Ubuntu, for example. If you work for, say, Red Hat, in a real sense you owe your job in part to this document.
[FSF's position on copyrights is more sophisticated than what I describe next. I had originally tried to fix the text up, but later realized that it's more bloggish just to let the text stand as written (or as close as I could un-fix it) and continue the conversation, as for example here. -- DH 18 Nov 2007]
One of the bases of GNU is that software copyrights are not only not useful, but inherently harmful. One reason given is that a piece of software is fundamentally different from a book, play, musical composition or what-have-you. Another is that network technology has changed the economics of copying.
It's an easy extrapolation from this second point to the notion that copyrights are not only inapplicable to software but to anything else as well. For centuries, copyrights could be enforced (logically enough) by limiting the means of copying. That avenue is open to serious challenge now, and TC as applied to DRM is clearly an attempt to put the genie back into the bottle.
I'm skeptical of genie-bottling exercises in general, but I'm not ready to give up on the idea of copyrights as a legal and economic construct. Much of the backlash against TC, however, seems to be based on the idea that copyrights in general are harmful -- at least when used in particular ways. Stallman says as much in a footnote, and others have mentioned it more prominently:
A previous statement by the palladium developers stated the basic premise that whoever developed or collected information should have total control of how you use it. This would represent a revolutionary overturn of past ideas of ethics and of the legal system, and create an unprecedented system of control.But the whole point of existing copyrights is that the creator of a work retains control over what happens to it. A common magazine contract is for "first serial rights", meaning that the buyer (a magazine) has the right to print the article once, but that the author retains the right to publish it again, for example in an anthology. When I buy that magazine, I in turn have the right to read it, but not to copy it or quote it outside the fairly well-delimited area of "fair use". Otherwise I am breaking the law and subject to stiff penalties.
This is fairly complete control over the physical realization of an author's ideas, and this is the current law, not a revolutionary break from it. So what's different in the digital world? My guess is that in the physical world, copyright is quite tightly controlled when it comes to large publishers -- a magazine publishing plagiarized work will be subject to major lawsuits and a seriously damaged reputation -- but pretty lax once you enter the home.
Who hasn't made a mix tape/CD? No one cares, even though an anthology is a "derived work", at least as far as I understand US law. TC has the potential to seriously disrupt this. It is not the idea of authors retaining control that is new and unsettling. It is the high degree of automated, fine control. TC can impose restrictions like "you can only listen to this song at these precise times on this particular player, and the player can report any attempt to get around this" as opposed to "if you try to make and sell a lot of copies of this song, you'll be in big trouble if we catch you." At the very least, this will require a lot of further hashing out in the courts and the markets.
There is a lot more to be said here. I haven't even touched on the very legitimate concerns about civil liberties and Orwellian nightmares. Again, I don't believe the problems are quite as new as they might seem nor the world quite as unprepared, but these too bear careful scrutiny. More to follow, I hope.
Thursday, October 11, 2007
Pumping data through the Hetch Hetchy Aqueduct
Paul Vixie made a very interesting speech to the Commonwealth Club in San Francisco last year. As it was aimed at a general audience, he started out with some familiar points. I'll repeat them here [with a couple of comments] because they lead up to the more interesting conclusions:
In light of the points above, this may not be such a good idea. That doesn't mean that software vendors, record labels and so forth are evil, just that they're for-profit entities and must be expected to act as such.
- Cash flow is more important than cash. The word for the day is monetize: to extract cash flow from.
- One's ability to monetize things in the physical world is governed by regulations, including anti-trust regulations, balancing the good of society against the good of the individual.
- Owning a physical CD or book or such is ownership in the dictionary sense.
- This is regulated by copyright law, a fair system which has made a lot of money for content creators while supplying a lot of content to people who might not have had it otherwise.
- This doesn't work in the virtual world, where perfect copying is cheap.
- In the case of music, this is mostly a concern to the major labels and their artists. Smaller artists give away music digitally to promote concerts and sell T-shirts [see also Radiohead's latest release]
- Big music, after trying to stop digital copying [actually, those lawsuits are still shaking out] has decided to try to make money off of digital music.
- They do this by letting you listen to what you want but controlling the means of playing it. A typical software player reports your downloading, maybe shows pop-ups, and ties you to one of the commercial OS's -- and its upgrades. Again, the word is "monetize".
- (For his part, Vixie just buys CDs and plays them on his Linux laptop. And respects copyrights.)
- This model of monetizing content applies to all content on computers, even content you produce yourself for your own use, that is, your email, text documents, etc. How does that work? It works because ...
- Viruses, worms etc. are a major problem for computer users these days, a problem that many companies are trying to solve, that is, monetize.
- Consumers just want their computers to work, but there's not actually any money to be had in solving that problem. A computer that Just Works is like a razor blade that never gets dull.
- One part of the solution is to rent virus protection. In a fuller solution, OSs would ideally only run trusted applications registered with the OS vendor -- for a fee, of course. This is already how game boxes work.
- Carry this over to the application world, and you end up renting the ability to access your own content, which is now stored in encrypted and/or proprietary form.
- Fortunately, this is very difficult to pull off on current platforms. It would really require a whole new kind of hardware/software platform. Best to start small. Say, with music ...
In light of the points above, this may not be such a good idea. That doesn't mean that software vendors, record labels and so forth are evil, just that they're for-profit entities and must be expected to act as such.
Subscribe to:
Posts (Atom)
