> 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

> ...

> read more »