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