Guessing at what is and is not likely to be merged is probably a
little off-topic for this thread, but I have to go with the assumption
that it wouldn't be merged without the security features. And this I
judge not by yours or my own relative perception of the security of
this system wrt the existing security, but rather based on statements
made by JBQ on the matter.
And remember that there is more to security than simply copy-
protection. Take for example the situation where you swap sdcards with
someone, and the sdcard you shove into your phone has a malicious app
on it that wants to steal all of your personal information and send it
off to some hacker. There needs to be a permission verification scheme
in place to handle this possibility. When installing an app
internally, *every* app goes through the process where it shows what
permissions it requires and gives you the option to decline if you
aren't comfortable with it -- and obviously, if you shove in an sdcard
with 500 apps installed, you can't individually verify the security
for *every* app *every* time you insert the card... One possibility
would be to verify security at RUNTIME, but this would get invasive/
annoying very quickly, which is why I proposed the encrypted per-
device configuration file. Perhaps security verification at FIRST-
runtime and added to the per-device configuration file? But even that
would create problems since it would require a *very significant*
change in the package manager and what would it be... dalvik?
So we are left with the possibility of leaving it to a single device,
or to use per-device configurations. If it is left to a single device,
then we need only one encrypted packages.xml file on the sdcard
showing all the apps and all installed apps are authorized. If we use
a per-device configuration, then we need a master (unencrypted)
packages.xml file and a per-device file for each device. Regardless of
which device an app is installed from, it is added to the *master*
list and to that device's configuration file.
The way I look at the per-device configuration file is this;
The package manager is only interested in the per-device configuration
file associated with *that device* and needs to be triggered to
refresh whenever the per-device configuration is *changed*. This has
to happen regardless of whether it is a single-device or multi-device
scheme. The package installer needs to be extended to write BOTH the
per-device configuration file as well as the master file in the event
of multi-device configuration. No other (user visible) functions need
to be added to existing infrastructure to handle multi-device
configurations, but will rather be handled by a separate sdcard-app
maintenance program, which has functions as follows; create app-
storage, destroy app-storage, delete app from sdcard (regardless of
what device owns it), delete per-device configuration file (regardless
of what device it relates to), create per-device configuration file
for *current device*, adjust app authorizations (add or remove from
per-device file pertaining to *current* device).
Scheme: insert sdcard, attempt to mount external apps filesystem. If
exists but there is no per-device config file, launch "sdcard
application management interface", which lists all apps on sdcard,
associated permissions for each, and has a checkbox next to each one,
if checked, it is added to the per-device config file (and package
manager/launcher). If it is a protected app, it is shown, but greyed
out for all devices except the authorized device (being encrypted, it
wouldn't be runnable even if it was authorized). Protected apps are
always authorized to the authorized device (so no checkbox). Protected
apps and per-device configuration files can be *deleted* from *any*
device. Upon sdcard insertion, if per-device configuration *does*
exist, verify that all items within the per-device configuration are
within the master configuration and purge as required. Trigger
application manager to incorporate the apps in the per-device
configuration file.
I think that this is actually quite *necessary*.
Now off the topic of security, I would like opinions regarding the
filesystem for storing these apps. Obviously, it needs to be something
that supports a unix security model. But what are our options? Is extX
suitable? There are issues with ext2 associated with an unclean
unmount. Journaled? BTRfs?
And how do we deal with the filesystem? The downside of putting it in
its own partition is that MS's hostility routines will tell users to
format it (which they WILL do for lack of understanding -- so this is
OUT), another downside is that it will have to be configured at
initial sdcard setup. Partition resizing, though possible and safe in
a controlled situation, is too slow and too unreliable to be
implemented in a phone. Loopback mount? Advantages are that there
won't be a format-this prompt on MS and that it can be safely grown as
needed. Disadvantage there is a limit of 4GiB (fat32 filesize limit).
Is there a way around this limit? LVM would do it, but that's way too
resource intense for the hardware (i.e. major performance impact). Any
simple way to create a spanned file? I.e. you have 3 files ".extapps.
1, .extapps.2, .extapps.3", which are regarded as a single file
".extapps", which contains a single loopback filesystem of up to
12GiB. Does it even matter if we are limited to 4GiB? I suppose that
this could be considered as "future expansion" and doesn't necessarily
have to be implemented right away.
On Oct 28, 10:22 am, Disconnect <
dc.disconn...@gmail.com> wrote:
> My point is that it will likely get merged ANYWAY. It offers exactly
> as much data protection as the onboard storage does.
>