In general, I'd buy that permission prompts are deferred until an app comes into focus. Once the permission has been granted or denied, that is going to be sticky, so the app can keep using it in the background. I'm not sure we want to deny access to an API for which permission has been granted when an app is not the focus. Certainly not for every API. I'll have to review the API list to see if there are any that might need that treatment. If there are, we should add it to the API review template.
As for services, these might be things like an alternate keyboard that want access to APIs. There is no specific app for the alternate keyboards (I think the idea at the moment is that these services would have special tagging in the manifest, or register themselves when first installed). The services is invoked by an intent. At that point (at least for input) it does have a displayed component. As an example, a keyboard service may want access to an API (ok, these are a little bit of a stretch, but a keyboard service may want USB to interface to a hardware input device. Or someone got really clever and figured out how to watch your hands with the camera and provide a virtual keyboard). We could show a prompt at that point, but how does the user know it is the keyboard that wants the permission instead of the app that is open? And the notification system may get confusing as well. Or we just punt it until we have a real use case and just use the must have app focus to have prompts appear (keyboard services never get app focus, so if they tried to use an API it would always be deferred). -Jim Straus On May 4, 2012, at 2:36 PM, Lucas Adamski wrote: > On May 2, 2012, at 8:34 AM, Jim Straus wrote: > >> Lucas - >> On Background Apps and just to be explicit. If we assume that Background >> apps always have a UI component that shows up in the home screen, then can >> we state that when a background component needs a permission that hasn't >> been granted that the UI component will be opened and the prompt occur >> there? If we allow Background only apps, I'm not sure where the permission >> prompt will occur. >> Actually, we may want to explicitly state that if an app that is not the >> currently viewed app and needs permissions that it the app needing the >> permission is made the currently viewed app. >> -Jim Straus > > That's an interesting question. Could another approach be that the app needs > to have focus to obtain the permissions, and that permission is blocked until > it becomes foreground? I think a lot of the permissions really need apps to > be focused before they can be granted anyway per our notification model. Its > a pretty complicated problem though, depending on if you think of these as > apps, or as services. > Lucas. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
