Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: [b2g] Permissions model thoughts
35 views
Skip to first unread message
Lucas Adamski
Mar 5, 2012, 1:25:22 PM3/5/12
to Jim Straus, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
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
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
Mar 5, 2012, 3:45:15 PM3/5/12
to Lucas Adamski, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
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
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
Adam Barth
Mar 5, 2012, 6:16:31 PM3/5/12
to Jim Straus, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Lucas Adamski, Mozilla B2G mailing list
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
> 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.
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.
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
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
Ben Francis
Mar 6, 2012, 8:11:45 AM3/6/12
to Adam Barth, dev-w...@lists.mozilla.org, Jim Straus, dev-se...@lists.mozilla.org, Lucas Adamski, Mozilla B2G mailing list
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
> 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).
>
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.
>
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.
Ben
--
Ben Francis
http://tola.me.uk
Fabrice Desré
Mar 6, 2012, 11:36:40 AM3/6/12
to Ben Francis, dev-w...@lists.mozilla.org, Adam Barth, Lucas Adamski, Mozilla B2G mailing list, dev-se...@lists.mozilla.org, Jim Straus
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:
> 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?
http://www.cs.berkeley.edu/~afelt/
Fabrice
--
Fabrice Desré
b2g Team
Mozilla Corporation
Adrienne Porter Felt
Mar 6, 2012, 9:28:15 PM3/6/12
to Fabrice Desré, dev-w...@lists.mozilla.org, Jim Straus, Matthew S. Finifter, Adam Barth, Ben Francis, Lucas Adamski, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
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
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
Jean-Marc Desperrier
Mar 7, 2012, 4:16:11 AM3/7/12
to mozilla-de...@lists.mozilla.org
Jim Straus a écrit :
As ROC said some months ago, the <input type="file"> permission model
just happens to work properly. It can be the model for a good solution
if we properly understand why it works.
So what is needed IMO :
- Find a way to not ask the user at all
To get that :
- don't give the application access to no-GUI API layer that they can
abuse
- give them access to an entry point that controls the GUI of the
sensible part
- allows an application to call an interface with a GUI only when it
has focus
- opaque elements are a good pivot to make this work. They can render
safe something that would be very dangerous if not opaque.
- If that fails and you do have to ask, ask to allow a feature, never
ask to authorize access to some technical elements the average user
understand nothing about
- In some case, the GUI could just *inform* the user, instead of asking.
Maybe the user just needs to be informed that an app is currently
requiring his location.
- Role isolation can help too. Access to contacts is not actually
dangerous if you have no network access and cannot transmit them to
another application.
To implement that you will need :
- A list of preexisting modules that handle safely the most often needed
sensible functionalities
- An extensibility mechanism that will allow to create new modules to
handle cases that the preexisting one don't handle properly. It will be
long, slow and hard to create one compared to just creating a normal
application, and the code will have to be fully audited (probably only
open source modules will be possible)
- Application won't need any authorization, because they are not allowed
to do anything sensible directly. They may however be linked to a list
of the sensible module they use, so that you can audit that, and react
if one is a bit strange.
Also, we could end up with some module that will only be safe if the
application strictly limited in what else it can do.
In concrete terms : You would be allowed to request full and complete
access to contacts, but then you become a contact management application
that has access to *nothing* else. That would be the role isolation
protection layer.
> 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.
The Android model is broken, but so was the permission pop-up model.
> 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.
As ROC said some months ago, the <input type="file"> permission model
just happens to work properly. It can be the model for a good solution
if we properly understand why it works.
So what is needed IMO :
- Find a way to not ask the user at all
To get that :
- don't give the application access to no-GUI API layer that they can
abuse
- give them access to an entry point that controls the GUI of the
sensible part
- allows an application to call an interface with a GUI only when it
has focus
- opaque elements are a good pivot to make this work. They can render
safe something that would be very dangerous if not opaque.
- If that fails and you do have to ask, ask to allow a feature, never
ask to authorize access to some technical elements the average user
understand nothing about
- In some case, the GUI could just *inform* the user, instead of asking.
Maybe the user just needs to be informed that an app is currently
requiring his location.
- Role isolation can help too. Access to contacts is not actually
dangerous if you have no network access and cannot transmit them to
another application.
To implement that you will need :
- A list of preexisting modules that handle safely the most often needed
sensible functionalities
- An extensibility mechanism that will allow to create new modules to
handle cases that the preexisting one don't handle properly. It will be
long, slow and hard to create one compared to just creating a normal
application, and the code will have to be fully audited (probably only
open source modules will be possible)
- Application won't need any authorization, because they are not allowed
to do anything sensible directly. They may however be linked to a list
of the sensible module they use, so that you can audit that, and react
if one is a bit strange.
Also, we could end up with some module that will only be safe if the
application strictly limited in what else it can do.
In concrete terms : You would be allowed to request full and complete
access to contacts, but then you become a contact management application
that has access to *nothing* else. That would be the role isolation
protection layer.
Kevin Chadwick
Mar 7, 2012, 6:00:09 AM3/7/12
to dev-se...@lists.mozilla.org
On Wed, 07 Mar 2012 10:16:11 +0100
Jean-Marc Desperrier wrote:
> The Android model is broken, but so was the permission pop-up model.
A good default determined by authors with the system highlighting the
Jean-Marc Desperrier wrote:
> The Android model is broken, but so was the permission pop-up model.
more dangerous ones requested but also maximising user configurability
and overrides is always best, similar to defaults, preferences, advanced
but also about:config.
It would also be good to have a blacklist of permissions revoked from
all apps or groups of apps.
Of course adding all this may add to complexity and the likelyhood of
permission escaping bugs.
Jean-Marc Desperrier
Mar 7, 2012, 7:19:33 AM3/7/12
to mozilla-de...@lists.mozilla.org
Jean-Marc Desperrier a écrit :
> [...]
I'll try to illustrate this with a few concrete possibilities.
Let's first try to figure more in detail how to make this work for the
basic contacts *access* module :
- It's a module that allows to *access* contacts, and whose interface is
safe enough that any application can use it
(even if it may have to list it in it's description)
- It allows the application only to obtain an opaque contact element.
After being called, the module takes care of displaying the list of
contact, letting the user select one (or enter the data for a new one),
with an input option that says if several contact can be selected.
* the received contact will be opaque and the application will have no
idea about what it contains
* the application will have to tell before calling the module what it
intends to do with the contact, send SMS, send email, make a phone call.
It both allows to properly filter the contact list, and inform the user
about what he selects a contact for
* we need several other APIs to be able to take the opaque contact as
input :
- SMS sending API
- Mail sending API
- phone call API
In fact I think they should *only* allow opaque contact, and *not* let
the application send an SMS, make a phone call to a phone number, mail
address that has not been explicitly selected by the user. For mail we
need to think about the case where the app needs to be able to "phone
home", but even "phoning home" is a sensible operation (it's easy to use
"home" just as a gateway to go anywhere else).
* We may decide to taint the opaque contact after use.
Either it can be used only once, and the user will be asked to one again
the next time, or the "xxx sending" API will use that tainting to know
they need to not transparently use the contact the next time.
However as said earlier, the confirmation pop-up model needs to be
avoided as much as possible. It may be that the best solution is to
provide a control element that can be integrated inside the GUI of the
app, loaded with the opaque contact information, and that the user has
to interact with to allow the action.
The purpose here is to avoid the model where the user first select
something in the application and then gets a pop-up.
So we provide that element whose selection will imply the consent of the
user, but this means that the application must not have a full control
of what it looks like. We are actually here very near the <input
type="file"> model, where the web page only includes that tag, and can
not fully control how it will look, and also just like a native app does
not fully control the appearance of the interface's native control elements.
Obviously that security model is a really demanding model for the
interface/API designer. It replaces the usual way of providing a list of
low level API call, and getting away with the security problem by just
saying the user will have to approve the app to use them, with something
that requires very significant effort from the API designer to be smart
enough to provide something that's both secure, but also versatile
enough to cover all the actual use case, not forgetting any of them.
However it's not really surprising that a good solution is hard, and
it's better if it's hard at the initial step, for the designer of the
solution, than if it's hard for the user. Or even, that if it's quite
obviously very broken for the suer.
> [...]
> So what is needed IMO :
> - Find a way to not ask the user at all
> To get that :
> - don't give the application access to no-GUI API layer that they can abuse
> - give them access to an entry point that controls the GUI of the
> sensible part
> - allows an application to call an interface with a GUI only when it has
> focus
> - opaque elements are a good pivot to make this work. They can render
> safe something that would be very dangerous if not opaque.
>
> [...]
> - Find a way to not ask the user at all
> To get that :
> - don't give the application access to no-GUI API layer that they can abuse
> - give them access to an entry point that controls the GUI of the
> sensible part
> - allows an application to call an interface with a GUI only when it has
> focus
> - opaque elements are a good pivot to make this work. They can render
> safe something that would be very dangerous if not opaque.
>
I'll try to illustrate this with a few concrete possibilities.
Let's first try to figure more in detail how to make this work for the
basic contacts *access* module :
- It's a module that allows to *access* contacts, and whose interface is
safe enough that any application can use it
(even if it may have to list it in it's description)
- It allows the application only to obtain an opaque contact element.
After being called, the module takes care of displaying the list of
contact, letting the user select one (or enter the data for a new one),
with an input option that says if several contact can be selected.
* the received contact will be opaque and the application will have no
idea about what it contains
* the application will have to tell before calling the module what it
intends to do with the contact, send SMS, send email, make a phone call.
It both allows to properly filter the contact list, and inform the user
about what he selects a contact for
* we need several other APIs to be able to take the opaque contact as
input :
- SMS sending API
- Mail sending API
- phone call API
In fact I think they should *only* allow opaque contact, and *not* let
the application send an SMS, make a phone call to a phone number, mail
address that has not been explicitly selected by the user. For mail we
need to think about the case where the app needs to be able to "phone
home", but even "phoning home" is a sensible operation (it's easy to use
"home" just as a gateway to go anywhere else).
* We may decide to taint the opaque contact after use.
Either it can be used only once, and the user will be asked to one again
the next time, or the "xxx sending" API will use that tainting to know
they need to not transparently use the contact the next time.
However as said earlier, the confirmation pop-up model needs to be
avoided as much as possible. It may be that the best solution is to
provide a control element that can be integrated inside the GUI of the
app, loaded with the opaque contact information, and that the user has
to interact with to allow the action.
The purpose here is to avoid the model where the user first select
something in the application and then gets a pop-up.
So we provide that element whose selection will imply the consent of the
user, but this means that the application must not have a full control
of what it looks like. We are actually here very near the <input
type="file"> model, where the web page only includes that tag, and can
not fully control how it will look, and also just like a native app does
not fully control the appearance of the interface's native control elements.
Obviously that security model is a really demanding model for the
interface/API designer. It replaces the usual way of providing a list of
low level API call, and getting away with the security problem by just
saying the user will have to approve the app to use them, with something
that requires very significant effort from the API designer to be smart
enough to provide something that's both secure, but also versatile
enough to cover all the actual use case, not forgetting any of them.
However it's not really surprising that a good solution is hard, and
it's better if it's hard at the initial step, for the designer of the
solution, than if it's hard for the user. Or even, that if it's quite
obviously very broken for the suer.
Jean-Marc Desperrier
Mar 7, 2012, 7:26:13 AM3/7/12
to mozilla-de...@lists.mozilla.org
Kevin Chadwick a écrit :
the user, letting him configure, lalala ...
Take a page form Apple's handbook : make it *just* *work*.
*You* have to tackle the very difficult issue of finding a way so that
it *just* *works*, don't try to pass the buck to the user.
> the system highlighting the
> more dangerous ones requested but also maximising user configurability
> and overrides is always best
No, you're still dodging the difficult part by providing information to
> more dangerous ones requested but also maximising user configurability
> and overrides is always best
the user, letting him configure, lalala ...
Take a page form Apple's handbook : make it *just* *work*.
*You* have to tackle the very difficult issue of finding a way so that
it *just* *works*, don't try to pass the buck to the user.
Adrienne Porter Felt
Mar 7, 2012, 10:03:02 AM3/7/12
to mozilla-de...@lists.mozilla.org
>
> No, you're still dodging the difficult part by providing information to
> the user, letting him configure, lalala ...
>
> Take a page form Apple's handbook : make it *just* *work*.
>
> *You* have to tackle the very difficult issue of finding a way so that it
> *just* *works*, don't try to pass the buck to the user.
That's not Apple's approach. Apple's approach is to have reviewers check
> No, you're still dodging the difficult part by providing information to
> the user, letting him configure, lalala ...
>
> Take a page form Apple's handbook : make it *just* *work*.
>
> *You* have to tackle the very difficult issue of finding a way so that it
> *just* *works*, don't try to pass the buck to the user.
that apps work the way they seem like they should. Also, if you've seen
the news lately -- sometimes people end up very unhappy when their
photos/contacts/etc. end up silently leaving the phone.
Kevin Chadwick
Mar 7, 2012, 11:44:49 AM3/7/12
to dev-se...@lists.mozilla.org
On Wed, 07 Mar 2012 13:26:13 +0100
Jean-Marc Desperrier wrote:
> > the system highlighting the
> > more dangerous ones requested but also maximising user configurability
> > and overrides is always best
>
Jean-Marc Desperrier wrote:
> > the system highlighting the
> > more dangerous ones requested but also maximising user configurability
> > and overrides is always best
>
> No, you're still dodging the difficult part by providing information to
> the user, letting him configure, lalala ...
>
> Take a page form Apple's handbook : make it *just* *work*.
>
> *You* have to tackle the very difficult issue of finding a way so that
> it *just* *works*, don't try to pass the buck to the user.
You misunderstand me. I'm not saying make the user decide. I'm saying
> the user, letting him configure, lalala ...
>
> Take a page form Apple's handbook : make it *just* *work*.
>
> *You* have to tackle the very difficult issue of finding a way so that
> it *just* *works*, don't try to pass the buck to the user.
inform and decide for the user but give the more concerned user absolute
control with the fine grained ability for revocation that is currently
lacking in implementations.
Kevin Chadwick
Mar 7, 2012, 11:52:05 AM3/7/12
to dev-se...@lists.mozilla.org
On Tue, 6 Mar 2012 18:28:15 -0800
Adrienne Porter Felt wrote:
> For example, there is relatively little risk attached to
> letting an app turn your Bluetooth on or off.
How about a local app introduced via qr code phishing switching
Adrienne Porter Felt wrote:
> For example, there is relatively little risk attached to
> letting an app turn your Bluetooth on or off.
it on and then a stack exploit by a local attacker or attackers device
getting root. What about bluetooth malware and the bugs in the
bluetooth stack. Bluetooth is an operating system feature that
unfortunately nautilus from the Gnome desktop depends on being
installed, when it shouldn't. Google may want the browser to be the OS
but >70% of the population never will, it's a foolish strategy for any
device that does more than web browsing (which is a useful device) even
with sandboxes and everything else they can dream up. Many security
specialist have said the modern web browser is already too much of a
bloated umbrella and they are right.
I've heard of an android app just ensuring all radio is off in case the
person is in an area banning all wireless comms, it may also form part
of a companies security policy.
I'm glad there are the permissions in Android especially if they were
more fine grained mainly to determine a non hacking apps intentions but
really the permission model in Android is more of a false sense of
security than a security feature, which is worse than no security
for those who don't realise it can be bypassed similar to apples store
where they tell people they audit apps.
If the web ever comes to us instead of us going to the web it will need
policing as seriously as email. Who knows maybe plain text web will
come along. (Joking, of course)
Adrienne Porter Felt
Mar 7, 2012, 12:26:31 PM3/7/12
to Kevin Chadwick, dev-se...@lists.mozilla.org
On Wed, Mar 7, 2012 at 8:52 AM, Kevin Chadwick <ma1l...@yahoo.co.uk>wrote:
> On Tue, 6 Mar 2012 18:28:15 -0800
> Adrienne Porter Felt wrote:
>
> > For example, there is relatively little risk attached to
> > letting an app turn your Bluetooth on or off.
>
> How about a local app introduced via qr code phishing switching
> it on and then a stack exploit by a local attacker or attackers device
> getting root. What about bluetooth malware and the bugs in the
> bluetooth stack.
That is a problem that the system itself needs to handle, via system design
> On Tue, 6 Mar 2012 18:28:15 -0800
> Adrienne Porter Felt wrote:
>
> > For example, there is relatively little risk attached to
> > letting an app turn your Bluetooth on or off.
>
> How about a local app introduced via qr code phishing switching
> it on and then a stack exploit by a local attacker or attackers device
> getting root. What about bluetooth malware and the bugs in the
> bluetooth stack.
and hardening. Users need to be able to assume that his or her device
works like it is supposed to (e.g., granting access to location will not
also accidentally grant access to the mic), otherwise permissions are
meaningless. If any privilege can be used to get any other privilege, then
how can you ever make a decision? Certainly there will be privilege
escalation bugs but it is the responsibility of the platform vendor to find
and fix them, not the responsibility of the user to plan ahead for them.
Kevin Chadwick
Mar 7, 2012, 3:26:00 PM3/7/12
to dev-se...@lists.mozilla.org
On Wed, 7 Mar 2012 09:26:31 -0800
Assumption is the mother of all ???? ups
In fact, most security books say users should assume that anyone can
access anything on an online computer. The leave it off and bury it
sentiment goes a bit far though, despite tempest attacks.
> If any privilege can be used to get any other privilege, then
> how can you ever make a decision? Certainly there will be privilege
> escalation bugs but it is the responsibility of the platform vendor to find
> and fix them, not the responsibility of the user to plan ahead for them.
That's true, but unfortunately it is quite ineffective. Certain
permissions will be far more easily exploited or have greater potential
consequences than others and the user needs to be given all the tools
for an easy life, both through the ability of a user to secure and
allowing a user to not give a ???? about what the browser is doing or
not being able to make any risk based decision.
This reinforces the fact that priviledges need to be fine grained and
definable by the user even if they are sane by default and hidden by
default and chosen by authors of apps but with warnings for a select
few more concerning permissions or domains the user has not chosen to
visit. Developers cannot please everyone and also want an easy life,
mandating riskier setups.
Personally I don't think any browser app should be able to or want to
turn bluetooth on/off as turning bluetooth on is a security risk which
could end with a machine being owned. A browser that could switch
wireless on or off without being exploited wouldn't touch my
radio free networks, that's for sure.
A couple of other examples where users may reduce default permissions
for a less risky setup, possibly because they simply will never need
those permissions but others might. Note that most people would think
disabling these was pointless and devs are right to enable them by
default.
______________________________________________________________________
IPV4 only network
Ipv6 is less secure than ipv4 (The brilliant OpenBSD based on code from
your establishment has one of it's two only remote holes attributed to
ipv6, cisco routers have had more than one exploit but that's no
surprise and a recent paper highlights many concerns with ipv6).
firefox enables ipv6 but lets you disable it through about:config.
You can also ultimately disable it through blacklisting the kernel
module and firewalls but I currently see no point in making hardening
harder or why anything other than the OS UI would need to control
bluetooths on/off state.
______________________________________________________________________
All Gentoo hardened users have to recompile firefox for it to run with
their hardened kernel due to a feature most people simply don't use.
I've switched to Opera as I don't wish to waste time and cpu
cycles compiling firefox and firefox depends upon being able to run Java
Just In Time Executions that the grsecurity patch blocks by default to
prevent simultaneously writeable and executable areas of memory. If I
have no need for JIT, I shouldn't have to have it enabled.
_______________________________________________________________________
Minimising and seperating priviledges is key to security. Why on earth
firefox needs IPC dbus just to write a config file and run is bad
overly complicated design. Hopefully designing this permission system
will improve these things.
Adrienne Porter Felt wrote:
> > > For example, there is relatively little risk attached to
> > > letting an app turn your Bluetooth on or off.
> >
> > How about a local app introduced via qr code phishing switching
> > it on and then a stack exploit by a local attacker or attackers device
> > getting root. What about bluetooth malware and the bugs in the
> > bluetooth stack.
>
>
> That is a problem that the system itself needs to handle, via system design
> and hardening. Users need to be able to assume that his or her device
> works like it is supposed to (e.g., granting access to location will not
> also accidentally grant access to the mic), otherwise permissions are
> meaningless.
Sorry to be obtuse but I standby the following sentiment.
> > > For example, there is relatively little risk attached to
> > > letting an app turn your Bluetooth on or off.
> >
> > How about a local app introduced via qr code phishing switching
> > it on and then a stack exploit by a local attacker or attackers device
> > getting root. What about bluetooth malware and the bugs in the
> > bluetooth stack.
>
>
> That is a problem that the system itself needs to handle, via system design
> and hardening. Users need to be able to assume that his or her device
> works like it is supposed to (e.g., granting access to location will not
> also accidentally grant access to the mic), otherwise permissions are
> meaningless.
Assumption is the mother of all ???? ups
In fact, most security books say users should assume that anyone can
access anything on an online computer. The leave it off and bury it
sentiment goes a bit far though, despite tempest attacks.
> If any privilege can be used to get any other privilege, then
> how can you ever make a decision? Certainly there will be privilege
> escalation bugs but it is the responsibility of the platform vendor to find
> and fix them, not the responsibility of the user to plan ahead for them.
permissions will be far more easily exploited or have greater potential
consequences than others and the user needs to be given all the tools
for an easy life, both through the ability of a user to secure and
allowing a user to not give a ???? about what the browser is doing or
not being able to make any risk based decision.
This reinforces the fact that priviledges need to be fine grained and
definable by the user even if they are sane by default and hidden by
default and chosen by authors of apps but with warnings for a select
few more concerning permissions or domains the user has not chosen to
visit. Developers cannot please everyone and also want an easy life,
mandating riskier setups.
Personally I don't think any browser app should be able to or want to
turn bluetooth on/off as turning bluetooth on is a security risk which
could end with a machine being owned. A browser that could switch
wireless on or off without being exploited wouldn't touch my
radio free networks, that's for sure.
A couple of other examples where users may reduce default permissions
for a less risky setup, possibly because they simply will never need
those permissions but others might. Note that most people would think
disabling these was pointless and devs are right to enable them by
default.
______________________________________________________________________
IPV4 only network
Ipv6 is less secure than ipv4 (The brilliant OpenBSD based on code from
your establishment has one of it's two only remote holes attributed to
ipv6, cisco routers have had more than one exploit but that's no
surprise and a recent paper highlights many concerns with ipv6).
firefox enables ipv6 but lets you disable it through about:config.
You can also ultimately disable it through blacklisting the kernel
module and firewalls but I currently see no point in making hardening
harder or why anything other than the OS UI would need to control
bluetooths on/off state.
______________________________________________________________________
All Gentoo hardened users have to recompile firefox for it to run with
their hardened kernel due to a feature most people simply don't use.
I've switched to Opera as I don't wish to waste time and cpu
cycles compiling firefox and firefox depends upon being able to run Java
Just In Time Executions that the grsecurity patch blocks by default to
prevent simultaneously writeable and executable areas of memory. If I
have no need for JIT, I shouldn't have to have it enabled.
_______________________________________________________________________
Minimising and seperating priviledges is key to security. Why on earth
firefox needs IPC dbus just to write a config file and run is bad
overly complicated design. Hopefully designing this permission system
will improve these things.
Kevin Chadwick
Mar 7, 2012, 5:58:37 AM3/7/12
to dev-se...@lists.mozilla.org
On Tue, 6 Mar 2012 18:28:15 -0800
people they audit apps.
It's already annoying how firefox depends on dbus and requires Java Just
In Time executions being permitted just to run. IPC required! just to
write a config file and JIT well just because no one realised it's a
dangerous practice that many may want to avoid, I guess. Opera seem? to
have realised it.
Adrienne Porter Felt wrote:
> For example, there is relatively little risk attached to
> letting an app turn your Bluetooth on or off.
Are you nuts, how about a local app via qr code phishing switching
> For example, there is relatively little risk attached to
> letting an app turn your Bluetooth on or off.
it on and then a stack exploit by a local attacker or attackers device
getting root. Never heard of drive by bluetooth malware and the bugs in
the bluetooth stack. Bluetooth is an operating system feature that
unfortunately nautilus from the Gnome desktop depends on being
installed, when it shouldn't. Google may want the browser to be the OS
but >70% of the population never will, it's a foolish strategy for any
device that does more than web browsing (which is a useful device) even
with sandboxes and everything else they can dream up.
unfortunately nautilus from the Gnome desktop depends on being
installed, when it shouldn't. Google may want the browser to be the OS
but >70% of the population never will, it's a foolish strategy for any
device that does more than web browsing (which is a useful device) even
with sandboxes and everything else they can dream up.
I've heard of an android app just ensuring all radio is off in case the
person is in an area banning all wireless comms, it may also form part
of a companies security policy.
I'm glad there are the permissions in Android especially if they were
more fine grained mainly to determine a non hacking apps intentions but
really the permission model in Android is more of a false sense of
security than a security feature, which is worse than no security
to those who don't realise that just like apples store where they tell
person is in an area banning all wireless comms, it may also form part
of a companies security policy.
I'm glad there are the permissions in Android especially if they were
more fine grained mainly to determine a non hacking apps intentions but
really the permission model in Android is more of a false sense of
security than a security feature, which is worse than no security
people they audit apps.
It's already annoying how firefox depends on dbus and requires Java Just
In Time executions being permitted just to run. IPC required! just to
write a config file and JIT well just because no one realised it's a
dangerous practice that many may want to avoid, I guess. Opera seem? to
have realised it.
Jim Straus
Mar 8, 2012, 1:35:46 PM3/8/12
to Adrienne Porter Felt, dev-w...@lists.mozilla.org, Matthew S. Finifter, Fabrice Desré, Ben Francis, Lucas Adamski, Mozilla B2G mailing list, dev-se...@lists.mozilla.org, Adam Barth
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:
>
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.
>
> 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
> 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.
>
Zack Weinberg
Mar 8, 2012, 8:43:28 PM3/8/12
to mozilla-de...@lists.mozilla.org
I'd like to mention a specific case where the Android scheme fails
catastrophically: Lots of apps ask for permission to "modify and delete
USB storage contents" (that's from memory, the exact phrase may be
different). This _sounds_ really scary, and it is: IIUC apps with that
privilege _could_ completely erase the USB-visible storage if they
wanted. What most of those apps actually _need_ is the ability to
_create some files_ on the USB storage, and then possibly delete _those_
files later. That could be enforced (perhaps not with OS-level file
permissions given that we seem to still be stuck with FAT for USB
storage, but certainly by the B2G monitor) and that could be described
in a far less scary way.
It is, of course, even better if the monitor can infer user intention to
allow an app to create, update, or delete a _specific file_ from user
actions, powerbox-style.
zw
catastrophically: Lots of apps ask for permission to "modify and delete
USB storage contents" (that's from memory, the exact phrase may be
different). This _sounds_ really scary, and it is: IIUC apps with that
privilege _could_ completely erase the USB-visible storage if they
wanted. What most of those apps actually _need_ is the ability to
_create some files_ on the USB storage, and then possibly delete _those_
files later. That could be enforced (perhaps not with OS-level file
permissions given that we seem to still be stuck with FAT for USB
storage, but certainly by the B2G monitor) and that could be described
in a far less scary way.
It is, of course, even better if the monitor can infer user intention to
allow an app to create, update, or delete a _specific file_ from user
actions, powerbox-style.
zw
Jonas Sicking
Mar 9, 2012, 11:44:20 PM3/9/12
to Jim Straus, dev-w...@lists.mozilla.org, Matthew S. Finifter, Fabrice Desré, Ben Francis, Lucas Adamski, dev-se...@lists.mozilla.org, Adam Barth, Adrienne Porter Felt, Mozilla B2G mailing list
2012/3/8 Jim Straus <jst...@mozilla.com>:
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
> 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
> 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.
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.
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.
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.
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.
"prompt user when used", then that should enable the user to be to see
when a given capability is used.
/ Jonas
lkcl luke
Mar 9, 2012, 11:56:48 PM3/9/12
to Jonas Sicking, dev-w...@lists.mozilla.org, Matthew S. Finifter, Jim Straus, Ben Francis, Lucas Adamski, Mozilla B2G mailing list, dev-se...@lists.mozilla.org, Adam Barth, Adrienne Porter Felt, Fabrice Desré
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.
> 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.
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".
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
Mar 11, 2012, 9:43:04 AM3/11/12
to lkcl luke, dev-w...@lists.mozilla.org, Fabrice Desré, Matthew S. Finifter, Jim Straus, Ben Francis, Lucas Adamski, Mozilla B2G mailing list, dev-se...@lists.mozilla.org, Adam Barth, Adrienne Porter Felt, Jonas Sicking
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.
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
Mar 11, 2012, 9:48:55 AM3/11/12
to Dean Landolt, dev-w...@lists.mozilla.org, Fabrice Desré, Matthew S. Finifter, Jim Straus, Ben Francis, Lucas Adamski, Mozilla B2G mailing list, dev-se...@lists.mozilla.org, Adam Barth, Adrienne Porter Felt, Jonas Sicking
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
> 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.
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
Mar 11, 2012, 10:54:52 PM3/11/12
to Jim Straus, dev-w...@lists.mozilla.org, Matthew S. Finifter, Fabrice Desré, Ben Francis, Lucas Adamski, Mozilla B2G mailing list, dev-se...@lists.mozilla.org, Adam Barth
>
> 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
> 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.
>
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
Mar 12, 2012, 1:04:29 PM3/12/12
to lkcl luke, dev-w...@lists.mozilla.org, Matthew S. Finifter, dev-se...@lists.mozilla.org, Fabrice Desré, Ben Francis, Lucas Adamski, Mozilla B2G mailing list, Dean Landolt, Adam Barth, Jonas Sicking, Adrienne Porter Felt, Jim Straus
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
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
ianG
Mar 12, 2012, 7:40:57 PM3/12/12
to dev-se...@lists.mozilla.org
On 13/03/12 04:04 AM, Chris Lee wrote:
> 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.
I'm missing an introduction to the business problem, and a set of
> 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.
requirements. Are they written down as yet? Or is this round table,
totally unstructured?
iang
PS: +1 to lkcl luke
David Chan
Mar 12, 2012, 8:09:09 PM3/12/12
to Chris Lee, dev-w...@lists.mozilla.org, Jim Straus, Dean Landolt, Matthew S. Finifter, Fabrice Desré, lkcl luke, Ben Francis, Lucas Adamski, Jonas Sicking, dev-se...@lists.mozilla.org, Adam Barth, Adrienne Porter Felt, Mozilla B2G mailing list
Hi all,
I took a stab at summarizing some of the points made in the thread. The wiki page can be found here
https://wiki.mozilla.org/Apps/Security
There is likely many things missing from the wiki page and the requirements are probably incomplete. Please correct any errors I have made on positions you argued for.
David Chan
----- Original Message -----
> From: "Chris Lee" <cl...@mozilla.com>
> To: "lkcl luke" <luke.l...@gmail.com>
> Cc: dev-w...@lists.mozilla.org, "Matthew S. Finifter" <fini...@cs.berkeley.edu>, dev-se...@lists.mozilla.org,
> "Fabrice Desré" <fab...@mozilla.com>, "Ben Francis" <b...@krellian.com>, "Lucas Adamski" <lada...@mozilla.com>,
> "Mozilla B2G mailing list" <dev...@lists.mozilla.org>, "Dean Landolt" <de...@deanlandolt.com>, "Adam Barth"
> <abarth-...@adambarth.com>, "Jonas Sicking" <jo...@sicking.cc>, "Adrienne Porter Felt" <a...@berkeley.edu>, "Jim
> Straus" <jst...@mozilla.com>
> Sent: Monday, March 12, 2012 10:04:29 AM
> Subject: Re: [b2g] Permissions model thoughts
>
> 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.
>
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
>
I took a stab at summarizing some of the points made in the thread. The wiki page can be found here
https://wiki.mozilla.org/Apps/Security
There is likely many things missing from the wiki page and the requirements are probably incomplete. Please correct any errors I have made on positions you argued for.
David Chan
----- Original Message -----
> From: "Chris Lee" <cl...@mozilla.com>
> To: "lkcl luke" <luke.l...@gmail.com>
> Cc: dev-w...@lists.mozilla.org, "Matthew S. Finifter" <fini...@cs.berkeley.edu>, dev-se...@lists.mozilla.org,
> "Fabrice Desré" <fab...@mozilla.com>, "Ben Francis" <b...@krellian.com>, "Lucas Adamski" <lada...@mozilla.com>,
> "Mozilla B2G mailing list" <dev...@lists.mozilla.org>, "Dean Landolt" <de...@deanlandolt.com>, "Adam Barth"
> <abarth-...@adambarth.com>, "Jonas Sicking" <jo...@sicking.cc>, "Adrienne Porter Felt" <a...@berkeley.edu>, "Jim
> Straus" <jst...@mozilla.com>
> Sent: Monday, March 12, 2012 10:04:29 AM
> Subject: Re: [b2g] Permissions model thoughts
>
> 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.
>
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
>
ianG
Mar 12, 2012, 8:45:05 PM3/12/12
to dev-se...@lists.mozilla.org
On 13/03/12 11:09 AM, David Chan wrote:
> Hi all,
>
> I took a stab at summarizing some of the points made in the thread. The wiki page can be found here
> https://wiki.mozilla.org/Apps/Security
Thanks.
> Hi all,
>
> I took a stab at summarizing some of the points made in the thread. The wiki page can be found here
> https://wiki.mozilla.org/Apps/Security
> There is likely many things missing from the wiki page and the requirements are probably incomplete. Please correct any errors I have made on positions you argued for.
the lines, it seems to be "we want to build a store/marketplace like
Apple or Android stores."
If that's the case, for what client profiles? As in, is this Firefox
plugins on Androids? Or?
Or is there some other business need happening here?
>> 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.
iang
0 new messages