Re: Dev Phone and RC33 update

No doubt that using a DRM solution that is not based on
forward-locking is the right long-term approach. We know what it would
take to implement it. There just wasn't enough time to do it.

JBQ

On Thu, Feb 26, 2009 at 11:00 PM, Al Sutton <al@funkyandroid.com> wrote:
>
> JBQ,
>
> You can do both (after all apps on Windows, DOS, Linux, etc., etc., etc.
> have been doing this for years).
>
> The solution we offer at
> http://andappstore.com/AndroidPhoneApplications/licensing... works
> irrespective of whether the 'phone is rooted, non-rooted, copied, spun
> dry, etc., etc., etc., because it does not prevent circulation of the
> apk but instead uses a DRM mechanism to ensure the user has obtained the
> rights to access features within an application. This is the "modern"
> way of doing things where the distribution media isn't protected, but
> the software requires a product key or similar to offer unhindered
> functionality.
>
> At the London Dev day last year I gave Mike Jennings an idea on creating
> "trusted" applications to alleviate the problem of "How does a user
> trust an app isn't malicious", and I got the impression that crypto was
> not a strong point of the team, so I'd be happy to go over how the
> AndAppStore licensing system works with one of more of you guys so that
> we can get a viable, working solution deployed.
>
> Al.
>
> Jean-Baptiste Queru 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 <barr8888@gmail.com> wrote:
>>
>>>>  On Thu, Feb 26, 2009 at 1:48 PM, vendor.net <vendor.net@gmail.com> wrote:
>>>>  > JBQ, will ADP1 support copy-protected apps in the future?
>>>>
>>> On 2/26/09, Jean-Baptiste Queru <jbq@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
>>>
>>>
>>
>>
>>
>>
>
>
> --
>
> * 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.
>
>
> >
>



-- 
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.

Please don't contact me directly.