Hello -
I definitely don't like the Android model. We'll have to figure out
exactly how to communicate permissions requests to users. On the other
hand, an appropriately vetted and signed app could be given permissions
implicitly in a permissions manifest, so the user doesn't need to deal
with it. Also, some kind of heuristics may make it possible for the
permissions manager to deal with things internally, again not bothering
the user. These are areas that need thought and experimentation.
We will definitely need some sort of identification for web apps and
sites. Origin was the first thought, but if you have further
suggestions, please post. Maybe for network loaded apps/sites,
permissions will need to be re-goten from the user each time they are
loaded (helps with, but doesn't completely cure hacked sites). Maybe
locally cached apps could keep their permissions until they are
re-installed.
-Jim Straus
On 3/5/12 1:25 PM, Lucas Adamski wrote:
I like this proposal at a high level, it provides for a lot of flexibility.
What I like about a permission model that can prompt at runtime is that is
makes some permissions optional. On Android many free apps require geolocation
purely for advertising targeting, requiring the user to trade their privacy for
functionality. Those same apps, on iPhone, run just fine if the user denies
them geolocation privileges. These decisions could be remembered for some
finite amount of time (30 days), or indefinitely if you provide the user with
the ability to manage them directly.
The downside of prompting at runtime is that it does need to map to permissions an
average user could hope to understand (hello user research?) Asking for location,
contacts, etc seems like a reasonable question to ask the user. Asking the user to
change the network proxy settings or fiddle with your email settings, maybe less so. The
latter might be better bundled into a general "scary system access" category.
The origin problem is still a tricky one. Browsers overall still rely on same origin as
the only meaningful security boundary (including work on iframe sandbox, CSP, etc.). I'm
still skeptical though that alone is sufficient to authenticate apps that would have
"system access". A web server is generally a much easier thing to compromise
than a code signature.
Adding dev-security for more brains.
Lucas.
On Mar 3, 2012, at 2:44 PM, Jim Straus wrote:
Redirecting to the public list and to the webapps team, with some additions...
Hello all -
I've been thinking about what the permissions model of b2g might look like,
so I'm putting down my ideas to solicit feedback and see if we can get this
going. A lot of the components and services we've been building are all
waiting on a permissions design.
Permissions in b2g are needed for access to services and data that is the user
might not want to allow an app to access. Examples include the users current
location (geolocation), contacts, making phone calls, maybe even cellular data
connections (if the user wants to control their costs), large storage areas,
etc. We'll have to decide the entire list as we go along.
I envision two user interfaces needed, the dialog/bar/whatever that asks the
user for permission, and a permissions manager app where the user can revoke
permissions, a priori grant a permission to all apps for a component (like
always allow cellular data connections if the user has unlimited data), and to
see what permissions exist and what apps have been granted permission. The
permission request user interface would allow for the user to grant/deny
permission once or permanently. If permission is not granted permanent, the
next time the service/component is invoked permission would be asked for again.
I also would like to make at least the permissions manager be able to be
changed to a non-built in app, if we feel we can maintain security.
The generally discussed model is that permissions are requested as a feature is
used, on a feature by feature basis (unlike Android's permission model).
However, there is nothing in particular about this design that would prevent us
from adding a permission manifest to the webapp manifest that could do it
wholesale when the app is loaded or launched, if that was desired. It is also
possible (but I'm not sure desirable) we could allow for apps to have
per-asserted permissions for appropriately signed and validated webapps.
My idea is that there is a permissions component that handles all the internal
work. The permissions component is also protected by a permission, so that
apps can't change the permissions without the user knowing. The permissions
component stores webapp signatures (originating url?, is this un-spoofable?)
along with the permissions permanently granted/denied in a protected indexedDB.
Components would query the permission component when the component starts for
a particular context and permission is returned about whether permission is
granted (by user interaction or previously stored permission). Apps could
possibly also explicitly ask the permission component about the state of their
granted/denied permissions so they could handle denials in a graceful manner
(this would not have to be protected).
The permissions component can (and will) become more intelligent as we figure
out the right things to do. We can try to infer permissions in some cases.
Apps signed as having come from a site known to validate it's apps and signed
as having come from a known developer can have per-autherized permissions in
their webapp manifest (an extension to the webapp manifest will be needed).
Webapp manifests could be used to request permission once when the app is
installed. Or some combination of any or all of these. Or something else. If
the components are all using the the permissions component, it doesn't matter
to the rest of the system how the permission is obtained, just that it is
either granted or not.
My thought is that the permission manager app would be internally restricted to
only being able to get the permission granting permission (is that confusing
enough), so that a third party permission manager would not be able to
secretly subvert other parts of the system. That still may not be secure
enough, so it is possible that we would not be able to allow the permission
manager app to be replaced. The permission granting to the permissions app
should not be able to be denied permanently so that the user can't be locked
out of controlling permissions. A full threat model and consideration needs to
be done here to figure out what is possible.
I'm hoping that we can provide the ability to query the permission component in
a simple way in the .idl files so that every component doesn't need to add in
explicit code all over the place. This might either be done in the .idl
compiler or through an include in the .idl files.
Note, this same architecture should be available for webapps in general, and
even non-app web sites in all other Mozilla browsers that need it. It should
also be proposed as a standard along with the webapp standard.
To progress with this, we need several things. Someone with expertise in
webapps that can answer questions about whether webapps can interact with other
webapps, what should be used as a signature for a webapp/sites. Someone to do
a threat model and look at security considerations to make sure we're covering
all the bases of where a malicious webapp/site might bypass the permissions
model, and to see if the permissions manager app can be replaced by a third
party app. We need UI design and implementation for the
notification/dialog/etc. for asking the users permission. We need UI design
and implementation for the permissions manager app. We need implementation of
the permission component. We need .idl extension/include for easily adding
permission requests to components.
Thoghts? Comments?
-Jim Straus
_______________________________________________
dev-b2g mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
