All the engineers you mention routinely take part in open discussions:
San for vold and SD card management, Dianne for the application and
security model, Fadden for the dalvik side (though I'm not sure why
that's relevant), Romain for the Launcher side (though anything that'd
require to modify Launcher will need to be considered carefully as it
implies that we're breaking compatibility to some extent).
As for product management, I can play one for 10 seconds: "yes, that
sounds like a good idea, you're the engineers, figure out how to make
it happen when you have time for it".
Some of the hard requirements are:
-security: apps2sd must safeguard users' data and developers' code
with as much security as internal storage.
-stability: apps2sd must not cause the system to crash or leak
(including in situations where an SD card is permanently lost).
-compatibility: apps2sd must allow all existing applications (using
supported APIs) to work without modification (to the extent possible).
-ease of use: apps2sd must work with any SD card without requiring any
complex configuration.
-interoperabilty: apps2sd must work with UMS, and the space used for
apps2sd must be recoverable on a regular computer with no special
tools.
-performance: apps2sd must not cause any significant performance
degradation, including CPU, RAM, and battery life.
There's an additional "soft" requirement:
-hot-swap: apps2sd should work on devices with hot-swappable SD cards.
There might be more requirements, but those are probably a decent
starting point.
A major issue is resources: I'd expect that the people I mentioned
above will have time to discuss the design, the code, etc... but
probably won't have time to actually write any of it in the short
term, so there's no clear black-or-white statement about whether
anyone can or will get involved.
On Tue, Oct 27, 2009 at 2:35 PM, Eric F <ericfrie...@gmail.com> wrote:
> I've followed every single Apps on SD card thread that's ever been on
> android-platform AND android-discuss. People act like "this issue has
> been hashed out over and over again previously" as a way of dismissing
> any communication on this. The truth is the tip of the iceberg has
> barely been reached each time.
> Now that it is clear that Android 2.0 does not support any kind of
> apps on SD and that Google still neglected to hit the send button on
> the email saying "512MB isn't really enough guys". We need to revisit
> this. We need a complete list of requirements from OHA that are non
> negotiable (as in, a guarantee that a solution meeting those
> requirements can be merged into AOSP master). We need the Android
> developers responsible for:
> vold
> Package Installation Manager
> All the SD card related settings, setup, etc
> Application security model
> Possibly someone low level on Dalvik to answer questions on memory
> management and process killing in the event of SD card failure
> Launcher (we want to gray out unavailable programs)
> and we probably need an Android Product Manager (if you have such a
> role)
> We need these people to join this discussion and make sure at the very
> least they put in what OHA requirements are non-negotiable, what
> problems they foresee, and optionally ideas on how to go start a final
> design.
> Let's be serious. Just tell us this will or won't happen so we don't
> waste OUR valuable time. Otherwise whatever ends up sounding good here
> after a lot of careful design will just be discarded in one sentence
> by the above individuals at a later date. I would just like an end to
> the hypocrisy. Just say "this isn't going to happen. sorry guys, maybe
> next year" if that's what you mean. Otherwise, the people involved
> should start collaborating, perhaps a wiki design doc and start making
> serious progress on this.
> -E
> On Oct 22, 12:31 pm, Jean-Baptiste Queru <j...@android.com> wrote:
>> 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).
Actually, I think that this project would be a perfect fit with
another possibility that you mentioned... the community-AOSP branch.
It would allow US to develop the system over a period of time, in the
earlier stages perhaps relaxing some of the security considerations in
favor of getting a stable system (of course taking into consideration
the eventual security requirements). I.e., the first step is to build
the infrastructure that allows a group of apps to be added and removed
from the package manager, the second step is to actually get that onto
a single SDCARD and trigger it by sdcard mount/unmount, the third step
is to deal with UID issues and multiple-sdcards, etc., etc,. Once the
system has advanced to a state where it meets the core-AOSP security
and stability requirements (most likely with the assistance of google
engineers in the latter stages), then it can be merged in and everyone
will be happy.
Obviously, as I'm sure that everybody can agree, the current community-
type apps-on-sdcard system leaves a LOT to be desired, and I think
that this is due to the very limited organizational infrastructure
available to the community. When dealing with a project of this
magnitude, there is simply no sensible way to organize the community.
I'm sure that there are a LOT of people who would like to contribute
to this as long as the entire project doesn't rest on one person's
back.
On Oct 28, 8:29 am, Jean-Baptiste Queru <j...@android.com> wrote:
> All the engineers you mention routinely take part in open discussions:
> San for vold and SD card management, Dianne for the application and
> security model, Fadden for the dalvik side (though I'm not sure why
> that's relevant), Romain for the Launcher side (though anything that'd
> require to modify Launcher will need to be considered carefully as it
> implies that we're breaking compatibility to some extent).
> As for product management, I can play one for 10 seconds: "yes, that
> sounds like a good idea, you're the engineers, figure out how to make
> it happen when you have time for it".
> Some of the hard requirements are:
> -security: apps2sd must safeguard users' data and developers' code
> with as much security as internal storage.
> -stability: apps2sd must not cause the system to crash or leak
> (including in situations where an SD card is permanently lost).
> -compatibility: apps2sd must allow all existing applications (using
> supported APIs) to work without modification (to the extent possible).
> -ease of use: apps2sd must work with any SD card without requiring any
> complex configuration.
> -interoperabilty: apps2sd must work with UMS, and the space used for
> apps2sd must be recoverable on a regular computer with no special
> tools.
> -performance: apps2sd must not cause any significant performance
> degradation, including CPU, RAM, and battery life.
> There's an additional "soft" requirement:
> -hot-swap: apps2sd should work on devices with hot-swappable SD cards.
> There might be more requirements, but those are probably a decent
> starting point.
> A major issue is resources: I'd expect that the people I mentioned
> above will have time to discuss the design, the code, etc... but
> probably won't have time to actually write any of it in the short
> term, so there's no clear black-or-white statement about whether
> anyone can or will get involved.
> JBQ
> On Tue, Oct 27, 2009 at 2:35 PM, Eric F <ericfrie...@gmail.com> wrote:
> > I've followed every single Apps on SD card thread that's ever been on
> > android-platform AND android-discuss. People act like "this issue has
> > been hashed out over and over again previously" as a way of dismissing
> > any communication on this. The truth is the tip of the iceberg has
> > barely been reached each time.
> > Now that it is clear that Android 2.0 does not support any kind of
> > apps on SD and that Google still neglected to hit the send button on
> > the email saying "512MB isn't really enough guys". We need to revisit
> > this. We need a complete list of requirements from OHA that are non
> > negotiable (as in, a guarantee that a solution meeting those
> > requirements can be merged into AOSP master). We need the Android
> > developers responsible for:
> > vold
> > Package Installation Manager
> > All the SD card related settings, setup, etc
> > Application security model
> > Possibly someone low level on Dalvik to answer questions on memory
> > management and process killing in the event of SD card failure
> > Launcher (we want to gray out unavailable programs)
> > and we probably need an Android Product Manager (if you have such a
> > role)
> > We need these people to join this discussion and make sure at the very
> > least they put in what OHA requirements are non-negotiable, what
> > problems they foresee, and optionally ideas on how to go start a final
> > design.
> > Let's be serious. Just tell us this will or won't happen so we don't
> > waste OUR valuable time. Otherwise whatever ends up sounding good here
> > after a lot of careful design will just be discarded in one sentence
> > by the above individuals at a later date. I would just like an end to
> > the hypocrisy. Just say "this isn't going to happen. sorry guys, maybe
> > next year" if that's what you mean. Otherwise, the people involved
> > should start collaborating, perhaps a wiki design doc and start making
> > serious progress on this.
> > -E
> > On Oct 22, 12:31 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> 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).
> 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.
You're forgetting something easy though, on the security side. It is
required to offer the same protection as onboard storage. So all the
encryption/security mess can go away (for now) because aosp ships with
root. And since the word from the beginning was "its not our fault
devices are all locked down" a "complete" solution for android
doesn't have to include encryption or data-signing. (Yes, that leaves
out retail devices, but it also puts some of the more finicky work out
later and possibly gets vendors to contribute it.)
On Wed, Oct 28, 2009 at 9:58 AM, lbcoder <lbco...@gmail.com> wrote:
> Actually, I think that this project would be a perfect fit with
> another possibility that you mentioned... the community-AOSP branch.
> It would allow US to develop the system over a period of time, in the
> earlier stages perhaps relaxing some of the security considerations in
> favor of getting a stable system (of course taking into consideration
> the eventual security requirements). I.e., the first step is to build
> the infrastructure that allows a group of apps to be added and removed
> from the package manager, the second step is to actually get that onto
> a single SDCARD and trigger it by sdcard mount/unmount, the third step
> is to deal with UID issues and multiple-sdcards, etc., etc,. Once the
> system has advanced to a state where it meets the core-AOSP security
> and stability requirements (most likely with the assistance of google
> engineers in the latter stages), then it can be merged in and everyone
> will be happy.
> Obviously, as I'm sure that everybody can agree, the current community-
> type apps-on-sdcard system leaves a LOT to be desired, and I think
> that this is due to the very limited organizational infrastructure
> available to the community. When dealing with a project of this
> magnitude, there is simply no sensible way to organize the community.
> I'm sure that there are a LOT of people who would like to contribute
> to this as long as the entire project doesn't rest on one person's
> back.
> On Oct 28, 8:29 am, Jean-Baptiste Queru <j...@android.com> wrote:
>> All the engineers you mention routinely take part in open discussions:
>> San for vold and SD card management, Dianne for the application and
>> security model, Fadden for the dalvik side (though I'm not sure why
>> that's relevant), Romain for the Launcher side (though anything that'd
>> require to modify Launcher will need to be considered carefully as it
>> implies that we're breaking compatibility to some extent).
>> As for product management, I can play one for 10 seconds: "yes, that
>> sounds like a good idea, you're the engineers, figure out how to make
>> it happen when you have time for it".
>> Some of the hard requirements are:
>> -security: apps2sd must safeguard users' data and developers' code
>> with as much security as internal storage.
>> -stability: apps2sd must not cause the system to crash or leak
>> (including in situations where an SD card is permanently lost).
>> -compatibility: apps2sd must allow all existing applications (using
>> supported APIs) to work without modification (to the extent possible).
>> -ease of use: apps2sd must work with any SD card without requiring any
>> complex configuration.
>> -interoperabilty: apps2sd must work with UMS, and the space used for
>> apps2sd must be recoverable on a regular computer with no special
>> tools.
>> -performance: apps2sd must not cause any significant performance
>> degradation, including CPU, RAM, and battery life.
>> There's an additional "soft" requirement:
>> -hot-swap: apps2sd should work on devices with hot-swappable SD cards.
>> There might be more requirements, but those are probably a decent
>> starting point.
>> A major issue is resources: I'd expect that the people I mentioned
>> above will have time to discuss the design, the code, etc... but
>> probably won't have time to actually write any of it in the short
>> term, so there's no clear black-or-white statement about whether
>> anyone can or will get involved.
>> JBQ
>> On Tue, Oct 27, 2009 at 2:35 PM, Eric F <ericfrie...@gmail.com> wrote:
>> > I've followed every single Apps on SD card thread that's ever been on
>> > android-platform AND android-discuss. People act like "this issue has
>> > been hashed out over and over again previously" as a way of dismissing
>> > any communication on this. The truth is the tip of the iceberg has
>> > barely been reached each time.
>> > Now that it is clear that Android 2.0 does not support any kind of
>> > apps on SD and that Google still neglected to hit the send button on
>> > the email saying "512MB isn't really enough guys". We need to revisit
>> > this. We need a complete list of requirements from OHA that are non
>> > negotiable (as in, a guarantee that a solution meeting those
>> > requirements can be merged into AOSP master). We need the Android
>> > developers responsible for:
>> > vold
>> > Package Installation Manager
>> > All the SD card related settings, setup, etc
>> > Application security model
>> > Possibly someone low level on Dalvik to answer questions on memory
>> > management and process killing in the event of SD card failure
>> > Launcher (we want to gray out unavailable programs)
>> > and we probably need an Android Product Manager (if you have such a
>> > role)
>> > We need these people to join this discussion and make sure at the very
>> > least they put in what OHA requirements are non-negotiable, what
>> > problems they foresee, and optionally ideas on how to go start a final
>> > design.
>> > Let's be serious. Just tell us this will or won't happen so we don't
>> > waste OUR valuable time. Otherwise whatever ends up sounding good here
>> > after a lot of careful design will just be discarded in one sentence
>> > by the above individuals at a later date. I would just like an end to
>> > the hypocrisy. Just say "this isn't going to happen. sorry guys, maybe
>> > next year" if that's what you mean. Otherwise, the people involved
>> > should start collaborating, perhaps a wiki design doc and start making
>> > serious progress on this.
>> > -E
>> > On Oct 22, 12:31 pm, Jean-Baptiste Queru <j...@android.com> wrote:
>> >> 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).
>> 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.
I thought that I just said that...
"in the earlier stages perhaps relaxing some of the security
considerations in
favor of getting a stable system".
The main thing to be wary of is that the infrastructure we develop not
preclude the possibility of security, since this would block it from
ever being merged. That means that we need to discuss and assess the
security issues, just not necessarily IMPLEMENT them [all].
On Oct 28, 10:08 am, Disconnect <dc.disconn...@gmail.com> wrote:
> You're forgetting something easy though, on the security side. It is
> required to offer the same protection as onboard storage. So all the
> encryption/security mess can go away (for now) because aosp ships with
> root. And since the word from the beginning was "its not our fault
> devices are all locked down" a "complete" solution for android
> doesn't have to include encryption or data-signing. (Yes, that leaves
> out retail devices, but it also puts some of the more finicky work out
> later and possibly gets vendors to contribute it.)
> On Wed, Oct 28, 2009 at 9:58 AM, lbcoder <lbco...@gmail.com> wrote:
> > Actually, I think that this project would be a perfect fit with
> > another possibility that you mentioned... the community-AOSP branch.
> > It would allow US to develop the system over a period of time, in the
> > earlier stages perhaps relaxing some of the security considerations in
> > favor of getting a stable system (of course taking into consideration
> > the eventual security requirements). I.e., the first step is to build
> > the infrastructure that allows a group of apps to be added and removed
> > from the package manager, the second step is to actually get that onto
> > a single SDCARD and trigger it by sdcard mount/unmount, the third step
> > is to deal with UID issues and multiple-sdcards, etc., etc,. Once the
> > system has advanced to a state where it meets the core-AOSP security
> > and stability requirements (most likely with the assistance of google
> > engineers in the latter stages), then it can be merged in and everyone
> > will be happy.
> > Obviously, as I'm sure that everybody can agree, the current community-
> > type apps-on-sdcard system leaves a LOT to be desired, and I think
> > that this is due to the very limited organizational infrastructure
> > available to the community. When dealing with a project of this
> > magnitude, there is simply no sensible way to organize the community.
> > I'm sure that there are a LOT of people who would like to contribute
> > to this as long as the entire project doesn't rest on one person's
> > back.
> > On Oct 28, 8:29 am, Jean-Baptiste Queru <j...@android.com> wrote:
> >> All the engineers you mention routinely take part in open discussions:
> >> San for vold and SD card management, Dianne for the application and
> >> security model, Fadden for the dalvik side (though I'm not sure why
> >> that's relevant), Romain for the Launcher side (though anything that'd
> >> require to modify Launcher will need to be considered carefully as it
> >> implies that we're breaking compatibility to some extent).
> >> As for product management, I can play one for 10 seconds: "yes, that
> >> sounds like a good idea, you're the engineers, figure out how to make
> >> it happen when you have time for it".
> >> Some of the hard requirements are:
> >> -security: apps2sd must safeguard users' data and developers' code
> >> with as much security as internal storage.
> >> -stability: apps2sd must not cause the system to crash or leak
> >> (including in situations where an SD card is permanently lost).
> >> -compatibility: apps2sd must allow all existing applications (using
> >> supported APIs) to work without modification (to the extent possible).
> >> -ease of use: apps2sd must work with any SD card without requiring any
> >> complex configuration.
> >> -interoperabilty: apps2sd must work with UMS, and the space used for
> >> apps2sd must be recoverable on a regular computer with no special
> >> tools.
> >> -performance: apps2sd must not cause any significant performance
> >> degradation, including CPU, RAM, and battery life.
> >> There's an additional "soft" requirement:
> >> -hot-swap: apps2sd should work on devices with hot-swappable SD cards.
> >> There might be more requirements, but those are probably a decent
> >> starting point.
> >> A major issue is resources: I'd expect that the people I mentioned
> >> above will have time to discuss the design, the code, etc... but
> >> probably won't have time to actually write any of it in the short
> >> term, so there's no clear black-or-white statement about whether
> >> anyone can or will get involved.
> >> JBQ
> >> On Tue, Oct 27, 2009 at 2:35 PM, Eric F <ericfrie...@gmail.com> wrote:
> >> > I've followed every single Apps on SD card thread that's ever been on
> >> > android-platform AND android-discuss. People act like "this issue has
> >> > been hashed out over and over again previously" as a way of dismissing
> >> > any communication on this. The truth is the tip of the iceberg has
> >> > barely been reached each time.
> >> > Now that it is clear that Android 2.0 does not support any kind of
> >> > apps on SD and that Google still neglected to hit the send button on
> >> > the email saying "512MB isn't really enough guys". We need to revisit
> >> > this. We need a complete list of requirements from OHA that are non
> >> > negotiable (as in, a guarantee that a solution meeting those
> >> > requirements can be merged into AOSP master). We need the Android
> >> > developers responsible for:
> >> > vold
> >> > Package Installation Manager
> >> > All the SD card related settings, setup, etc
> >> > Application security model
> >> > Possibly someone low level on Dalvik to answer questions on memory
> >> > management and process killing in the event of SD card failure
> >> > Launcher (we want to gray out unavailable programs)
> >> > and we probably need an Android Product Manager (if you have such a
> >> > role)
> >> > We need these people to join this discussion and make sure at the very
> >> > least they put in what OHA requirements are non-negotiable, what
> >> > problems they foresee, and optionally ideas on how to go start a final
> >> > design.
> >> > Let's be serious. Just tell us this will or won't happen so we don't
> >> > waste OUR valuable time. Otherwise whatever ends up sounding good here
> >> > after a lot of careful design will just be discarded in one sentence
> >> > by the above individuals at a later date. I would just like an end to
> >> > the hypocrisy. Just say "this isn't going to happen. sorry guys, maybe
> >> > next year" if that's what you mean. Otherwise, the people involved
> >> > should start collaborating, perhaps a wiki design doc and start making
> >> > serious progress on this.
> >> > -E
> >> > On Oct 22, 12:31 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> 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).
> >> 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.
On Wed, Oct 28, 2009 at 10:17 AM, lbcoder <lbco...@gmail.com> wrote:
> I thought that I just said that...
> "in the earlier stages perhaps relaxing some of the security
> considerations in
> favor of getting a stable system".
> The main thing to be wary of is that the infrastructure we develop not
> preclude the possibility of security, since this would block it from
> ever being merged. That means that we need to discuss and assess the
> security issues, just not necessarily IMPLEMENT them [all].
> On Oct 28, 10:08 am, Disconnect <dc.disconn...@gmail.com> wrote:
>> You're forgetting something easy though, on the security side. It is
>> required to offer the same protection as onboard storage. So all the
>> encryption/security mess can go away (for now) because aosp ships with
>> root. And since the word from the beginning was "its not our fault
>> devices are all locked down" a "complete" solution for android
>> doesn't have to include encryption or data-signing. (Yes, that leaves
>> out retail devices, but it also puts some of the more finicky work out
>> later and possibly gets vendors to contribute it.)
>> On Wed, Oct 28, 2009 at 9:58 AM, lbcoder <lbco...@gmail.com> wrote:
>> > Actually, I think that this project would be a perfect fit with
>> > another possibility that you mentioned... the community-AOSP branch.
>> > It would allow US to develop the system over a period of time, in the
>> > earlier stages perhaps relaxing some of the security considerations in
>> > favor of getting a stable system (of course taking into consideration
>> > the eventual security requirements). I.e., the first step is to build
>> > the infrastructure that allows a group of apps to be added and removed
>> > from the package manager, the second step is to actually get that onto
>> > a single SDCARD and trigger it by sdcard mount/unmount, the third step
>> > is to deal with UID issues and multiple-sdcards, etc., etc,. Once the
>> > system has advanced to a state where it meets the core-AOSP security
>> > and stability requirements (most likely with the assistance of google
>> > engineers in the latter stages), then it can be merged in and everyone
>> > will be happy.
>> > Obviously, as I'm sure that everybody can agree, the current community-
>> > type apps-on-sdcard system leaves a LOT to be desired, and I think
>> > that this is due to the very limited organizational infrastructure
>> > available to the community. When dealing with a project of this
>> > magnitude, there is simply no sensible way to organize the community.
>> > I'm sure that there are a LOT of people who would like to contribute
>> > to this as long as the entire project doesn't rest on one person's
>> > back.
>> > On Oct 28, 8:29 am, Jean-Baptiste Queru <j...@android.com> wrote:
>> >> All the engineers you mention routinely take part in open discussions:
>> >> San for vold and SD card management, Dianne for the application and
>> >> security model, Fadden for the dalvik side (though I'm not sure why
>> >> that's relevant), Romain for the Launcher side (though anything that'd
>> >> require to modify Launcher will need to be considered carefully as it
>> >> implies that we're breaking compatibility to some extent).
>> >> As for product management, I can play one for 10 seconds: "yes, that
>> >> sounds like a good idea, you're the engineers, figure out how to make
>> >> it happen when you have time for it".
>> >> Some of the hard requirements are:
>> >> -security: apps2sd must safeguard users' data and developers' code
>> >> with as much security as internal storage.
>> >> -stability: apps2sd must not cause the system to crash or leak
>> >> (including in situations where an SD card is permanently lost).
>> >> -compatibility: apps2sd must allow all existing applications (using
>> >> supported APIs) to work without modification (to the extent possible).
>> >> -ease of use: apps2sd must work with any SD card without requiring any
>> >> complex configuration.
>> >> -interoperabilty: apps2sd must work with UMS, and the space used for
>> >> apps2sd must be recoverable on a regular computer with no special
>> >> tools.
>> >> -performance: apps2sd must not cause any significant performance
>> >> degradation, including CPU, RAM, and battery life.
>> >> There's an additional "soft" requirement:
>> >> -hot-swap: apps2sd should work on devices with hot-swappable SD cards.
>> >> There might be more requirements, but those are probably a decent
>> >> starting point.
>> >> A major issue is resources: I'd expect that the people I mentioned
>> >> above will have time to discuss the design, the code, etc... but
>> >> probably won't have time to actually write any of it in the short
>> >> term, so there's no clear black-or-white statement about whether
>> >> anyone can or will get involved.
>> >> JBQ
>> >> On Tue, Oct 27, 2009 at 2:35 PM, Eric F <ericfrie...@gmail.com> wrote:
>> >> > I've followed every single Apps on SD card thread that's ever been on
>> >> > android-platform AND android-discuss. People act like "this issue has
>> >> > been hashed out over and over again previously" as a way of dismissing
>> >> > any communication on this. The truth is the tip of the iceberg has
>> >> > barely been reached each time.
>> >> > Now that it is clear that Android 2.0 does not support any kind of
>> >> > apps on SD and that Google still neglected to hit the send button on
>> >> > the email saying "512MB isn't really enough guys". We need to revisit
>> >> > this. We need a complete list of requirements from OHA that are non
>> >> > negotiable (as in, a guarantee that a solution meeting those
>> >> > requirements can be merged into AOSP master). We need the Android
>> >> > developers responsible for:
>> >> > vold
>> >> > Package Installation Manager
>> >> > All the SD card related settings, setup, etc
>> >> > Application security model
>> >> > Possibly someone low level on Dalvik to answer questions on memory
>> >> > management and process killing in the event of SD card failure
>> >> > Launcher (we want to gray out unavailable programs)
>> >> > and we probably need an Android Product Manager (if you have such a
>> >> > role)
>> >> > We need these people to join this discussion and make sure at the very
>> >> > least they put in what OHA requirements are non-negotiable, what
>> >> > problems they foresee, and optionally ideas on how to go start a final
>> >> > design.
>> >> > Let's be serious. Just tell us this will or won't happen so we don't
>> >> > waste OUR valuable time. Otherwise whatever ends up sounding good here
>> >> > after a lot of careful design will just be discarded in one sentence
>> >> > by the above individuals at a later date. I would just like an end to
>> >> > the hypocrisy. Just say "this isn't going to happen. sorry guys, maybe
>> >> > next year" if that's what you mean. Otherwise, the people involved
>> >> > should start collaborating, perhaps a wiki design doc and start making
>> >> > serious progress on this.
>> >> > -E
>> >> > On Oct 22, 12:31 pm, Jean-Baptiste Queru <j...@android.com> wrote:
>> >> >> 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).
>> >> 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.
For the record there is at least one more hard requirement: the
solution has to support swappable SD cards, and must "do the right
thing" when an app on SD card winds up having the same uid assignment
as an app already installed on the internal disk. REALLY doing the
right thing involves correctly handling the case of explicitly
shared-uid apps in this situation as well as not-shared-uid.
On Wed, Oct 28, 2009 at 5:29 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> All the engineers you mention routinely take part in open discussions:
> San for vold and SD card management, Dianne for the application and
> security model, Fadden for the dalvik side (though I'm not sure why
> that's relevant), Romain for the Launcher side (though anything that'd
> require to modify Launcher will need to be considered carefully as it
> implies that we're breaking compatibility to some extent).
> As for product management, I can play one for 10 seconds: "yes, that
> sounds like a good idea, you're the engineers, figure out how to make
> it happen when you have time for it".
> Some of the hard requirements are:
> -security: apps2sd must safeguard users' data and developers' code
> with as much security as internal storage.
> -stability: apps2sd must not cause the system to crash or leak
> (including in situations where an SD card is permanently lost).
> -compatibility: apps2sd must allow all existing applications (using
> supported APIs) to work without modification (to the extent possible).
> -ease of use: apps2sd must work with any SD card without requiring any
> complex configuration.
> -interoperabilty: apps2sd must work with UMS, and the space used for
> apps2sd must be recoverable on a regular computer with no special
> tools.
> -performance: apps2sd must not cause any significant performance
> degradation, including CPU, RAM, and battery life.
> There's an additional "soft" requirement:
> -hot-swap: apps2sd should work on devices with hot-swappable SD cards.
> There might be more requirements, but those are probably a decent
> starting point.
> A major issue is resources: I'd expect that the people I mentioned
> above will have time to discuss the design, the code, etc... but
> probably won't have time to actually write any of it in the short
> term, so there's no clear black-or-white statement about whether
> anyone can or will get involved.
> JBQ
> On Tue, Oct 27, 2009 at 2:35 PM, Eric F <ericfrie...@gmail.com> wrote:
>> I've followed every single Apps on SD card thread that's ever been on
>> android-platform AND android-discuss. People act like "this issue has
>> been hashed out over and over again previously" as a way of dismissing
>> any communication on this. The truth is the tip of the iceberg has
>> barely been reached each time.
>> Now that it is clear that Android 2.0 does not support any kind of
>> apps on SD and that Google still neglected to hit the send button on
>> the email saying "512MB isn't really enough guys". We need to revisit
>> this. We need a complete list of requirements from OHA that are non
>> negotiable (as in, a guarantee that a solution meeting those
>> requirements can be merged into AOSP master). We need the Android
>> developers responsible for:
>> vold
>> Package Installation Manager
>> All the SD card related settings, setup, etc
>> Application security model
>> Possibly someone low level on Dalvik to answer questions on memory
>> management and process killing in the event of SD card failure
>> Launcher (we want to gray out unavailable programs)
>> and we probably need an Android Product Manager (if you have such a
>> role)
>> We need these people to join this discussion and make sure at the very
>> least they put in what OHA requirements are non-negotiable, what
>> problems they foresee, and optionally ideas on how to go start a final
>> design.
>> Let's be serious. Just tell us this will or won't happen so we don't
>> waste OUR valuable time. Otherwise whatever ends up sounding good here
>> after a lot of careful design will just be discarded in one sentence
>> by the above individuals at a later date. I would just like an end to
>> the hypocrisy. Just say "this isn't going to happen. sorry guys, maybe
>> next year" if that's what you mean. Otherwise, the people involved
>> should start collaborating, perhaps a wiki design doc and start making
>> serious progress on this.
>> -E
>> On Oct 22, 12:31 pm, Jean-Baptiste Queru <j...@android.com> wrote:
>>> 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).
> 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.
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.
> On Wed, Oct 28, 2009 at 10:17 AM, lbcoder <lbco...@gmail.com> wrote:
> > I thought that I just said that...
> > "in the earlier stages perhaps relaxing some of the security
> > considerations in
> > favor of getting a stable system".
> > The main thing to be wary of is that the infrastructure we develop not
> > preclude the possibility of security, since this would block it from
> > ever being merged. That means that we need to discuss and assess the
> > security issues, just not necessarily IMPLEMENT them [all].
> > On Oct 28, 10:08 am, Disconnect <dc.disconn...@gmail.com> wrote:
> >> You're forgetting something easy though, on the security side. It is
> >> required to offer the same protection as onboard storage. So all the
> >> encryption/security mess can go away (for now) because aosp ships with
> >> root. And since the word from the beginning was "its not our fault
> >> devices are all locked down" a "complete" solution for android
> >> doesn't have to include encryption or data-signing. (Yes, that leaves
> >> out retail devices, but it also puts some of the more finicky work out
> >> later and possibly gets vendors to contribute it.)
> >> On Wed, Oct 28, 2009 at 9:58 AM, lbcoder <lbco...@gmail.com> wrote:
> >> > Actually, I think that this project would be a perfect fit with
> >> > another possibility that you mentioned... the community-AOSP branch.
> >> > It would allow US to develop the system over a period of time, in the
> >> > earlier stages perhaps relaxing some of the security considerations in
> >> > favor of getting a stable system (of course taking into consideration
> >> > the eventual security requirements). I.e., the first step is to build
> >> > the infrastructure that allows a group of apps to be added and removed
> >> > from the package manager, the second step is to actually get that onto
> >> > a single SDCARD and trigger it by sdcard mount/unmount, the third step
> >> > is to deal with UID issues and multiple-sdcards, etc., etc,. Once the
> >> > system has advanced to a state where it meets the core-AOSP security
> >> > and stability requirements (most likely with the assistance of google
> >> > engineers in the latter stages), then it can be merged in and everyone
> >> > will be happy.
> >> > Obviously, as I'm sure that everybody can agree, the current community-
> >> > type apps-on-sdcard system leaves a LOT to be desired, and I think
> >> > that this is due to the very limited organizational infrastructure
> >> > available to the community. When dealing with a project of this
> >> > magnitude, there is simply no sensible way to organize the community.
> >> > I'm sure that there are a LOT of people who would like to contribute
> >> > to this as long as the entire project doesn't rest on one person's
> >> > back.
> >> > On Oct 28, 8:29 am, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> All the engineers you mention routinely take part in open discussions:
> >> >> San for vold and SD card management, Dianne for the application and
> >> >> security model, Fadden for the dalvik side (though I'm not sure why
> >> >> that's relevant), Romain for the Launcher side (though anything that'd
> >> >> require to modify Launcher will need to be considered carefully as it
> >> >> implies that we're breaking compatibility to some extent).
> >> >> As for product management, I can play one for 10 seconds: "yes, that
> >> >> sounds like a good idea, you're the engineers, figure out how to make
> >> >> it happen when you have time for it".
> >> >> Some of the hard requirements are:
> >> >> -security: apps2sd must safeguard users' data and developers' code
> >> >> with as much security as internal storage.
> >> >> -stability: apps2sd must not cause the system to crash or leak
> >> >> (including in situations where an SD card is permanently lost).
> >> >> -compatibility: apps2sd must allow all existing applications (using
> >> >> supported APIs) to work without modification (to the extent possible).
> >> >> -ease of use: apps2sd must work with any SD card without requiring any
> For the record there is at least one more hard requirement: the
> solution has to support swappable SD cards, and must "do the right
> thing" when an app on SD card winds up having the same uid assignment
> as an app already installed on the internal disk. REALLY doing the
> right thing involves correctly handling the case of explicitly
> shared-uid apps in this situation as well as not-shared-uid.
> --
> chris tate
> android framework engineer
> On Wed, Oct 28, 2009 at 5:29 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> > All the engineers you mention routinely take part in open discussions:
> > San for vold and SD card management, Dianne for the application and
> > security model, Fadden for the dalvik side (though I'm not sure why
> > that's relevant), Romain for the Launcher side (though anything that'd
> > require to modify Launcher will need to be considered carefully as it
> > implies that we're breaking compatibility to some extent).
> > As for product management, I can play one for 10 seconds: "yes, that
> > sounds like a good idea, you're the engineers, figure out how to make
> > it happen when you have time for it".
> > Some of the hard requirements are:
> > -security: apps2sd must safeguard users' data and developers' code
> > with as much security as internal storage.
> > -stability: apps2sd must not cause the system to crash or leak
> > (including in situations where an SD card is permanently lost).
> > -compatibility: apps2sd must allow all existing applications (using
> > supported APIs) to work without modification (to the extent possible).
> > -ease of use: apps2sd must work with any SD card without requiring any
> > complex configuration.
> > -interoperabilty: apps2sd must work with UMS, and the space used for
> > apps2sd must be recoverable on a regular computer with no special
> > tools.
> > -performance: apps2sd must not cause any significant performance
> > degradation, including CPU, RAM, and battery life.
> > There's an additional "soft" requirement:
> > -hot-swap: apps2sd should work on devices with hot-swappable SD cards.
> > There might be more requirements, but those are probably a decent
> > starting point.
> > A major issue is resources: I'd expect that the people I mentioned
> > above will have time to discuss the design, the code, etc... but
> > probably won't have time to actually write any of it in the short
> > term, so there's no clear black-or-white statement about whether
> > anyone can or will get involved.
> > JBQ
> > On Tue, Oct 27, 2009 at 2:35 PM, Eric F <ericfrie...@gmail.com> wrote:
> >> I've followed every single Apps on SD card thread that's ever been on
> >> android-platform AND android-discuss. People act like "this issue has
> >> been hashed out over and over again previously" as a way of dismissing
> >> any communication on this. The truth is the tip of the iceberg has
> >> barely been reached each time.
> >> Now that it is clear that Android 2.0 does not support any kind of
> >> apps on SD and that Google still neglected to hit the send button on
> >> the email saying "512MB isn't really enough guys". We need to revisit
> >> this. We need a complete list of requirements from OHA that are non
> >> negotiable (as in, a guarantee that a solution meeting those
> >> requirements can be merged into AOSP master). We need the Android
> >> developers responsible for:
> >> vold
> >> Package Installation Manager
> >> All the SD card related settings, setup, etc
> >> Application security model
> >> Possibly someone low level on Dalvik to answer questions on memory
> >> management and process killing in the event of SD card failure
> >> Launcher (we want to gray out unavailable programs)
> >> and we probably need an Android Product Manager (if you have such a
> >> role)
> >> We need these people to join this discussion and make sure at the very
> >> least they put in what OHA requirements are non-negotiable, what
> >> problems they foresee, and optionally ideas on how to go start a final
> >> design.
> >> Let's be serious. Just tell us this will or won't happen so we don't
> >> waste OUR valuable time. Otherwise whatever ends up sounding good here
> >> after a lot of careful design will just be discarded in one sentence
> >> by the above individuals at a later date. I would just like an end to
> >> the hypocrisy. Just say "this isn't going to happen. sorry guys, maybe
> >> next year" if that's what you mean. Otherwise, the people involved
> >> should start collaborating, perhaps a wiki design doc and start making
> >> serious progress on this.
> >> -E
> >> On Oct 22, 12:31 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> 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).
> > 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.
> For the record there is at least one more hard requirement: the
> solution has to support swappable SD cards, and must "do the right
> thing" when an app on SD card winds up having the same uid assignment
> as an app already installed on the internal disk. REALLY doing the
> right thing involves correctly handling the case of explicitly
> shared-uid apps in this situation as well as not-shared-uid.
> --
> chris tate
> android framework engineer
> On Wed, Oct 28, 2009 at 5:29 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> > All the engineers you mention routinely take part in open discussions:
> > San for vold and SD card management, Dianne for the application and
> > security model, Fadden for the dalvik side (though I'm not sure why
> > that's relevant), Romain for the Launcher side (though anything that'd
> > require to modify Launcher will need to be considered carefully as it
> > implies that we're breaking compatibility to some extent).
> > As for product management, I can play one for 10 seconds: "yes, that
> > sounds like a good idea, you're the engineers, figure out how to make
> > it happen when you have time for it".
> > Some of the hard requirements are:
> > -security: apps2sd must safeguard users' data and developers' code
> > with as much security as internal storage.
> > -stability: apps2sd must not cause the system to crash or leak
> > (including in situations where an SD card is permanently lost).
> > -compatibility: apps2sd must allow all existing applications (using
> > supported APIs) to work without modification (to the extent possible).
> > -ease of use: apps2sd must work with any SD card without requiring any
> > complex configuration.
> > -interoperabilty: apps2sd must work with UMS, and the space used for
> > apps2sd must be recoverable on a regular computer with no special
> > tools.
> > -performance: apps2sd must not cause any significant performance
> > degradation, including CPU, RAM, and battery life.
> > There's an additional "soft" requirement:
> > -hot-swap: apps2sd should work on devices with hot-swappable SD cards.
> > There might be more requirements, but those are probably a decent
> > starting point.
> > A major issue is resources: I'd expect that the people I mentioned
> > above will have time to discuss the design, the code, etc... but
> > probably won't have time to actually write any of it in the short
> > term, so there's no clear black-or-white statement about whether
> > anyone can or will get involved.
> > JBQ
> > On Tue, Oct 27, 2009 at 2:35 PM, Eric F <ericfrie...@gmail.com> wrote:
> >> I've followed every single Apps on SD card thread that's ever been on
> >> android-platform AND android-discuss. People act like "this issue has
> >> been hashed out over and over again previously" as a way of dismissing
> >> any communication on this. The truth is the tip of the iceberg has
> >> barely been reached each time.
> >> Now that it is clear that Android 2.0 does not support any kind of
> >> apps on SD and that Google still neglected to hit the send button on
> >> the email saying "512MB isn't really enough guys". We need to revisit
> >> this. We need a complete list of requirements from OHA that are non
> >> negotiable (as in, a guarantee that a solution meeting those
> >> requirements can be merged into AOSP master). We need the Android
> >> developers responsible for:
> >> vold
> >> Package Installation Manager
> >> All the SD card related settings, setup, etc
> >> Application security model
> >> Possibly someone low level on Dalvik to answer questions on memory
> >> management and process killing in the event of SD card failure
> >> Launcher (we want to gray out unavailable programs)
> >> and we probably need an Android Product Manager (if you have such a
> >> role)
> >> We need these people to join this discussion and make sure at the very
> >> least they put in what OHA requirements are non-negotiable, what
> >> problems they foresee, and optionally ideas on how to go start a final
> >> design.
> >> Let's be serious. Just tell us this will or won't happen so we don't
> >> waste OUR valuable time. Otherwise whatever ends up sounding good here
> >> after a lot of careful design will just be discarded in one sentence
> >> by the above individuals at a later date. I would just like an end to
> >> the hypocrisy. Just say "this isn't going to happen. sorry guys, maybe
> >> next year" if that's what you mean. Otherwise, the people involved
> >> should start collaborating, perhaps a wiki design doc and start making
> >> serious progress on this.
> >> -E
> >> On Oct 22, 12:31 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> 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).
> > 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.
Wouldn't it be easier to make a "per application" configuration that gets
stored on the device? The device reads the .APK's stored on the card. At
first runtime it generates a hash of the APK and then prompts for
permissions.
Any time that app comes across the device (whether on another SDCARD that the
user used to back up or whatever) the launcher checks the hash to make sure
it's the same application that got approved previously.
You could also, in the same config file, link each app to a local UID so that
you don't run into the UID problem.
Of course, this feels like you now need changes to the app launcher and the
package manager...
[mailto:android-platform@googlegroups.com] On Behalf Of lbcoder
Sent: October-28-09 12:46 PM
To: android-platform
Subject: ****SPAM**** Re: More Applications on SDCARD
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.
> On Wed, Oct 28, 2009 at 10:17 AM, lbcoder <lbco...@gmail.com> wrote:
> > I thought that I just said that...
> > "in the earlier stages perhaps relaxing some of the security
> > considerations in
> > favor of getting a stable system".
> > The main thing to be wary of is that the infrastructure we develop not
> > preclude the possibility of security, since this would block it from
> > ever being merged. That means that we need to discuss and assess the
> > security issues, just not necessarily IMPLEMENT them [all].
> > On Oct 28, 10:08 am, Disconnect <dc.disconn...@gmail.com> wrote:
> >> You're forgetting something easy though, on the security side. It is
> >> required to offer the same protection as onboard storage. So all the
> >> encryption/security mess can go away (for now) because aosp ships with
> >> root. And since the word from the beginning was "its not our fault
> >> devices are all locked down" a "complete" solution for android
> >> doesn't have to include encryption or data-signing. (Yes, that leaves
> >> out retail devices, but it also puts some of the more finicky work out
> >> later and possibly gets vendors to contribute it.)
> >> On Wed, Oct 28, 2009 at 9:58 AM, lbcoder <lbco...@gmail.com> wrote:
> >> > Actually, I think that this project would be a perfect fit with
> >> > another possibility that you mentioned... the community-AOSP branch.
> >> > It would allow US to develop the system over a period of time, in the
> >> > earlier stages perhaps relaxing some of the security considerations in
> >> > favor of getting a stable system (of course taking into consideration
> >> > the eventual security requirements). I.e., the first step is to build
> >> > the infrastructure that allows a group of apps to be added and removed
> >> > from the package manager, the second step is to actually get that onto
> >> > a single SDCARD and trigger it by sdcard mount/unmount, the third step
> >> > is to deal with UID issues and multiple-sdcards, etc., etc,. Once the
> >> > system has advanced to a state where it meets the core-AOSP security
> >> > and stability requirements (most likely with the assistance of google
> >> > engineers in the latter stages), then it can be merged in and everyone
> >> > will be happy.
> >> > Obviously, as I'm sure that everybody can agree, the current
community-
> >> > type apps-on-sdcard system leaves a LOT to be desired, and I think
> >> > that this is due to the very limited organizational infrastructure
> >> > available to the community. When dealing with a project of this
> >> > magnitude, there is simply no sensible way to organize the community.
> >> > I'm sure that there are a LOT of people who would like to contribute
> >> > to this as long as the entire project doesn't rest on one person's
> >> > back.
> >> > On Oct 28, 8:29 am, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> All the engineers you mention routinely take part in open
discussions:
> >> >> San for vold and SD card management, Dianne for the application and
> >> >> security model, Fadden for the dalvik side (though I'm not sure why
> >> >> that's relevant),
3 words: simplify, simplify, simplify. Assume it's a really hard
problem (if it wasn't, we'd have solved it a long time ago).
-aim to make the SD card work in a single device. Heck, even if the
system can only track a single SD card at a time it's probably still
fine. Personally, I'd hate to put restrictions on shared UIDs but I
guess that's just a pet peeve of mine.
-filesystem: let's assume some permission-enforcing filesystem in an
encrypted disk image stored in a single file (skip the encryption for
initial development). Start with ext2 or ext3. Once the rest of the
system works, we can refine this part as necessary. Partitioning the
SD card isn't an option. Keep UMS in mind, it's probably more tricky
than it seems.
On Wed, Oct 28, 2009 at 9:46 AM, lbcoder <lbco...@gmail.com> wrote:
> 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.
>> On Wed, Oct 28, 2009 at 10:17 AM, lbcoder <lbco...@gmail.com> wrote:
>> > I thought that I just said that...
>> > "in the earlier stages perhaps relaxing some of the security
>> > considerations in
>> > favor of getting a stable system".
>> > The main thing to be wary of is that the infrastructure we develop not
>> > preclude the possibility of security, since this would block it from
>> > ever being merged. That means that we need to discuss and assess the
>> > security issues, just not necessarily IMPLEMENT them [all].
>> > On Oct 28, 10:08 am, Disconnect <dc.disconn...@gmail.com> wrote:
>> >> You're forgetting something easy though, on the security side. It is
>> >> required to offer the same protection as onboard storage. So all the
>> >> encryption/security mess can go away (for now) because aosp ships with
>> >> root. And since the word from the beginning was "its not our fault
>> >> devices are all locked down" a "complete" solution for android
>> >> doesn't have to include encryption or data-signing. (Yes, that leaves
>> >> out retail devices, but it also puts some of the more finicky work out
>> >> later and possibly gets vendors to contribute it.)
>> >> On Wed, Oct 28, 2009 at 9:58 AM, lbcoder <lbco...@gmail.com> wrote:
>> >> > Actually, I think that this project would be a perfect fit with
>> >> > another possibility that you mentioned... the community-AOSP branch.
>> >> > It would allow US to develop the system over a period of time, in the
>> >> > earlier stages perhaps relaxing some of the security considerations in
>> >> > favor of getting a stable system (of course taking into consideration
>> >> > the eventual security requirements). I.e., the first step is to build
>> >> > the infrastructure that allows a group of apps to be added and removed
>> >> > from the package manager, the second step is to actually get that onto
>> >> > a single SDCARD and trigger it by sdcard mount/unmount, the third step
>> >> > is to deal with UID issues and multiple-sdcards, etc., etc,. Once the
>> >> > system has advanced to a state where it meets the core-AOSP security
>> >> > and stability requirements (most likely with the assistance of google
>> >> > engineers in the latter stages), then it can be merged in and everyone
>> >> > will be happy.
>> >> > Obviously, as I'm sure that everybody can agree, the current community-
>> >> > type apps-on-sdcard system leaves a LOT to be desired, and I think
>> >> > that this is due to the very limited organizational infrastructure
>> >> > available to the community. When dealing with a project of this
>> >> > magnitude, there is simply no sensible way to organize the community.
>> >> > I'm sure that there are a LOT of people who would like to contribute
>> >> > to this as long as the entire project doesn't rest on one person's
>> >> > back.
>> >> > On Oct 28, 8:29 am, Jean-Baptiste Queru <j...@android.com> wrote:
>> >> >> All the engineers you mention routinely take part in open discussions:
>> >> >> San for vold and SD card management, Dianne for the application and
Could you check your email client settings... it marked this as spam
and added an ugly ***SPAM*** into the thread title.
I think I understand what you are proposing, but here's where it
breaks down; each application has its home path -- currently in /data/
data/package.name. These files are owned by the UID associated with
that particular app in the system. This means that the same UID must
be maintained regardless of what device the card is inserted into.
Could you go back and please consider my UID range segregation
proposal.
Regarding changes to the app launcher and package manager...
obviously, no matter what scheme is settled on, changes will be
required. Though I don't think necessarily to the launcher (although
it would ultimately be nice to have external apps visually separated
from internal apps...).
On Oct 28, 12:58 pm, "Patrick Ethier" <patr...@secureops.com> wrote:
> Wouldn't it be easier to make a "per application" configuration that gets
> stored on the device? The device reads the .APK's stored on the card. At
> first runtime it generates a hash of the APK and then prompts for
> permissions.
> Any time that app comes across the device (whether on another SDCARD that the
> user used to back up or whatever) the launcher checks the hash to make sure
> it's the same application that got approved previously.
> You could also, in the same config file, link each app to a local UID so that
> you don't run into the UID problem.
> Of course, this feels like you now need changes to the app launcher and the
> package manager...
> [mailto:android-platform@googlegroups.com] On Behalf Of lbcoder
> Sent: October-28-09 12:46 PM
> To: android-platform
> Subject: ****SPAM**** Re: More Applications on SDCARD
> 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.
> > On Wed, Oct 28, 2009 at 10:17 AM, lbcoder <lbco...@gmail.com> wrote:
> > > I thought that I just said that...
> > > "in the earlier stages perhaps relaxing some of the security
> > > considerations in
> > > favor of getting a stable system".
> > > The main thing to be wary of is that the infrastructure we develop not
> > > preclude the possibility of security, since this would block it from
> > > ever being merged. That means that we need to discuss and assess the
> > > security issues, just not necessarily IMPLEMENT them [all].
> > > On Oct 28, 10:08 am, Disconnect <dc.disconn...@gmail.com> wrote:
> > >> You're forgetting something easy though, on the security side. It is
> > >> required to offer the same protection as onboard storage. So all the
> > >> encryption/security mess can go away (for now) because aosp ships with
> > >> root. And since the word from the beginning was "its not our fault
> > >> devices are all locked down" a "complete" solution for android
> > >> doesn't have to include encryption or data-signing. (Yes, that leaves
> > >> out retail devices, but it also puts some of the more finicky work out
> > >> later and possibly gets vendors to contribute it.)
> > >> On Wed, Oct 28, 2009 at 9:58 AM, lbcoder <lbco...@gmail.com> wrote:
> > >> > Actually, I think that this project would be a perfect fit with
> > >> > another possibility that you mentioned... the community-AOSP branch.
> > >> > It would allow US to develop the system over a period of time, in the
> > >> > earlier stages perhaps relaxing some of the security considerations in
> > >> > favor of getting a stable system (of course taking into consideration
> > >> > the eventual security requirements). I.e., the first step is to build
> > >> > the infrastructure that allows a group of apps to be added and removed
> > >> > from the package manager, the second step is to actually get that onto
> > >> > a single SDCARD and trigger it by sdcard mount/unmount, the third step
> > >> > is to deal with UID
I agree that we need to start simple.
However, I am concerned that design decisions early on may negatively
impact the possibility of future enhancements.
I also understand the issue with restricting shared UIDs... so I'll
propose a scenerio:
Application A is installed internally, B is installed externally,
shared UID. Card is removed, application A is uninstalled and then
reinstalled (so it has a new UID). Card is put back in. Now the UIDs
no longer match unless it stores card info internally. Given the
condition proposed by Mr. Tate, we *must* allow swappable sdcards,
which suggests an eventual requirement to be able to track multiple
sdcards containing apps (I think this would lead to user problems
otherwise). And also, given an ultimate goal of being able to share
sdcards between multiple devices (even if it isn't implemented
initially), then shared UIDs become a real nightmare.
So I'm going to suggest that at least this requirement is fairly
simple to deal with.. during the install process, check for shared
UIDs, if shared UIDs are to be used, only allow installation to the
same location as the existing app in the pair. In the event that an
sdcard is inserted containing an app that wants to share UIDs with an
already-internal app, require that this app be installed internally,
i.e. prompt saying "for this app to function, it must be installed
internally. Do you wish to proceed?". Per one of my previous
suggestions, if the app exists in both places, only the internal one
is regarded as being "present".
On Oct 28, 1:01 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> 3 words: simplify, simplify, simplify. Assume it's a really hard
> problem (if it wasn't, we'd have solved it a long time ago).
> -aim to make the SD card work in a single device. Heck, even if the
> system can only track a single SD card at a time it's probably still
> fine. Personally, I'd hate to put restrictions on shared UIDs but I
> guess that's just a pet peeve of mine.
> -filesystem: let's assume some permission-enforcing filesystem in an
> encrypted disk image stored in a single file (skip the encryption for
> initial development). Start with ext2 or ext3. Once the rest of the
> system works, we can refine this part as necessary. Partitioning the
> SD card isn't an option. Keep UMS in mind, it's probably more tricky
> than it seems.
> JBQ
> On Wed, Oct 28, 2009 at 9:46 AM, lbcoder <lbco...@gmail.com> wrote:
> > 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.
> >> On Wed, Oct 28, 2009 at 10:17 AM, lbcoder <lbco...@gmail.com> wrote:
> >> > I thought that I just said that...
> >> > "in the earlier stages perhaps relaxing some of the security
> >> > considerations in
> >> > favor of getting a stable system".
> >> > The main thing to be wary of is that the infrastructure we develop not
> >> > preclude the possibility of security, since this would block it from
> >> > ever being merged. That means that we need to discuss and assess the
> >> > security issues, just not necessarily IMPLEMENT them [all].
> >> > On Oct 28, 10:08 am, Disconnect <dc.disconn...@gmail.com> wrote:
> >> >> You're forgetting something easy though, on the security side. It is
> >> >> required to offer the same protection as onboard storage. So all the
> >> >> encryption/security mess can go away (for now) because aosp ships with
> >> >> root. And since the word from the beginning was "its not our fault
> >> >> devices are all locked down" a "complete" solution for android
> >> >> doesn't have to include encryption or data-signing. (Yes, that leaves
> >> >> out retail devices, but it also puts some of the more finicky work out
> >> >> later and possibly gets vendors to contribute it.)
On Wed, Oct 28, 2009 at 1:01 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> 3 words: simplify, simplify, simplify. Assume it's a really hard > problem (if it wasn't, we'd have solved it a long time ago).
> -aim to make the SD card work in a single device. Heck, even if the > system can only track a single SD card at a time it's probably still > fine. Personally, I'd hate to put restrictions on shared UIDs but I > guess that's just a pet peeve of mine.
> -filesystem: let's assume some permission-enforcing filesystem in an > encrypted disk image stored in a single file (skip the encryption for > initial development). Start with ext2 or ext3. Once the rest of the > system works, we can refine this part as necessary. Partitioning the > SD card isn't an option. Keep UMS in mind, it's probably more tricky > than it seems.
The issue of hot-swapping SD card is orthogonal to that of shared UIDs
- you could turn off the phone, swap the SD and turn it back on, and
the same issue would still exist.
There are so many issues with the notion of sharing cards between
devices that I think it should be a non-goal at this point. Really.
It's great to think about it as we go, but I'd have no qualms making
simplifying decisions right now even if those prevent an immediate
extension to card-sharing.
On Wed, Oct 28, 2009 at 10:48 AM, lbcoder <lbco...@gmail.com> wrote:
> I agree that we need to start simple.
> However, I am concerned that design decisions early on may negatively
> impact the possibility of future enhancements.
> I also understand the issue with restricting shared UIDs... so I'll
> propose a scenerio:
> Application A is installed internally, B is installed externally,
> shared UID. Card is removed, application A is uninstalled and then
> reinstalled (so it has a new UID). Card is put back in. Now the UIDs
> no longer match unless it stores card info internally. Given the
> condition proposed by Mr. Tate, we *must* allow swappable sdcards,
> which suggests an eventual requirement to be able to track multiple
> sdcards containing apps (I think this would lead to user problems
> otherwise). And also, given an ultimate goal of being able to share
> sdcards between multiple devices (even if it isn't implemented
> initially), then shared UIDs become a real nightmare.
> So I'm going to suggest that at least this requirement is fairly
> simple to deal with.. during the install process, check for shared
> UIDs, if shared UIDs are to be used, only allow installation to the
> same location as the existing app in the pair. In the event that an
> sdcard is inserted containing an app that wants to share UIDs with an
> already-internal app, require that this app be installed internally,
> i.e. prompt saying "for this app to function, it must be installed
> internally. Do you wish to proceed?". Per one of my previous
> suggestions, if the app exists in both places, only the internal one
> is regarded as being "present".
> On Oct 28, 1:01 pm, Jean-Baptiste Queru <j...@android.com> wrote:
>> 3 words: simplify, simplify, simplify. Assume it's a really hard
>> problem (if it wasn't, we'd have solved it a long time ago).
>> -aim to make the SD card work in a single device. Heck, even if the
>> system can only track a single SD card at a time it's probably still
>> fine. Personally, I'd hate to put restrictions on shared UIDs but I
>> guess that's just a pet peeve of mine.
>> -filesystem: let's assume some permission-enforcing filesystem in an
>> encrypted disk image stored in a single file (skip the encryption for
>> initial development). Start with ext2 or ext3. Once the rest of the
>> system works, we can refine this part as necessary. Partitioning the
>> SD card isn't an option. Keep UMS in mind, it's probably more tricky
>> than it seems.
>> JBQ
>> On Wed, Oct 28, 2009 at 9:46 AM, lbcoder <lbco...@gmail.com> wrote:
>> > 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.
>> >> On Wed, Oct 28, 2009 at 10:17 AM, lbcoder <lbco...@gmail.com> wrote:
>> >> > I thought that I just said that...
>> >> > "in the earlier stages perhaps relaxing some of the security
>> >> > considerations in
>> >> > favor of getting a stable system".
>> >> > The main thing to be wary of is that the infrastructure we develop not
>> >> > preclude the possibility of security, since this would block it from
>> >> > ever being merged. That means that we need to discuss and assess the
>> >> > security issues, just not necessarily IMPLEMENT them [all].
As far as filesystem, can I suggest something like encfs?
(http://www.arg0.net/encfs) That specific tool uses some c++
libraries, but that should be fixable. It does per-file encryption, so
space is trivially recoverable, and it uses fuse and openssl (it
should be fairly independent of any underlying hardware changes, and
able to take advantage of any platform/device level ssl enhancements.)
On Wed, Oct 28, 2009 at 1:01 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> 3 words: simplify, simplify, simplify. Assume it's a really hard
> problem (if it wasn't, we'd have solved it a long time ago).
> -aim to make the SD card work in a single device. Heck, even if the
> system can only track a single SD card at a time it's probably still
> fine. Personally, I'd hate to put restrictions on shared UIDs but I
> guess that's just a pet peeve of mine.
> -filesystem: let's assume some permission-enforcing filesystem in an
> encrypted disk image stored in a single file (skip the encryption for
> initial development). Start with ext2 or ext3. Once the rest of the
> system works, we can refine this part as necessary. Partitioning the
> SD card isn't an option. Keep UMS in mind, it's probably more tricky
> than it seems.
> JBQ
> On Wed, Oct 28, 2009 at 9:46 AM, lbcoder <lbco...@gmail.com> wrote:
>> 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.
>>> On Wed, Oct 28, 2009 at 10:17 AM, lbcoder <lbco...@gmail.com> wrote:
>>> > I thought that I just said that...
>>> > "in the earlier stages perhaps relaxing some of the security
>>> > considerations in
>>> > favor of getting a stable system".
>>> > The main thing to be wary of is that the infrastructure we develop not
>>> > preclude the possibility of security, since this would block it from
>>> > ever being merged. That means that we need to discuss and assess the
>>> > security issues, just not necessarily IMPLEMENT them [all].
>>> > On Oct 28, 10:08 am, Disconnect <dc.disconn...@gmail.com> wrote:
>>> >> You're forgetting something easy though, on the security side. It is
>>> >> required to offer the same protection as onboard storage. So all the
>>> >> encryption/security mess can go away (for now) because aosp ships with
>>> >> root. And since the word from the beginning was "its not our fault
>>> >> devices are all locked down" a "complete" solution for android
>>> >> doesn't have to include encryption or data-signing. (Yes, that leaves
>>> >> out retail devices, but it also puts some of the more finicky work out
>>> >> later and possibly gets vendors to contribute it.)
>>> >> On Wed, Oct 28, 2009 at 9:58 AM, lbcoder <lbco...@gmail.com> wrote:
>>> >> > Actually, I think that this project would be a perfect fit with
>>> >> > another possibility that you mentioned... the community-AOSP branch.
>>> >> > It would allow US to develop the system over a period of time, in the
>>> >> > earlier stages perhaps relaxing some of the security considerations in
>>> >> > favor of getting a stable system (of course taking into consideration
>>> >> > the eventual security requirements). I.e., the first step is to build
>>> >> > the infrastructure that allows a group of apps to be added and removed
>>> >> > from the package manager, the second step is to actually get that onto
>>> >> > a single SDCARD and trigger it by sdcard mount/unmount, the third step
>>> >> > is to deal with UID issues and multiple-sdcards, etc., etc,. Once the
>>> >> > system has advanced to a state where it meets the core-AOSP security
>>> >> > and stability requirements (most likely with the assistance of google
>>> >> > engineers in the latter stages), then it can be merged in and everyone
>>> >> > will be happy.
>>> >> > Obviously, as I'm sure that everybody can agree, the current community-
>>> >> > type apps-on-sdcard system leaves a LOT to be desired,
That's out of my league, to be honest. I guess that it is sufficiently
tamper-proof (i.e. that it's possible to detect whether someone tried
to modify the data from outside this one device, including
adding/deleting files), that should work.
I think that it would make sense to write a first implementation of
the filesystem stuff in order to unblock work on the higher layers,
and then write "real" filesystem-level code.
On Wed, Oct 28, 2009 at 10:55 AM, Disconnect <dc.disconn...@gmail.com> wrote:
> As far as filesystem, can I suggest something like encfs?
> (http://www.arg0.net/encfs) That specific tool uses some c++
> libraries, but that should be fixable. It does per-file encryption, so
> space is trivially recoverable, and it uses fuse and openssl (it
> should be fairly independent of any underlying hardware changes, and
> able to take advantage of any platform/device level ssl enhancements.)
> On Wed, Oct 28, 2009 at 1:01 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>> 3 words: simplify, simplify, simplify. Assume it's a really hard
>> problem (if it wasn't, we'd have solved it a long time ago).
>> -aim to make the SD card work in a single device. Heck, even if the
>> system can only track a single SD card at a time it's probably still
>> fine. Personally, I'd hate to put restrictions on shared UIDs but I
>> guess that's just a pet peeve of mine.
>> -filesystem: let's assume some permission-enforcing filesystem in an
>> encrypted disk image stored in a single file (skip the encryption for
>> initial development). Start with ext2 or ext3. Once the rest of the
>> system works, we can refine this part as necessary. Partitioning the
>> SD card isn't an option. Keep UMS in mind, it's probably more tricky
>> than it seems.
>> JBQ
>> On Wed, Oct 28, 2009 at 9:46 AM, lbcoder <lbco...@gmail.com> wrote:
>>> 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.
>>>> On Wed, Oct 28, 2009 at 10:17 AM, lbcoder <lbco...@gmail.com> wrote:
>>>> > I thought that I just said that...
>>>> > "in the earlier stages perhaps relaxing some of the security
>>>> > considerations in
>>>> > favor of getting a stable system".
>>>> > The main thing to be wary of is that the infrastructure we develop not
>>>> > preclude the possibility of security, since this would block it from
>>>> > ever being merged. That means that we need to discuss and assess the
>>>> > security issues, just not necessarily IMPLEMENT them [all].
>>>> > On Oct 28, 10:08 am, Disconnect <dc.disconn...@gmail.com> wrote:
>>>> >> You're forgetting something easy though, on the security side. It is
>>>> >> required to offer the same protection as onboard storage. So all the
>>>> >> encryption/security mess can go away (for now) because aosp ships with
>>>> >> root. And since the word from the beginning was "its not our fault
>>>> >> devices are all locked down" a "complete" solution for android
>>>> >> doesn't have to include encryption or data-signing. (Yes, that leaves
>>>> >> out retail devices, but it also puts some of the more finicky work out
>>>> >> later and possibly gets vendors to contribute it.)
>>>> >> On Wed, Oct 28, 2009 at 9:58 AM, lbcoder <lbco...@gmail.com> wrote:
>>>> >> > Actually, I think that this project would be a perfect fit with
>>>> >> > another possibility that you mentioned... the community-AOSP branch.
>>>> >> > It would allow US to develop the system over a period of time, in the
>>>> >> > earlier stages perhaps relaxing some of the security considerations in
>>>> >> > favor of getting a stable system (of course taking into consideration
>>>> >> > the eventual security requirements). I.e., the first step is to build
>>>> >> > the infrastructure that allows a group of
Regarding the filesystem... ok, loopback ext3 located at /
sdcard/.extapps limit to 4GiB (for now, we can deal with that limit
later). I like ext3 over ext2 because it (typically) doesn't need an
fsck upon harsh unmount. UMS is no issue here since whatever system
mounts the fat32 filesystem will regard the .extapps as any regular
file. Is there any way we can set the file as "hidden" to MS from
within linux?
So to start;
mkdir /data/extapps
dd if=/dev/zero of=/sdcard/.extapps count=200000
mkfs.ext3 /sdcard/.extapps
mount -o loop -t ext3 /sdcard/.extapps /data/extapps
Step 1... enhance the sdcard mount to first mount /sdcard and then try
to mount /sdcard/.hidden to /data/extapps (or is there another
location that would be preferred?), and then unmount function to first
unmount /sdcard/.hidden and then unmount /sdcard.
Step 2... add to the unmount (before unmounting anything) a check for
open file handles and a request to kill the processes or cancel the
unmount.
Question: What is the preferred way to kill off applications? If the
user answers yes, can we just go and *kill* the processes? or is there
a sane shutdown mechanism? Whatever the answer, we need to go and do
it if the user says to.
Question 2: Where is the current mechanism for handling sdcard removal-
without-unmount?
Step 3: (where it gets fun) fix up package manager to be able to add
and remove apps.
Question: Where is the application home directory location and dalvik
cache location established? (I know where they are presently, I need
to know how *it* knows where they are.)
** after this it should *work* (sortof) -- won't be possible to
install apps onto sdcard and won't be sane shutdown of apps if the
card is forcibly removed without unmounting.
Step 4: update installer to prompt for install location.
** here it will be able to install and run apps from sdcard, but
nothing is done to handle UIDs.
Points of failure after completion of step4:
1) things crash bad when sdcard is pulled without unmount,
2) installation of packages when sdcard is OUT will break things in a
BAD WAY,
3) shared UIDs should still work regardless of where things are
located, but may give unexpected results if member of pair is missing
(card out),
4) applications that refer to their home directory by absolute path
will be broken. I don't know what (if anything) we can do about this
except advise app developers to use '~' to refer to home directories.
Is there any way we can internally rewrite paths that look like "/data/
data/my.package.name/" into "~/"? Or maybe runtime-symlink?,
5) no tracking for sdcard, so if the user swaps in another sdcard with
apps, things will crash.
*note: at this point it is already way better than community-hack.
Step 5+: more installer and package manager updates, handling UIDs,
etc. deal with it when we get there.
> -filesystem: let's assume some permission-enforcing filesystem in an
> encrypted disk image stored in a single file (skip the encryption for
> initial development). Start with ext2 or ext3. Once the rest of the
> system works, we can refine this part as necessary. Partitioning the
> SD card isn't an option. Keep UMS in mind, it's probably more tricky
> than it seems.
Where do you put dalvik cache in this plan? I'm thinking it needs to
be associated with the apk for size, but for speed it shouldn't be
encrypted. (At least for now.) And there should be some way of
detecting tampering, or just regenerate all the caches on insert (SLOW
but unlike boot-time, at least we can provide feedback.)
On Wed, Oct 28, 2009 at 2:32 PM, lbcoder <lbco...@gmail.com> wrote:
> Regarding the filesystem... ok, loopback ext3 located at /
> sdcard/.extapps limit to 4GiB (for now, we can deal with that limit
> later). I like ext3 over ext2 because it (typically) doesn't need an
> fsck upon harsh unmount. UMS is no issue here since whatever system
> mounts the fat32 filesystem will regard the .extapps as any regular
> file. Is there any way we can set the file as "hidden" to MS from
> within linux?
> So to start;
> mkdir /data/extapps
> dd if=/dev/zero of=/sdcard/.extapps count=200000
> mkfs.ext3 /sdcard/.extapps
> mount -o loop -t ext3 /sdcard/.extapps /data/extapps
> Step 1... enhance the sdcard mount to first mount /sdcard and then try
> to mount /sdcard/.hidden to /data/extapps (or is there another
> location that would be preferred?), and then unmount function to first
> unmount /sdcard/.hidden and then unmount /sdcard.
> Step 2... add to the unmount (before unmounting anything) a check for
> open file handles and a request to kill the processes or cancel the
> unmount.
> Question: What is the preferred way to kill off applications? If the
> user answers yes, can we just go and *kill* the processes? or is there
> a sane shutdown mechanism? Whatever the answer, we need to go and do
> it if the user says to.
> Question 2: Where is the current mechanism for handling sdcard removal-
> without-unmount?
> Step 3: (where it gets fun) fix up package manager to be able to add
> and remove apps.
> Question: Where is the application home directory location and dalvik
> cache location established? (I know where they are presently, I need
> to know how *it* knows where they are.)
> ** after this it should *work* (sortof) -- won't be possible to
> install apps onto sdcard and won't be sane shutdown of apps if the
> card is forcibly removed without unmounting.
> Step 4: update installer to prompt for install location.
> ** here it will be able to install and run apps from sdcard, but
> nothing is done to handle UIDs.
> Points of failure after completion of step4:
> 1) things crash bad when sdcard is pulled without unmount,
> 2) installation of packages when sdcard is OUT will break things in a
> BAD WAY,
> 3) shared UIDs should still work regardless of where things are
> located, but may give unexpected results if member of pair is missing
> (card out),
> 4) applications that refer to their home directory by absolute path
> will be broken. I don't know what (if anything) we can do about this
> except advise app developers to use '~' to refer to home directories.
> Is there any way we can internally rewrite paths that look like "/data/
> data/my.package.name/" into "~/"? Or maybe runtime-symlink?,
> 5) no tracking for sdcard, so if the user swaps in another sdcard with
> apps, things will crash.
> *note: at this point it is already way better than community-hack.
> Step 5+: more installer and package manager updates, handling UIDs,
> etc. deal with it when we get there.
>> -filesystem: let's assume some permission-enforcing filesystem in an
>> encrypted disk image stored in a single file (skip the encryption for
>> initial development). Start with ext2 or ext3. Once the rest of the
>> system works, we can refine this part as necessary. Partitioning the
>> SD card isn't an option. Keep UMS in mind, it's probably more tricky
>> than it seems.
I like that document. I have only skimmed through it so far, and only
two question;
- does "mount -o loop -t ext3 /wherever/it/is/located/.extapps /mnt"
count as "standard tools" or "special tools"? it is perfectly standard
on a linux system, but I doubt that it is at all possible on MS.
- *IS* it really a requirement? A regular user doesn't have the
ability to read files off the internal /data partition unless they
have some specific technical know-how.
On Oct 28, 1:50 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> If I missed any features, or miscategorized any, etc please update the
> doc. Please don't destroy it. (Does google docs have wave-style undo?)
> On Wed, Oct 28, 2009 at 1:01 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > 3 words: simplify, simplify, simplify. Assume it's a really hard
> > problem (if it wasn't, we'd have solved it a long time ago).
> > -aim to make the SD card work in a single device. Heck, even if the
> > system can only track a single SD card at a time it's probably still
> > fine. Personally, I'd hate to put restrictions on shared UIDs but I
> > guess that's just a pet peeve of mine.
> > -filesystem: let's assume some permission-enforcing filesystem in an
> > encrypted disk image stored in a single file (skip the encryption for
> > initial development). Start with ext2 or ext3. Once the rest of the
> > system works, we can refine this part as necessary. Partitioning the
> > SD card isn't an option. Keep UMS in mind, it's probably more tricky
> > than it seems.
I think - esp for now - it would be considered a pass if "delete
.extapps" was possible. (EG no partitioning or other weirdness)
As an additional thought it might make sense to do each app as it's
own bundle. That way a user can say "Oh! That 2 gig mess is
JoesGiantTileGenerator". Means added complexity on the mounts though.
(Hmm. Adds to security though - even with shared-uid, if a user
refuses the perms on an app it is not mounted..)
On Wed, Oct 28, 2009 at 2:40 PM, lbcoder <lbco...@gmail.com> wrote:
> I like that document. I have only skimmed through it so far, and only
> two question;
> - does "mount -o loop -t ext3 /wherever/it/is/located/.extapps /mnt"
> count as "standard tools" or "special tools"? it is perfectly standard
> on a linux system, but I doubt that it is at all possible on MS.
> - *IS* it really a requirement? A regular user doesn't have the
> ability to read files off the internal /data partition unless they
> have some specific technical know-how.
>> If I missed any features, or miscategorized any, etc please update the
>> doc. Please don't destroy it. (Does google docs have wave-style undo?)
>> On Wed, Oct 28, 2009 at 1:01 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>> > 3 words: simplify, simplify, simplify. Assume it's a really hard
>> > problem (if it wasn't, we'd have solved it a long time ago).
>> > -aim to make the SD card work in a single device. Heck, even if the
>> > system can only track a single SD card at a time it's probably still
>> > fine. Personally, I'd hate to put restrictions on shared UIDs but I
>> > guess that's just a pet peeve of mine.
>> > -filesystem: let's assume some permission-enforcing filesystem in an
>> > encrypted disk image stored in a single file (skip the encryption for
>> > initial development). Start with ext2 or ext3. Once the rest of the
>> > system works, we can refine this part as necessary. Partitioning the
>> > SD card isn't an option. Keep UMS in mind, it's probably more tricky
>> > than it seems.
The APK itself, the application's home directory, and the
application's dalvik-cache must all be within the same device. I was
just about to write 'within the same filesystem', but this isn't
necessarily a requirement, i.e., if you use filesystem-level
encryption vs file-level encryption.
And for the initial development, we aren't going to make any (major)
consideration for encryption, except to note that it eventually must
be done (just so we don't write ourselves into a corner).
On Oct 28, 2:36 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> Where do you put dalvik cache in this plan? I'm thinking it needs to
> be associated with the apk for size, but for speed it shouldn't be
> encrypted. (At least for now.) And there should be some way of
> detecting tampering, or just regenerate all the caches on insert (SLOW
> but unlike boot-time, at least we can provide feedback.)
> On Wed, Oct 28, 2009 at 2:32 PM, lbcoder <lbco...@gmail.com> wrote:
> > Regarding the filesystem... ok, loopback ext3 located at /
> > sdcard/.extapps limit to 4GiB (for now, we can deal with that limit
> > later). I like ext3 over ext2 because it (typically) doesn't need an
> > fsck upon harsh unmount. UMS is no issue here since whatever system
> > mounts the fat32 filesystem will regard the .extapps as any regular
> > file. Is there any way we can set the file as "hidden" to MS from
> > within linux?
> > So to start;
> > mkdir /data/extapps
> > dd if=/dev/zero of=/sdcard/.extapps count=200000
> > mkfs.ext3 /sdcard/.extapps
> > mount -o loop -t ext3 /sdcard/.extapps /data/extapps
> > Step 1... enhance the sdcard mount to first mount /sdcard and then try
> > to mount /sdcard/.hidden to /data/extapps (or is there another
> > location that would be preferred?), and then unmount function to first
> > unmount /sdcard/.hidden and then unmount /sdcard.
> > Step 2... add to the unmount (before unmounting anything) a check for
> > open file handles and a request to kill the processes or cancel the
> > unmount.
> > Question: What is the preferred way to kill off applications? If the
> > user answers yes, can we just go and *kill* the processes? or is there
> > a sane shutdown mechanism? Whatever the answer, we need to go and do
> > it if the user says to.
> > Question 2: Where is the current mechanism for handling sdcard removal-
> > without-unmount?
> > Step 3: (where it gets fun) fix up package manager to be able to add
> > and remove apps.
> > Question: Where is the application home directory location and dalvik
> > cache location established? (I know where they are presently, I need
> > to know how *it* knows where they are.)
> > ** after this it should *work* (sortof) -- won't be possible to
> > install apps onto sdcard and won't be sane shutdown of apps if the
> > card is forcibly removed without unmounting.
> > Step 4: update installer to prompt for install location.
> > ** here it will be able to install and run apps from sdcard, but
> > nothing is done to handle UIDs.
> > Points of failure after completion of step4:
> > 1) things crash bad when sdcard is pulled without unmount,
> > 2) installation of packages when sdcard is OUT will break things in a
> > BAD WAY,
> > 3) shared UIDs should still work regardless of where things are
> > located, but may give unexpected results if member of pair is missing
> > (card out),
> > 4) applications that refer to their home directory by absolute path
> > will be broken. I don't know what (if anything) we can do about this
> > except advise app developers to use '~' to refer to home directories.
> > Is there any way we can internally rewrite paths that look like "/data/
> > data/my.package.name/" into "~/"? Or maybe runtime-symlink?,
> > 5) no tracking for sdcard, so if the user swaps in another sdcard with
> > apps, things will crash.
> > *note: at this point it is already way better than community-hack.
> > Step 5+: more installer and package manager updates, handling UIDs,
> > etc. deal with it when we get there.
> >> -filesystem: let's assume some permission-enforcing filesystem in an
> >> encrypted disk image stored in a single file (skip the encryption for
> >> initial development). Start with ext2 or ext3. Once the rest of the
> >> system works, we can refine this part as necessary. Partitioning the
> >> SD card isn't an option. Keep UMS in mind, it's probably more tricky
> >> than it seems.
The data -should- eventually support encryption, and the cache
-should- support tamper detection or encryption (to match the apk
security) but right now we're assuming aosp with root. Doh.
I updated the doc as well, since data-protection is a soft requirement
(and I fleshed that out a bit, so if someone - eg jbq - could
doublecheck that it is correct from google's side that'd be nice.)
On Wed, Oct 28, 2009 at 2:46 PM, lbcoder <lbco...@gmail.com> wrote:
> The APK itself, the application's home directory, and the
> application's dalvik-cache must all be within the same device. I was
> just about to write 'within the same filesystem', but this isn't
> necessarily a requirement, i.e., if you use filesystem-level
> encryption vs file-level encryption.
> And for the initial development, we aren't going to make any (major)
> consideration for encryption, except to note that it eventually must
> be done (just so we don't write ourselves into a corner).
> On Oct 28, 2:36 pm, Disconnect <dc.disconn...@gmail.com> wrote:
>> Where do you put dalvik cache in this plan? I'm thinking it needs to
>> be associated with the apk for size, but for speed it shouldn't be
>> encrypted. (At least for now.) And there should be some way of
>> detecting tampering, or just regenerate all the caches on insert (SLOW
>> but unlike boot-time, at least we can provide feedback.)
>> On Wed, Oct 28, 2009 at 2:32 PM, lbcoder <lbco...@gmail.com> wrote:
>> > Regarding the filesystem... ok, loopback ext3 located at /
>> > sdcard/.extapps limit to 4GiB (for now, we can deal with that limit
>> > later). I like ext3 over ext2 because it (typically) doesn't need an
>> > fsck upon harsh unmount. UMS is no issue here since whatever system
>> > mounts the fat32 filesystem will regard the .extapps as any regular
>> > file. Is there any way we can set the file as "hidden" to MS from
>> > within linux?
>> > So to start;
>> > mkdir /data/extapps
>> > dd if=/dev/zero of=/sdcard/.extapps count=200000
>> > mkfs.ext3 /sdcard/.extapps
>> > mount -o loop -t ext3 /sdcard/.extapps /data/extapps
>> > Step 1... enhance the sdcard mount to first mount /sdcard and then try
>> > to mount /sdcard/.hidden to /data/extapps (or is there another
>> > location that would be preferred?), and then unmount function to first
>> > unmount /sdcard/.hidden and then unmount /sdcard.
>> > Step 2... add to the unmount (before unmounting anything) a check for
>> > open file handles and a request to kill the processes or cancel the
>> > unmount.
>> > Question: What is the preferred way to kill off applications? If the
>> > user answers yes, can we just go and *kill* the processes? or is there
>> > a sane shutdown mechanism? Whatever the answer, we need to go and do
>> > it if the user says to.
>> > Question 2: Where is the current mechanism for handling sdcard removal-
>> > without-unmount?
>> > Step 3: (where it gets fun) fix up package manager to be able to add
>> > and remove apps.
>> > Question: Where is the application home directory location and dalvik
>> > cache location established? (I know where they are presently, I need
>> > to know how *it* knows where they are.)
>> > ** after this it should *work* (sortof) -- won't be possible to
>> > install apps onto sdcard and won't be sane shutdown of apps if the
>> > card is forcibly removed without unmounting.
>> > Step 4: update installer to prompt for install location.
>> > ** here it will be able to install and run apps from sdcard, but
>> > nothing is done to handle UIDs.
>> > Points of failure after completion of step4:
>> > 1) things crash bad when sdcard is pulled without unmount,
>> > 2) installation of packages when sdcard is OUT will break things in a
>> > BAD WAY,
>> > 3) shared UIDs should still work regardless of where things are
>> > located, but may give unexpected results if member of pair is missing
>> > (card out),
>> > 4) applications that refer to their home directory by absolute path
>> > will be broken. I don't know what (if anything) we can do about this
>> > except advise app developers to use '~' to refer to home directories.
>> > Is there any way we can internally rewrite paths that look like "/data/
>> > data/my.package.name/" into "~/"? Or maybe runtime-symlink?,
>> > 5) no tracking for sdcard, so if the user swaps in another sdcard with
>> > apps, things will crash.
>> > *note: at this point it is already way better than community-hack.
>> > Step 5+: more installer and package manager updates, handling UIDs,
>> > etc. deal with it when we get there.
>> >> -filesystem: let's assume some permission-enforcing filesystem in an
>> >> encrypted disk image stored in a single file (skip the encryption for
>> >> initial development). Start with ext2 or ext3. Once the rest of the
>> >> system works, we can refine this part as necessary. Partitioning the
>> >> SD card isn't an option. Keep UMS in mind, it's probably more tricky
>> >> than it seems.
An application can't have a negative impact on security except in two
conditions; 1) it is added by the package manager, or 2) it is a
protected app that can easily be copied. Basically, if everything was
within a single external filesystem, it doesn't matter if some of it
is untrusted as long as you don't allow it to run or be accessed by
other regular users, and it can't run unless it is given the
permission to be added to the package manager.
And it is most definitely possible to delete .extapps (i.e. right-
click, delete). And I don't think there is any reason to secure
against it since it must, by definition, be an intentional and user-
initiated event.
On Oct 28, 2:45 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> I think - esp for now - it would be considered a pass if "delete
> .extapps" was possible. (EG no partitioning or other weirdness)
> As an additional thought it might make sense to do each app as it's
> own bundle. That way a user can say "Oh! That 2 gig mess is
> JoesGiantTileGenerator". Means added complexity on the mounts though.
> (Hmm. Adds to security though - even with shared-uid, if a user
> refuses the perms on an app it is not mounted..)
> On Wed, Oct 28, 2009 at 2:40 PM, lbcoder <lbco...@gmail.com> wrote:
> > I like that document. I have only skimmed through it so far, and only
> > two question;
> > - does "mount -o loop -t ext3 /wherever/it/is/located/.extapps /mnt"
> > count as "standard tools" or "special tools"? it is perfectly standard
> > on a linux system, but I doubt that it is at all possible on MS.
> > - *IS* it really a requirement? A regular user doesn't have the
> > ability to read files off the internal /data partition unless they
> > have some specific technical know-how.
> >> If I missed any features, or miscategorized any, etc please update the
> >> doc. Please don't destroy it. (Does google docs have wave-style undo?)
> >> On Wed, Oct 28, 2009 at 1:01 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> > 3 words: simplify, simplify, simplify. Assume it's a really hard
> >> > problem (if it wasn't, we'd have solved it a long time ago).
> >> > -aim to make the SD card work in a single device. Heck, even if the
> >> > system can only track a single SD card at a time it's probably still
> >> > fine. Personally, I'd hate to put restrictions on shared UIDs but I
> >> > guess that's just a pet peeve of mine.
> >> > -filesystem: let's assume some permission-enforcing filesystem in an
> >> > encrypted disk image stored in a single file (skip the encryption for
> >> > initial development). Start with ext2 or ext3. Once the rest of the
> >> > system works, we can refine this part as necessary. Partitioning the
> >> > SD card isn't an option. Keep UMS in mind, it's probably more tricky
> >> > than it seems.
It could be considered a security impact if an app is refused by the
user (eg tampering or unwanted) and the associated data is accessible
to a different shared uid app. (EG "No, I don't want to run
JohnsKeyLoggerKeyboard" but oops, the logging it did last time is
already available to "JimsInnocentLookingWebSender". If the user
refuses permission, it should behave as if it was not installed - no
app or data access.)
On Wed, Oct 28, 2009 at 2:55 PM, lbcoder <lbco...@gmail.com> wrote:
> An application can't have a negative impact on security except in two
> conditions; 1) it is added by the package manager, or 2) it is a
> protected app that can easily be copied. Basically, if everything was
> within a single external filesystem, it doesn't matter if some of it
> is untrusted as long as you don't allow it to run or be accessed by
> other regular users, and it can't run unless it is given the
> permission to be added to the package manager.
> And it is most definitely possible to delete .extapps (i.e. right-
> click, delete). And I don't think there is any reason to secure
> against it since it must, by definition, be an intentional and user-
> initiated event.
> On Oct 28, 2:45 pm, Disconnect <dc.disconn...@gmail.com> wrote:
>> I think - esp for now - it would be considered a pass if "delete
>> .extapps" was possible. (EG no partitioning or other weirdness)
>> As an additional thought it might make sense to do each app as it's
>> own bundle. That way a user can say "Oh! That 2 gig mess is
>> JoesGiantTileGenerator". Means added complexity on the mounts though.
>> (Hmm. Adds to security though - even with shared-uid, if a user
>> refuses the perms on an app it is not mounted..)
>> On Wed, Oct 28, 2009 at 2:40 PM, lbcoder <lbco...@gmail.com> wrote:
>> > I like that document. I have only skimmed through it so far, and only
>> > two question;
>> > - does "mount -o loop -t ext3 /wherever/it/is/located/.extapps /mnt"
>> > count as "standard tools" or "special tools"? it is perfectly standard
>> > on a linux system, but I doubt that it is at all possible on MS.
>> > - *IS* it really a requirement? A regular user doesn't have the
>> > ability to read files off the internal /data partition unless they
>> > have some specific technical know-how.
>> >> If I missed any features, or miscategorized any, etc please update the
>> >> doc. Please don't destroy it. (Does google docs have wave-style undo?)
>> >> On Wed, Oct 28, 2009 at 1:01 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>> >> > 3 words: simplify, simplify, simplify. Assume it's a really hard
>> >> > problem (if it wasn't, we'd have solved it a long time ago).
>> >> > -aim to make the SD card work in a single device. Heck, even if the
>> >> > system can only track a single SD card at a time it's probably still
>> >> > fine. Personally, I'd hate to put restrictions on shared UIDs but I
>> >> > guess that's just a pet peeve of mine.
>> >> > -filesystem: let's assume some permission-enforcing filesystem in an
>> >> > encrypted disk image stored in a single file (skip the encryption for
>> >> > initial development). Start with ext2 or ext3. Once the rest of the
>> >> > system works, we can refine this part as necessary. Partitioning the
>> >> > SD card isn't an option. Keep UMS in mind, it's probably more tricky
>> >> > than it seems.
