Permissions model thoughts

[Jim Straus]

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

[ptheriault]

Jim,

I'll put my hand up for the B2G threat model component (combined with the others in the security team also working on the web apps & marketplace threat models). I've recently joined the security team and I've been spending the several weeks getting familiar with B2G. As a first step to the threat model, it would be great if some B2G people to help understand/document the data flows between Web Content, the WebAPIs and the underlying platform - who is the best person to co-ordinate this through?

I've added some thoughts below, based on discussions we've had so far on permissions.

On Mar 4, 2012, at 9:44 AM, 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 think we also need to define the security requirements of various permissions too. For a Web App to be granted a particularly sensitive permission, we might want to set specific security requirements. For example, "only Web Apps served over strict SSL are allowed to access the Contact API" or similar.

With B2G, could one of these requirements be "must be served locally" (i.e. part of Gaia)? Is there some concept of "privileged" in B2G code already - I have seen it mentioned in various bugs but I haven't seen it defined anywhere apart from specific things like the whitelist for mozSMS. My logic being that that certain permissions might be too sensitive to trust to remote applications (or at least not without some form integrity verification mechanism, such as would be typically associated with a network install, code signing etc).

Requirements might be user-configurable as well, but at a minimum I think we should provide secure defaults. Requirements might also define the level of user interaction required to grant the permission. From a previous thread on the web apps list (the dev-webapps mailing list archives on google groups seem to be empty,did it move?) :
API sensitivity levels
1. Low - okay to give to anyone e.g. localStorage
2. Medium - contextual requests that the user should be prompted for e.g. geolocation
3. High - sensitive APIs that should always require user interaction e.g. camera

>
> 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.

The "signature" of an application will need to take into account network threats (captive portals, DNS attacks etc) amongst other things. I believe the current "signature" for an app is the protocol/address/port (AFAIK, maybe someone can confirm?). Do we associate permissions with this URL or with the Web App itself. For example, if a user navigates to the URL of an installed web app( which has permissions) in the browser, would that page inherit the permissions of the Web App by virtue of being on the same domain, or should it be separate? And vice versa, what happens if someone grants permissions to a URL in the browser, but happens to have a web app installed from the same location? Or maybe "being installed" is a prerequisite for certain permissions.

> 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.

Some other ideas that discussed:
- decaying permissions over time, or time-based permission (i.e. is it ok for this application to use your location today?)
- Permissions UI based on context or permission type (some permissions will be grant once, last forever, where as others might be
- different permission types, within certain APIs (e.g. permission to take a photo with the camera vs permission to stream)

>
> 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-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps

[Ben Francis]

On Mon, Mar 5, 2012 at 10:17 AM, ptheriault <pther...@mozilla.com> wrote:

> I think we also need to define the security requirements of various
> permissions too. For a Web App to be granted a particularly sensitive
> permission, we might want to set specific security requirements. For
> example, "only Web Apps served over strict SSL are allowed to access the
> Contact API" or similar.
>
> With B2G, could one of these requirements be "must be served locally"
> (i.e. part of Gaia)?

No, because Gaia apps won't be served locally. They will be served from a
web server on the Internet and then cached locally, like any other web app.
Serving from localhost is a temporary hack.

Also, "Gaia" apps should not have any special permissions that other web
apps don't have, just because they were developed by Mozilla. You should be
able to swap out any Gaia app (including the homescreen) with a third party
one (with the possible exception of the dialer for certification reasons).

> Is there some concept of "privileged" in B2G code already - I have seen it
> mentioned in various bugs but I haven't seen it defined anywhere apart from
> specific things like the whitelist for mozSMS. My logic being that that
> certain permissions might be too sensitive to trust to remote applications
> (or at least not without some form integrity verification mechanism, such
> as would be typically associated with a network install, code signing etc).
>

As explained above, all applications will be "remote" applications.
Currently we whitelist localhost in prefs to give Gaia apps access to
certain Web APIs, but this practice should be replaced by whatever
permissions model we define and should be available to any web app to which
the user wishes to give permission. Code becomes "privileged" by the user
granting permissions to its origin.

> The "signature" of an application will need to take into account network
> threats (captive portals, DNS attacks etc) amongst other things. I believe
> the current "signature" for an app is the protocol/address/port (AFAIK,
> maybe someone can confirm?).

This is my understanding too (where "address" = "domain"). Currently Open
Web Apps are limited to one app per origin and one origin per app. Google
Chrome hosted apps define the scope of an app with a list of URLs with
wildcards which is much more flexible, but I've been told that the Mozilla
security team would prefer app === origin to make the security model
simpler.

Note that this would not allow:
* http://google.com and http://google.com/calendar being two different apps
* http://facebook.com being the same app as http://touch.facebook.com or
even https://facebook.com

> Do we associate permissions with this URL or with the Web App itself. For
> example, if a user navigates to the URL of an installed web app( which has
> permissions) in the browser, would that page inherit the permissions of the
> Web App by virtue of being on the same domain, or should it be separate?
> And vice versa, what happens if someone grants permissions to a URL in the
> browser, but happens to have a web app installed from the same location? Or
> maybe "being installed" is a prerequisite for certain permissions.
>

As described above, currently app === origin as far as I know, so if an app
is installed from an origin, any web page served from that origin would be
considered part of the app. Whether you'll be able to grant any permission
to web pages that you can grant to web apps, I don't know.

Ben

--
Ben Francis
http://tola.me.uk

[Lucas Adamski]

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

[Jim Straus]

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

[Jim Straus]

Hello -
But maybe "locally cached" could be a requirement? On the idea of
origin being the (part of?) the signature, this means that re-directs
after the original app is given permission would mean that permissions
would need to be re-granted. This goes to the discussion of re-directs
for web apps that occurred recently. This also leads to the idea that
sites should be as restrictive as possible for their origins (so
google.com/calendar, not just google.com). I don't know of a way to
enforce this, but should be part of any recommendations for creating web
apps.

[Jim Straus]

Hello -
See some of the responses to Ben's email. On other areas,
permissions probably relate more to privacy in addition to security.
Access to Contacts shouldn't just depend on SSL, since the user would
still want to know that the app is accessing contacts, even if they
can't be sniffed on the wire. This leads to the thought that maybe the
permission request (if we make the apps have to explicitly ask for
permission) could include a reason string that could be displayed while
asking for a particular permission. It might also help users understand
why they are being asked.
I saw the discussion of different security levels, but I wasn't clear
on exactly why. It seems that given the definitions, low level would
always be granted (though maybe they could be turned off in the
permissions manager application). And the distinction between medium
and high I don't understand. Why would the camera be more of an issue
than geolocation? I would still like to control both of those.
But yes, jump right in and start mapping threat areas and how we can
ameliorate them.
-Jim Straus

On 3/5/12 5:17 AM, ptheriault wrote:
> Jim,
>
> I'll put my hand up for the B2G threat model component (combined with
> the others in the security team also working on the web apps &
> marketplace threat models). I've recently joined the security team and
> I've been spending the several weeks getting familiar with B2G. As a
> first step to the threat model, it would be great if some B2G people
> to help understand/document the data flows between Web Content, the
> WebAPIs and the underlying platform - who is the best person to
> co-ordinate this through?
>
> I've added some thoughts below, based on discussions we've had so far
> on permissions.
>

> On Mar 4, 2012, at 9:44 AM, 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 think we also need to define the security requirements of various
> permissions too. For a Web App to be granted a particularly sensitive
> permission, we might want to set specific security requirements. For
> example, "only Web Apps served over strict SSL are allowed to access
> the Contact API" or similar.
>
> With B2G, could one of these requirements be "must be served locally"

> (i.e. part of Gaia)? Is there some concept of "privileged" in B2G code

> already - I have seen it mentioned in various bugs but I haven't seen
> it defined anywhere apart from specific things like the whitelist for
> mozSMS. My logic being that that certain permissions might be too
> sensitive to trust to remote applications (or at least not without
> some form integrity verification mechanism, such as would be typically
> associated with a network install, code signing etc).
>

> Requirements might be user-configurable as well, but at a minimum I
> think we should provide secure defaults. Requirements might also
> define the level of user interaction required to grant the permission.
> From a previous thread on the web apps list (the dev-webapps mailing
> list archives on google groups seem to be empty,did it move?) :
> API sensitivity levels
> 1. Low - okay to give to anyone e.g. localStorage
> 2. Medium - contextual requests that the user should be prompted for e.g. geolocation
> 3. High - sensitive APIs that should always require user interaction e.g. camera
>
>>

> The "signature" of an application will need to take into account
> network threats (captive portals, DNS attacks etc) amongst other
> things. I believe the current "signature" for an app is the

> protocol/address/port (AFAIK, maybe someone can confirm?). Do we

> associate permissions with this URL or with the Web App itself. For
> example, if a user navigates to the URL of an installed web app( which
> has permissions) in the browser, would that page inherit the
> permissions of the Web App by virtue of being on the same domain, or
> should it be separate? And vice versa, what happens if someone grants
> permissions to a URL in the browser, but happens to have a web app
> installed from the same location? Or maybe "being installed" is a
> prerequisite for certain permissions.
>

>> 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.
>

> Some other ideas that discussed:
> - decaying permissions over time, or time-based permission (i.e. is it
> ok for this application to use your location today?)
> - Permissions UI based on context or permission type (some permissions
> will be grant once, last forever, where as others might be
> - different permission types, within certain APIs (e.g. permission to
> take a photo with the camera vs permission to stream)
>
>>

>> dev-webapps mailing list
>> dev-w...@lists.mozilla.org <mailto:dev-w...@lists.mozilla.org>
>> https://lists.mozilla.org/listinfo/dev-webapps
>

[David Chan]

I think locally-cached is a good starting point. The difficulty will apps
which can be locally-cached but evaluate server supplied code, though this may
fall under "re-goten" that you mentioned in a previous email. Maybe we
should look into an approach similar to the Flashplayer local-with-filesystem
vs local-with-networking sandboxes. An app with only filesystem access would
retain permissions until it is updated. However a locally-cached app with
network access would be subject to more stringent checks. I want to lean away
from restricting eval() et al since that breaks a lot of
frameworks.


Origin does seem too broad and restricting of a scope for
webapps. I think the currently limitation is that we don't have a good
identifier for apps outside of origin. If multiple apps were to be served from
the same origin in the current model, then they could access same-origin
resources such as cookie / localStorage. This may not be the desired outcome.
Perhaps we could rewrite resource requests for apps with some app-specific
UUID? Combining this with domain (origin?) may be sufficient to uniquely
identify an app
e.g.
app manifest contains
<UUID="e5915ac6-8ca1-4b40-a711-03b0bf5a119a" />

app served from
www.example.com

app is identified by
(www.example.com, e5915ac6-8ca1-4b40-a711-03b0bf5a119a)

requests for resources on www.example.com
would be rewritten to appear as if they originated from
"e5915ac6-8ca1-4b40-a711-03b0bf5a119a". Two apps on the same domain
shouldn't have access to each others data / permissions. There would need to
be a common origin for sharing data though.

Another app could have the same
UUID as long as it isn't served from the same domain. This also doesn't
address the server compromise scenario. I think we need code signing /
signatures to solve that threat.


David

----- Original Message -----
> From: "Jim Straus" <jst...@mozilla.com>
> To: "Ben Francis" <b...@tola.me.uk>
> Cc: dev-w...@lists.mozilla.org, "ptheriault" <pther...@mozilla.com>, "Mozilla B2G mailing list"
> <dev...@lists.mozilla.org>
> Sent: Monday, March 5, 2012 1:00:43 PM
> Subject: Re: Permissions model thoughts
>
> Hello -
> But maybe "locally cached" could be a requirement? On the idea of
> origin being the (part of?) the signature, this means that re-directs
> after the original app is given permission would mean that
> permissions
> would need to be re-granted. This goes to the discussion of
> re-directs
> for web apps that occurred recently. This also leads to the idea
> that
> sites should be as restrictive as possible for their origins (so
> google.com/calendar, not just google.com). I don't know of a way to
> enforce this, but should be part of any recommendations for creating
> web
> apps.
>
> On 3/5/12 8:41 AM, Ben Francis wrote:
> > On Mon, Mar 5, 2012 at 10:17 AM, ptheriault <pther...@mozilla.com
> > <mailto:pther...@mozilla.com>> wrote:
> >

> > I think we also need to define the security requirements of
> > various permissions too. For a Web App to be granted a
> > particularly sensitive permission, we might want to set
> > specific
> > security requirements. For example, "only Web Apps served over
> > strict SSL are allowed to access the Contact API" or similar.
> >
> > With B2G, could one of these requirements be "must be served
> > locally" (i.e. part of Gaia)?
> >
> >

> > No, because Gaia apps won't be served locally. They will be served
> > from a web server on the Internet and then cached locally, like any
> > other web app. Serving from localhost is a temporary hack.
> >
> > Also, "Gaia" apps should not have any special permissions that
> > other
> > web apps don't have, just because they were developed by Mozilla.
> > You
> > should be able to swap out any Gaia app (including the homescreen)
> > with a third party one (with the possible exception of the dialer
> > for
> > certification reasons).
> >

> > Is there some concept of "privileged" in B2G code already - I
> > have
> > seen it mentioned in various bugs but I haven't seen it defined
> > anywhere apart from specific things like the whitelist for
> > mozSMS.
> > My logic being that that certain permissions might be too
> > sensitive to trust to remote applications (or at least not
> > without
> > some form integrity verification mechanism, such as would be
> > typically associated with a network install, code signing etc).
> >
> >

> > As explained above, all applications will be "remote" applications.
> > Currently we whitelist localhost in prefs to give Gaia apps access
> > to
> > certain Web APIs, but this practice should be replaced by whatever
> > permissions model we define and should be available to any web app
> > to
> > which the user wishes to give permission. Code becomes "privileged"
> > by
> > the user granting permissions to its origin.
> >
> >

> > The "signature" of an application will need to take into
> > account
> > network threats (captive portals, DNS attacks etc) amongst
> > other
> > things. I believe the current "signature" for an app is the
> > protocol/address/port (AFAIK, maybe someone can confirm?).
> >
> >

> > This is my understanding too (where "address" = "domain").
> > Currently
> > Open Web Apps are limited to one app per origin and one origin per
> > app. Google Chrome hosted apps define the scope of an app with a
> > list
> > of URLs with wildcards which is much more flexible, but I've been
> > told
> > that the Mozilla security team would prefer app === origin to make
> > the
> > security model simpler.
> >
> > Note that this would not allow:
> > * http://google.com and http://google.com/calendar being two
> > different
> > apps
> > * http://facebook.com being the same app as
> > http://touch.facebook.com
> > or even https://facebook.com
> >

> > Do we associate permissions with this URL or with the Web App
> > itself. For example, if a user navigates to the URL of an
> > installed web app( which has permissions) in the browser, would
> > that page inherit the permissions of the Web App by virtue of
> > being on the same domain, or should it be separate? And vice
> > versa, what happens if someone grants permissions to a URL in
> > the
> > browser, but happens to have a web app installed from the same
> > location? Or maybe "being installed" is a prerequisite for
> > certain
> > permissions.
> >
> >

> > As described above, currently app === origin as far as I know, so
> > if
> > an app is installed from an origin, any web page served from that
> > origin would be considered part of the app. Whether you'll be able
> > to
> > grant any permission to web pages that you can grant to web apps, I
> > don't know.
> >
> > Ben
> >
> > --
> > Ben Francis
> > http://tola.me.uk
>

> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-webapps
>

[Jim Straus]

Hello oDavid -
I think the idea of a uuid is getting closer. Perhaps Mozilla
supplies a uuid server that guarantees uniqueness. We do know that when
a webapp is being loaded/installed the network must be available, we
know we can validate the uuid at that time (okay, this might not always
be true. In a walled garden situation an app server my be available but
the uuid server not accessible. In this case the app can't get any
permissions until it has been validated with the uuid server). This
server could also maintain the signatures for apps. So, apps would be
have to be registered with Mozilla (not the actual app, just the
signature/uuid). At the same time, I could see the same server being
used to invalidate apps that are discovered to being abusive. I
wouldn't necessarily go as far as Android/Apple and delete the apps, but
perhaps just revoke all permissions with a warning to the user.
As for the local-with-filesystem vs. local-with-networking, that
sounds like a good idea, but I don't have enough experience with how we
can handle these type of things. How do we know an app won't try to
access the network after it is given permission? Do we change permanent
permissions to temporary if an app tries to access the network?
-Jim Straus

[David Chan]

Hi

The current Mozilla marketplace roadmap includes having the developer provide
a short description of why their app requires certain permissions. However if
I understand your proposal correctly, you want developers to provide a reason
for accessing the permission at the time of request. That seems fine with me
since the developers are the ones that understand the context of why they are
requesting permissions. This would also allow reviewers to verify in the code
that a permission request matches up with the description.

The argument for different permissions levels was to call out which APIs
require a user prompt at minimum. For a "low" permission such as localStorage,
we may determine that it is sufficient to notify the user at install time and
not prompt them while using the app. There may be other circumstances which
require a prompt, such as if the app stores more than some predefined max KB.
For more sensitive permissions, we may decide that the user is prompted
per-launch / per-request with some way to remember their decision. I don't
have a good idea of what a medium vs high sensitivity API is. Maybe "high"
can be system APIs that webapps shouldn't have access to unless signed?
whitelisted?

I do want to stay away from a decision which makes Mozilla the sole decider
of whether an app is whitelisted or not.

David


----- Original Message -----
> From: "Jim Straus" <jst...@mozilla.com>
> To: "ptheriault" <pther...@mozilla.com>
> Cc: dev-w...@lists.mozilla.org, "Mozilla B2G mailing list" <dev...@lists.mozilla.org>
> Sent: Monday, March 5, 2012 1:00:48 PM
> Subject: Re: Permissions model thoughts
>
> Hello -

> > I think we also need to define the security requirements of various
> > permissions too. For a Web App to be granted a particularly
> > sensitive
> > permission, we might want to set specific security requirements.
> > For
> > example, "only Web Apps served over strict SSL are allowed to
> > access
> > the Contact API" or similar.
> >
> > With B2G, could one of these requirements be "must be served
> > locally"

> > (i.e. part of Gaia)? Is there some concept of "privileged" in B2G

> > code
> > already - I have seen it mentioned in various bugs but I haven't
> > seen
> > it defined anywhere apart from specific things like the whitelist
> > for
> > mozSMS. My logic being that that certain permissions might be too
> > sensitive to trust to remote applications (or at least not without
> > some form integrity verification mechanism, such as would be
> > typically
> > associated with a network install, code signing etc).
> >

> > The "signature" of an application will need to take into account
> > network threats (captive portals, DNS attacks etc) amongst other
> > things. I believe the current "signature" for an app is the

> > protocol/address/port (AFAIK, maybe someone can confirm?). Do we

> > associate permissions with this URL or with the Web App itself. For
> > example, if a user navigates to the URL of an installed web app(
> > which
> > has permissions) in the browser, would that page inherit the
> > permissions of the Web App by virtue of being on the same domain,
> > or
> > should it be separate? And vice versa, what happens if someone
> > grants
> > permissions to a URL in the browser, but happens to have a web app
> > installed from the same location? Or maybe "being installed" is a
> > prerequisite for certain permissions.
> >

> >> _______________________________________________
> >> dev-webapps mailing list
> >> dev-w...@lists.mozilla.org

> >> <mailto:dev-w...@lists.mozilla.org>
> >> https://lists.mozilla.org/listinfo/dev-webapps

[David Chan]

Hey Jim,

To expand on the UUID server, I'm assuming that there can be multiple
servers run by different companies? Having a single point of failure
would make it a high priority target for attackers / malicious users.
However having multiple servers can result in problems if there is a
UUID collision.

local-with-filesytem and local-with-networking would be a setting that
apps declare in their manifest. Network request would fail in the
filesystem sandbox and filesystem requests would fail in the networking
sandbox. We would have to implement these controls in the platform.
Flash also has the idea of a local-trusted SWF which can access both
the filesystem and network. If we do implement these restrictions, I
don't think an app should be able to move from one to the other without
an update. However if a "local-trusted" app wants to downgrade to one
of the more restricted sandboxes, we should allow that. This may also
be a result of permission decaying.

I imagine the permissions model would be different for each of the above
sandboxes, in what may be implicitly granted if any.

David

----- Original Message -----
> From: "Jim Straus" <jst...@mozilla.com>
> To: "David Chan" <dc...@mozilla.com>
> Cc: dev-w...@lists.mozilla.org, "ptheriault" <pther...@mozilla.com>, "Mozilla B2G mailing list"
> <dev...@lists.mozilla.org>, "Ben Francis" <b...@tola.me.uk>
> Sent: Monday, March 5, 2012 2:30:19 PM
> Subject: Re: Permissions model thoughts
>

> > webapps. I think the currently limitation is that we don't have a
> > good

> > David
> >
> >
> > ----- Original Message -----
> >> From: "Jim Straus"<jst...@mozilla.com>

> >> To: "Ben Francis"<b...@tola.me.uk>
> >> Cc: dev-w...@lists.mozilla.org,

> >> "ptheriault"<pther...@mozilla.com>, "Mozilla B2G mailing list"
> >> <dev...@lists.mozilla.org>
> >> Sent: Monday, March 5, 2012 1:00:43 PM
> >> Subject: Re: Permissions model thoughts
> >>
> >> Hello -

> >> But maybe "locally cached" could be a requirement? On the
> >> idea of
> >> origin being the (part of?) the signature, this means that
> >> re-directs
> >> after the original app is given permission would mean that
> >> permissions
> >> would need to be re-granted. This goes to the discussion of
> >> re-directs
> >> for web apps that occurred recently. This also leads to the idea
> >> that
> >> sites should be as restrictive as possible for their origins (so
> >> google.com/calendar, not just google.com). I don't know of a way
> >> to
> >> enforce this, but should be part of any recommendations for
> >> creating
> >> web
> >> apps.
> >>
> >> On 3/5/12 8:41 AM, Ben Francis wrote:
> >>> On Mon, Mar 5, 2012 at 10:17 AM,
> >>> ptheriault<pther...@mozilla.com
> >>> <mailto:pther...@mozilla.com>> wrote:
> >>>

> >>> I think we also need to define the security requirements of
> >>> various permissions too. For a Web App to be granted a
> >>> particularly sensitive permission, we might want to set
> >>> specific
> >>> security requirements. For example, "only Web Apps served
> >>> over
> >>> strict SSL are allowed to access the Contact API" or
> >>> similar.
> >>>
> >>> With B2G, could one of these requirements be "must be served
> >>> locally" (i.e. part of Gaia)?
> >>>
> >>>

> >>> No, because Gaia apps won't be served locally. They will be
> >>> served
> >>> from a web server on the Internet and then cached locally, like
> >>> any
> >>> other web app. Serving from localhost is a temporary hack.
> >>>
> >>> Also, "Gaia" apps should not have any special permissions that
> >>> other
> >>> web apps don't have, just because they were developed by Mozilla.
> >>> You
> >>> should be able to swap out any Gaia app (including the
> >>> homescreen)
> >>> with a third party one (with the possible exception of the dialer
> >>> for
> >>> certification reasons).
> >>>

> >>> Is there some concept of "privileged" in B2G code already -
> >>> I
> >>> have
> >>> seen it mentioned in various bugs but I haven't seen it
> >>> defined
> >>> anywhere apart from specific things like the whitelist for
> >>> mozSMS.
> >>> My logic being that that certain permissions might be too
> >>> sensitive to trust to remote applications (or at least not
> >>> without
> >>> some form integrity verification mechanism, such as would be
> >>> typically associated with a network install, code signing
> >>> etc).
> >>>
> >>>

> >>> As explained above, all applications will be "remote"
> >>> applications.
> >>> Currently we whitelist localhost in prefs to give Gaia apps
> >>> access
> >>> to
> >>> certain Web APIs, but this practice should be replaced by
> >>> whatever
> >>> permissions model we define and should be available to any web
> >>> app
> >>> to
> >>> which the user wishes to give permission. Code becomes
> >>> "privileged"
> >>> by
> >>> the user granting permissions to its origin.
> >>>
> >>>

> >>> The "signature" of an application will need to take into
> >>> account
> >>> network threats (captive portals, DNS attacks etc) amongst
> >>> other
> >>> things. I believe the current "signature" for an app is the
> >>> protocol/address/port (AFAIK, maybe someone can confirm?).
> >>>
> >>>

> >>> This is my understanding too (where "address" = "domain").
> >>> Currently
> >>> Open Web Apps are limited to one app per origin and one origin
> >>> per
> >>> app. Google Chrome hosted apps define the scope of an app with a
> >>> list
> >>> of URLs with wildcards which is much more flexible, but I've been
> >>> told
> >>> that the Mozilla security team would prefer app === origin to
> >>> make
> >>> the
> >>> security model simpler.
> >>>
> >>> Note that this would not allow:
> >>> * http://google.com and http://google.com/calendar being two
> >>> different
> >>> apps
> >>> * http://facebook.com being the same app as
> >>> http://touch.facebook.com
> >>> or even https://facebook.com
> >>>

> >>> Do we associate permissions with this URL or with the Web
> >>> App
> >>> itself. For example, if a user navigates to the URL of an
> >>> installed web app( which has permissions) in the browser,
> >>> would
> >>> that page inherit the permissions of the Web App by virtue
> >>> of
> >>> being on the same domain, or should it be separate? And vice
> >>> versa, what happens if someone grants permissions to a URL
> >>> in
> >>> the
> >>> browser, but happens to have a web app installed from the
> >>> same
> >>> location? Or maybe "being installed" is a prerequisite for
> >>> certain
> >>> permissions.
> >>>
> >>>

> >>> As described above, currently app === origin as far as I know, so
> >>> if
> >>> an app is installed from an origin, any web page served from that
> >>> origin would be considered part of the app. Whether you'll be
> >>> able
> >>> to
> >>> grant any permission to web pages that you can grant to web apps,
> >>> I
> >>> don't know.
> >>>
> >>> Ben
> >>>
> >>> --
> >>> Ben Francis
> >>> http://tola.me.uk

[Adam Barth]

On Mon, Mar 5, 2012 at 12:45 PM, Jim Straus <jst...@mozilla.com> wrote:
> 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.

There's been a bunch of research on the Android permission model in
academia, including a bunch of suggestions for how to do better. If
you'd like, I'd be happy to connect you with the folks who've studied
this topic (off-list).

>  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.

One thing that has worked well for packaged apps in Chrome is to use a
public key in the URL to identify local content. For example:

b2g-or-whatever://ankgjoopnopeoeljehjkighfcfefalcg/path/inside/package.html

where ankgjoopnopeoeljehjkighfcfefalcg is a public key and
"/path/inside/package.html" is a path inside a zip archive self-signed
with ankgjoopnopeoeljehjkighfcfefalcg.

This model is decentralized and provides a solid, secure foundation.
It also plays well with the usual same-origin model for web security.
I'm happy to answer any questions you have about Chrome's experience
with this approach.

Adam

> 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.
>>>

>>> dev-b2g mailing list
>>> dev...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-b2g
>
>

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security

[Ben Francis]

On Mon, Mar 5, 2012 at 11:16 PM, Adam Barth <abarth-...@adambarth.com>wrote:

> There's been a bunch of research on the Android permission model in
> academia, including a bunch of suggestions for how to do better. If
> you'd like, I'd be happy to connect you with the folks who've studied
> this topic (off-list).
>

I'd be interested to hear about these studies, are then any papers
available freely on the Internet?

> One thing that has worked well for packaged apps in Chrome is to use a
> public key in the URL to identify local content. For example:
>
> b2g-or-whatever://ankgjoopnopeoeljehjkighfcfefalcg/path/inside/package.html
>
> where ankgjoopnopeoeljehjkighfcfefalcg is a public key and
> "/path/inside/package.html" is a path inside a zip archive self-signed
> with ankgjoopnopeoeljehjkighfcfefalcg.
>
> This model is decentralized and provides a solid, secure foundation.
> It also plays well with the usual same-origin model for web security.
> I'm happy to answer any questions you have about Chrome's experience
> with this approach.
>

I don't have an opinion on this particular feature, but in general I would
really like to advocate that we don't diverge too much from what Chrome
Hosted Apps do unless there is a really good reason to do so, we'll be
looking to standardise parts of this after all.

[Robert Kaiser]

ptheriault schrieb:

> 3. High - sensitive APIs that should always require user interaction e.g. camera

To stay with this example, if I'm installing and using a camera app, I
surely don't want to be prompted every time I open it. For other uses of
the camera, that might be a good idea, though.


In any case, I think we'll need to find a good middle ground between
Android's eat-or-die for-lifetime-on-install model and a rather
user-annoying ask-every-time model. It will be interesting to find the
sweet spot in between, but I'm sure this can be figured out somehow. I
guess we'll need to have something in there like Geolocation has on
desktop, which has a "always allow for this site" checkbox.

Robert Kaiser

[Fabrice Desré]

On 03/06/2012 05:11 AM, Ben Francis wrote:
> On Mon, Mar 5, 2012 at 11:16 PM, Adam Barth<abarth-...@adambarth.com>wrote:
>
>> There's been a bunch of research on the Android permission model in
>> academia, including a bunch of suggestions for how to do better. If
>> you'd like, I'd be happy to connect you with the folks who've studied
>> this topic (off-list).
>>
>
> I'd be interested to hear about these studies, are then any papers
> available freely on the Internet?

Look for instance at work from Adrienne Porter Felt:
http://www.cs.berkeley.edu/~afelt/

Fabrice
--
Fabrice Desré
b2g Team
Mozilla Corporation

[Adrienne Porter Felt]

Thanks for the pointer, Fabrice.

I've been studying Chrome extension & Android app permissions; some of
those results are relevant to this discussion. Links to the full papers
are below. Here are some of the main lessons and recommendations from
those studies:

-- Permissions significantly limit the severity of Chrome extension
vulnerabilities. I therefore think that manifest-based permissions would
be a *very* valuable addition to a new web app platform. If a web app is
owned (e.g., an XSS bug), at least the permissions would limit the attack
to a subset of the API. This doesn't necessarily mean that permissions
have to be shown to the user the first time s/he visits a web app: the
upfront permissions could act as a maximum bound on the number of runtime
permissions that the web app can get.

-- Installation is the wrong time to ask about most permissions. People
don't have enough information to decide, and we find that many people
assume they will be asked again at runtime before the actions actually
occur.

-- A permission system does not need to prompt every user about
everything. For example, there is relatively little risk attached to
letting an app turn your Bluetooth on or off. People have finite attention
spans, and every additional warning devalues the permission system. People
should only be asked about things that have very clear, definite risks.
The system should support a separate "paranoid mode" where people can
voluntarily enable more warnings.

-- Developers tend to think in terms of actions and resources, but people
have a hard time connecting actions and resources to risks. Any warnings
should be framed in terms of concrete risks. For example, "read phone
state and identity" talks about resources but "track you across
applications" refers to the risk of letting an application know your IMEI.

-- Whenever possible, permissions should be built in to the user's natural
system flow to avoid the need for permission dialogs. For example, there
are three possible ways for a web app to send a text message: (1) it asks
for permission via a dialog and then directly sends a text message, (2) it
uses WebIntents to point the user to a trusted platform text messaging
system, or (3) the platform provides a trusted "send SMS" that a web app
can embed somewhere in its UI. Options #2 and #3 are highly preferable to
option #1 because it doesn't interrupt the user to ask for permission;
instead, we just implicitly know that the user wants to send an SMS
message. As many things should be built using #2 and #3 as possible. Some
apps may need to use approach #1; however, support for that should be added
later (when it is requested by enough developers) to avoid everyone using
that "shortcut." (Android provides options #1 and #2, and a lot of
developers unnecessarily use #1.)

-- Auditing. Once a user has granted a permission, users should be able to
see when they are actually used.

-- If a user is shown an Always/Once/No permission dialog, there should be
some context for the "Always" option so the user knows what that will
entail. Is this app going to send 1 text message, or 30,000? Matt
Finfiter & Dev Akhawe suggested something interesting: collect statistics
on how permissions are used in aggregate (e.g., how often) and present the
statistics as an optionally-visible part of the dialog.

Cheers,
Adrienne

---------------------
Papers:

*An Evaluation of the Google Chrome Extension Security Architecture*
http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities.pdf
Found vulnerabilities in Chrome extensions; Section 6 discusses the impact
of permissions on the scope of the vulnerabilities.

*Android Permissions: User Attention, Comprehension, and Behavior*
http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-26.pdf
Did two user studies to see whether people pay attention to, understand, or
act on permissions. Most interesting results relate to comprehension.
Section 7 summarizes the results and provides a set of concrete
recommendations for improving permissions.

*Android Permissions Demystified*
http://www.cs.berkeley.edu/~afelt/android_permissions.pdf
Looked at how well developers use Android permissions and the types of
mistakes they make. Section 6 presents the results (the rest of the paper
talks about the tool).

Also, Franzi Roesner has a paper talking about how to embed permission
widgets into UIs to avoid the need for permission dialogs:
http://research.microsoft.com/pubs/152495/user-driven-access-control-nov2011.pdf

[Jim Straus]

Hello Adrienne -
Thanks for the good thoughts. I think we all 100% agree that installation time is the wrong time to ask. I'm wondering about your thoughts on asking for all permissions at the same time (in a list, with the option to selectively allow different permissions) or as they are used? The former seems less obtrusive, since the user is only interrupted once, but tends to lead to users just approving everything without thinking about each permission. I guess part of the decision will be how many permissions we expect any specific application to need. If it is one or two (like geolocation and contacts), as you go would be okay. If it is more than two or three, getting multiple requests is going to be too intrusive.
The idea that some permissions are implicitly provided (based on a previous decision or some heuristics) is part of the plan. But we may still want to enumerate the permissions in a permissions manager application so a user can see what things an app is using and explicitly turn them on or off even if they are enabled or disabled by default.
I agree that framing things in terms of explicit risks is a good idea, but can we always say what they are? Letting an application know your IMEI can certainly be used to "track you across applications" is one risk, but an app could also use it for other nefarious uses. And there are reasons where granting IMEI is legitimate. Trying to come up with the right messages might be impossible.
On the idea that permissions should be built into the user's natural flow, I agree. I think it goes further. If we can determine that a user explicitly took an action to perform a task, we can assume they have implicitly given permission. If a user presses a shutter button to take a picture with the camera, they are implicitly giving permission to use the camera. Likewise, if a user enters credentials for Facebook, we can assume they want to post to their Facebook wall. Whether we can do this at all or in some cases for web applications, I don't know yet.
I like the idea of auditing. I'm not sure what you mean by when a specific permission is actually used, but the idea of giving the user a sense of how often an application is using the permission is certainly possible and could be shown in a permissions manager.
-Jim Straus

On Mar 6, 2012, at 9:28 PM, Adrienne Porter Felt wrote:

> Thanks for the pointer, Fabrice.
>
> I've been studying Chrome extension & Android app permissions; some of those results are relevant to this discussion. Links to the full papers are below. Here are some of the main lessons and recommendations from those studies:
>
> -- Permissions significantly limit the severity of Chrome extension vulnerabilities. I therefore think that manifest-based permissions would be a *very* valuable addition to a new web app platform. If a web app is owned (e.g., an XSS bug), at least the permissions would limit the attack to a subset of the API. This doesn't necessarily mean that permissions have to be shown to the user the first time s/he visits a web app: the upfront permissions could act as a maximum bound on the number of runtime permissions that the web app can get.
>
> -- Installation is the wrong time to ask about most permissions. People don't have enough information to decide, and we find that many people assume they will be asked again at runtime before the actions actually occur.
>
> -- A permission system does not need to prompt every user about everything. For example, there is relatively little risk attached to letting an app turn your Bluetooth on or off. People have finite attention spans, and every additional warning devalues the permission system. People should only be asked about things that have very clear, definite risks. The system should support a separate "paranoid mode" where people can voluntarily enable more warnings.
>
> -- Developers tend to think in terms of actions and resources, but people have a hard time connecting actions and resources to risks. Any warnings should be framed in terms of concrete risks. For example, "read phone state and identity" talks about resources but "track you across applications" refers to the risk of letting an application know your IMEI.
>
> -- Whenever possible, permissions should be built in to the user's natural system flow to avoid the need for permission dialogs. For example, there are three possible ways for a web app to send a text message: (1) it asks for permission via a dialog and then directly sends a text message, (2) it uses WebIntents to point the user to a trusted platform text messaging system, or (3) the platform provides a trusted "send SMS" that a web app can embed somewhere in its UI. Options #2 and #3 are highly preferable to option #1 because it doesn't interrupt the user to ask for permission; instead, we just implicitly know that the user wants to send an SMS message. As many things should be built using #2 and #3 as possible. Some apps may need to use approach #1; however, support for that should be added later (when it is requested by enough developers) to avoid everyone using that "shortcut." (Android provides options #1 and #2, and a lot of developers unnecessarily use #1.)
>
> -- Auditing. Once a user has granted a permission, users should be able to see when they are actually used.
>
> -- If a user is shown an Always/Once/No permission dialog, there should be some context for the "Always" option so the user knows what that will entail. Is this app going to send 1 text message, or 30,000? Matt Finfiter & Dev Akhawe suggested something interesting: collect statistics on how permissions are used in aggregate (e.g., how often) and present the statistics as an optionally-visible part of the dialog.
>
> Cheers,
> Adrienne
>
> ---------------------
> Papers:
>

> An Evaluation of the Google Chrome Extension Security Architecture

> http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities.pdf
> Found vulnerabilities in Chrome extensions; Section 6 discusses the impact of permissions on the scope of the vulnerabilities.
>

> Android Permissions: User Attention, Comprehension, and Behavior

> http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-26.pdf
> Did two user studies to see whether people pay attention to, understand, or act on permissions. Most interesting results relate to comprehension. Section 7 summarizes the results and provides a set of concrete recommendations for improving permissions.
>

> Android Permissions Demystified

[Robert Kaiser]

Jim Straus schrieb:

> I guess part of the decision will be how many permissions we expect any specific application to need. If it is one or two (like geolocation and contacts), as you go would be okay. If it is more than two or three, getting multiple requests is going to be too intrusive.

Could we allow any application to always only ask, say, two permissions
at once (within a timeframe of X)?

Robert Kaiser

[Jonas Sicking]

2012/3/8 Jim Straus <jst...@mozilla.com>:
> Hello Adrienne -
>  Thanks for the good thoughts.  I think we all 100% agree that installation time is the wrong time to ask.  I'm wondering about your thoughts on asking for all permissions at the same time (in a list, with the option to selectively allow different permissions) or as they are used?  The former seems less obtrusive, since the user is only interrupted once, but tends to lead to users just approving everything without thinking about each permission.  I guess part of the decision will be how many permissions we expect any specific application to need.  If it is one or two (like geolocation and contacts), as you go would be okay.  If it is more than two or three, getting multiple requests is going to be too intrusive.

Another reason that asking for permissions at once is that it's hard
to build a UI for that that users would actually read.

I think it's generally considered that putting a big dialog in the
user's face asking them to make a security decision generally simply
makes them click "whatever button that will make this dialog thing go
away so I can get back to what I was doing". I.e. users too often just
try to dismiss it without bothering to read it's full contents.

However what seems to work better is if you actually put the relevant
text in the actual buttons that the user is pushing. So instead of
having a dialog saying "This website wants to know where you are
currently located. Do you want to allow this" and to buttons that say
"yes" and "no", users will read the two buttons and try to figure out
which one will make the dialog diappear.

However if you instead make the dialog say "This website is trying to
get your current location. What do you want to do?" with two buttons
that say "Give my location to website" and "Deny access", then you
have a better chance of getting a more relevant answer.

If you lump all your questions together into a single dialog, you'll
have a very hard time using that trick.

>  The idea that some permissions are implicitly provided (based on a previous decision or some heuristics) is part of the plan.  But we may still want to enumerate the permissions in a permissions manager application so a user can see what things an app is using and explicitly turn them on or off even if they are enabled or disabled by default.

Using heuristics I think will be hard. But I do think that we should
have a default policy for websites as well as a default policy for
installed apps, and that those policies should be user configurable.

>  I agree that framing things in terms of explicit risks is a good idea, but can we always say what they are?  Letting an application know your IMEI can certainly be used to "track you across applications" is one risk, but an app could also use it for other nefarious uses.  And there are reasons where granting IMEI is legitimate.  Trying to come up with the right messages might be impossible.

Maybe provide both pieces of information is the best solution. I.e.
make the dialog say "This app wants access to your IMEI number. If you
grant this access they can do evil actions X and Y. And if you grant
access to multiple apps they can track you across apps." and then make
the buttons say "Grant IMEI number" and "Don't grant IMEI number".

>  On the idea that permissions should be built into the user's natural flow, I agree.  I think it goes further.  If we can determine that a user explicitly took an action to perform a task, we can assume they have implicitly given permission.  If a user presses a shutter button to take a picture with the camera, they are implicitly giving permission to use the camera.  Likewise, if a user enters credentials for Facebook, we can assume they want to post to their Facebook wall.  Whether we can do this at all or in some cases for web applications, I don't know yet.

How will we know that the user pressed something that looked like a
shutter button? Especially given technologies like clickjacking and
CSS.

>  I like the idea of auditing.  I'm not sure what you mean by when a specific permission is actually used, but the idea of giving the user a sense of how often an application is using the permission is certainly possible and could be shown in a permissions manager.

If we allow a the user to change the level of access from "allow" to
"prompt user when used", then that should enable the user to be to see
when a given capability is used.

/ Jonas

[lkcl luke]

On Sat, Mar 10, 2012 at 4:44 AM, Jonas Sicking <jo...@sicking.cc> wrote:

> However if you instead make the dialog say "This website is trying to
> get your current location. What do you want to do?" with two buttons
> that say "Give my location to website" and "Deny access", then you
> have a better chance of getting a more relevant answer.

that's a bloody good idea.

do you know what? it's the only time i've ever heard *anyone* come
up with a decent way to deal with the
idiot-user-clickety-click-to-get-rid-of-the-what's-that-dialog
problem.

> Maybe provide both pieces of information is the best solution. I.e.
> make the dialog say "This app wants access to your IMEI number. If you
> grant this access they can do evil actions X and Y. And if you grant
> access to multiple apps they can track you across apps." and then make
> the buttons say "Grant IMEI number" and "Don't grant IMEI number".

HA, that's hilarious. can you imagine a profit-maximising company
such as google, apple or palm/hp coming up with something like this?
*sotto voice* "oo noo, mr deevelupurr, we couldn't possibly do
something like actually tell people they could be tracked, it might
scare away the customer and that would hurt our profits".

remember though that you'll have to make those dialog buttons be
"Give away IMEI number and be tracked for as long as you shall live"
and "Don't grant IMEI number and be denied the use of this wonderful
free addictive application which aalllll of your peers have been
pressurised into installing" :)

*cough* sorry cynical of me.

l.

[Dean Landolt]

2012/3/9 lkcl luke <luke.l...@gmail.com>

Regardless of the prompts and dialogs chosen it's critical -- for both devs
and laymen -- to be able to able to get quick access to a detailed list of
capability grants for any given application from the application itself.
And not just for b2g and mobile -- it should be right there with
view-source, fundamental to gecko.

[lkcl luke]

On Sun, Mar 11, 2012 at 1:43 PM, Dean Landolt <de...@deanlandolt.com> wrote:

> Regardless of the prompts and dialogs chosen it's critical -- for both devs
> and laymen -- to be able to able to get quick access to a detailed list of
> capability grants for any given application from the application itself. And
> not just for b2g and mobile -- it should be right there with view-source,
> fundamental to gecko.

again, it is worth repeating: this recommended requirement needs to
be FORMALLY PLACED onto an OFFICIAL DOCUMENT.

could someone please for the love of god take responsibility for that
task and actually make an announcement "we have created a wiki page
here {insert location} and are coordinating all requirements at that
specific location".

if you do not have anyone who is actually doing that nor does anyone
have time to actually do so then it is indicative that the B2G project
requires an additional funded post, paid for by the mozilla
foundation, doesn't it?

you cannot leave something like the security model of the B2G system
run along as an "arbitrary meandering path" that is completely
uncoordinated. it's too fundamental and critical to the success of
the project.

l.

[Adrienne Porter Felt]

>
> I agree that framing things in terms of explicit risks is a good idea,
> but can we always say what they are? Letting an application know your IMEI
> can certainly be used to "track you across applications" is one risk, but
> an app could also use it for other nefarious uses. And there are reasons
> where granting IMEI is legitimate. Trying to come up with the right
> messages might be impossible.
>

Yes, it's possible to miss a risk. However, a set of security experts will
certainly be better at figuring out what the risks are than arbitrary end
users, who are really quite terrible at it. And of course it is possible
for it to be a legitimate request. The user should be able to figure out
the legitimate reason because s/he has presumably clicked on a button or
done something else to trigger the permission prompt. The security warning
serves as a counterbalance to present the risks, which the user presumably
may not be able to figure out on his/her own (otherwise we wouldn't need to
show a warning at all).

[Chris Lee]

Hi all,

The team will be putting together and documenting a proposal for the overall permissions/security/privacy model for B2G.

At this time, the mailing list and email threads are to openly discuss ideas around what the overall team believes are key needs for this work.

The goal is to work closely with the community and larger team to ensure we're not missing important requirements and then prioritize/focus on what needs to be built based on the timeline we've agreed upon with our partners.

Feel free to ping me if you any specific questions on the roadmap/schedule.

Thanks,
Chris