That house has been rebuilt. With traditional Japanese building materials, no residence can survive more than 40 years. It might be replaced piece-by-piece, or all at once after a disaster, but the original building is gone.
PS. What's the rule of thumb for evaluating the veracity of any sentence starting with "100% of the..." ?
(Nobody should mod you down for that. Real flamebait looks distinctly different)
I might add that the Japanese military would have shown no similar sense of honor.
Some would question whether avoiding potentially useful targets, which prolongs the fighting and endagers your own troops, is really "honor". What does it mean to value some rotting wooden buildings over human lives?
Others might ask if commanding a single pilot to kill 100,000 helpless civilians simply to impress the USSR is honorable.
make a big, heavy, crude sucker out of whatever you can turn to the task.
The word "crude" has no place around atomic weapons. You've got to line up the atoms exactly, or almost nothing happens.
However, it would be quite reasonable to ship a bomb as little parts, each 40kg or less, which can be assembled near the target site. I'd personally recommend concealing them inside the air-gaps within wide-screen TVs being shipped from China, but there are lots of ways to hide these things.
gasp, use the internet.
I've got a screenplay to sell you. An attractive teenage hacker stumbles onto a terrorist plot to nuke Washington, but he wards it off with a quick DDoS worm. Now he's got to find the bomb and unplug it while dodging the FBI and HLS agents hot on his trail!
As soon as somebody uses Nukes on the U.S. they would be screwed the moment the CIA investigation got overwith.
Oh, a CIA investigation! Oh that's really reliable. Especially considering that all direct evidence of the perpetrators was atomized at ground zero. As was Langley itself.
The only evidence firm enough for a reflexive venegance-strike is a radar-track from Lesotho to Pennsylvania Avenue.
That'd be a "blink and you missed it" kinda thing. What if the political leaders didn't happen to be watching? What if it was hard to judge distance, and they assumed a conventional bomb had nearly missed them? A blast over water doesn't leave tangible evidence behind (unless prehaps it destroyed some warships, but the Imperial Navy was already pushing up coral)
To make a good demonstration, you'd need to do it on lightly inhabited land so that nearby people can wander onto the blast area and gaze around in awe before reporting back to the emperor. And you'd want to telegraph a warning 24 hours ahead, to re-emphasize military superiority (proving that it wasn't some kind of natural volcano).
Mt. Fuji would've been an ideal target. Take a scared mountain and convert it into a scared gravel pit. That would be an undeniable show of force!
Hiroshima is gorgeous. It's not a crater and not a radioactive wasteland. Unless you recognize the name, you'd have no way to tell it apart from any other gleaming Japanese city. Some people have absorbed anti-nuclear propaganda and assume that atomic weapons will render the target area uninhabitable for centuries. That's just wrong (although the propaganda is based on Cold War era weapons, which dwarf the power of the bombs dropped on Japan)
Note that 100% of Japanese cities were bombed flat in WWII, so all buildings are less than 50 years old (even without the bombing, earthquakes would keep destroying them). Thus they may all look similar to a naive visitor.
Eventually every nation, even the ones in Africa, will have nukes. Yep.
"Nukes" are nuclear explosives, sometimes called "warheads". They do not need missiles to deliver them. Kamikaze terrorists are sufficient. A good ICBM shield does nothing against nukes.
An African nation that fired an ICBM at the US would have 80 missiles targeted to melt it into a puddle before their single shot even reached the Atlantic. Any non-suicidal African dictator who wishes to nuke America will transport the bomb by SUV, not ICBM.
How would you feel if I simply said "I trust software version N, the one with hash X." Is that okay, or is my comment a derivative work, too?
As I explicitly stated in a postscript, asserting that code matching a hash value is trusted is not a derivative work. (The hash contains a negligibly small fraction of the copyrighted work, making it a fair-use exception)
Signing creates a new file with your stuff at the beginning and end and my code in the middle. That means it's a derivative work. (The signed binary contains 100% of the copyrighted work, which is illegal to redistribute without permission)
Hardware vendors can work around that interpretation by distributing hashes and executables separately. That dodge may or may not be a legal loophole.
I could sign your GNU software, and set up a machine that will only run the signed version.
The argument I would hope to make (possibly needing a modified GPL license version to explicitly require this) is that by signing the software (which is my copyright), you have created a derivative work, which is illegal. The only way I'll permit you to distribute it is if you agree to supply the recipients with anything needed to create the binary they got. This means the source code, the compilers (if they're hard to get), and the private key.
Of course, if you're obliged to give out that private key, then there was no reason to sign at all.
As a non-lawyer, I can't construct a good license to enforce that requirement, but in time the FSF will be forced to address this issue. They might even be able to content that the existing GPL already suffices.
Then when someone creates a derivative work, it would not run on my machine.
You keep using things like "my machine" and "someone chooses", which are misleading. In the common case, the machine has been sold long ago, and the current owner might actually prefer to choose the derivative software. The user-hostile DRM hardware has denied him that choice.
(The hardware vendors, of course, will argue the user made his choice when he bought the machine. Even accepting that position, one can't claim that such behavior supports choice, flexibility, or consumer power. Koenig made an aprops quote while appearing in "Batman: Dead End")
PS. Note that similar hard-DRM systems might also be implemented without signing, by storing hashes of an approved-kernel whitelist on a ROM in the hardware. This has practical disadvantages- it's harder for the vendor to ship a new kernel revision when bugfixes happen, and it might be easier to build modchips. But it could offer the vendor a legal protection from the license I describe, since he was not distributing a derivative work of my software without the full materials needed to recreate it.
PPS. I will further note that individuals have already attempted to exempt a single magic number (rather like a key) from the GPL requirement to provide source code. It failed. I don't remember the defendant, but you can find the case by searching for the plaintiff, John Carmack. (Yes, I know settlements are weak precedent!)
I'd pay good money to watch you try to withstand him in any legal argument. Scalia can barely stop the guy; you'd be mincemeat.
The US government doesn't even control it.
Have you been paying attention? The US thinks it can control everything, and unless something amazing happens at the next national election, they're going to try.
Sorry, but the US doesn't own the internet.
They own (or can dispatch SWAT teams to) every router that connects the US to the outside world. Might they someday decide to build the PATRIOT firewall which squelches untrusted packets to protect us from the dangers of worms, viruses, file-sharing, and terrorists? They'll jump to work on it the first time an Al-Quaida sympathsizer is caught with a homebrew Sarin recipe on his laptop.
in fact, most of them come from parts made in China, a country that would love to see US dominance further destabilised.
In China, a country that would love for the police to be able to monitor the computer usage of every citizen!
When you start to hold up China as a bulwark against authoritarianism, that should be a warning that things are going very wrong. China wants to sell PCs to the US. They also want to control the communication of their own citizens. By building "user-hostile" DRM, they can advance both goals.
One needs to question the ethics of anyone who would work on such a project.
That's a fair question. But these Dartmouth guys pass it. They're trying something that we all knew (or feared) would be possible, and demonstrating how practical it really is.
And they're publishing the results, so the public can discuss the implications now, before the Great Irreversable DRM Rollout happens.
It's surely better than if Microsoft, Sun, or Sony were conducting this research secretly! (Oh wait, they probably already have...)
I do not, however, like the attitude of the submitter's blurb, which spins this system as a useful feature to compete with Microsoft(tm), rather than a way to cut off the stream of cheap, general-purpose computers that make Open Source possible.
Your statement is right but your implementation is all wrong
I was describing a possible extension to the normal DRM scheme which could solve some of the problems amcguinn cited as to why DRM will never succeed in the marketplace. DRM-implementors don't have to do it my way- but if they don't, they'll lose some customers (maybe not enough for them to care)
But your software won't be able to access your Quicken billpaying database, because that is encrypted using a key that only Quicken-signed software can access.
In the hypothetical system I was describing, the authors of the DRM OS have created additional safeguards that will allow user-authored (or otherwise untrusted) programs to access some Quicken data, without being able to completely liberate it. Removing that limitation will make power-users like amcguinn more likely to buy a DRM-based PC.
Assuming that the vendor of both the OS and Quicken are in agreement, they can allow Quicken to output data in an unencrypted format. But the OS is trusted to not obey the user fully. It will manage that data and only allow limited operations on it. Any program which attempts to load the data will be placed in a restrictive sandbox, where it can perform some kinds of analysis and display, but not output anything to a remote computer by using a hard disk, network card, or printer.
With a system like this, it's still possible for user to run an unauthorized 3rd-party program to do a calculation on data stored in Quicken. But the 3rd-party program cannot be used as a bulk way to strip the protection from a mass of files.
Visited the NYT lately? How about LA Times? How about MIT Press? There are already hundreds, if not thousands of sites, locking their content away behind logins - they don't need DRM to do it.
You're avoiding the point. They already use logins today, and will in the future. But someday they can have these logins protected by DRM technology. They will get a minor economic advantage from this extra protection, but newspaper margins are slim, so they'll grab for it.
Then, it will be impossible to visit those sites with an untrusted OS. It will be impossible to build a PC, compile Linux, compile Mozilla, and use that to browse the web. The freedom of disorganized amateurs to create useful computer systems will be gone.
When free expression is no longer possible on US soil, US dollars will make sure there's a world of domains out there where speech remains free
That's a head-in-the-sand argument. "The government cannot now enforce a prohibition against a behavior. Therefore they will never be able to prohibit it."
Sorry, but in the face of ever-increasing computer power, that viewpoint just doesn't hold up. If you don't believe me, Lessig has published extensive documents describing exactly why.
2. Has the kernel module loading facility been disabled?
No, but it verifies that any modules have also been signed before loading them. (Alternatively, the superuser could force an untrusted module to be loaded, but this will taint the whole kernel and it will lose the ability to open protected files until you reboot)
1. Its open source. You must (by requirements of the GPL) be given everything you need to compile a derivitive work of this.
The currently prevaling legal interpretation (shared by Linus Torvalds amoung others) is that the signing key cannot be construed as part of the source code. Source code is human-readable description of what software does. A key is just 1024 bits of random noise.
The argument is that the GPL requires people to give you the source code to a program; they don't have to buy you the hardware needed to run it.
Suppose you buy a Playstation5 from Sony and request the kernel code under GPL. If you compile the kernel without having the key, you've got a working kernel. The hardware you own won't load it, but that's not Sony's problem. If you sign a pile of NDAs and supply a check for $65000, Sony will rent you one of the same developer-class machines their own programmers use to write games. That system will load unsigned code, although you've sworn in blood not to abuse that great priviledge.
I would rather that this legal interpretation doesn't hold, as it perverts the intent of GNU "Free Software", but it hasn't been seriously challenged yet.
Couldn't this be defeated by running a Pentium-with-palladium emulator.
An assumption that DRM-proponents sometimes forget to mention is that the system will require government cooperation to work at all.
Specifically, anyone who cracks open DRM hardware to read keys that could be used to make an emulator must be treated as the highest class of terrorist. To protect the American way, corporate property must be respected!
DRM technology is really only there to make the process of circumventing or emulating it so difficult that only a small number of smart, dedicated people can accomplish it. Those people can be suppressed by federal marshals (if US citizens) or FA-18s (if foreigners). The rest of the masses won't be able to defeat the hardware.
Enabling DRM is impossible in the sense that DRM doesn't cover the analog hole.
The technologies being used to enable DRM hardware create user-hostile computers and are a step along the way to plugging the "analog hole". You mention that digital cameras (still or video) are getting cheaper and better all the time. But digital watermarking already exists, and digital shape-recognition is getting better and better. Long-term, the advances in software will overwhelm hardware improvements. Hardware may open an analog hole, but software will close it.
Future scenario: 20 years from now, a friend visits you with a laptop, and he plays music while your webcam dumps his whole visit into a 3 terabyte AVI.
Weeks later, you'll order a few MP8 songs with your credit card. A click-through license agreement gives the publisher certain rights to monitior your compliance. In collaboration with your OS vendor, they transmit a program onto your PC during a routine system update. This program runs automatically during periods of low CPU use and scans your audio data for any patterns resembling something the publisher owns (not just the songs you rented, but anything in their vast catalog). The software is fast, because it only needs to read user-recorded files. The majority of your songs were legally downloaded and have a copy-protect flag, so they can be skipped.
If an unprotected file gets a 98% confidence match on anything they own, it is automatically uploaded to a lawyer on another continent. This man doesn't know what user's computer it came from, and is sworn not to violate your privacy if the file turns out to be anything other than an analog copy of his client's work. After a quick human-verification that the file sounds the same, the publisher's HQ sends an emergency message to both the OS vendor and the FBI. Instantaneously, your computer freezes up to protect evidence, and an arrest warrant pours out of the fax machine of the nearest police department.
a proportion of the software on the desktop is in-house developed. Will the corporate IT department accept a windows upgrade that would mean every new release had to be submitted to MS for signing? Will they accept an office upgrade that would mean they can no longer exchange data between standard and in-house applications?
That's no obstacle to user-hostile DRM. (Read my other comments in this thread for more explanation).
The heart of "hard DRM" is that the hardware, OS, and application all form a chain of trust that will not willingly violate any copy-protection labels applied to a piece of data.
All of the data processed by your company will have flags stored in the filesystem indicating either that it belongs to your corporation, or is unprotected. When a trusted program loads the data, it will correctly propagate that flag to any output files. When an untrusted program loads data, the OS will do that job for it. The program will only be allowed to load files from a single owner in one session, and any output it generates will be stamped with the most restrictive flags from any file it read.
That is, a DRM OS may permit you to run untrusted code, but it will assume the worst and flag any outputs of that program as infringing copies of whatever inputs it had. If you load an MP3 into a custom program which writes the average loudness into a small text file, that output will have the same restriction flags as the original song file. It will only be readable as long as your paid license to hear the MP3 is still in force.
PS. Naturally, an effective DRM implementation also assumes some other changes will be done as a prerequisit. Well-known protections against memory corruption and buffer overflows will need to be added as a matter of course.
Tricking "signed" applications to doing things they aren't supposed to do was demonstrated to great effect with the XBox hack.
That's a temporary effect- you cannot rely on that kind of weakness continuing to work.
Current and near-future implementations of hardware DRM will have a weakness in that if an unsafe application is accidently signed, it becomes a permanently exploitable hole on that platform. This has already been demonstrated with a buffer-overrun in a certain James Bond game.
However, highspeed internet access will be eventually be ubiquitious. In 15 years or so, a tiny, low-power chip will get you a 56Kbps connection from anywhere on the planet for a neglible cost. When that time comes, bugs in signed code will no longer be a weakness to hard DRM.
It will become easy to revoke a specific certificate even after the code has been deployed. Before loading any program, the OS will just send a hash-value back to the secure fortress of the original signing authority. If a once-trusted program has been found to be buggy, then the OS will blacklist it from execution until a (certified) patch is applied.
(In fact, an even worse scenario might happen: If the OS ever learns that a program you've been running is exploitable, it could retroactively destroy any files that were written by the program, just in case they had some "stolen" data. Nah, that level of response is too extreme even for the RIAA)
I haven't bought a DVD player, and have never bought a DVD, because I would miss being able to easily copy movies like I can do so easily now with my VCR.
If you copy movies with a VCR, you must be doing some illegal trick to circumvent Macrovision.
If you get a $25 DVD player for your computer, you can copy movies using an easy trick called DeCSS (look for it on a T-Shirt).
There's no difference between a VCR and DVD in this area, except that DVD players don't include write-equipment by default. But that's a technological restriction, not a legal or copy-protection one. Buying VHS but not DVD is not a way to send the manufacturers any kind of political message.
Now, if the company was prepared to make the large investment in setting up a full TCPA-style architecture to stop me doing that
It won't be a large investment. Or at least, it won't look like a big investment until we're several years down the path and in too deep to back out.
The initial capital to deploy DRM will be supplied by corporations with a long-term interest. This means *AA somewhat, but more directly computer corps like Intel and especially Microsoft(tm).
Primarily, Microsoft and Intel will work together to get DRM into the next generation of motherboards, with the 2006 revision of Windows(r) as the first trusted OS. Even though big corps like IBM will be able to market signed Linux distributions, that change will help Microsoft (and other established industry-leaders) by strenghtening barriers to entry. The development of Linux will be slowed because unfunded amateurs won't be able to test their modifications without major sponsorship. (That reason alone is enough to justify Microsoft underwriting DRM deployment)
Once "optional" DRM features are standard equipment on every new PC, it'll no longer be a significant cash investment for a corporation who wants to use DRM to lock their own boxes to an approved list of software.
Secondly, the value of a general-purpose computer that will easily run new software is so high even for the ordinary home user that they will not be entirely replaced by DRM-enabled home entertainment consoles.
The ability to quickly download and run a new program is valuable. However, DRM can be implemented in a way which is mostly compatible with that ability. This unfortunately means that we cannot depend on market pressure to protect us from the spread of hard DRM.
It is already a recommended software engineering practice to use system libraries to access data and to run new programs in unpriviledged sandboxes. The natural extension of those techniques to DRM will handle 95% of a typical user's need to run custom software.
Here's how it might work:
You get a computer with a DRM chip that'll only load a trusted OS: either Microsoft(tm) Windows(r), or RedHat Linux 12.1 (Redhat has no choice but to cooperate with DRM proponents or go bankrupt). That OS, in turn, will check that executables are certified to protect any proprietary data they load.
You're a power-user, so you occasionally download new programs. And you're a programmer, so you occasionally write your own. Many of the executables you download and 100% of the ones you write will be flagged by the OS as untrusted.
Untrusted programs can be run, but only in a virtual machine "sandbox" type environment. They can't access hardware or filesystems at a low level. An untrusted program can load unprotected files, display data onscreen, and also save unprotected files. But if it tries to load a protected file (something with a "copy-protect" flag set), then the OS cripples the program. It no longer has any ability to save files to disk or to use a printer. It certainly can't send network packets. Even screen-dumps and vidcap won't work on the application. Maybe it can send data to other programs (with copy&paste or a similar mechanism), but any recipients will become untrusted and face the same restrictions.
In a system implemented as I described (or in several possible variants), the average consumer would still get most of the benefits of running custom code. She could download Bejeweled to play a game. She could run an amortizer plugin over financial data, or an animated filter on a WMA song.
But you've still lost the ability to execute a fully-generic program that gives all data-processing authority to the local user. Will the public care about that loss? I can't see why it'd bother them.
No they don't. Look at the page you're reading now... megabytes and megabytes of "content". Visit msn.com or nytimes.com or even mapquest.com. What do you find there? More and more content.
Now, you are correct that the entertainment industry (RIAA + MPAA) doesn't allow a significant amount of their product to be released in digital format, and that hardware-enforced DRM would encourage them to release more. But music and videos aren't the entierty of "content"- in fact, they're arguably the least useful content, from the standpoint of doing practical work.
The proliferation of DRM technology would also lead existing websites to use it. Many of the free newspapers would go away. The minority of sites that remain free will probably use DRM to mandate user login accounts. The even smaller minority that don't log r users will probably engage some DRM flags to stop their files from being printed or locally stored.
That kind of behavior will make a computer running Open Source software useless for general-purpose web-browsing. (And web-browsing is the #1 most important task most computers are used for)
PS. Some people will object and say "A DRM computer can use an Open Source OS! As long as a 3rd party signs the specific binary that's running, the end-user can be allowed to read the source code". That may be true, but if the user has no ability to modify the code he runs then it's not Free or Open software from any practical perspective.
One of many potential problems with a super-long railgun would be its vulnerability. Something that big cannot be effectively patrolled along its whole length. Terrorist saboteurs might get a destructive payoff if they damage the halfway point of the rail while a launch is in progress.
(The launch site should be chosen carefully so there are no valuable population centers to be struck if an aborted launch puts a heavy vehicle zooming along with less velocity than intended)
but upon loss of propulsion the deceleration due to air
That becomes a bigger problem when a long, 100km track is considered. A long track will have to be at a low angle, increasing the amount of time the vehicle spends flying through air. Shorter tracks of under 5km could be at a steeper angle and come closer to the trajectory of a modern shuttle launch.
However, building even a 5km railgun would stress contemporary engineering techniques.
One thing Bush does have right is that to get any farther than we have, we need nuclear powered craft.
That could be one of the best uses of a railgun launch system. Putting major quantities of nuclear fuel ontop of a rocket (that might explode in the atmosphere) will always be percieved as a major public hazard. The ~1% failure rate for orbital rockets is too risky for decent atomic payloads to be accepted. (There was an uproar over even the small Cassini reactor)
A magnetically-launched vehicle will be much safer. A projectile from a railgun will be inert once it leaves the track, and will stay safely in orbit even if a disaster occurs. Using a system like that to supply reactive mass to an orbital construction site for a Mars vehicle is a plausible idea.
A similar, but stronger railgun might be used to dispose of hazardous nuculear waste... although I haven't worked out the math to see if the energy required for the launch would be sufficiently less than what the uranium generated back in the power plant.
Slashdot Mirror
That house has been rebuilt. With traditional Japanese building materials, no residence can survive more than 40 years. It might be replaced piece-by-piece, or all at once after a disaster, but the original building is gone.
..." ?
PS. What's the rule of thumb for evaluating the veracity of any sentence starting with "100% of the
(Nobody should mod you down for that. Real flamebait looks distinctly different)
I might add that the Japanese military would have shown no similar sense of honor.
Some would question whether avoiding potentially useful targets, which prolongs the fighting and endagers your own troops, is really "honor". What does it mean to value some rotting wooden buildings over human lives?
Others might ask if commanding a single pilot to kill 100,000 helpless civilians simply to impress the USSR is honorable.
But let's not get into that.
make a big, heavy, crude sucker out of whatever you can turn to the task.
The word "crude" has no place around atomic weapons. You've got to line up the atoms exactly, or almost nothing happens.
However, it would be quite reasonable to ship a bomb as little parts, each 40kg or less, which can be assembled near the target site. I'd personally recommend concealing them inside the air-gaps within wide-screen TVs being shipped from China, but there are lots of ways to hide these things.
gasp, use the internet.
I've got a screenplay to sell you. An attractive teenage hacker stumbles onto a terrorist plot to nuke Washington, but he wards it off with a quick DDoS worm. Now he's got to find the bomb and unplug it while dodging the FBI and HLS agents hot on his trail!
As soon as somebody uses Nukes on the U.S. they would be screwed the moment the CIA investigation got overwith.
Oh, a CIA investigation! Oh that's really reliable. Especially considering that all direct evidence of the perpetrators was atomized at ground zero. As was Langley itself.
The only evidence firm enough for a reflexive venegance-strike is a radar-track from Lesotho to Pennsylvania Avenue.
That'd be a "blink and you missed it" kinda thing. What if the political leaders didn't happen to be watching? What if it was hard to judge distance, and they assumed a conventional bomb had nearly missed them? A blast over water doesn't leave tangible evidence behind (unless prehaps it destroyed some warships, but the Imperial Navy was already pushing up coral)
To make a good demonstration, you'd need to do it on lightly inhabited land so that nearby people can wander onto the blast area and gaze around in awe before reporting back to the emperor. And you'd want to telegraph a warning 24 hours ahead, to re-emphasize military superiority (proving that it wasn't some kind of natural volcano).
Mt. Fuji would've been an ideal target. Take a scared mountain and convert it into a scared gravel pit. That would be an undeniable show of force!
Is Hiroshima as it was after the blast?
Hiroshima is gorgeous. It's not a crater and not a radioactive wasteland. Unless you recognize the name, you'd have no way to tell it apart from any other gleaming Japanese city. Some people have absorbed anti-nuclear propaganda and assume that atomic weapons will render the target area uninhabitable for centuries. That's just wrong (although the propaganda is based on Cold War era weapons, which dwarf the power of the bombs dropped on Japan)
Note that 100% of Japanese cities were bombed flat in WWII, so all buildings are less than 50 years old (even without the bombing, earthquakes would keep destroying them). Thus they may all look similar to a naive visitor.
The world needs missiles.
Nope.
Eventually every nation, even the ones in Africa, will have nukes.
Yep.
"Nukes" are nuclear explosives, sometimes called "warheads". They do not need missiles to deliver them. Kamikaze terrorists are sufficient. A good ICBM shield does nothing against nukes.
An African nation that fired an ICBM at the US would have 80 missiles targeted to melt it into a puddle before their single shot even reached the Atlantic. Any non-suicidal African dictator who wishes to nuke America will transport the bomb by SUV, not ICBM.
How would you feel if I simply said "I trust software version N, the one with hash X." Is that okay, or is my comment a derivative work, too?
As I explicitly stated in a postscript, asserting that code matching a hash value is trusted is not a derivative work. (The hash contains a negligibly small fraction of the copyrighted work, making it a fair-use exception)
Signing creates a new file with your stuff at the beginning and end and my code in the middle. That means it's a derivative work. (The signed binary contains 100% of the copyrighted work, which is illegal to redistribute without permission)
Hardware vendors can work around that interpretation by distributing hashes and executables separately. That dodge may or may not be a legal loophole.
I could sign your GNU software, and set up a machine that will only run the signed version.
The argument I would hope to make (possibly needing a modified GPL license version to explicitly require this) is that by signing the software (which is my copyright), you have created a derivative work, which is illegal. The only way I'll permit you to distribute it is if you agree to supply the recipients with anything needed to create the binary they got. This means the source code, the compilers (if they're hard to get), and the private key.
Of course, if you're obliged to give out that private key, then there was no reason to sign at all.
As a non-lawyer, I can't construct a good license to enforce that requirement, but in time the FSF will be forced to address this issue. They might even be able to content that the existing GPL already suffices.
Then when someone creates a derivative work, it would not run on my machine.
You keep using things like "my machine" and "someone chooses", which are misleading. In the common case, the machine has been sold long ago, and the current owner might actually prefer to choose the derivative software. The user-hostile DRM hardware has denied him that choice.
(The hardware vendors, of course, will argue the user made his choice when he bought the machine. Even accepting that position, one can't claim that such behavior supports choice, flexibility, or consumer power. Koenig made an aprops quote while appearing in "Batman: Dead End")
PS. Note that similar hard-DRM systems might also be implemented without signing, by storing hashes of an approved-kernel whitelist on a ROM in the hardware. This has practical disadvantages- it's harder for the vendor to ship a new kernel revision when bugfixes happen, and it might be easier to build modchips. But it could offer the vendor a legal protection from the license I describe, since he was not distributing a derivative work of my software without the full materials needed to recreate it.
PPS. I will further note that individuals have already attempted to exempt a single magic number (rather like a key) from the GPL requirement to provide source code. It failed. I don't remember the defendant, but you can find the case by searching for the plaintiff, John Carmack. (Yes, I know settlements are weak precedent!)
Now that most of the lies and falsehoods have been eliminated (Your system won't boot linux!
It won't. Will Linus Torvalds be able to pull a tarball from kernel.org, compile it, and boot it on the system?
No he will not.
That ain't Linux.
Not in any useful way. It's been gutted, it's soulless, it's dead.
Dude, Lessig is simply wrong...
I'd pay good money to watch you try to withstand him in any legal argument. Scalia can barely stop the guy; you'd be mincemeat.
The US government doesn't even control it.
Have you been paying attention? The US thinks it can control everything, and unless something amazing happens at the next national election, they're going to try.
Sorry, but the US doesn't own the internet.
They own (or can dispatch SWAT teams to) every router that connects the US to the outside world. Might they someday decide to build the PATRIOT firewall which squelches untrusted packets to protect us from the dangers of worms, viruses, file-sharing, and terrorists? They'll jump to work on it the first time an Al-Quaida sympathsizer is caught with a homebrew Sarin recipe on his laptop.
in fact, most of them come from parts made in China, a country that would love to see US dominance further destabilised.
In China, a country that would love for the police to be able to monitor the computer usage of every citizen!
When you start to hold up China as a bulwark against authoritarianism, that should be a warning that things are going very wrong. China wants to sell PCs to the US. They also want to control the communication of their own citizens. By building "user-hostile" DRM, they can advance both goals.
One needs to question the ethics of anyone who would work on such a project.
That's a fair question. But these Dartmouth guys pass it. They're trying something that we all knew (or feared) would be possible, and demonstrating how practical it really is.
And they're publishing the results, so the public can discuss the implications now, before the Great Irreversable DRM Rollout happens.
It's surely better than if Microsoft, Sun, or Sony were conducting this research secretly! (Oh wait, they probably already have...)
I do not, however, like the attitude of the submitter's blurb, which spins this system as a useful feature to compete with Microsoft(tm), rather than a way to cut off the stream of cheap, general-purpose computers that make Open Source possible.
Your statement is right but your implementation is all wrong
I was describing a possible extension to the normal DRM scheme which could solve some of the problems amcguinn cited as to why DRM will never succeed in the marketplace. DRM-implementors don't have to do it my way- but if they don't, they'll lose some customers (maybe not enough for them to care)
But your software won't be able to access your Quicken billpaying database, because that is encrypted using a key that only Quicken-signed software can access.
In the hypothetical system I was describing, the authors of the DRM OS have created additional safeguards that will allow user-authored (or otherwise untrusted) programs to access some Quicken data, without being able to completely liberate it. Removing that limitation will make power-users like amcguinn more likely to buy a DRM-based PC.
Assuming that the vendor of both the OS and Quicken are in agreement, they can allow Quicken to output data in an unencrypted format. But the OS is trusted to not obey the user fully. It will manage that data and only allow limited operations on it. Any program which attempts to load the data will be placed in a restrictive sandbox, where it can perform some kinds of analysis and display, but not output anything to a remote computer by using a hard disk, network card, or printer.
With a system like this, it's still possible for user to run an unauthorized 3rd-party program to do a calculation on data stored in Quicken. But the 3rd-party program cannot be used as a bulk way to strip the protection from a mass of files.
Visited the NYT lately? How about LA Times? How about MIT Press? There are already hundreds, if not thousands of sites, locking their content away behind logins - they don't need DRM to do it.
You're avoiding the point. They already use logins today, and will in the future. But someday they can have these logins protected by DRM technology. They will get a minor economic advantage from this extra protection, but newspaper margins are slim, so they'll grab for it.
Then, it will be impossible to visit those sites with an untrusted OS. It will be impossible to build a PC, compile Linux, compile Mozilla, and use that to browse the web. The freedom of disorganized amateurs to create useful computer systems will be gone.
When free expression is no longer possible on US soil, US dollars will make sure there's a world of domains out there where speech remains free
That's a head-in-the-sand argument. "The government cannot now enforce a prohibition against a behavior. Therefore they will never be able to prohibit it."
Sorry, but in the face of ever-increasing computer power, that viewpoint just doesn't hold up. If you don't believe me, Lessig has published extensive documents describing exactly why.
2. Has the kernel module loading facility been disabled?
No, but it verifies that any modules have also been signed before loading them. (Alternatively, the superuser could force an untrusted module to be loaded, but this will taint the whole kernel and it will lose the ability to open protected files until you reboot)
1. Its open source. You must (by requirements of the GPL) be given everything you need to compile a derivitive work of this.
The currently prevaling legal interpretation (shared by Linus Torvalds amoung others) is that the signing key cannot be construed as part of the source code. Source code is human-readable description of what software does. A key is just 1024 bits of random noise.
The argument is that the GPL requires people to give you the source code to a program; they don't have to buy you the hardware needed to run it.
Suppose you buy a Playstation5 from Sony and request the kernel code under GPL. If you compile the kernel without having the key, you've got a working kernel. The hardware you own won't load it, but that's not Sony's problem. If you sign a pile of NDAs and supply a check for $65000, Sony will rent you one of the same developer-class machines their own programmers use to write games. That system will load unsigned code, although you've sworn in blood not to abuse that great priviledge.
I would rather that this legal interpretation doesn't hold, as it perverts the intent of GNU "Free Software", but it hasn't been seriously challenged yet.
Couldn't this be defeated by running a Pentium-with-palladium emulator.
An assumption that DRM-proponents sometimes forget to mention is that the system will require government cooperation to work at all.
Specifically, anyone who cracks open DRM hardware to read keys that could be used to make an emulator must be treated as the highest class of terrorist. To protect the American way, corporate property must be respected!
DRM technology is really only there to make the process of circumventing or emulating it so difficult that only a small number of smart, dedicated people can accomplish it. Those people can be suppressed by federal marshals (if US citizens) or FA-18s (if foreigners). The rest of the masses won't be able to defeat the hardware.
Anyone who wants to win a 10 month, all-expenses-paid to gorgeous Club Fed in Guantanamo Bay, Cuba!
Enabling DRM is impossible in the sense that DRM doesn't cover the analog hole.
The technologies being used to enable DRM hardware create user-hostile computers and are a step along the way to plugging the "analog hole". You mention that digital cameras (still or video) are getting cheaper and better all the time. But digital watermarking already exists, and digital shape-recognition is getting better and better. Long-term, the advances in software will overwhelm hardware improvements. Hardware may open an analog hole, but software will close it.
Future scenario:
20 years from now, a friend visits you with a laptop, and he plays music while your webcam dumps his whole visit into a 3 terabyte AVI.
Weeks later, you'll order a few MP8 songs with your credit card. A click-through license agreement gives the publisher certain rights to monitior your compliance. In collaboration with your OS vendor, they transmit a program onto your PC during a routine system update. This program runs automatically during periods of low CPU use and scans your audio data for any patterns resembling something the publisher owns (not just the songs you rented, but anything in their vast catalog). The software is fast, because it only needs to read user-recorded files. The majority of your songs were legally downloaded and have a copy-protect flag, so they can be skipped.
If an unprotected file gets a 98% confidence match on anything they own, it is automatically uploaded to a lawyer on another continent. This man doesn't know what user's computer it came from, and is sworn not to violate your privacy if the file turns out to be anything other than an analog copy of his client's work. After a quick human-verification that the file sounds the same, the publisher's HQ sends an emergency message to both the OS vendor and the FBI. Instantaneously, your computer freezes up to protect evidence, and an arrest warrant pours out of the fax machine of the nearest police department.
a proportion of the software on the desktop is in-house developed. Will the corporate IT department accept a windows upgrade that would mean every new release had to be submitted to MS for signing? Will they accept an office upgrade that would mean they can no longer exchange data between standard and in-house applications?
That's no obstacle to user-hostile DRM. (Read my other comments in this thread for more explanation).
The heart of "hard DRM" is that the hardware, OS, and application all form a chain of trust that will not willingly violate any copy-protection labels applied to a piece of data.
All of the data processed by your company will have flags stored in the filesystem indicating either that it belongs to your corporation, or is unprotected. When a trusted program loads the data, it will correctly propagate that flag to any output files. When an untrusted program loads data, the OS will do that job for it. The program will only be allowed to load files from a single owner in one session, and any output it generates will be stamped with the most restrictive flags from any file it read.
That is, a DRM OS may permit you to run untrusted code, but it will assume the worst and flag any outputs of that program as infringing copies of whatever inputs it had. If you load an MP3 into a custom program which writes the average loudness into a small text file, that output will have the same restriction flags as the original song file. It will only be readable as long as your paid license to hear the MP3 is still in force.
PS. Naturally, an effective DRM implementation also assumes some other changes will be done as a prerequisit. Well-known protections against memory corruption and buffer overflows will need to be added as a matter of course.
Tricking "signed" applications to doing things they aren't supposed to do was demonstrated to great effect with the XBox hack.
That's a temporary effect- you cannot rely on that kind of weakness continuing to work.
Current and near-future implementations of hardware DRM will have a weakness in that if an unsafe application is accidently signed, it becomes a permanently exploitable hole on that platform. This has already been demonstrated with a buffer-overrun in a certain James Bond game.
However, highspeed internet access will be eventually be ubiquitious. In 15 years or so, a tiny, low-power chip will get you a 56Kbps connection from anywhere on the planet for a neglible cost. When that time comes, bugs in signed code will no longer be a weakness to hard DRM.
It will become easy to revoke a specific certificate even after the code has been deployed. Before loading any program, the OS will just send a hash-value back to the secure fortress of the original signing authority. If a once-trusted program has been found to be buggy, then the OS will blacklist it from execution until a (certified) patch is applied.
(In fact, an even worse scenario might happen: If the OS ever learns that a program you've been running is exploitable, it could retroactively destroy any files that were written by the program, just in case they had some "stolen" data. Nah, that level of response is too extreme even for the RIAA)
I haven't bought a DVD player, and have never bought a DVD, because I would miss being able to easily copy movies like I can do so easily now with my VCR.
If you copy movies with a VCR, you must be doing some illegal trick to circumvent Macrovision.
If you get a $25 DVD player for your computer, you can copy movies using an easy trick called DeCSS (look for it on a T-Shirt).
There's no difference between a VCR and DVD in this area, except that DVD players don't include write-equipment by default. But that's a technological restriction, not a legal or copy-protection one. Buying VHS but not DVD is not a way to send the manufacturers any kind of political message.
Now, if the company was prepared to make the large investment in setting up a full TCPA-style architecture to stop me doing that
It won't be a large investment. Or at least, it won't look like a big investment until we're several years down the path and in too deep to back out.
The initial capital to deploy DRM will be supplied by corporations with a long-term interest. This means *AA somewhat, but more directly computer corps like Intel and especially Microsoft(tm).
Primarily, Microsoft and Intel will work together to get DRM into the next generation of motherboards, with the 2006 revision of Windows(r) as the first trusted OS. Even though big corps like IBM will be able to market signed Linux distributions, that change will help Microsoft (and other established industry-leaders) by strenghtening barriers to entry. The development of Linux will be slowed because unfunded amateurs won't be able to test their modifications without major sponsorship. (That reason alone is enough to justify Microsoft underwriting DRM deployment)
Once "optional" DRM features are standard equipment on every new PC, it'll no longer be a significant cash investment for a corporation who wants to use DRM to lock their own boxes to an approved list of software.
The ability to quickly download and run a new program is valuable. However, DRM can be implemented in a way which is mostly compatible with that ability. This unfortunately means that we cannot depend on market pressure to protect us from the spread of hard DRM.
It is already a recommended software engineering practice to use system libraries to access data and to run new programs in unpriviledged sandboxes. The natural extension of those techniques to DRM will handle 95% of a typical user's need to run custom software.
Here's how it might work:
You're a power-user, so you occasionally download new programs. And you're a programmer, so you occasionally write your own. Many of the executables you download and 100% of the ones you write will be flagged by the OS as untrusted.
Untrusted programs can be run, but only in a virtual machine "sandbox" type environment. They can't access hardware or filesystems at a low level. An untrusted program can load unprotected files, display data onscreen, and also save unprotected files. But if it tries to load a protected file (something with a "copy-protect" flag set), then the OS cripples the program. It no longer has any ability to save files to disk or to use a printer. It certainly can't send network packets. Even screen-dumps and vidcap won't work on the application. Maybe it can send data to other programs (with copy&paste or a similar mechanism), but any recipients will become untrusted and face the same restrictions.
In a system implemented as I described (or in several possible variants), the average consumer would still get most of the benefits of running custom code. She could download Bejeweled to play a game. She could run an amortizer plugin over financial data, or an animated filter on a WMA song.
But you've still lost the ability to execute a fully-generic program that gives all data-processing authority to the local user. Will the public care about that loss? I can't see why it'd bother them.
But right now they have it all "locked" away
No they don't. Look at the page you're reading now... megabytes and megabytes of "content". Visit msn.com or nytimes.com or even mapquest.com. What do you find there? More and more content.
Now, you are correct that the entertainment industry (RIAA + MPAA) doesn't allow a significant amount of their product to be released in digital format, and that hardware-enforced DRM would encourage them to release more. But music and videos aren't the entierty of "content"- in fact, they're arguably the least useful content, from the standpoint of doing practical work.
The proliferation of DRM technology would also lead existing websites to use it. Many of the free newspapers would go away. The minority of sites that remain free will probably use DRM to mandate user login accounts. The even smaller minority that don't log r users will probably engage some DRM flags to stop their files from being printed or locally stored.
That kind of behavior will make a computer running Open Source software useless for general-purpose web-browsing. (And web-browsing is the #1 most important task most computers are used for)
PS. Some people will object and say "A DRM computer can use an Open Source OS! As long as a 3rd party signs the specific binary that's running, the end-user can be allowed to read the source code". That may be true, but if the user has no ability to modify the code he runs then it's not Free or Open software from any practical perspective.
Why not 100km, 200km?
One of many potential problems with a super-long railgun would be its vulnerability. Something that big cannot be effectively patrolled along its whole length. Terrorist saboteurs might get a destructive payoff if they damage the halfway point of the rail while a launch is in progress.
(The launch site should be chosen carefully so there are no valuable population centers to be struck if an aborted launch puts a heavy vehicle zooming along with less velocity than intended)
but upon loss of propulsion the deceleration due to air
That becomes a bigger problem when a long, 100km track is considered. A long track will have to be at a low angle, increasing the amount of time the vehicle spends flying through air. Shorter tracks of under 5km could be at a steeper angle and come closer to the trajectory of a modern shuttle launch.
However, building even a 5km railgun would stress contemporary engineering techniques.
One thing Bush does have right is that to get any farther than we have, we need nuclear powered craft.
That could be one of the best uses of a railgun launch system. Putting major quantities of nuclear fuel ontop of a rocket (that might explode in the atmosphere) will always be percieved as a major public hazard. The ~1% failure rate for orbital rockets is too risky for decent atomic payloads to be accepted. (There was an uproar over even the small Cassini reactor)
A magnetically-launched vehicle will be much safer. A projectile from a railgun will be inert once it leaves the track, and will stay safely in orbit even if a disaster occurs. Using a system like that to supply reactive mass to an orbital construction site for a Mars vehicle is a plausible idea.
A similar, but stronger railgun might be used to dispose of hazardous nuculear waste... although I haven't worked out the math to see if the energy required for the launch would be sufficiently less than what the uranium generated back in the power plant.