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