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.