> On the UIDs issue, can't a "drive id" be used as part of the UID
> associated with an app?

> For example, if we use 0 for internal, 1 for the first SD, etc. then
> an app can get a UID of 0x1234 when its' installed, but would be run
> with a UID of 0x001234 if its' run from internal storage, 0x011234 if
> run from "drive" 1, 0x021234 if user from "drive" 2, etc.

> That way any device an SD card is inserted into only needs to worry
> about uniqueness of the UID within the device as opposed to uniqueness
> across any system it's inserted into.

> Al.
> --

> * Looking for Android Apps? - Try http://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 22 Oct 2009, at 20:31, Jean-Baptiste Queru wrote:

>> All right, here are a few hints of things which I think have been
>> discussed in the past (though I don't remember whether that was in
>> public or not).

>> -application and its data stored on the same volume. Internal apps
>> store data internally, sdcard apps store data on sdcard.

>> -apps and their data as stored on SD are tied to the device that
>> installed them, can't be read on a PC or on another device (i.e.
>> crypto).

>> -shared UIDs need to work, one way or another. That's the tricky
>> design part IMHO when it comes to dealing with UIDs (or maybe this is
>> where we need to make big simplifying decisions).

>> The basic idea for the filesystem-level work is to create an e3fs
>> image (or equivalent) in an encrypted disk image on the SD card. with
>> the crypto key being stored on /data (so that access to it goes away
>> after a factory reset).

>> A significant implementation detail is that all processes that have
>> file opened on the SD card either need to close them or be killed.
>> Once apps get on the SD card, you end up in a situation where the
>> system server will need to do that too; in addition to all the
>> "legitimate" codepaths to deal with, we also think that there are
>> cases there the system server leaks open file descriptors of apks.

>> A further simplifying assumption might be to only allow one SD card
>> with apps tracked by the system at any time.

>> JBQ

>> On Thu, Oct 22, 2009 at 11:43 AM, Eric F <ericfrie...@gmail.com>
>> wrote:

>>> A bold move lbcoder!

>>> I think first we should get a confirmation from Google that the list
>>> of requirements is both complete and correct. Otherwise any designed
>>> solution might be for nothing. Also confirmation that they are not
>>> working on this already in their private repo would be nice
>>> (although,
>>> we have to be realistic here, this is AOSP we are talking about).

>>> I think there should be some discussion as to #5 on the requirements.
>>> Apps installed on an SD card in an Android 2.5 device and then
>>> plugged
>>> into an Android 2.1 device should not necessarily function correctly,
>>> or display at all. What about an app that is tightly coupled with the
>>> contacts of one phone that wouldn't make sense to run on a second
>>> phone with the same app data, and would make more sense to start
>>> separate app data per phone.

>>> Also, I think added to the requirements should be determined if the
>>> capability to support multiple cards should be:
>>> 1) Designed to be explicitly never supported
>>> 2) Designed to one day work with more improvements in a way that is
>>> compatible with the design for supporting one card
>>> 3) Designed to be supported

>>> A good design takes into account where Android and Android devices
>>> might be in 2 years, not just what's in the stores today.

>>> I agree that some kind of loopback filesystem on the fat32 card is in
>>> order. I had a post a while back describing how I thought the UI and
>>> the user should have to deal with creating this section of the memory
>>> card, changing its size, deleting, installing apps etc. Remember
>>> people can also eject the card and insert it into a card reader on
>>> their computer, so I am not sure how well just reporting fat32 over
>>> usb mass storage is sufficient to protect users from formatting their
>>> cards by accident.

>>> -E

>>> On Oct 22, 10:47 am, lbcoder <lbco...@gmail.com> wrote:
>>>> In looking through the various threads, I see that there are some
>>>> questions on how to handle application storage on SDCARD safely and
>>>> securely.

>>>> I would like to propose a mechanism for handling this in a manner
>>>> that
>>>> is fair, safe, and secure,  however there are bound to be questions
>>>> and or unforseen issues.

>>>> First, in simplest form, the minimum requirements:

>>>> 1) Application and all application data to be stored externally on
>>>> sdcard.
>>>> 2) SDCARD must be able to be removed and replaced at will, including
>>>> possibility of being replaced with a different sdcard.
>>>> 3) Contingency must be made for possibility of installing
>>>> application
>>>> both internally as well as on sdcard.
>>>> 4) Protected applications installed to sdcard must remain secure.
>>>> 5) Insertion of sdcard into another device should allow
>>>> application to
>>>> function in other device except in the case where the application is
>>>> "protected".
>>>> 6) SDCARD must be protected from MS-hostility, i.e. mounting
>>>> sdcard to
>>>> a computer (via usb to phone) must not prompt non-expert users that
>>>> they should format it.

>>>> Scheme:
>>>> i) Need to segregate a group of user id's for use as sdcard-UIDs
>>>> (i.e.
>>>> 20000-29999).
>>>> ii) Need app, app-private, data, and dalvik-cache directory on
>>>> sdcard.
>>>> iii) Need a packages.xml on sdcard.
>>>> iv) Upon unmount need to (in order):
>>>> a) kill all running sdcard processes.
>>>> b) refresh package list (modify the package manager to update
>>>> package
>>>> status by rereading /data/system/packages.xml and sdcard's
>>>> packages.xml).
>>>> c) actually unmount the partition.
>>>> v) Need to modify installer to prompt for where to install to (if
>>>> sdcard is available).

>>>> Problems:
>>>> 1) When sdcard is yanked-without-unmount by non-expert user, running
>>>> application may crash.
>>>> 2) Multiple current installations of the same application -- how to
>>>> select between?
>>>> 3) Copying of protected applications is trivial.
>>>> 4) How to control per-process permissions on a card from an unknown
>>>> source?
>>>> 5) How to safely allow sdcard to be mounted to a separate computer
>>>> without non-expert user reformatting.
>>>> 6) SDCARD applications added to the home screen.

>>>> Solutions:
>>>> 1) Android already kills off background processes to free up memory.
>>>> This can be extended to kill off ALL background processes running on
>>>> SDCARD. The problem here is in the event that a running/foreground
>>>> app
>>>> is forcibly removed. SDCARD removal (forcefully) should kill all
>>>> processes that would safely be killed off for memory cleanup, and
>>>> forcefully (kill -9) all processes that can't be safely killed.
>>>> Should
>>>> also show the user an error message that says something like "You
>>>> removed the sdcard without unmounting, the following sdcard
>>>> applications were running and had to be killed. All unsaved data has
>>>> been lost." There is no need to get fancy and save the application
>>>> states.
>>>> 1b) In the event that the user chose to safely unmount the sdcard,
>>>> IF
>>>> there are running applications, show a message like "The following
>>>> applications on the SDCARD are currently running: ... If you
>>>> continue,
>>>> these applications will be killed. Would you like to proceed?"
>>>> 2) In the event of multiple of the same applications installed
>>>> (internal and sdcard), choose to run the one on INTERNAL (do not add
>>>> the external one to the application manager). I.e., when scanning
>>>> the
>>>> applications on the sdcard, if (application exists on internal
>>>> memory)
>>>> do not add to application manager. The assumption being that if you
>>>> have it installed internally, then the REASON is that you want it to
>>>> be available when you remove or change sdcard.
>>>> 3) Two possible solutions to this;
>>>> a) (I don't like this one) -- don't allow protected apps to be
>>>> installed to sdcard at all. This would be perceived as hostile to
>>>> software vendors wishing their apps to be copy protected.
>>>> b) encrypt protected app's apk and dalvik cache using a key stored
>>>> internally. If the card is inserted into another device, it will not
>>>> have the necessary decryption key and therefore can either not show
>>>> the application at all, or it can show the application as "not
>>>> licensed for this device".
>>>> (*) note: it is not necessary to secure non-protected apps, free or
>>>> priced, since it is by the seller choice that there is no copy
>>>> protection on the app.
>>>> 4) THIS IS A BIG ONE... Insertion and removal of other sdcards,
>>>> particularly given the possibility that the sdcard belongs to
>>>> someone
>>>> else and/or stands the possibility that it has been tampered with. I
>>>> suggest that there be a group of secure databases on the sdcard, one
>>>> for each device that the card has been inserted into, this
>>>> database is
>>>> encrypted by the devices encryption key (the same one as 3(b)). If
>>>> you
>>>> insert an sdcard which has not been used in your device before, it
>>>> will create a new encrypted database and ask which applications to
>>>> allow (showing, of course, their permission requests). The resulting
>>>> database would hold the kind of data corresponding to /data/system/
>>>> packages.xml. There would, of course, also be an option to delete
>>>> the
>>>> databases for "other" devices (which would prompt the same rebuild).
>>>> There must be, of course, a "master" databases on the sdcard showing
>>>> ALL installed apps, upon insertion, this must be compared to the
>>>> per-
>>>> device database resulting in the user being prompted for any new
>>>> applications and for removing from the per-device database, any
>>>> obsolete entries.
>>>> 5) Since due to other-device compatibility, it must remain fat32,
>>>> there are two options I can think of;
>>>> a) loopback filesystem within the primary fat32 filesystem. This
>>>> would
>>>> fly under the radar of MS's hostility routines. Secondary benefit is
>>>> that it would easily allow advanced users to 'mount -o loop' the
>>>> application filesystem.
>>>> b) modify the mass storage controller code to only show the fat32
>>>> filesystem. Makes it a little more akward for advanced users.
>>>> (*) there is another FEATURE that could be added, not exactly
>>>> relevant, but related... Change the mass storage driver to present a
>>>> *virtual* filesystem, i.e., be able to leave the sdcard MOUNTED, but
>>>> still grant access to it (i.e. how NFS is able to share a filesystem
>>>> to (multiple) other machines without making it unavailable to the
>>>> host.
>>>> 6) Two options;
>>>> a) tag it as unavailable. If a different sdcard is inserted
>>>> containing
>>>> the same app, it would also activate that one. If the same app is
>>>> later added to internal, it would activate that, i.e., the intent
>>>> would be the same since it isn't related to the UID.
>>>> b) don't allow sdcard apps to be added to the home screen. This is
>>>> just slightly easier, but not by much. It is also less "cool".

>>>> I would like to hear about any holes in this scheme that anyone can
>>>> think of.
>>>> And please, if you wish to contribute, be precise about any problems
>>>> that you see with this, and if possible, a solution *within the
>>>> bounds* of the infrastructure I have presented. I would rather not
>>>> have this degenerate into a "yeah, its nice, but wouldn't it be cool
>>>> if we did this instead". I would like comments that are constructive
>>>> with respect to making these suggestions happen with absolutely as
>>>> little modification as is required.

>>>> If we are able to come up with a concrete logical scheme, then at
>>>> that
>>>> point I would like to begin working on this from an implementation
>>>> perspective, i.e., how to *actually* make it happen.

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