As we are getting closer to finalising the v3 permission mode, I wanted to 
share my current thoughts on a revised permission model for Firefox OS.

My main goals in this effort are mainly:

* simplify the permission model for users and developers
* move the FxOS permission model more in line with desktop & mobile (i.e. for 
regular web content)
* Provide a permission model that supports the new security model [1]

I wanted to outline my current thinking below, and gather feedback. The key 
change I’m proposing is to more clearly distinguish between permissions 
available to web content and those which are limited to privileged/signed 
content (or whatever we call it in the new model). For the web ones, lets 
remove the differences between FxOS & Firefox Deskop/Mobile. For the privileged 
permissions, they will largely be the same as currently though we do need to 
figure out how to safely implement “linkable” privileged apps.

== Web Content/Webapps - “Web Permissions” ==
* We should harmonise the permission granting behaviour on Firefox OS with 
desktop and mobile.
* Example permissions:  microphone, geolocation, camera, alarms, push, storage, 
notifications (i.e. all the things you can already request from web pages)
* Remove requirement for apps to declare these permissions, we don’t use it for 
anything meaningful and it means less in a linkable app world
* Most permissions granted by prompt, except for those granted implicitly by 
install/pinning (e.g. alarms, storage)
* Make the prompting UX closer to desktop & mobile (no more modal prompts that 
force users into bad decisions)
* Implement an “about:permissions <about:permissions>” equivalent for managing 
permissions that works for websites, not just apps:
 ** we need a permission management interface that doesn’t depend on app 
permission declarations
 ** we need to support managing permissions for websites as well as apps

== Signed & Pre-installed content - “Privileged Permissions” == 
* permissions will still be declared, and the content reviewed by marketplace & 
signed
* there’s no install step though, so the apps just load except no longer just 
granting implicit permissions
* restrict the apps entry points by default (i.e. you can only link to 
predeclared entry points) - perhaps something like the W3C Entry Points 
Restriction spec [2]
* for explicit permissions (prompted ones), they are granted as normal, however 
I think we need to to improve the prompting UX to differentiate these more 
powerful APIs from regular web permissions. I’m imagine a specific visual 
metaphors for “data” permissions (contacts, photos, videos, music), and maybe 
something more like a “per-app” toggle for device permissions like fmradio,nfc 
& bluetooth. (i.e. you “turn on” bluetooth on a per-app basis, in addition to a 
system-wide). I’m interested to see what people can come up with here.
* for implicit permissions (hidden permissions, previously granted upon 
install): we can’t just grant these upon load (its too dangerous, at least for 
most apps), so we will need some other mechanism. I imagine this will be a 
combination of approaches:
 ** follow a similar mechanism to what we do for alarms & notifications (that 
is, grant permissions only after pinning the app)
 ** having an extended verification review program for apps which request 
certain more-sensitive permissions (especially those which were previously 
certified permissions)
* we will also need strong blocking/revocation mechanism to revoke apps signed 
by marketplace that are subsequently found to be vulnerable/malicious

I’m writing up a more detailed proposal at the moment, but I wanted to 
circulate a summary first just to garner initial feedback.

Thanks,
Paul


[1] https://wiki.mozilla.org/FirefoxOS/New_security_model 
<https://wiki.mozilla.org/FirefoxOS/New_security_model>
[2] https://w3c.github.io/webappsec/specs/epr/ 
<https://w3c.github.io/webappsec/specs/epr/> 

_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to