> On 11 Jun 2015, at 10:39 pm, Benjamin Francis <[email protected]> wrote: > > On 11 June 2015 at 06:17, Paul Theriault <[email protected] > <mailto:[email protected]>> wrote: > We discussed this in another thread, but Jonas convinced me that pinning will > not have any security side-effects, and I’ve updated the permission model to > reflect this [1]. > > To clarify, have you decided that granting extra storage, the ability to run > in the background and the ability to appear in the web activity picker will > have nothing to do with whether or not the site is pinned, so Gecko doesn't > need to know?
Thats correct. Though you are mixing things up a little here by throwing in Activities. That’s not a permission, that’s just something that is registered at install time. (In the same way that system message listeners are declared). Without an install step, we will need a new way for apps to register anything that was previously registered in the manifest that we want to continue to support. > Does that mean that the user will always be prompted for these permissions > instead? Yes, for now. But it doesn’t have to be, I would like to see improved UX so we don’t need to prompt up front for things that don’t really need user permission. For example, currently the only two manifest-declared web permissions are Alarms[1] & Storage. Neither of these would be terribly bad to grant to a website, so long as the user had a way to a) see that the permission was being used and b) had a way to respond if the website abuses the permission. I imagining something like a notification, when these APIs are used. In the case of alarms, we might have a persistent Alarm notification set, so the user is aware that there are pending alarms (and can remove them if they don’t want to be woken up!). I also imagine something an “about:permissions <about:permissions>” style UX that allows the user to block annoying sites, and set defaults (a user might want to decide that alarms should be denied by default, and only allowed by exception). [1] I remember elsewhere Jonas suggested to merge Alarms into something like a “run in the background” permission. Imho we should keep alarms separate since its easy to explain and something the user can be expected to manage. This implications of “run in the background” aren’t very clear to me, especially when our app model already does’t suspend apps that are not foreground. > > I assume “installation” will remain for add-ons and will remain as gate to > implicit permissions. > > That's my understanding too, that add-ons will be "installed". > > Ben >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
