Linus on DRM 969
Thread on LKML:
Date: Wed, 23 Apr 2003 20:59:45 -0700 (PDT)
From: Linus Torvalds
To: Kernel Mailing List
Subject: Flame Linus to a crisp!
Ok,
there's no way to do this gracefully, so I won't even try. I'm going to
just hunker down for some really impressive extended flaming, and my
asbestos underwear is firmly in place, and extremely uncomfortable.
I want to make it clear that DRM is perfectly ok with Linux!
There, I've said it. I'm out of the closet. So bring it on...
I've had some private discussions with various people about this already,
and I do realize that a lot of people want to use the kernel in some way
to just make DRM go away, at least as far as Linux is concerned. Either by
some policy decision or by extending the GPL to just not allow it.
In some ways the discussion was very similar to some of the software
patent related GPL-NG discussions from a year or so ago: "we don't like
it, and we should change the license to make it not work somehow".
And like the software patent issue, I also don't necessarily like DRM
myself, but I still ended up feeling the same: I'm an "Oppenheimer", and I
refuse to play politics with Linux, and I think you can use Linux for
whatever you want to - which very much includes things I don't necessarily
personally approve of.
The GPL requires you to give out sources to the kernel, but it doesn't
limit what you can _do_ with the kernel. On the whole, this is just
another example of why rms calls me "just an engineer" and thinks I have
no ideals.
[ Personally, I see it as a virtue - trying to make the world a slightly
better place _without_ trying to impose your moral values on other
people. You do whatever the h*ll rings your bell, I'm just an engineer
who wants to make the best OS possible. ]
In short, it's perfectly ok to sign a kernel image - I do it myself
indirectly every day through the kernel.org, as kernel.org will sign the
tar-balls I upload to make sure people can at least verify that they came
that way. Doing the same thing on the binary is no different: signing a
binary is a perfectly fine way to show the world that you're the one
behind it, and that _you_ trust it.
And since I can imaging signing binaries myself, I don't feel that I can
disallow anybody else doing so.
Another part of the DRM discussion is the fact that signing is only the
first step: _acting_ on the fact whether a binary is signed or not (by
refusing to load it, for example, or by refusing to give it a secret key)
is required too.
But since the signature is pointless unless you _use_ it for something,
and since the decision how to use the signature is clearly outside of the
scope of the kernel itself (and thus not a "derived work" or anything like
that), I have to convince myself that not only is it clearly ok to act on
the knowledge of whather the kernel is signed or not, it's also outside of
the scope of what the GPL talks about, and thus irrelevant to the license.
That's the short and sweet of it. I wanted to bring this out in the open,
because I know there are people who think that signed binaries are an act
of "subversion" (or "perversion") of the GPL, and I wanted to make sure
that people don't live under mis-apprehension that it can't be done.
I think there are many quite valid reasons to sign (and verify) your
kernel images, and while some of the uses of signing are odious, I don't
see any sane way to distinguish between "good" signers and "bad" signers.
Comments? I'd love to get some real discussion about this, but in the end
I'm personally convinced that we have to allow it.
Btw, one thing that is clearly _not_ allowed by the GPL is hiding private
keys in the binary. You can sign the binary that is a result of the build
process, but you can _not_ make a binary that is aware of certain keys
without making those keys public - because those keys will obviously have
been part of the kernel build itself.
So don't get these two things confused - one is an external key that is
applied _to_ the kernel (ok, and outside the license), and the other one
is embedding a key _into_ the kernel (still ok, but the GPL requires that
such a key has to be made available as "source" to the kernel).
Linus
Huh? (Score:4, Interesting)
Is that "Oppenheimer" as in the head of the most politically motivated science program of all time?
DRM's not really about Linux, anyhow... (Score:2, Interesting)
If you disable sharing of certain digital information for a vast majority of users, you've effectively plugged up the problem. Obviously, you'll never stop *everybody*, so that's not a realistic goal in the first place. So it doesn't really matter what Linus thinks/does, at least not in this point in time (the GUIs that come with the popular Linux distributions ain't ready to take a serious run at the desktop yet).
what ? (Score:3, Interesting)
Can someone explain what's he talking about here ?
AFAIK, You sign someting with your private key and ppl. can use your public key to verify the integrety of the message.
Also if you want encryption, then u encrypt with the receivers public key so that only he can decrypt it with his private key
No where in this process is the private key required to be disclosed.
So what am i missing here ? or is he talking of some totally different keys ?
I'm glad linus did this (Score:3, Interesting)
Linux needs some DRM infrastructure, though it's use is to be discouraged. It is not tech's place to play politics. Linux will need DRM to be used everywhere, as it can today as soon as MS makes it availible for the studios to use.
I stand behind Linus here.
DRM will be *needed* by linux (Score:5, Interesting)
Look, you put out a set-top media box running embedded Linux. Assuming it is the multimedia grail (online video/audio playback & capture) it will do more than GPL/opensource codecs. It will NEED to handle WMAs and other proprietary formats that may include a time-locked DRM.
Do I like blanket DRM? No, I want to be able to make backups of my DVDs, CDs, and other purchased materials.
What I don't have a problem with is a box that will D/L the movie I want to watch and store it for a max of 48 hours in a "digital Blockbuster" scenario. And that will eventually happen as digital cable set-top boxes will include hard drives for local caching and they will require DRM on that hardware.
Same thing goes for more and more Point of Sale stations. Signed binary data will be more and more necessary. I'm waiting for the day software compares my signature with the one stored on the credit card's chip. And I'm all for it.
I'll be honest; I want them to be able to choose linux. The other option is that everything becomes Windows. Do you really want every credit card terminal, ATM and terminal to be Windows because it is the only thing that supports DRM?
I think Linus Missed the Point.... (Score:2, Interesting)
Making the Kernel Compliant so that it will refuse to let certain media types run because the OS/System doesn't have the secret key to that media type...NOT OK...
The Preblem is in the furture inorder for some media types to run in the future to run public/private key stuff is going to hace to happen...however how can that happen in an OS kernel whose source code is public...the private key is then exposed to the world, which the media people who want this crap will never stand for...it could be wrapped up in a shared lib...but that violates everything OSS stands for...
DRM for the kernel to run on hardware which requires a signed binary is OK, I suppose although how do you control that since if I complie up my own kernel I need to sign it somehow to get it to run on my protected hardware, which means I have the ability to sign any binary to make it run on protected hardware...including a virus...and also I don't see myself spending 100's to 1000's of dollars to aquire the right to make binaries that run on my own computer....which is really where this discussion ultimately heads...
Re:Props to Linus (Score:5, Interesting)
Re:what ? (Score:4, Interesting)
External keys are fine.
Re:Corn crops to Linus (Score:5, Interesting)
Don't use the GPL
Ah... I see. Apparantly the only way you can have morals is to use the GPL. Righto.
And, apparantly, Linus's refusal to go off the deep end on zealotry means that he's "wimped out". Got it.
It must be nice to view the world in black and white... so easy, so simple... so naive and foolish.
Linus is making the right call here... there are valid reasons for DRM-like policies. There are lots of invalid ones too. But if you want it to be free, then it needs to be free. Trying to contort the GPL or other free license to fit your world view is bullshit, and it undermines the entire point of the license.
Comment removed (Score:2, Interesting)
Re:what ? (Score:5, Interesting)
I think he's talking about a situation such as DVD-CSS, where content is encrypted with a product key and the product key is protected by being encrypted with a master key which is embedded in the OS itself. Then only the OS can obtain the product keys needed to decrypt the contents, and the OS can enforce any access controls it wants on the content because the user can't get at the content except by going through the OS. What he's saying is that doing that is perfectly OK under the Linux license, as long as you release the master key, in the clear, as part of the OS source just as the license requires.
Yes, that does make the master key useless for it's intended purpose. :)
linux and DRM pros/cons (Score:2, Interesting)
the other thing is the other DRM that the alliance of music, media and software industry wants to produce.. where every content is digitally signed.. where you can not change the operating system on your hardware anymore etc... this are extremly bad things for linux and free software... we have to stop this whereever we can.. or else in a few years we will not be able to do anything useful on linux anymore...
mond
Re:what ? (Score:5, Interesting)
Since if the key is part of the library, and the library is GPL, the key must be in the source. Not a huge hurdle to get around, but it would stop someone distributing a set top box with a modified version of "cp" that has keys hidden in it.. they would need to modify "cp" to call another binary to do secret stuff, and then provide the source for the modification of cp, which shows how the secret binary is called, but not actuall yhte secret binary.
Slashdot Mirror system (Score:4, Interesting)
"Don't click through, it's reproduced below"
Apparently the Slashdot editors have changed their position on caching pages to prevent overload [slashdot.org] (the "Slashdot effect")
Will this be a permanent change, I wonder? And how did Michael get around those pesky US copyright laws? Did he actually wait for Linus's permission before duplicating his email?
Re:Props to Linus (Score:5, Interesting)
[flame][sarcasm]...and the less of those scummy poor people we have, the better!!![/sarcasm]
Zappa's "we're only in it for the money" is written about and from the POV of the lumpen proletariat (who happened to be the members of the creative and political 'freak' movement--which the media later morphed into 'hippies'); Old punk (dead kennedys, mc5) were lumpen proletariat...and highly political as well.
The reason that liberalism lost it's relevency [sp?] is because the liberals became too academic and pendantic...allowing the christian right to come in and take over as the voice of the 'lumpen proletariat'.
So now, we have DRM, the DMCA and John Ashcroft using the constitution as his own personal toilet paper...yay yay yay![/flame]
Re:DRM will be *needed* by linux (Score:1, Interesting)
Re:DRM will be *needed* by linux (Score:5, Interesting)
Sorry, you haven't convinced me DRM is inevitable. Saying Linux must support DRM because DRM is inevitable because in order to support their current business plans, companies will require it doesn't work. Business plans change, attitudes change. Especially in response to customer feedback. You give Joe Average a set-top box that he can record his favorite shows on, but only play them back for 48 hours after recording, and Joe will flip you off and go back to using his VCR. Which doesn't try to tell him how he's allowed to use it.
I'd argue the opposite. That the eventual elimination of DRM is inevitable, as customers refuse technology that employs it, and companies see the technology they purchased for billions from some "security company" defeated in 15 seconds by a grad student. Read Bruce Schnieder sometime - "encryption" and "signing" are not the answer.
Some people seem to miss the point. (Score:4, Interesting)
While Linus dosen't want to take a political stand on the issue (completly understandable, he's mearly protecting the sole reason for the existence of OSS) I think the GPL will clearly protect itself.
If you are required to publish the source of your work, even if you use DRM with linux, the source of that DRM must be released, which kinda cancels it out dosen't it? Making it pointless.
I'm not 100% sure on this, but putting DRM on anything GPL'd is a waste of time, cuz a DRM is only good if it's closed source.
Re:Props to Linus (Score:2, Interesting)
We don't have the option of "going home" (cf zappa: "..I'll stay a week and get the crabs and take a bus back home/I'm really just a phony/ but forgive me 'cos I'm stoned"; cf Dead Kennedys: "Harder-core than thou for a year or two/ then it's time to get a real job")
If growing out of it was an option, you didn't really belong in the first place, and should have simply stayed in your frathouse, IMO.
IT'S THE LAW, STUPID (Score:5, Interesting)
The problem today is not the technology -- "IT IS THE LAW, STUPID!"
If Microsoft puts some crazy stupid DRM in the next version of Windows, it might be the final straw to get something else to the desktop (be it Mac OS X, FreeBSD, Linux, or something else). As long as people have the freedom of choice, M$ can only go so far before they loose the customer base.
The problem is the DCMA and the baby-DCMAs popping up at the state level. If the government makes DRM *MANDATORY*, you loose your choice. I can very easily see the RIAA and MPAA requiring that all OS's require DRM in the very near future. Think about it.
Hmm (Score:4, Interesting)
Ah, but do they really? I don't think there's anything in the GPL stipulating that an end user cannot modify a compiled binary. Why couldn't you just put a big static array of zeros in the code, and supply a secondary (closed source) program which overwrites those zeros with an actual key? You couldn't distribute pre-keyed binaries (since they wouldn't correspond to the source) but you can allow the end user to run a quick command to insert the keys into the binary him/herself.
You'd just make it a part of the installation process, like installing the boot loader. 1) Install kernel 2) Twiddle some bits in kernel 3) Install bootloader.
It seems like there would be no GPL violation since the binary you distributed was directly compiled from the source you distributed; the user just happened to run a command which overwrote a portion of that binary.
Re:I think Linus Missed the Point.... (Score:3, Interesting)
But you have to remember that this is a two-edged sword. Just because the ??AA uses it in an attempt to reduce copyright infringement doesn't make it evil. It can be used to protect corporate documents, reducing corporate espionage, or to protect your bank account's information so it can't be transferred to another computer.
Frankly, while I find the ??AA's use of DRM distasteful and choice-limiting (I can't play leagally-downloaded and purchased songs from Pressplay or some other 100% above the table downloading service onto my iPod-- yet), the fact of the matter is that there is rather widespread copyright infringement, and they feel it necessary to protect their revenue stream. Whether this is the right decision isn't the point; the point is that it gives them a choice on how they wish to distribute their product, which is something they do have every right to control, whether you like it or not.
With few exceptions, you still go to the supermarket to buy groceries; this does not mean that they are trying to control the distribution of their product. Buying a bottle that is labeled as 'Coca-Cola' is a good indication that you are in fact buying the product on the label, and that it comes from a 'real' source; that the laborers from the Coca-Cola company are getting paid for their work as a result of your purchase. While the ??AA is large, and its revenue probably isn't distributed properly, there still are a large number of 'little people' from recording/mixing engineers to assembly-line workers whom actually create the CD's and DVD's that depend on the revenue of record sales to make a living. The music industry isn't just about the artists and their executive workmasters; there are other extremely talented people who get little or no credit for their work.
Proving that you apparently are more interested in gratis software than libre software. This is already the case; even on Linux. Ever hear of Maya or Shake? They cost a few thousand each. Matlab, Mathmatica, Maple? Quite expensive. The programmers that made these products still need to eat and feed their families. They are already heavily DRM'd, although I'm not sure if they require a hardware dongle at this point in time.
Before the internet became as widespread and common as it is today, if you wanted a copy of the GNU utilities, you had to plunk down a few hundred to get a copy, directly from the FSF. As Stallman is widely noted as saying -- there's a difference between libre and gratis. He has no qualms making money selling people free/libre software; this is how the FSF stayed afloat during the 80's and early-90's, where you typically had to pay a few hundred for Free Software.
It's more complicated than that. (Score:5, Interesting)
1) Someone makes a BIOS that will only boot a signed kernel, where the person with the BIOS password gets to pick which signatures are valid.
2) My company buys a bunch of workstations with this BIOS.
3) Our IT guys build a kernel that's tweaked for our company. They sign the kernel, and set the BIOS to only boot kernels with their signature.
This is wonderful. It means folks can deploy Linux within an organization without having to worry about umpteen zillion different kernels being installed by the workers. It means you can deploy at a university in such a way that students can't make their own boot floppies to get by the access controls on your public machines. It's a Good Thing.
Now, imagine this:
4) A set-top box designer uses this BIOS.
5) They set the BIOS to only boot kernels with their own signature, and don't give the BIOS password to people who buy the set-top boxes.
6) They refuse to sign any kernels that anyone else makes, and refuse to sign any kernels with dynamic module loading turned on.
This, I think, actually violates the GPL. They're distributing a Linux binary, and they're not giving you any way at all to modify it. You can't tweak the kernel you run on your own hardware that you bought with your own money. I think this would only comply with the GPL if you could boot your own signed kernels that the system would use. The fixed signature ends up being an important part of the running binary, and you're not given the "source code" you need to compile that part of the binary.
So, I think some uses of signature do not fall outside the scope of the GPL.
What I don't understand is... (Score:3, Interesting)
Maybe I've missed something here, but client-side security never works in the end. And in the case of DRM-on-linux, I don't see how it can even get off the ground....
Here is how it's going to go down (Score:3, Interesting)
The hordes will eat this machine up and it will become the most popular system out there. They will love it and see nothing wrong with it. It will run just like their old machine only faster and more stable. It will run their old software and new DRM enable software transparently. The difference is that the DRM software will be copy protected and the users will be almost guaranteed to pay for it. The majority of people will not notice since most people pay for their software anyway. The hordes will drive the market to a DRM enabled system, the ultimate lock-in.
On the other side of the fence, the 'free alternatives' will be not be able to get the new hardware to work with their 'Free alternative'. They will boycott the manufacturers, but their boycott will not change things. They will not see the market for non-DRM enabled hardware and will, most likely, be locked into DRM for fear of being excluded from the much larger DRM market. Eventually, the 'free alternative' will only work on older hardware with older software. The 'free alternative' will not be able to run the latest and greatest DRM enabled software or media.
The free alternative will eventually die off due to the fact that it can't run the latest and greatest hardware and software.
It's coming to a neighborhood near you...sooner than you think.
Torvalds muddying discussion with PERSONAL stuff (Score:2, Interesting)
Nice one Linus, drag in the hated figure of RMS to rally the troops around to support your position and make sure that this becomes a personality grudge-fest instead of a discussion about the principles involved.
Easy steps to win an argument in the GNU/Linux community:
Who gives a rat's ass what RMS says about your ideals. The question is what are your ideals? The continued existence of GNU/Linux above all other things?
OK, so how do you justify that? Just stating your position doesn't justify it.
That's a dishonest position: when you do anything you impose your moral values on other people. The decision to not "impose your moral values" is in itself an imposition of your moral values on me. Everything we do and don't do has an effect on everyone around us. Specifically allowing the spread of DRM into GNU/Linux allows the propagation of content which has none of the fair use rights that content has had in the past in other media. Your decision not to oppose this (which it is your right to make blah blah etc) is a decision to allow something which you "don't agree with" to occur. You've made a choice with concrete effects in the real world.
Then don't make political pronouncements on political matters and pretend that you're not doing that.
Reply to oncoming flames: no, I can't code to a hundredth fraction of Linus.
Signed binaries subvert the GPL (Score:3, Interesting)
- Stop doing business with a programmer who works against your interest.
- Shop around for whatever programmers you want, based on price, quality, or
whatever.
- Recover from a programmer getting run over a bus or going out of business
or "reprioritizing their corporate strategies" or something like that. When
you run GPLed software, you don't have to worry
about being "orphaned" anymore, as long as you are willing to put in the time
and effort and expense to do something about it. (I have to say that as an
ex-Amiga user and a former OS/2 user, I am very sensitive to and
grateful for how the GPL solves
this problem. Think about what happens to the user of "dead" products. It
really, really sucks, and you don't want it to happen to you.)
This gives users a strong incentive to choose GPLed software. GPLed software is worth more than software that can't be maintained or supported. I am not speaking as an ivory-tower theoretical religeous "zealot" -- I'm speaking from real-life experience directly derived from has happened to me when software that I used, rotted. This is real and it matters.But binaries that can't be loaded without the right signature, take all that away. The main advantages of Free Software -- from a user's point of view -- are nullified by it. If your computer's BIOS won't load your OS because the signature is wrong, it's no different than not being able to build the software at all, due to it being linked against a proprietary library or due to you not having the include file that contains the define for a secret key, or due to you not having the source to anything. You can't maintain the software that you use. It might as well be proprietary software -- it's no different to you.
Linus isn't thinking in these terms, and Linux is his baby, so while it may make sense for me to talk about the purpose of the GPL in general, it is of course wrong for me to talk about the purpose of Linux's license specifically (even though that license happens to be the GPL). Apparently Linus didn't choose the GPL because he thought it was perfect, but because he thought it was best, or good enough or something. And as a developer he still gets the advantages of "open source" even though the users of his work are apparently destined to lose the advantages of "free software." (I guess this paragraph isn't saying anything that everyone doesn't already know; I'm just acknowledging the difference between Linus' values and many Linux users' values.) It makes me wonder: why didn't Linus choose the BSD license instead? It seems that it would serve his interests just as well.
(Well, I'm off to vacation. No more arrogant noise outta me for about a week -- well, at least not here on Slashdot. See ya.)
Re:what ? (Score:3, Interesting)
This is a good basis for distinguishing between the "good" and "bad" uses of software: If the signature is a way of identifying and asserting your trust in the software to other humans, it is a form of speech rather than a derivative work. If the signature is a way of telling a device how to operate, it is not speech -- merely a derivative work.
You're forgetting one thing... (Score:2, Interesting)
Private key != source (Score:5, Interesting)
Let's say I want to operate karlandtanya's streaming radion station. You can play music but you can't copy it. I believe this is possible becasue I don't believe in the existence of analog recorders. Hardware is cheap, but commercial OSs are not. So I choose to use GNU/Linux for the OS.
I want to prevent you from copying the digital stream I send you. How do control functionality and still respect the fact that you have the right to hack GPL software?
I sell a subscription to my service. I give you the OS and software. The box (and its Fritz chip) remain mine, but you are allowed to use it as long as you are a subscriber. I threaten to sue you if I find out you've changed my hardware in any way.
The OS I give you is "karlandtanya's Orwellian GNU/Linux". The distro comes with a binary kernel that I've signed. I also give you sources for everything, including a key-response program (which is compiled into the kernel) and (just to show I'm sincere) the source for the server side of the system. But I don't give you my secret key.
You immediately untar the sources, recompile the kernel and install. You don't make any changes to the source or any configuration.
You boot the box I loaned you. The Fritz chip won't let it boot. My hardware can only be used to do what I want it to you. "That's fair.", you say. "I paid for the subscription, not the box."
Because you are very clever, you have another very similar box, but without the Fritz chip. You build and install all the packages in karlandtanya's Orwellian GNU/Linux on your hardware and boot it up.
Next, you log onto my site. The site initiates a secure handshake with the key-response program built into your kernel. But when you built your kernel, you did not use my secret key. So the binaries cannot verify against my server. The site denies you access.
Now comes the interesting part:
Now, you and 10,000 of your friends take me to court for GPL violation.
Plaintiff: "Since I cannot compile a working binary from the source you sent me, you did not release the source code. You are in violation of GPL. You must release the source, replace the OS with a non-GPL OS, or refund our money."
Defendant: "Yes, I did release the source code. And it works. I just didn't give you my secret key."
Plaintiff: "No, you did not release the source. Since I cannot build exactly the same binary that you sent me, part of the source must be missing."
Defendant: "Yes, I did release the source. The binaries you generated function exactly the same as the ones I gave you. Part of their function is to verify that they were created using the same secret key as the server they are trying to connect to."
Judge:...
One question... (Score:3, Interesting)
Or is there some reason why that's not relevant? (I admit, I don't really know exactly how DRM's supposed to work.)
My revisions, with justification (Score:3, Interesting)
Gates is the worst of the worst. He's bad, and competently so.
Ellison: BAD!
I think Ellison is fine. Yes, he's arrogant, immature, and runs a big company with tight licenses...but he also spends his days having fun taking swipes at Gates. He wins because he's a lesser of two evils. If Gates weren't around, he'd probably be a bad guy.
McNealy: BAD!
Doesn't seem to be particularly bad or good, in my book. Some good things, some bad things.
Carly (HP): VERY BAD!
She's bad, but incompetently so. Reminds me of AOL execs -- sure, they fall into the bad category, but they're far less dangerous than their MS competitors, so I'll root for them just as the underdog.
IBM CEO: What day is it?
IBM's happening to be nice ATM, but...
Linus: See above
Linus is great.
ESR is great too...sorta like Linus. The emphasis is on engineering.
RMS is a jerk, but I suppose that you have to have an extremist to lead a movement.
Why signed binaries are not allowed by the GPL (Score:3, Interesting)
Let's assume you're using a standard signing algorithm like RSA, which signs a hash of the message (the binary).
Such a hash is a derivative work -- it's created directly from the binary through a hash function. (This is the biggest stretch of the argument, but at least in a mathematical sense this is very accurate. Note that it is not simply a re-expression of the work, but really reassembly of the bits in the original copyrighted expression).
A signed hash is a derivative work of the hash of the binary, for the same reason.
Therefore, the signature has to be distributed under the terms of the GPL as well. That means that if you give it out, you need to give the source to it as well. The source code is defined in the GPL: "The source code for a work means the preferred form of the work for making modifications to it.
Of course, this is a little tongue-in-cheek. But I think it's important to remember the clause in the GPL that requires you to provide not just source code but all of your build tools. Imagine if you created a new wacky language extension to C, (like a new primitive called do_my_secret_stuff) then used that to compile a program and gave out only the source code in C_with_secret_stuff? Those clauses are in the GPL for a reason, so don't forget what "source" means!
I don't agree fully (Score:3, Interesting)
It seems a little redundant to me really and whenever Microsoft talks about DRM they are talking about media as in video, music etc. 90% of people don't check checksums now all of a sudden they are going to start checking who signs their binaries? So here are a couple of questions that remain.
Is DRM really protecting the consumer?
Who's going to sign my binaries? ie: Project maintainer? Microsoft? Redhat?
If Joe Q Hacker signs my binary what's to stop it from running? I mean in all reality Joe Q User isn't going to check that it's safe or even care.
Is this protecting me as the computer user?
Feel free to answer the questions or point me in the direction of some documentation but as of now I think DRM is pretty retarded and is just going to be more stuff I don't waste time compiling, all it does is add another level of exploitation that already exist, this is just spelling it out and making it easier to exploit platforms that use DRM. Also, correct me if i'm wrong.
Will DRM even work in Linux? (Score:5, Interesting)
What the media content providers want to ensure is that you, the human being, can hear/see the content, without there being a way for you to actually copy it to allow others to hear/see that content, or even for you to hear/see it at some later time frame or more than a specified (e.g. paid for) number of times. Whether we agree with their right to do that or not, that is a general description of their goal (or at least for many of them).
No protection will be perfect, of course. If you can hear it, you can record it from a microphone. If you can see it, you can record it from a camera. But as we know from past articles on Slashdot and elsewhere, even these techniques of copying are targets of efforts to prevent recordability. If you succeed at such recording, perhaps at least these methods will have forced a degradation of quality in that recording (e.g. while working to strip out any watermarking, you also damage the quality).
What the content providers particularly loath, however, is the ability to have direct access to the content digitally. If you have that, you can copy that as is, and play it back at a different time or place or in front of a different audience or multiple times. The primary means of preventing this is encryption. But at some point it has to be decrypted. At that point you then find the content in the clear. One aspect of DRM is to deploy a "sealed box" wherein the decryption can take place, yet the user cannot get access to the clear content. Windows can potentially do this due to its closed and proprietary nature. It won't be perfect, but most people will not have any idea how to bypass DRM. There is the potential to distribute software to do it that anyone can use, but certainly we can expect DRM in cooperation with Windows itself to make it hard for unsigned (by Microsoft) software to have access at the level needed to get at the clear content. For example, Windows with DRM will probably refuse to allow you to install your own sound card driver since that is one place where the clear content will be going through.
Linux could certainly have DRM code integrated into it. But because it is open source, and you can build your own kernel, this is a much harder black box to implement. From the point of view of content providers, Linux is a hazardous environment (so is BSD).
Linux supports loading modules which might be available only in object form. There are such modules already available commercially, such as for certain video cards. Some of us love them (because the cards are awesome) or hate them (because the modules are buggy, perhaps with new kernel versions, and cause crashes that would otherwise not be the norm in Linux). But when it comes right down to it, we can add new code to the kernel to work around all the interfaces the module is using. For a device driver, the hard aspect will be seeing what it actually does with the device at the register level. But a DRM black box would be something quite different, since it would need to be able to use existing sound card or video/TV card drivers. That opens the potential to wedge a tap in between DRM and the drivers (or even replace the driver with your own), which Linux would allow and Windows would not so easily. And don't think the media content providers don't know this (they have been getting a lot of hard technical lessons the past few years).
But it can still be possible to have DRM with Linux. One approach is to put the DRM directly in the device driver. That would help, but wouldn't be perfect since other code can be present in the kernel to get cozy with what the DRM is doing. The big problem is getting all the device manufacturers to make a Linux driver.
Perhaps the best (from a practical perspective, were the content providers ever to realize this) way is to put DRM directly in the hardware. That's about as sealed up as you can get. I'll explain how this can work in terms of music in an encrypted MP3 format, but you can extrapolate it in terms of other media or
I would LOVE signed kernel support in bios!!! (Score:5, Interesting)
Imagine being able to tell your bios not to load a kernel (actually, boot loader is probably more accurate), unless it was signed by you. Then you've just guaranteed that even after a system break-in, you can at least start from a known clean kernel.
Doing this in hardware, designed so that there is no way for the running OS to overwrite the BIOS' copy of the key, is the only way to make it safe.
And, yes, I would personally USE it. I would LOVE to be able to tell the bios not to load a version of grub I didn't install, and I'd love to then also be able to tell grub not to load a kernel that was modified without my knowledge. While we're at it, I'd like to be able to extend that to all of my kernel modules, and from there even to certain key system binaries used during run-time.
In other words, allowing the bios to offer security checking really DOES allow for the possibility of ENDING the requirement that you wipe and re-install an OS (or even an application) after a successful break-in. It provides a very much needed "guaranteed safe starting point" for building additional security.
Should bios makers embed a microsoft key in every bios - absolutely not. Should bios makers provide a straight-forward way of letting system owners install their own keys? YES, PLEASE, YES!!!
So what APIs should the bios offer to the OS? Certainly nothing that allows the key to be read or overwritten, but it would be nice if it would provide a "check and approve or reject" API so running applications could determine whether other files are clean before loading them. As long as this all starts from a single trusted source (system reboot checks boot loader, which checks everything it loads (including the files used to make future checks)), this is THE CURE for lots of current security problems.
Re:Props to Linus (Score:2, Interesting)
People on the boards have been saying this was illegal with regards to the GPL....and I guess Linus was addressing this here?
TIvo certainly isn't as 'hacker friendly' as they used to be...
Re:Props to Linus (Score:4, Interesting)
RMS is like the anti-abortion protestor who sets up camp on the doctor's lawn. It's a perversion of the point of protesting. It stinks of a rules mechanic, and it's disgusting. It follows the letter of the law, but tramples all over the spirit.
RMS isn't the type that accepts that people disagree with him. If you disagree, he sees you as somehow misinformed, and it's his moral obligation to change that. Look at the "GNU/Linux" vs. "Linux" debate - Linus claimed that in his opinion "Linux" refers only to the kernel, and anything else is none of his business. Yet RMS seems to blame Linus for the lack of credit GNU gets. Linus doesn't want to fight that fight; RMS, smelling blood, wades in swinging.
Yes, Linus is an Engineer. With a capital E. Among people in the know, I would guess he is one of the most highly respected engineer around - certainly more respected than, say, RMS. RMS is really a salesman, pushing his philosophy along with his software. He also happens to be one of the best salesmen around. But, as a computer geek, I despise salesmen as manipulative, and have the utmost respect for good, honest, engineers.
Moot Points and Using the GPL Immorally (Score:3, Interesting)
So what.
The author of the license (RMS) is making a claim that his license is a moral one. I disagree. He's entitled to his opinions, as I am entitled to my opinions.
IMO, The license simply establishes the rules of a contract for community software. The way I see it, it's a moral less system, which just happens to be less vulnerable to commercial exploitation than other systems.
I like the GPL. I think it's an extremely empowering tool for building standards and charity.
"Tools and technology are neither good or evil. People are good and evil."
Re:Props to Linus (Score:2, Interesting)
I started using Linux (and FreeBSD) in around 1994 after having experience with various flavors of UNIX. I used Linux because it was UNIX-like, free, and worked on my hardware. I didn't even know exactly what the terms of the GPL are until a few years ago. I think all this zealotry nonsense is something that became popular in the last few years, and the people who have always been into UNIX/Linux and computers in general know that politics is not the issue. It's all these newcommers who think its some kind of revolution.
At best you can say Linux has gotten to where it is right now because of the politics surrounding it. Me, I'd be happy to use a proprietary OS that gave me a better experience. I would be willing to use OS X if I could afford it. But right now, Linux meets my needs and is a nice piece of technology. That is all.
Re:What this is about (Score:3, Interesting)
The OS is responsible for making sure that everything loaded is "trusted" and turning off Palladium for the untrusted ones. If it didn't do this (or if there is a mistake, which is why "security" of Palladium will be absolutely zero) then the user can load some program that can examine the trusted program after it has been decrypted by Palladium and thus break the DRM.
Re:I'm sorry, I can't let that one past! (Score:3, Interesting)
No, of course not. I'm simply using extreme examples to illustrate that there are ethical issues worth considering. Because of the disruptive effects of open/free software, it should be examined from an ethical context.
For the record, if you have state funded healthcare, the rich, not the poor, pay for it disproportionately. So you're never going to be in a position where your taxes take enough money to leave you vulnerable to 'medical needs not covered by the "free" program'
Funny. That's exactly how my father died: he paid so much in taxes he could not afford essential surgery (about US$25,000 to US$50,000 with a 30% mortality rate -- his situation was grave), nor even the insurance that would cover it. Canada, of course, had the excuse that there were no qualified Canadian doctors to perform it, so, "Sorry, you die.".
I'm told they do send some people to the U.S. for care, now, but many still die that could be saved if they had bought real insurance and not the government bogus crap that was shoved down their throats as part of their taxes.
Avoid state healthcare like the plague!
For the record (Score:5, Interesting)
The problem is I think that Linus sees himself as a software engineer while Stallman wants to engineer a society (not to be confused with the security term of social engineering). I think that Stallman sees himself more as a role model and teacher while Linus sees the centerpiece of his work being the software he helps to build.
I agree-- RMS is the one picking the GNU/Linux debate for *stupid* reasons. And that detracts from the images of his real software accomplishes.