I think we're getting two phrases mixed up here. DRM is a blanket term for many technilogies (see http://en.wikipedia.org/wiki/Digital_rights_management), I think what we're taking about is the Android Copy Protection mechanism which is an attempt to implement a set of DRM principles.
The current implementation of the Android Copy Protection mechanism doesn't allow developers to say "I don't want my application to be available on devices from which it can be copied" as you suggest because it allows copy protected applications to be installed on a rooted G1 (as shown at http://strazzere.com/blog/?p=185). So as it stands the Android Copy Protection mechanism isn't an effective form of DRM because the methods to circumvent it are already widely known, and so I would say that referring to it as DRM is, well, kind of wishful thinking. Al. Jean-Baptiste Queru wrote: > DRM in this context (and as I've always seen it used in other > contexts) is related to the specific rights of copyright holders and > they way they're granted to users and enforced. For this specific > discussion "DRM" is forward-locking, though it could also be "no-save" > (more restricted), "no-cache" (even more restricted), or it could take > the form of time limits or other forms of restrictions (user-locked, > node-locked, simultaneous users, geographic restrictions...). > > Permissions in the context of Android are related to the specific > "rights" (not in the copyright sense) that a user grants to an > application (and hence indirectly to that application's developer). > > The two notions are orthogonal (notice how permissions still apply to > public-domain apps, and how forward-locked apps don't have access to > more or fewer permissions than unprotected apps, and still need to go > through the same permission-checking screen before being downloaded). > > DRM in this discussion is a mechanism that allows developers to say "I > don't want my application to be available on devices from which it can > be copied". Since ADP1s are explicitly designed in a way that allows > to bypass the copy-protection mechanism in 1.1, developers are > effectively saying "I don't want my application to be available on > ADP1s" when they check the copy-protection box. > > If you feel that a middle ground would make sense (i.e. "I want my > applications to be copy-protected on devices where copy-protection is > available"), please file a feature request. > > JBQ > > 2009/2/27 Al Sutton <a...@funkyandroid.com>: > >> Huh?, DRM is about ensuring that an application uses only the facilities >> that it is supposed to (either by license or by platform design). The >> Android "uses-permission" handling system is DRM, are you saying that >> the it makes "something not work on the devices that have the most >> capabilities". >> >> DRM doesn't prevent a device having all capabilities, it just puts a >> hurdle in the way for software to ensure that software stays within a >> set of rules and doesn't run wild with all the possible capabilities >> (e.g. the restriction on dialling emergency services numbers is a form >> of DRM). >> >> Not all forms of DRM are copy-protection, some are more like the keys to >> a safe. Anyone can move the safe around, but the keyholders are the only >> ones who can get at whats inside it. >> >> Al. >> >> Jean-Baptiste Queru wrote: >> >>> DRM is a case where more is less and less is more. The whole point of >>> DRM is to explicitly make something not work on the devices that have >>> the most capabilities. As such, DRM makes it impossible to have a >>> device that simultaneously has all capabilities. It's a frustrating >>> concept for all engineers. >>> >>> JBQ >>> >>> 2009/2/27 vendor.net <vendor....@gmail.com>: >>> >>> >>>> We can compare G1 and ADP1, but the intention of buying ADP1 is more >>>> important. People buy ADP1 to develop apps for G1. Not to say: "Hey, >>>> I`ve got a hacked G1 and I can do whatever I like.". So in this case >>>> ADP1 should do the same things as G1. We develop apps for G1, but test >>>> them on ADP1, so we need the same conditions. And we also need to test >>>> other developer`s applications like paid ones. >>>> >>>> On 27 Фев, 04:47, Jean-Baptiste Queru <j...@android.com> wrote: >>>> >>>> >>>>> The problem is that you're fighting between two conflicting goals here: >>>>> >>>>> -the need to have a root-capable debuggable and custom-flashable >>>>> device like the ADP1 for application development. >>>>> >>>>> -the need to have a non-root-capable non-debuggable >>>>> non-custom-flashable device like a consumer device in order to >>>>> maintain forward-locking guarantees. >>>>> >>>>> Intuitively, it should be theoretically possible to implement a design >>>>> that can switch between the two modes with the proper guarantees (i.e. >>>>> wiping the relevant partitions clean when going from a >>>>> forward-locking-capable build to a non-forward-locking capable one). >>>>> That'd require resources, of course, which would then have to be >>>>> pulled from other tasks. >>>>> >>>>> That being said, from the point of view of application development, >>>>> you need to expect that the differences from one consumer device to >>>>> another (e.g. which apps are installed by each user) will be greater >>>>> than the differences between an ADP1 and consumer devices like the G1 >>>>> (ignoring for now the issues about 1.0 vs 1.1 on ADP1 that we're >>>>> working on). Worrying about the differences between e.g. one ADP1 and >>>>> one G1 seems to be ignoring the differences between the thousands of >>>>> G1s out there. >>>>> >>>>> JBQ >>>>> >>>>> >>>>> >>>>> On Thu, Feb 26, 2009 at 6:21 PM, Steve Barr <barr8...@gmail.com> wrote: >>>>> >>>>> >>>>> >>>>>>> On Thu, Feb 26, 2009 at 1:48 PM, vendor.net <vendor....@gmail.com> >>>>>>> wrote: >>>>>>> > JBQ, will ADP1 support copy-protected apps in the future? >>>>>>> >>>>>>> >>>>>> On 2/26/09, Jean-Baptiste Queru <j...@android.com> wrote: >>>>>> >>>>>> >>>>>>> I'd say that the current design would make this hard, but I have no >>>>>>> visibility over what the future plans might be. >>>>>>> >>>>>>> >>>>>> I think a lot of us just want their Dev Phone to be as close as >>>>>> possible to a customer's phone so we can test and have confidence in >>>>>> our Java apps before putting them out on the Market. Should we go to >>>>>> Holiday and be done with it? It would be great if there was some >>>>>> official blessed "upgrade" that would let us have a customer-like >>>>>> phone. I'm willing to nuke whatever's currently on the my phone to >>>>>> get it to that point. >>>>>> >>>>>> Otherwise, perhaps some return/refund program should be put in place. >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>> -- >>>>> Jean-Baptiste M. "JBQ" Queru >>>>> Android Engineer, Google. >>>>> >>>>> Please don't contact me directly. >>>>> >>>>> >>>>> >>> >>> >>> >> -- >> >> * Written an Android App? - List it at http://andappstore.com/ * >> >> ====== >> Funky Android Limited is registered in England & Wales with the >> company number 6741909. The registered head office is Kemp House, >> 152-160 City Road, London, EC1V 2NX, UK. >> >> The views expressed in this email are those of the author and not >> necessarily those of Funky Android Limited, it's associates, or it's >> subsidiaries. >> >> >> > > > > -- * Written an Android App? - List it at http://andappstore.com/ * ====== Funky Android Limited is registered in England & Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
