[mailto:android-platform@googlegroups.com] On Behalf Of Jean-Baptiste Queru
Sent: October-26-09 1:29 PM
To: android-platform@googlegroups.com
Subject: Re: More Applications on SDCARD

The notion of encrypting per-device auth stuff is pretty interesting,
though it obviously adds quite an extra level of complexity.

Keeping the filesystem unencrypted, though, opens quite some cans of
security worms that might be worth avoiding as a starting point.

JBQ

On Mon, Oct 26, 2009 at 9:41 AM, lbcoder <lbco...@gmail.com> wrote:

> I think I touched on this in the thread starter.

> i.e., keep any number of per-device configurations within the same
> sdcard for the possibility of sharing to other devices. If the per-
> device configuration is encrypted, then upon sdcard insertion, only
> those apps permitted by that device are runnable. And we can either
> key-check those apps on insertion, OR run a simple SHA hash of the
> file. If the hash doesn't match what is stored in the per-device
> configuration, request authorization refresh. If the per-device
> configuration doesn't exist, create it and go through the full
> authorization requests. The user can put a checkmark beside each app
> they want to authorize.

> i.e., the sdcard has a "master" packages.xml, and for each device, it
> has a "deviceid-packages.xml" which is a subset of the master
> packages.xml for that card.

> Regarding users not understanding why some apps can't be shared
> between devices... I think that it is important that they be warned of
> this. You can give them a LIST of *ALL* of the apps that are installed
> on the card, and do something along the lines of greying out the
> "protected" apps. If a user tries to authorize a protected app, give
> them a warning that says "This app is not authorized. The app
> developer requires that this app be restricted to the device it was
> initially installed on". That should make it pretty clear. And since
> the apk is encrypted using the same key as the deviceid-packages.xml
> file for the device it was initially installed on, it will be
> gibberish to any other device, so even if they hacked the
> authorization dialog, it would still be impossible to run it.

> On Oct 23, 8:28 am, Jean-Baptiste Queru <j...@android.com> wrote:
>> Well, as soon as we allow something like that, we can't allow
>> forward-locked apps on the SD card, and those are likely to be the
>> largest ones, i.e. the ones that'd benefit most from being installed
>> there. Maybe that could be worked around by keeping the "protected"
>> parts of the app on internal storage, and putting the rest on the SD
>> card. I'm not sure that users would understand why only some of their
>> apps can be shared between devices.

>> This opens a lot of other cans of worms: e.g. this'll create
>> situations where the same app is installed on the internal storage and
>> on the SD card. This doesn't directly allow to guarantee overall
>> uniqueness of UIDs on a given device. This creates some nasty issues
>> of compatibility if developers start to fine-tune individual versions
>> of their app for individual devices and an SD card is shared between
>> non-identical devices. This would also require to re-validate all the
>> permissions of all the SD-card apps whenever that SD-card is mounted
>> on a device (including at each boot). In general, this would create a
>> truckload of security issues, since no device can't trust the content
>> of the SD card.

>> Like I said, this is something that we should really really really not
>> try to do in a first version - it'd doom the feature to being so hard
>> to implement and to have so many subtle issues that I guarantee it'd
>> delay it much further. Enough users have been vocal enough about this
>> that I strongly feel that we should aim for something simple that's
>> more likely to be feasible (because "simple" is already going to be
>> hard enough).

>> JBQ

>> On Thu, Oct 22, 2009 at 11:56 PM, Al Sutton <a...@funkyandroid.com> wrote:

>> > I've never been a fan of assuming how a user uses their device and not
>> > including functionality on that basis.

>> > Personally I can see people temporarily swapping SD cards so they can
>> > try out other peoples apps on their phone, so I can see the need to
>> > handle it properly.

>> > Al.
>> > --

>> > * Looking for Android Apps? - Tryhttp://andappstore.com/*

>> > ======
>> > Funky Android Limited is registered in England & Wales with the
>> > company number  6741909.

>> > 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.

>> > On 23 Oct 2009, at 01:05, Eric F wrote:

>> >>  you buy a Mac Mini you get to
>> >> choose how big of a disk drive you want. I can't really imagine a
>> >> situation where I'd want to have different apps on different SD cards
>> >> and switch between them. Sure in a perfect world it should still work.
>> >> But if it degrades from the system being able to work smoothly in
>> >> other areas, I don't think this is a bad thing to give up. Especially
>> >> if it's possible to A) take the file that represents the encrypted
>> >> file system and copy it to the computer, and then copy it to a second
>> >> card. So let's say we bought an 8GB card thinking that would be
>> >> sufficient. Later we realize we wanted a 16 GB card, we move the file
>> >> between cards using a computer and then use Android to resize the
>> >> filesystem to our new choice, preserving our installed apps.

>> >> I can't see normal users "swapping cards", so that leaves us with
>> >> power users. I think most power users are hungry for the largest/
>> >> fastest SD card they can get their hands on. Which means 16 (soon 32)
>> >> GB cards, how many of those is a user going to need? Many phones are

>> --
>> Jean-Baptiste M. "JBQ" Queru
>> Software Engineer, Android Open-Source Project, Google.

>> Questions sent directly to me that have no reason for being private
>> will likely get ignored or forwarded to a public forum with no further
>> warning.

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.