On Sun, Dec 4, 2011 at 5:47 PM, klewelling <[email protected]> wrote:
>
> > I don't completely follow your description, sorry. You're using too
> > many terms ("the app", "host APK", "UI APK", "dynamic apps") that you
> > know how they relate, but I don't. Perhaps I'm just being thick.
>
> Ya what I wrote was a bit stream-of-consciousness. Let me try again.
>
> Here is my suggestion for a more secure model. The stumbleUpon like
> service involves installing two apks, a UI apk and a Host apk. The UI
> apk has a lot of permissions including access to the internet and has
> a "Next App" button. A second host apk has a limited set of
> permissions, basically no direct access to the network, SMS, or
> personally identifying information. When the user want to "stumble"
> onto a new app they click the "Next App" button and the UI app
> downloads the trial app which is then transferred to the host app via
> a Service. The host app then loads the trial app. When/if the trial
> app needs a resource the host does not have (SMS, network, contacts,
> etc) it will ask the UI apk which does have the permissions (assume
> the trial app uses a different API to make its requests).
How? Have you thought about the fact that certain apps will have calls to
find out if they have a permission, and if they don't the app will not
behave the same?
How do you host the app via a service? Marshalling instrumentation calls
over IPC?
The UI app
> receives the requests and asks the user via a dialog if it is OK to
> allow the trial app access to the requested resource.
Okay, but how do you catch the app when it tries to access that resource?
What happens if the app tries to access the network, sets a timeout, and
the user doesn't press the "okay" button in time?
> For example the
> UI app may pop up a dialog and say "App xyz wants to send a text
> message. OK or Cancel".
So you also have to halt the main app's UI, how do you plan to do that?
> If the app does not request access from the UI
> app and instead tries to directly access a resource the android
> security model will kick it and throw an exception.
True.
> I know there are
> performance and usability issues with what I described, but from a
> security point of view what are your thoughts?
My thoughts are that there are a lot of implementation issues you're not
thinking about that will make this extremely complicated.
Kris
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
