| |||||||||||||
Bitfrost: the OLPC security modelBitfrost: the OLPC security modelPosted Feb 8, 2007 6:05 UTC (Thu) by bronson (subscriber, #4806)In reply to: Bitfrost: the OLPC security model by cjb Parent article: Bitfrost: the OLPC security model
I don't think so... I remember the FSF shooting this down a few months ago. The example used was, what if Tivo releases a developer key as a substitute for releasing their private key? Without the same key, there's no guarantee of the same rights. I did some googling but can't come up with the article so take this with a grain of salt.
The first draft even suggested that if hardware requiring a private key was found in the wild, the private key must be made public. Luckily that was softened in the second draft.
The final GPLv3 is due in March... That's coming up awful soon.
(Log in to post comments)
Bitfrost: the OLPC security model Posted Feb 8, 2007 6:16 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] however, this would only apply if the BIOS or the system software gets released under the GPLv3 without also being available under the GPLv2.
and since the core system software is written by the OLPC project, they wouldn't be stupid enough as to license it under a license that conflicts with their other goals.
Bitfrost: the OLPC security model Posted Feb 8, 2007 7:38 UTC (Thu) by bronson (subscriber, #4806) [Link] But the OLPC is one of the most free computer projects ever undertaken. What if the GPLv3 can't be used for its low-level (read: important) parts? Isn't that a pretty bad sign?
This appears to be one situation where DRM can actually be a good thing. Like a knife or a car or a programming language, it's all just technology. People will use it for good and they will use it for bad.
That's why the FSF's "DRM is EVIL!!" stance is so foreign to me. It's like calling gunpowder evil.
Bitfrost: the OLPC security model Posted Feb 8, 2007 12:47 UTC (Thu) by drag (subscriber, #31333) [Link] With my infinate ignorance it seems here that the difference is allowing the owner/handler of the device greater control over it versus attempting to remove control from a owner and give it to a third party.
I wouldn't nessicarially call it 'DRM'. It certainly uses features that mirror what is used in DRM, but it's goal/purpose is different. Similarly how I wouldn't consider a signature on a E-mail DRM.
The only problem I see is that it's probably going to make the system much harder to hack around with versus if it was more PC-like. To bad there isn't a positive way to identify users and key the machine to them, like through voice recognition or fingerprint or something like that. I don't suppose something like that is reasonable for a machine like this.
Bitfrost: the OLPC security model Posted Feb 8, 2007 14:28 UTC (Thu) by NAR (subscriber, #1313) [Link] It certainly uses features that mirror what is used in DRM, but it's goal/purpose is different.This feature is basically "the hardware doesn't run the code if it's not signed". Which is good, when it disables working around the anti-theft code in the OLPC, but which is bad, when disables creating graphics card drivers that dump their output into a file (to copy a DVD, etc.).
Bitfrost: the OLPC security model Posted Feb 8, 2007 18:26 UTC (Thu) by bronson (subscriber, #4806) [Link] The OLPC uses a private key to restrict the rights of the computer's owner. How can you not call this DRM?? It's exactly the same thing!
I'm not exactly clear on just who will own these devices: the student, the student's parents, the school, or the state? If the state keeps ownership of all the computers for itself, and just loans them to kids for a year at a time, would the GPLv3 still force the release of the private keys?
Would the answer change if they loaned them to random kids for an hour at a time rather than one kid for a year at a time?
Bitfrost: the OLPC security model Posted Feb 8, 2007 19:29 UTC (Thu) by cjb (guest, #40354) [Link] The OLPC uses a private key to restrict the rights of the computer's owner. How can you not call this DRM?? It's exactly the same thing!It is DRM. However, GPLv3 doesn't say no-one can implement DRM, it says that if you implement DRM you must also make the key available so that the computer's owner has the freedom to turn off the DRM if they want to. That's what OLPC is doing, so it's all good. I'm not exactly clear on just who will own these devicesI think the plan is that the devices are for the children to keep, even after they finish school.
Bitfrost: the OLPC security model Posted Feb 8, 2007 20:18 UTC (Thu) by bronson (subscriber, #4806) [Link] I'm not sure I buy that. If OLPC gets to do this, couldn't Tivo do the same thing?
Why doesn't Tivo set up a restricted developer program? The customers who really want can jump through hoops could get themselves a developer's key. Like OLPC, developers keys will be quite hard to come by. The vast majority of people won't know, won't bother, or won't qualify.
Is Tivoization possible under the GPLv3 after all?
Bitfrost: the OLPC security model Posted Feb 8, 2007 20:50 UTC (Thu) by drag (subscriber, #31333) [Link] And they wouldn't care either. Most people who own TiVOs don't care, and if I owned a TiVO I probably wouldn't care much either.
As long as they make the 'developer keys' (or equivelent) aviable to end users then that's all that matters. If they make significant barriers to this then that could be construed as a violation, but it's not like they have to make it easy for you either.
I'd say it would be reasonable to require you to call Tivo and provide some sort of proof (say a UUID number on the bottom of the case) that the device belongs to you and then they'll mail you a key on a cdrom or whatever for 5 bucks or whatever reasonable to cover their costs.
There is no reason why they would have to provide keys to all Tivos, just the ones you own.
And the reason I originally said it's not 'DRM' is because DRM is designed to restrict a person's rights in regards to copyrighted material. If this is DRM, then setting file permissions on your home folder is DRM also. Implimenting filesystem encryption is DRM also, then.
If you want to make the definition so broad to encompas everything then I suppose you can call any sort of security measure DRM if you want to.
Bitfrost: the OLPC security model Posted Feb 8, 2007 23:04 UTC (Thu) by bronson (subscriber, #4806) [Link] And the reason I originally said it's not 'DRM' is because DRM is designed to restrict a person's rights in regards to copyrighted material.Exactly like the OLPC BIOS. If this is DRM, then setting file permissions on your home folder is DRM also. Implimenting filesystem encryption is DRM also, then.Neither of those scenarios involve an upstream party using private keys (or other technology) to inhibit your enjoyment of a product that you rightfully own. I don't see how they could be considered DRM.
Bitfrost: the OLPC security model Posted Feb 9, 2007 7:22 UTC (Fri) by man_ls (subscriber, #15091) [Link] Exactly like the OLPC BIOS.Not really. The OLPC doesn't prevent access to copyrighted material; it shuts down the machine and turns it into a brick. Not even close. Neither of those scenarios involve an upstream party using private keys (or other technology) to inhibit your enjoyment of a product that you rightfully own. I don't see how they could be considered DRM.I don't see how you can call Bitfrost "DRM" when there is no copyrighted material and no digital "rights" to manage. DRM is not "using private keys to inhibit enjoyment of products", it involves limiting access to certain files. Drag's example (setting permissions on a directory) is actually closer to DRM than OLPC's Bitfrost, IMHO.
Bitfrost: the OLPC security model Posted Feb 10, 2007 8:01 UTC (Sat) by bronson (subscriber, #4806) [Link] DRM can be used with anything, not just copyrighted content (according to http://www.defectivebydesign.org/en/about anyway). When the OLPC turns into a brick, isn't that awfully similar to a DVD refusing to decript its content or a Vista computer refusing to run an executable? Sure seems it to me.
And both DRM and Bitfrost are very dissimilar to chmod a-rw ~/. Directory permissions don't involve a 3rd party, DRM and Bitfrost do, chmod a+rw ~/* undoes the damage; DRM and Bitfrost don't have any such exit, etc. Shall I continue?
I guess we'll just have to agree to disagree on this one.
DRM vs TM Posted Feb 10, 2007 10:21 UTC (Sat) by man_ls (subscriber, #15091) [Link] As the linked page takes pains to explain, DRM can be based (on computers) upon "Trusted Computing", which Stallman mimics as "Treacherous Computing". You are saying that DRM can be used for anything (and is indeed used on the OLPC), when in fact it is TM that you are speaking about. It seems like a pedantic point, but it is important for the discussion not to mix these concepts IMHO.TM can be a chip used by the kernel with cryptographic keys under the control of the owner, in which case it can be a good thing. The keys can also be under the control of a third party, which is a disaster. In the case of the OLPC it can turn into a brick. As it is a government-sponsored program anyway, I guess they have thought about it: if it gets disabled by mistake, you can always take it to a hypothetic repair service. I personally don't like the idea, and think it is a weak point in the whole scheme, but inexplicably nobody asked me before implementing it ;) DRM, as one of its main peddlers has just said, is always a bad idea. Notice that, in the case of a DVD player you don't even need TM, as it is a closed platform anyway; in this case the device can simply have its keys revoked and it will refuse to play protected content, which is different than turning into a brick. When it is a computer in disguise you need complicated schemes such as TM to make the device obey its true master, the manufacturer.
DRM vs TM Posted Feb 10, 2007 20:03 UTC (Sat) by bronson (subscriber, #4806) [Link] TC is now such a broad concept that it's nearly useless. The wikipedia page does make it sound like both Bitfrost and drectory permissions would fall under the TC umbrella. But so would AppArmor. And hardware virtualization extensions. That doesn't mean they have anything in common with each other.We can at least agree that FairPlay, CSS, and Microsoft's incompatible flavor du jour are examples of DRM, yes? defectivebydesign says that Tivoization is a form of DRM. And Hasp HL claims to be DRM. Bitfrost's ultimate behavior is basically the same as these technologies and has only the most superficial resemblance to directory permissions. That's why I really don't think it's a stretch to consider it DRM. Maybe you could point me to an authoritative definition of DRM? The definition at the top of the Wikipedia entry clearly includes Bitfrost but, alas, I'd hardly call it authoritative. Perhaps the media is subverting the meaning of DRM like it did with hacker? At this point, though, I'm afraid the cat's pretty far out of the bag.
DRM vs TM Posted Feb 10, 2007 20:27 UTC (Sat) by bronson (subscriber, #4806) [Link] ...*not a stretch* to call [Bitfrost] DRM. Gah.
DRM vs TM Posted Feb 10, 2007 23:01 UTC (Sat) by man_ls (subscriber, #15091) [Link] I would say that Trusted Computing is a well defined concept, or at least it was until vendors started marketing it. OTOH DRM was always snake oil, and still is today. Maybe that is why authoritative definitions are hard to find. Look at this one (in PDF):Digital Rights Management (DRM) is a system to protect high-value digital assets and control the distribution and usage of those digital assets.It comes from an academic paper, but the "high value" part is not very objective: DRM can also be used for low-value garbage. As to the examples you cite: Tivoization is a form of DRM only because it is used to protect digital content (digitized TV in this case). The article in Dr Dobb's Journal talks about protection of content and restriction of document distribution. Even if the press and the general public misuse the term, that is IMHO no excuse for spreading bad usage. DRM protects content by whatever means, even if it's just a remotely controlled daemon setting directory permissions. After all, Adobe's protected PDF's rely on something like a bit set on a file.
Bitfrost: the OLPC security model Posted Feb 8, 2007 20:51 UTC (Thu) by cjb (guest, #40354) [Link] I'm not sure I buy that. If OLPC gets to do this, couldn't Tivo do the same thing?Remove their restrictions by bundling an offer to supply a developer key that gives you complete access to the machine if you want it? Sure, they could, and they'd be GPLv3-compliant by my interpretation if they did. They presumably won't, because they don't want you to be able to (for example) use a public source of TV listings and stop paying them for monthly service. The vast majority of people won't know, won't bother, or won't qualify.No, if you've bought the device, it would be a breach of GPLv3 to not give you the key on request. A "restricted" developer program wouldn't suffice. (But no-one's suggesting the OLPC program will be restricted.)
Bitfrost: the OLPC security model Posted Feb 8, 2007 22:52 UTC (Thu) by bronson (subscriber, #4806) [Link] Of course the OLPC program is restricted.
From the article: "in general, the children will not have that functionality available to them."
From our editor's comment: "There is a delay built into the developer key mechanism; if the laptop is reported stolen during the wait, no key is issued."
This makes total sense. If there really were no restrictions, there would be no point to making the keys private in the first place. The thieves would just request the keys after they'd stolen the laptops.
I've read the v3 draft a few times. You'll notice that 6.3b doesn't specify any durations. How long could Tivo delay issuing a key before It's in violation? A few months? A year? And could Tivo pull the old tape trick used by a number of BSDs in the early 90s? (charging $400 for a $30 tape claiming "it's a reasonable cost of physically performing this conveying of source. Go ahead, take us to court -- it'll cost you a lot more than $400!")
From reading the license, it seems to me like they could.
Bitfrost: the OLPC security model Posted Feb 8, 2007 23:56 UTC (Thu) by cjb (guest, #40354) [Link] From the article: "in general, the children will not have that functionality available to them."This doesn't mean that developer keys will be refused to some children, it means that before the child asks for the key, the (BIOS-writing) functionality won't work. I've read the v3 draft a few times. You'll notice that 6.3b doesn't specify any durations.The Bitfrost spec (section 8.19) says that the delay between asking for and receiving the key will be fourteen days. That seems entirely consistent with the delay one would expect from replying to a written offer of source code under the GPL that we've been using for the last twenty years. I'm only really interested in talking about this to the extent of showing that the scheme is entirely in accord with GPLv3 and the spirit of the GPL. If your problem is that the GPL isn't free enough for you, you need to find some other people to talk to. :)
Bitfrost: the OLPC security model Posted Feb 9, 2007 2:34 UTC (Fri) by bronson (subscriber, #4806) [Link] I'm genuinely interested. I still don't understand how the GPLv3 can allow the OLPC to use DRM and at the same time prevent Tivo from abusing it. That's why I was asking about known modes of GPL abuse from the past. There will always be people who want to skirt the rules.
I *like* the GPLv2, and presumably I'll like the v3 when it ships. Ideally I'd like v3 to be able to be the go-to license for most projects. Other than the DRM language, which I'm unsure about, it looks like v3 could be that license.
Of course, I'm happy to let our discussion rest here and leave any further fine slicing to future litigators. :)
Bitfrost: the OLPC security model Posted Feb 9, 2007 2:49 UTC (Fri) by cjb (guest, #40354) [Link] I'm genuinely interested. I still don't understand how the GPLv3 can allow the OLPC to use DRM and at the same time prevent Tivo from abusing it.So, my understanding is that the GPLv3's answer to DRM is to say "Sure, you can build DRM -- after all, you wouldn't have freedom if you couldn't -- but you must give the person who you distribute the code to the freedom to remove the DRM if they wish". That's what Bitfrost tries to do. How do you think TiVo would claim to be following that, yet abusing it? The methods you mentioned (waiting too long, or charging too much) just aren't ones that we've seen people abuse over the last twenty years; I can't think of a single memorable example of either, so it certainly hasn't been common. If they *do* provide the source+key that gives you full control of the system in a timely manner, then it's Free Software.
Bitfrost: the OLPC security model Posted Feb 9, 2007 11:56 UTC (Fri) by NAR (subscriber, #1313) [Link] you must give the person who you distribute the code to the freedom to remove the DRM if they wishI think I get it - the code is distributed to the child, but not to the thief, so the thief can't ask for the key. However, an other thing occured to me. As far as I know, the children can't sell or give away their laptops, i.e. can't distribute it (I could be wrong here). Can they distribute the software (including the OpenBIOS) on the laptop? GPL (even v2) gives them the right, but will the software work on any other laptop (even if they distribute the key, which is part of the software under GPLv3)?
Bitfrost: the OLPC security model Posted Feb 8, 2007 21:04 UTC (Thu) by cjb (guest, #40354) [Link] By the way, feel free to read the GPLv3 (draft) itself. It makes it clear that the key needed to change the Program is part of the Corresponding Source, and that it is valid to supply an offer to provide the Corresponding Source on request, rather than directly bundling the Corresponding Source with the Program itself.
Bitfrost: the OLPC security model Posted Feb 8, 2007 22:24 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] I think lots of people agree that it's a bad sign, everyone is split between
1. it's a bad sign for the GPLv3
and
2. it's a bad sign for the OPLC project
by the way, to throw a little gasoline around here, who is the 'owner' of these things, the govenments who pay for them, or the child who takes it home each night?
if it's defined as being the govenments who pay for them then all these requirements are within the limits of the GPLv3 as the owner of the devices has all the nessasary keys.
Bitfrost: the OLPC security model Posted Feb 11, 2007 17:49 UTC (Sun) by JohnNilsson (guest, #41242) [Link] Does the GPL really care about "owners"? It only mention "users". I would think even a theif would qualify as a "user".
Bitfrost: the OLPC security model Posted Feb 8, 2007 6:35 UTC (Thu) by drag (subscriber, #31333) [Link] ""I don't think so... I remember the FSF shooting this down a few months ago. The example used was, what if Tivo releases a developer key as a substitute for releasing their private key? Without the same key, there's no guarantee of the same rights. I did some googling but can't come up with the article so take this with a grain of salt.""
I beleive that is a bogus arguement. It either gives you the ability to run modified code with no loss of functionality or it doesn't. As long as it does, then that's it as far as the GPLv3 is concerned. There is absolutely no requirement in the GPLv3 for developers to release any private keys, they just have to provide the ability to allow users to run modified code with no loss in functionality if the original makers themselves can do so also.
Garrentees be damned. If there is a question of violation then obtaining a "developer's key" and using it to load modified code and testing the functionality is all that would be needed to prove compliance.
Plus with this design even the BIOS can be swapped out with the developer's key, so the BIOS itself could be licensed GPLv3 if you felt like it.
Bitfrost: the OLPC security model Posted Feb 8, 2007 14:13 UTC (Thu) by NAR (subscriber, #1313) [Link] There is absolutely no requirement in the GPLv3 for developers to release any private keys, they just have to provide the ability to allow users to run modified code with no loss in functionality if the original makers themselves can do so also.So the developers would have to give me a key, which enables me to run the modified code - even if the modification means that I've removed the anti-theft features like the "calling home" thing. Which would brake the whole anti-theft concept. Or is there something I'm missing?
Bitfrost: the OLPC security model Posted Feb 8, 2007 16:07 UTC (Thu) by nix (subscriber, #2304) [Link] I see what you mean: what stops thieves contacting the developers and asking for a developer's key? (Equally, what stops crooked bureaucrats diverting the identity USB keys at the same time as they divert a bunch of laptops?)
Bitfrost: the OLPC security model Posted Feb 8, 2007 16:11 UTC (Thu) by corbet (editor, #1) [Link] There is a delay built into the developer key mechanism; if the laptop is reported stolen during the wait, no key is issued.
Bitfrost: the OLPC security model Posted Feb 8, 2007 23:03 UTC (Thu) by drag (subscriber, #31333) [Link] Also I presume that they would take steps to confirm your identity so that they are issuing a key to a laptop to the person that is actually suppose to have the laptop. (I don't think 'theft' would constitute 'distribution' under the GPL)
Sort of like how if you work in a corporate setting and somebody calls you up asking for (or to reset and replace) a password they 'forgot' you would want to take a bit of time to try to confirm the identity of the person on the other side of the phone before issuing the password.
|
|||||||||||||