Re: Adding Privacy to WebApps Permissions Security Model

[Paul Theriault]

Sid,

Afaik, the current thinking in B2G (afaik) is to for apps to request
permissions by specifying a list of desired permissions in the manifest.
There has been talk of a "reason" field, which would accompany each
permission for basically the purposes you describe.

I think this could be a useful feature for app reviewers (be it
marketplace staff, community members, or just security/privacy minded
users). We would need to implement it in such a way that it could not be
used as a social engineering mechanism though. For example, if we just
presented a dialog with the permission and reason together, the app
could seek to confuse the user. For example, your stashy camera app
might try to trick the user into giving access to the address book by
prompting something like "Permission: Addressbook, Reason: Allow your
camera to take photos. We need to make sure the permission being
granted is clear.

But I do see the value per your points below, so i think we should have
a manifest format that supports this, and then figure out where and how
this information is presented. And also what to do when this information
isn't available.

Regards,
Paul


On 5/23/12 8:31 AM, Sid Stamm wrote:
> Hey All,
>
> tl;dr: Apps should also explain how they'll use data from various
> permissions (like access to your contacts) since use of capabilities
> varies so much across apps.
>
> The Apps Permission Security model sets forth mechanisms by which users
> can allow or deny these capabilities to apps (and includes mechanisms to
> ensure that users make informed choices that are not burdonsome).
>
> While the security model facilitates access control for these
> capabilities, it does not dictate what the apps do with data obtained
> from these capabilities.
>
> EXAMPLE: Perhaps an app, Stashy, may be granted access to my device's
> camera, but the B2G security model won't restrict what the app does with
> the bits that come from the camera sensor. These bits could be recorded
> and shipped off to the app's server at stashy.com and later used to
> identify me as I walk past other cameras controlled by the app developers.
>
> Everywhere the security model engages with its user, we can provide an
> opportunity for apps to represent their *usage intentions* to the user.
> This can be considered a commitment for limited data use by the app
> developers.
>
> I'd like to propose an update to the security model Lucas has been
> guiding through discussion[0]. Specifically, I'd like to add to the
> application permissions model so apps not only ask for permission to use
> various capabilities, but also explain their intended use of the data
> they gain from such access. I'm calling these "usage intentions".
>
> EXAMPLE: The same Stashy app in the previous example requests permission
> to use the camera in my device, and includes a usage intention that says
> "we will edit the camera video stream to paint a mustache on your face
> and display the composite image on your device's screen -- we won't
> record photos or videos from your camera." When the user is asked to
> authorize this capability for the app, he is shown to what the app wants
> to *access* but also *why*.
>
> Ways this can improve users' privacy:
>
> == On the Hook ==
> Apps that make promises via usage intentions have essentially provided
> assurance to the user that their data will be used in a certain way. If
> it turns out the app developers use the data for another purpose (say
> actually recording Stashy photos and posting them on a public twitter
> feed), users have a clear way to explain how the app is operating
> deceptively.
>
> == Pre-Validation with Privacy Policies ==
> Many apps will have a privacy policy. An app store has the opportunity
> to pre-screen apps based on the usage intentions in their manifest and
> the privacy policy they provide. So long as the two are consistent,
> users have a commitment from the app about what it intends to do with
> their data. Apps that are not consistent or vague can be rejected from
> an app store.
>
> == Auditing ==
> To provide a "trail of activity", B2G or other app runtime could
> additionally maintain a capability-access log for each app that keeps
> track of requests for capabilities and the usage intentions over time.
> That way a curious user could analyze the log to see how often an app
> used a permission, why it used it, and perhaps help illustrate abuse of
> their consent.
>
> What do you think?
>
> -Sid
>
> [0] https://wiki.mozilla.org/Apps/Security/Discussion
>
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps

[Lucas Adamski]

More than talk, it's already in the app security model (under https://wiki.mozilla.org/Apps/Security#Permission_prompting_mechanisms). Probably could do a better job of calling it out.

Whats interesting is that it does not provide any consistent way to notify the user about privacy-sensitive interactions that aren't API related. For example, if an app requests access to your Facebook account, the rationale for that request is not in scope for the current model, and maybe it should be.
Lucas.

[Matthew S. Finifter]

I think this is a great idea. To make it simpler for both developers and
users, you may consider using some standardized form for presenting the
information. In other words, do not allow arbitrary text descriptions of
how the data will be used, but instead use something like a "nutrition
label" that expresses a privacy policy in a standardized form.

For more information about this, as well as the results of user studies in
which a group researchers had some success with web site privacy policies,
see this paper:

http://cups.cs.cmu.edu/soups/2009/proceedings/a4-kelley.pdf

- Matt Finifter

[Sid Stamm]

On 5/22/12 10:39 PM, Paul Theriault wrote:
> Sid,
>
> Afaik, the current thinking in B2G (afaik) is to for apps to request
> permissions by specifying a list of desired permissions in the manifest.
> There has been talk of a "reason" field, which would accompany each
> permission for basically the purposes you describe.

This is great. We need to emphasize that "Reason" should be used to
explain what the app will do with data obtained from the API. A
"Reason" that doesn't fit this use is, for example, "we need camera to
capture video". An appropriate usage intention for a "mirror" app would
be "we need camera, we will do live stream editing and not store video."

The difference is subtle, but important.

> I think this could be a useful feature for app reviewers (be it
> marketplace staff, community members, or just security/privacy minded
> users). We would need to implement it in such a way that it could not be
> used as a social engineering mechanism though. For example, if we just
> presented a dialog with the permission and reason together, the app
> could seek to confuse the user. For example, your stashy camera app
> might try to trick the user into giving access to the address book by
> prompting something like "Permission: Addressbook, Reason: Allow your
> camera to take photos. We need to make sure the permission being
> granted is clear.

Yeah, this would be bad. One option (off the top of my head) might be
to avoid displaying reasons for apps whose manifests haven't been vetted
by app store reviewers -- but they would still be in the manifest for
inspection by advanced users.

> But I do see the value per your points below, so i think we should have
> a manifest format that supports this, and then figure out where and how
> this information is presented. And also what to do when this information
> isn't available.

I think we should require app manifests to have this in order to be
granted permissions.

The problem I see is in localizing these strings. Admittedly, I haven't
followed this discussion as much as I should have. Is there a strategy
for providing localized "reason" strings to present users?

-Sid

[Lucas Adamski]

On May 23, 2012, at 18:12, Sid Stamm <sst...@mozilla.com> wrote:

> On 5/22/12 10:39 PM, Paul Theriault wrote:

>> Sid,
>>
>> Afaik, the current thinking in B2G (afaik) is to for apps to request
>> permissions by specifying a list of desired permissions in the manifest.
>> There has been talk of a "reason" field, which would accompany each
>> permission for basically the purposes you describe.
>

> This is great. We need to emphasize that "Reason" should be used to
> explain what the app will do with data obtained from the API. A
> "Reason" that doesn't fit this use is, for example, "we need camera to
> capture video". An appropriate usage intention for a "mirror" app would
> be "we need camera, we will do live stream editing and not store video."
>
> The difference is subtle, but important.

Yup, that is the purpose of the "rationale" field but defining how that exactly should be used in the spec is tricky. That's probably the biggest holdup to adding it to the manifest spec.

>> I think this could be a useful feature for app reviewers (be it
>> marketplace staff, community members, or just security/privacy minded
>> users). We would need to implement it in such a way that it could not be
>> used as a social engineering mechanism though. For example, if we just
>> presented a dialog with the permission and reason together, the app
>> could seek to confuse the user. For example, your stashy camera app
>> might try to trick the user into giving access to the address book by
>> prompting something like "Permission: Addressbook, Reason: Allow your
>> camera to take photos. We need to make sure the permission being
>> granted is clear.
>

> Yeah, this would be bad. One option (off the top of my head) might be
> to avoid displaying reasons for apps whose manifests haven't been vetted
> by app store reviewers -- but they would still be in the manifest for
> inspection by advanced users.

Yes, the rationale is only provided for trusted apps. It probably shouldn't be included for untrusted.

>
>> But I do see the value per your points below, so i think we should have
>> a manifest format that supports this, and then figure out where and how
>> this information is presented. And also what to do when this information
>> isn't available.
>

> I think we should require app manifests to have this in order to be
> granted permissions.

It's required for trusted apps.

>
> The problem I see is in localizing these strings. Admittedly, I haven't
> followed this discussion as much as I should have. Is there a strategy
> for providing localized "reason" strings to present users?

Good question, ouch. I'd imagine we have a localization problem with manifests in general.
Lucas.

>
> -Sid

[Ian Bicking]

On Wed, May 23, 2012 at 11:46 AM, Lucas Adamski <lada...@mozilla.com>wrote:

> > The problem I see is in localizing these strings. Admittedly, I haven't
> > followed this discussion as much as I should have. Is there a strategy
> > for providing localized "reason" strings to present users?
>
> Good question, ouch. I'd imagine we have a localization problem with
> manifests in general.

I'm unclear from that document exactly what the manifest would look like
for permissions, but there's a general localization solution for the
manifests. Making up a permission syntax:

{
name: "My creepy app",
permissions: {
"camera": {reason: "To spy on you while you are sleeping"}
},
locales: {
"es": {
permissions: {
"camera": {reason: "Para espiar a usted mientras usted está
durmiendo"}
}
}
},
default_locale: "en-US"
}

Generally we have a whitelist of what locales is allowed to overlay, so it
wouldn't be able to add a new permission, but we'd specifically allow
permissions.*.reason (while making sure that the locale overlay does not
add any new items to the permission list).

[Jim Straus]

In looking in some of the "manifest.webapp"s in gaia, there is a locales section with the localized name and description. That could be extended with localization for the reasons for each of the permissions. The default would be to use the original reason and leave it up to the developer to localize for whatever languages they are supporting.
-Jim Straus

On May 23, 2012, at 12:46 PM, Lucas Adamski wrote:

>
>>
>> The problem I see is in localizing these strings. Admittedly, I haven't
>> followed this discussion as much as I should have. Is there a strategy
>> for providing localized "reason" strings to present users?
>
> Good question, ouch. I'd imagine we have a localization problem with manifests in general.

> Lucas.
>
>>
>> -Sid

[Lucas Adamski]

On May 23, 2012, at 7:06 PM, Jim Straus wrote:

> In looking in some of the "manifest.webapp"s in gaia, there is a locales section with the localized name and description. That could be extended with localization for the reasons for each of the permissions. The default would be to use the original reason and leave it up to the developer to localize for whatever languages they are supporting.
> -Jim Straus

True, so we should use the same convention for the rationale. So some open questions:

- what to name the field? I proposed "Rationale". I think Sid suggested "Usage". The latter sounds good to me.
- length: not a lot of room to communicate in a mobile UI, so the usage would have to be of tweet-length. 128?

- Not directly related to privacy, but since we are talking about updating the manifest should the manifest point explicitly to the appcache for verifying trusted apps?
Lucas.

[Sid Stamm]

On 5/24/12 2:50 AM, Lucas Adamski wrote:
> - what to name the field? I proposed "Rationale". I think Sid
> suggested "Usage". The latter sounds good to me.

I like "Intended Use" or similar -- something that gets to the heart of
what we want: what the app plans to do with access and the data it collects.

> - length: not a lot
> of room to communicate in a mobile UI, so the usage would have to be
> of tweet-length. 128?

Seems reasonable. Twitter went with 140 chars, but I don't know the
rationale for that specific number.

-Sid

[Mounir Lamouri]

On 05/23/2012 06:46 PM, Lucas Adamski wrote:
> Yes, the rationale is only provided for trusted apps. It probably shouldn't be included for untrusted.

A big issue with the Android security model is that you have no idea why
an application is asking for a specific permission so you don't know if
this is for good or bad reasons. Sure, a 'reason' field might not be
true if the app is untrusted but I would prefer that than nothing.

This said, presentation here is the biggest issue. However, the market
place could show the reasons with a big disclaimer, for example.

--
Mounir

[Jim Straus]

A store may not do as much of an audit for an untrusted app but it could at least look at the "reason" fields and make sure they're at least reasonable. There is nothing preventing an app from abusing a permission, but the permissions that are available to untrusted apps are reasonably benign (which is why they are granted to untrusted apps). Even untrusted apps don't have to automatically be accepted to a store if the store finds the reason (or other things) not reasonable.
-Jim Straus

[Mike Hanson]

I would also not undercount the significance of simply forcing the developer to go "on the record" with their intent.

IANAL, but it seems to me that a statement of intent from the developer provides a way for users (and markets) to hold the developer to their claims.

If a developer is later found to have misrepresented its intentions, there could be repercussions - reputation-based, financial, or legal, depending on the terms of use.

-m

On May 29, 2012, at 8:54 AM, Jim Straus wrote:

> A store may not do as much of an audit for an untrusted app but it could at least look at the "reason" fields and make sure they're at least reasonable. There is nothing preventing an app from abusing a permission, but the permissions that are available to untrusted apps are reasonably benign (which is why they are granted to untrusted apps). Even untrusted apps don't have to automatically be accepted to a store if the store finds the reason (or other things) not reasonable.
> -Jim Straus
>
> On May 29, 2012, at 10:45 AM, Mounir Lamouri wrote:
>
>> On 05/23/2012 06:46 PM, Lucas Adamski wrote:
>>> Yes, the rationale is only provided for trusted apps. It probably shouldn't be included for untrusted.
>>
>> A big issue with the Android security model is that you have no idea why
>> an application is asking for a specific permission so you don't know if
>> this is for good or bad reasons. Sure, a 'reason' field might not be
>> true if the app is untrusted but I would prefer that than nothing.
>>
>> This said, presentation here is the biggest issue. However, the market
>> place could show the reasons with a big disclaimer, for example.
>>
>> --
>> Mounir

[Lucas Adamski]

On May 29, 2012, at 7:45 AM, Mounir Lamouri wrote:

> On 05/23/2012 06:46 PM, Lucas Adamski wrote:
>> Yes, the rationale is only provided for trusted apps. It probably shouldn't be included for untrusted.
>
> A big issue with the Android security model is that you have no idea why
> an application is asking for a specific permission so you don't know if
> this is for good or bad reasons. Sure, a 'reason' field might not be
> true if the app is untrusted but I would prefer that than nothing.
>
> This said, presentation here is the biggest issue. However, the market
> place could show the reasons with a big disclaimer, for example.

The reason we display the "intended usage" with trusted apps is that it has been reviewed and approved by an app store (and the developer is at least somewhat authenticated), so that UI can be considered reasonably authoritative. For an untrusted app that space would could easily be used by a bad-guy to trick the user into allowing access, and the user would not understand the different levels of trustworthiness. Disclaimers don't work here (insufficient real estate, and if its really untrustworthy then we shouldn't show it).
Lucas.

[Sid Stamm]

On 05/29/2012 09:30 AM, Mike Hanson wrote:
> I would also not undercount the significance of simply forcing the
> developer to go "on the record" with their intent.
>
> IANAL, but it seems to me that a statement of intent from the
> developer provides a way for users (and markets) to hold the
> developer to their claims.
>
> If a developer is later found to have misrepresented its intentions,
> there could be repercussions - reputation-based, financial, or legal,
> depending on the terms of use.

This is precisely the biggest value I see in adding this, and why I want
to call out the feature specifically for privacy: future accountability.
It can help enable an audit trail for those who want it, and at the
very least, provide something shorter and more accessible than a privacy
policy for app consumers.

-Sid

[Lucas Adamski]

On May 24, 2012, at 7:56 PM, Adrienne Porter Felt wrote:
>
> Malware is going to use other forms of social engineering anyway. Non-
> malware won't lie because of the fear of ramifications. Why not
> include it for untrusted as well? You could design the UI with big
> quotes around it or something to make it clear that it is something
> the developer says, not something the browser/OS says.

Sure, but I'm more comfortable if users get phished the old fashioned way; less so if we enable new and improved ways of doing so. :)

I'm not sure if your example would be accurately interpreted by most users. If the prompt said something like "This developer claims they want to access your <insert API here> for the supposed purposes of <insert rationale here>, but have no idea what they'll actually do with it" would it still be worth having?
Lucas.

[Adrienne Porter Felt]

As it stands, users can only find out what applications do with their data
if they go read a long privacy policy. Consequently, users likely assume
that their data is only being used for the functionality that they see.
For example, consider a game that asks for contacts in the context of
finding friends who also use the same game. Without reading the long
privacy policy, the user has little way of knowing that this app will now
*also* add those contacts' e-mail addresses to their mailing list.

Now imagine that developers had to specify the rationale for their actions
as part of the request. To continue my earlier example, the user would
immediately know that the data would be used for both friend-finding and
spam. Most developers are incentivized to be honest: if they are caught
lying, they'll face civil suits, removal from "official" markets, bad
press, and a decline in popularity.

The odds of encountering outright malware are fairly small, but users
routinely install applications that want to stretch the bounds of data
usage. I'm personally in favor of designing for the much more common case.

Here are some examples from the WWDC iOS 6 demo: http://twitpic.com/9yo9n4.

[Sid Stamm]

Hi All,
I updated the security model wiki page to reflect the things we talked
about in the late-May thread. The changes were pretty minor since, as a
few people pointed out, the underpinnings of the privacy updates were
already considered in the model! Here's a diff:

https://wiki.mozilla.org/index.php?title=Apps/Security&diff=446856&oldid=441197

There are still a few open issues that I think we can easily iron out.

1. For untrusted apps, should we show data usage intentions (rationale)
as permissions are requested? These strings are not reviewed by an app
store, but as Adrienne pointed out, the value may outweigh the risk of
deception.

2. Format of the field in the manifest. I propose the field name be
"Intended Use", and the value be 128 characters (to keep it easy to
read). Sound good?

3. How will users be able to access usage intentions for permissions
that are implicit or for certified apps? Currently they can read the
manifest, but will we build an easier way for them to find 'em at runtime?

4. In the developer documentation, should we provide a suggested
formula for the usage intentions? (e.g., "We want {permission} to
obtain {data type} which we will keep {how long and where kept}") or
should we provide some pre-written examples for each permission? This
may be too difficult to get right, but should we try?


Finally, there's one technical follow-up for the manifest. Does the
below proposal sound like a reasonable approach? I like it.

5. How can these strings be localized into the app runtime's chosen
locale? ianb suggested:
{
name: "Stachy (beta)",
permissions: {
"camera": {usage: "To spy on you while you are sleeping"}
},
locales: {
"es": {
permissions: {
"camera": {usage: "Para espiar a usted mientras usted está
durmiendo"}
}
}
},
default_locale: "en-US"
}

Cheers,
Sid

[ptheriault]

On Jun 30, 2012, at 9:52 AM, Sid Stamm wrote:

> Hi All,
> I updated the security model wiki page to reflect the things we talked
> about in the late-May thread. The changes were pretty minor since, as a
> few people pointed out, the underpinnings of the privacy updates were
> already considered in the model! Here's a diff:
>
> https://wiki.mozilla.org/index.php?title=Apps/Security&diff=446856&oldid=441197
>
> There are still a few open issues that I think we can easily iron out.
>
> 1. For untrusted apps, should we show data usage intentions (rationale)
> as permissions are requested? These strings are not reviewed by an app
> store, but as Adrienne pointed out, the value may outweigh the risk of
> deception.

I tend to agree with Adrienne that the value may outweigh any benefit to a malicious app.

>
> 2. Format of the field in the manifest. I propose the field name be
> "Intended Use", and the value be 128 characters (to keep it easy to
> read). Sound good?
>
> 3. How will users be able to access usage intentions for permissions
> that are implicit or for certified apps? Currently they can read the
> manifest, but will we build an easier way for them to find 'em at runtime?

The current UI for viewing/editing permissions has a brief text description after the setting. Maybe we could also show the "intended use" here somehow, though this may clutter up the current design a little. Also, with the current design (http://people.mozilla.com/~lco/Settings_B2G/Release_1_Specs/R1_Security_and_Privacy_v2.pdf) implicit permissions are not shown (or not as far as I can tell, since they would show as permissions, but mysteriously not be able to be edited).

An simple option might be to add an "advanced details" button to the current permissions page, which links to a page which simply details the information that is in the manifest. This page could be designed in such a way to impart the difference between the explicit and implicit permissions. (to prevent the user from wondering why the implicit permissions don't show up in the "edit permissions" page)

>
> 4. In the developer documentation, should we provide a suggested
> formula for the usage intentions? (e.g., "We want {permission} to
> obtain {data type} which we will keep {how long and where kept}") or
> should we provide some pre-written examples for each permission? This
> may be too difficult to get right, but should we try?

We should definitely provide guidelines/examples I think.

>
>
> Finally, there's one technical follow-up for the manifest. Does the
> below proposal sound like a reasonable approach? I like it.
>
> 5. How can these strings be localized into the app runtime's chosen
> locale? ianb suggested:
> {
> name: "Stachy (beta)",
> permissions: {
> "camera": {usage: "To spy on you while you are sleeping"}
> },
> locales: {
> "es": {
> permissions: {
> "camera": {usage: "Para espiar a usted mientras usted está
> durmiendo"}
> }
> }
> },
> default_locale: "en-US"
> }
>

Are you defining the actual permissions list in multiple places here? (i.e. you switch locales can you get a different set of permissions?) Or is the logic such that the root "permissions" declaration is the one which is used for the list of permissions, and the permissions tags inside the locales are simply used to override the text that is shown in the intended use. I assume the latter, but maybe call the one inside the locales section "permissions_use" or something just to reduce ambiguity?



> Cheers,
> Sid

[Lucas Adamski]

On Jun 30, 2012, at 1:52 AM, Sid Stamm wrote:

> Hi All,
> I updated the security model wiki page to reflect the things we talked
> about in the late-May thread. The changes were pretty minor since, as a
> few people pointed out, the underpinnings of the privacy updates were
> already considered in the model! Here's a diff:
>
> https://wiki.mozilla.org/index.php?title=Apps/Security&diff=446856&oldid=441197
>
> There are still a few open issues that I think we can easily iron out.
>
> 1. For untrusted apps, should we show data usage intentions (rationale)
> as permissions are requested? These strings are not reviewed by an app
> store, but as Adrienne pointed out, the value may outweigh the risk of
> deception.

I think our permission UI should be trustworthy, which means the user should be able to rely upon the information it presents. This falls far short of that.

> 2. Format of the field in the manifest. I propose the field name be
> "Intended Use", and the value be 128 characters (to keep it easy to
> read). Sound good?

Sounds good.

> 3. How will users be able to access usage intentions for permissions
> that are implicit or for certified apps? Currently they can read the
> manifest, but will we build an easier way for them to find 'em at runtime?

We don't intend to exposure implicit permissions to users. Then again, implicit permissions (except for certified apps) should not be privacy impacting things that the user would likely have any understanding of anyway. Our criteria for explicit permissions is basically: things that could put the user's privacy at risk. Modulo low-risk data leakage and persistence (i.e. apps can store more data and for longer than webpages).

> 4. In the developer documentation, should we provide a suggested
> formula for the usage intentions? (e.g., "We want {permission} to
> obtain {data type} which we will keep {how long and where kept}") or
> should we provide some pre-written examples for each permission? This
> may be too difficult to get right, but should we try?

Such a template seems like a good idea but it would have to be validated with a pretty broad set of use cases. It would help with localization too, though.

> Finally, there's one technical follow-up for the manifest. Does the
> below proposal sound like a reasonable approach? I like it.
>
> 5. How can these strings be localized into the app runtime's chosen
> locale? ianb suggested:
> {
> name: "Stachy (beta)",
> permissions: {
> "camera": {usage: "To spy on you while you are sleeping"}
> },
> locales: {
> "es": {
> permissions: {
> "camera": {usage: "Para espiar a usted mientras usted está
> durmiendo"}
> }
> }
> },
> default_locale: "en-US"
> }

Paul brought this up too but it does seem like it would be prone to cut&paste mistakes (resulting in different permissions sets for different locales). Maybe having a single permission list with per-locale usages would work.
Lucas.

[Ian Bicking]

On Mon, Jul 2, 2012 at 5:36 PM, Lucas Adamski <lada...@mozilla.com> wrote:

> > 5. How can these strings be localized into the app runtime's chosen
> > locale? ianb suggested:
> > {
> > name: "Stachy (beta)",
> > permissions: {
> > "camera": {usage: "To spy on you while you are sleeping"}
> > },
> > locales: {
> > "es": {
> > permissions: {
> > "camera": {usage: "Para espiar a usted mientras usted está
> > durmiendo"}
> > }
> > }
> > },
> > default_locale: "en-US"
> > }
>
> Paul brought this up too but it does seem like it would be prone to
> cut&paste mistakes (resulting in different permissions sets for different
> locales). Maybe having a single permission list with per-locale usages
> would work.
>

We already have rules about what a locale can override. In this case we
can say that it can override the usage on a permission, but not add a
permission or change any other properties. Then if you had "es":
{permissions: {camra: {usage: "..."}}} it would either be ignored or signal
a warning.

[Jonas Sicking]

On Mon, Jul 2, 2012 at 3:36 PM, Lucas Adamski <lada...@mozilla.com> wrote:
> On Jun 30, 2012, at 1:52 AM, Sid Stamm wrote:
>
>> Hi All,
>> I updated the security model wiki page to reflect the things we talked
>> about in the late-May thread. The changes were pretty minor since, as a
>> few people pointed out, the underpinnings of the privacy updates were
>> already considered in the model! Here's a diff:
>>
>> https://wiki.mozilla.org/index.php?title=Apps/Security&diff=446856&oldid=441197
>>
>> There are still a few open issues that I think we can easily iron out.
>>
>> 1. For untrusted apps, should we show data usage intentions (rationale)
>> as permissions are requested? These strings are not reviewed by an app
>> store, but as Adrienne pointed out, the value may outweigh the risk of
>> deception.
>
> I think our permission UI should be trustworthy, which means the user should be able to rely upon the information it presents. This falls far short of that.

I am also not a fan of this proposal.

One option might be to put a link there that says something like "The
developer of the application has provided a description of why they
want this permission. Click here to see that description".

When clicked we would replace the whole UI with something that shows
the description as well as a 'back' button.

That way the displayed UI is can be trusted, but if the user takes an
explicit, and fairly clear, action, they can see the description.

/ Jonas

[Sid Stamm]

On 07/03/2012 08:07 PM, Jonas Sicking wrote:
>>> 1. For untrusted apps, should we show data usage intentions (rationale)
>>> as permissions are requested? These strings are not reviewed by an app
>>> store, but as Adrienne pointed out, the value may outweigh the risk of
>>> deception.
>>
>> I think our permission UI should be trustworthy, which means the
>> user should be able to rely upon the information it presents. This
>> falls far short of that.
>
> I am also not a fan of this proposal.
>
> One option might be to put a link there that says something like "The
> developer of the application has provided a description of why they
> want this permission. Click here to see that description".
>
> When clicked we would replace the whole UI with something that shows
> the description as well as a 'back' button.
>
> That way the displayed UI is can be trusted, but if the user takes an
> explicit, and fairly clear, action, they can see the description.

Sounds like we need to treat trusted apps and untrusted apps differently
regarding the usage intentions.

I still think we should require (in the manifest) that the app developer
put something as the usage intention, but we don't have to display it to
users all the time, perhaps doing something like what you suggest here,
Jonas.

Adrienne -- what do you think of this idea?

-Sid

[Adrienne Porter Felt]

On Thu, Jul 5, 2012 at 10:37 AM, Sid Stamm <s...@mozilla.com> wrote:

> On 07/03/2012 08:07 PM, Jonas Sicking wrote:

> >>> 1. For untrusted apps, should we show data usage intentions
> (rationale)
> >>> as permissions are requested? These strings are not reviewed by an app
> >>> store, but as Adrienne pointed out, the value may outweigh the risk of
> >>> deception.
> >>
> >> I think our permission UI should be trustworthy, which means the
> >> user should be able to rely upon the information it presents. This
> >> falls far short of that.
> >
> > I am also not a fan of this proposal.
> >
> > One option might be to put a link there that says something like "The
> > developer of the application has provided a description of why they
> > want this permission. Click here to see that description".
> >
> > When clicked we would replace the whole UI with something that shows
> > the description as well as a 'back' button.
> >
> > That way the displayed UI is can be trusted, but if the user takes an
> > explicit, and fairly clear, action, they can see the description.
>

> Sounds like we need to treat trusted apps and untrusted apps differently
> regarding the usage intentions.
>
> I still think we should require (in the manifest) that the app developer
> put something as the usage intention, but we don't have to display it to
> users all the time, perhaps doing something like what you suggest here,
> Jonas.
>

I like the idea of having a "show more" button* that requires the user to
click on something to see the developer's reason. It seems to meet all the
constraints, plus it avoids cluttering up the prompt with extra text. It
might make sense to do this for both trusted and untrusted apps to avoid
confusing people as to why they sometimes have to click a button (and other
times don't).

It would be really interesting to initially instrument this so that you can
see how many people actually click on it, and whether people who click on
it are more or less likely to approve/deny the request.


*I'm not literally suggesting it should say "show more"

[Lucas Adamski]

On Jun 27, 2012, at 12:09 AM, Adrienne Porter Felt wrote:

> As it stands, users can only find out what applications do with their data
> if they go read a long privacy policy. Consequently, users likely assume
> that their data is only being used for the functionality that they see.
> For example, consider a game that asks for contacts in the context of
> finding friends who also use the same game. Without reading the long
> privacy policy, the user has little way of knowing that this app will now
> *also* add those contacts' e-mail addresses to their mailing list.

No argument there!

> Now imagine that developers had to specify the rationale for their actions
> as part of the request. To continue my earlier example, the user would
> immediately know that the data would be used for both friend-finding and
> spam. Most developers are incentivized to be honest: if they are caught
> lying, they'll face civil suits, removal from "official" markets, bad
> press, and a decline in popularity.
>
> The odds of encountering outright malware are fairly small, but users
> routinely install applications that want to stretch the bounds of data
> usage. I'm personally in favor of designing for the much more common case.

I'm more concerned with overtly malicious apps. The sanctions you mention above don't seem to have significantly dissuaded overtly bad actors from distributing malicious apps on Android devices. If they get a few thousand victims before they get pulled, they are still happy. Having apparently trustworthy UI that something like "this app would like to have your location/picture for the purposes of verifying your Bank of Whatever account information" seems like a serious issue to me. We have always treated security bugs in our chrome UI which let a 3rd party confuse or deceive the user as significantly worse & very different than simply the ability to display deceptive content.

Keep in mind that web installed apps (aka untrusted) don't have to be distributed by any app store, so blocking them is tricky. The ability to blacklist + review process are the two reasons I'm pretty happy to display "intended usage" for trusted apps.
Lucas.

> Here are some examples from the WWDC iOS 6 demo: http://twitpic.com/9yo9n4.
>
>
>
> On Tue, Jun 26, 2012 at 6:45 PM, Lucas Adamski <lada...@mozilla.com> wrote:
>
>> On May 24, 2012, at 7:56 PM, Adrienne Porter Felt wrote:
>>>> Malware is going to use other forms of social engineering anyway. Non-
>>> malware won't lie because of the fear of ramifications. Why not
>>> include it for untrusted as well? You could design the UI with big
>>> quotes around it or something to make it clear that it is something
>>> the developer says, not something the browser/OS says.
>>
>> Sure, but I'm more comfortable if users get phished the old fashioned way;
>> less so if we enable new and improved ways of doing so. :)
>>
>> I'm not sure if your example would be accurately interpreted by most
>> users. If the prompt said something like "This developer claims they want
>> to access your <insert API here> for the supposed purposes of <insert
>> rationale here>, but have no idea what they'll actually do with it" would
>> it still be worth having?
>> Lucas.
>>
>>

[Ian Bicking]

On Thu, Jul 5, 2012 at 6:31 PM, Lucas Adamski <lada...@mozilla.com> wrote:

> > The odds of encountering outright malware are fairly small, but users
> > routinely install applications that want to stretch the bounds of data
> > usage. I'm personally in favor of designing for the much more common
> case.
>
> I'm more concerned with overtly malicious apps. The sanctions you mention
> above don't seem to have significantly dissuaded overtly bad actors from
> distributing malicious apps on Android devices. If they get a few thousand
> victims before they get pulled, they are still happy. Having apparently
> trustworthy UI that something like "this app would like to have your
> location/picture for the purposes of verifying your Bank of Whatever
> account information" seems like a serious issue to me. We have always
> treated security bugs in our chrome UI which let a 3rd party confuse or
> deceive the user as significantly worse & very different than simply the
> ability to display deceptive content.
>

Consider the two cases with a malicious app:

1. Without explanations the install dialog will say something like "this
app wants access to your contact database"
2. With the explanation the install dialog might say something like "this
app wants access to your contact database for the reason: 'to see if any of
your friends are also using the service!'" (or whatever particularly
innocuous claim they can come up with).

In theory with 2 they could be making a claim that is falsely reassuring,
essentially downplaying the extent of what they are asking for. (Though I
would question the ability of such app developers to actually perform this
social engineering competently, given what I've seen elsewhere.) They
could also try to simply confuse the user, perhaps: "this app wants access
to your contact database: 'no access required'" thus confusing the user
into whether they really are giving access or not. On further thought,
simply confusing users seems like the greater danger.

With 1 I believe the danger is that the confirmation dialog is so
hopelessly boring that no one will pay attention to it, and my
understanding is that evidence backs this up* *(as does personal
experience). I think we have a general security problem that confirmation
dialogs do not lead to intelligent decisions on the parts of users, they
only cover our butt because in theory it's the user's fault when they
confirm something they shouldn't have. So I'm a little skeptical of our
conventions here. We do have the opportunity to style the dialog to
visually differentiate between our text and the provided reasons, and there
is some convention around this distinction (and in the end it's all visual
differentiation).

It would be neat if we had a "report this permission" option on that
confirmation dialog – report that the description is nonsensical, that it's
inappropriate for the scope of the app, or that it's used in a way that is
not consistent with the rationale given. Of course you have to figure out
who to report to... which is clear in the case of the Marketplace, but not
for self-install (and it's unclear how much you would trust a third-party
store – we have put up very few barriers to keep people from putting up
fraudulent stores).

Keep in mind that web installed apps (aka untrusted) don't have to be
> distributed by any app store, so blocking them is tricky. The ability to
> blacklist + review process are the two reasons I'm pretty happy to display
> "intended usage" for trusted apps.
>

Trusted apps are just a subset of apps on the Marketplace, right?