Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
WebApps - Types of applications
79 views
Skip to first unread message
Lucas Adamski
Mar 23, 2012, 2:45:47 AM3/23/12
to Mozilla B2G mailing list, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org
== Goal ==
Determine a baseline for the different types of applications in the B2G app ecosystem.
We are not going to evaluate operating system level issues (such as processes sandboxing, OS hardening and updates) just yet, as this part of the conversation should strive to remain OS agnostic so it can apply to apps on many different platforms, including desktops and non-B2G mobile devices.
Once we've determined these general categories of applications, the next step will be to evaluate the security implications of each WebAPI for the app categories, followed by discussing threats and mitigations for each app category.
== Overview ==
To kickstart the conversation, 3 categories of web / B2G applications seem to have clarified in the recent discussion:
1) normal web pages utilizing a set of WebAPIs
2) installed web applications utilizing a set of WebAPIs
3) installed web applications requiring access to OS-level APIs
Please take a look at the descriptions below and comment. Hopefully we came move through this part quickly and start discussing the properties and risks of each webAPI.
=== Web pages ===
Description: A normal web page can request access to a certain set of WebAPIs.
Use cases: Web pages would like to perform functions historically limited to plugins or other binary browser extensions. They might want to capture audio or video input to stream to a server or process client-side, use various cool input devices for games, enable desktop notifications for new emails or tweets, etc. It might optionally be possible to "bookmark" a given web app, but this does not imply any additional trust.
Technical characteristics: No manifest, does not need to be installed or cached locally, and has no client-visible versioning scheme. No restrictions on transport or content outside of normal browser model (because it is just normal browser content).
Security & Privacy Characteristics: The user does not necessarily have any relationship with or trust in this site, so these APIs require explicit user opt-in at runtime, and should present users with a choice where they can be realistically expected to understand the inherent security and privacy risks. Its possible these APIs may be limited entirely to things that only present privacy or annoyance risk, but not security.
Scope: Security permissions are granted for a fully qualified domain name.
=== Installed applications with WebAPI access ===
Description: A web application installed from a specific server, discovered from one of potentially many web app stores.
Use cases: Persistent apps that the user opens to perform specific tasks. They perform functions that native apps on a given platform would be expected to perform. While some runtime dialogs might be expected, a typical feature-rich app should not result in a flood of permission requests. Social networking is a typical use case, where a single app may require access to camera/microphone for chat, contacts for integration, access photos, send SMS, trigger notifications, determine user's location, etc.
Technical characteristics: A app manifest is referred to from an app store and retrieved from the app host. An app store is required (is it)? The app store can limit the privileges the app is granted. The app is stored in the appcache on the client. The manifest contains version information and an explicit list of files that comprise the app, so that the appcache can be effectively updated from the server when necessary. Otherwise app is always instantiated from local appcache.
Security & Privacy Characteristics: User makes choice to install an app, which implies a limited degree of trust. That limited trust may permit implicit access to certain low-risk APIs, and explicit access to the bulk of the rest. Implicit access to API's that could compromise the intergrity of the OS or expose the user to direct financial risk is prohibited. Note there's a big difference between a user approving a OS mediated app dialog to dial a number, and an app that can dial a phone # directly without user any involvement.
Scope: Security permissions are granted to code enumerated in the manifest.
=== Installed applications with OS-level API access ===
Description: Some apps are integral components of the device UI, and need direct access to highly sensitive APIs. These apps are approved by a trusted 3rd party (ie. carrier or manufacturer) app store for implicit access to dangerous APIs.
Use cases: User might want to swap out their default phone dialer or SMS client for a different one. Some APIs may be too difficult to secure so such apps may only be granted privileges after the app store has obtained certain assurances from the developer.
Technical characteristics: Largely the same as the previous "Installed applications with WebAPI access" category, except for the extra trust granted to it by the store.
Security & Privacy Characteristics: Implicit access to dangerous APIs means the risk to the user or carrier should this type of app be compromised is very high. For example, this type of app can dial a phone number directly without any user involvement or knowledge.
Scope: Security permissions are granted to code enumerated in the manifest.
Determine a baseline for the different types of applications in the B2G app ecosystem.
We are not going to evaluate operating system level issues (such as processes sandboxing, OS hardening and updates) just yet, as this part of the conversation should strive to remain OS agnostic so it can apply to apps on many different platforms, including desktops and non-B2G mobile devices.
Once we've determined these general categories of applications, the next step will be to evaluate the security implications of each WebAPI for the app categories, followed by discussing threats and mitigations for each app category.
== Overview ==
To kickstart the conversation, 3 categories of web / B2G applications seem to have clarified in the recent discussion:
1) normal web pages utilizing a set of WebAPIs
2) installed web applications utilizing a set of WebAPIs
3) installed web applications requiring access to OS-level APIs
Please take a look at the descriptions below and comment. Hopefully we came move through this part quickly and start discussing the properties and risks of each webAPI.
=== Web pages ===
Description: A normal web page can request access to a certain set of WebAPIs.
Use cases: Web pages would like to perform functions historically limited to plugins or other binary browser extensions. They might want to capture audio or video input to stream to a server or process client-side, use various cool input devices for games, enable desktop notifications for new emails or tweets, etc. It might optionally be possible to "bookmark" a given web app, but this does not imply any additional trust.
Technical characteristics: No manifest, does not need to be installed or cached locally, and has no client-visible versioning scheme. No restrictions on transport or content outside of normal browser model (because it is just normal browser content).
Security & Privacy Characteristics: The user does not necessarily have any relationship with or trust in this site, so these APIs require explicit user opt-in at runtime, and should present users with a choice where they can be realistically expected to understand the inherent security and privacy risks. Its possible these APIs may be limited entirely to things that only present privacy or annoyance risk, but not security.
Scope: Security permissions are granted for a fully qualified domain name.
=== Installed applications with WebAPI access ===
Description: A web application installed from a specific server, discovered from one of potentially many web app stores.
Use cases: Persistent apps that the user opens to perform specific tasks. They perform functions that native apps on a given platform would be expected to perform. While some runtime dialogs might be expected, a typical feature-rich app should not result in a flood of permission requests. Social networking is a typical use case, where a single app may require access to camera/microphone for chat, contacts for integration, access photos, send SMS, trigger notifications, determine user's location, etc.
Technical characteristics: A app manifest is referred to from an app store and retrieved from the app host. An app store is required (is it)? The app store can limit the privileges the app is granted. The app is stored in the appcache on the client. The manifest contains version information and an explicit list of files that comprise the app, so that the appcache can be effectively updated from the server when necessary. Otherwise app is always instantiated from local appcache.
Security & Privacy Characteristics: User makes choice to install an app, which implies a limited degree of trust. That limited trust may permit implicit access to certain low-risk APIs, and explicit access to the bulk of the rest. Implicit access to API's that could compromise the intergrity of the OS or expose the user to direct financial risk is prohibited. Note there's a big difference between a user approving a OS mediated app dialog to dial a number, and an app that can dial a phone # directly without user any involvement.
Scope: Security permissions are granted to code enumerated in the manifest.
=== Installed applications with OS-level API access ===
Description: Some apps are integral components of the device UI, and need direct access to highly sensitive APIs. These apps are approved by a trusted 3rd party (ie. carrier or manufacturer) app store for implicit access to dangerous APIs.
Use cases: User might want to swap out their default phone dialer or SMS client for a different one. Some APIs may be too difficult to secure so such apps may only be granted privileges after the app store has obtained certain assurances from the developer.
Technical characteristics: Largely the same as the previous "Installed applications with WebAPI access" category, except for the extra trust granted to it by the store.
Security & Privacy Characteristics: Implicit access to dangerous APIs means the risk to the user or carrier should this type of app be compromised is very high. For example, this type of app can dial a phone number directly without any user involvement or knowledge.
Scope: Security permissions are granted to code enumerated in the manifest.
JOSE MANUEL CANTERA FONSECA
Mar 23, 2012, 4:51:51 AM3/23/12
to Mozilla B2G mailing list, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org
El 23/03/12 07:45, "Lucas Adamski" <lada...@mozilla.com> escribió:
also install a Web Application but which has not been discovered through
an app store and as as result, it might not be trusted ...
>Description: Some apps are integral components of the device UI, and need
>direct access to highly sensitive APIs. These apps are approved by a
>trusted 3rd party (ie. carrier or manufacturer) app store for implicit
>access to dangerous APIs.
...
>
>Use cases: User might want to swap out their default phone dialer or SMS
>client for a different one. Some APIs may be too difficult to secure so
>such apps may only be granted privileges after the app store has obtained
>certain assurances from the developer.
>
>Technical characteristics: Largely the same as the previous "Installed
>applications with WebAPI access" category, except for the extra trust
>granted to it by the store.
>
>Security & Privacy Characteristics: Implicit access to dangerous APIs
>means the risk to the user or carrier should this type of app be
>compromised is very high. For example, this type of app can dial a phone
>number directly without any user involvement or knowledge.
>
>Scope: Security permissions are granted to code enumerated in the
>manifest.
>
>
>_______________________________________________
>dev-webapi mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapi
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Adrienne Porter Felt
Mar 23, 2012, 11:09:20 AM3/23/12
to Mozilla B2G mailing list, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org
I do think that having the concept of installation has nice security
properties because there are some capabilities that the user should not be
prompted about, but not every single website should have (it would be
annoying).
However, one aspect of the user experience worries me. When someone is
given a link to Facebook.com/whatever/foo/bar.php, and the user has the app
installed, which opens? The app or the site? It seems like it is
undesirable for there to be two versions of the same "web presence" for the
user to choose between; and one is more powerful but maybe doesn't
understand normal links.
(I'm sorry if this has already been discussed, the previous thread was too
long for me to read it all.)
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
properties because there are some capabilities that the user should not be
prompted about, but not every single website should have (it would be
annoying).
However, one aspect of the user experience worries me. When someone is
given a link to Facebook.com/whatever/foo/bar.php, and the user has the app
installed, which opens? The app or the site? It seems like it is
undesirable for there to be two versions of the same "web presence" for the
user to choose between; and one is more powerful but maybe doesn't
understand normal links.
(I'm sorry if this has already been discussed, the previous thread was too
long for me to read it all.)
> Description: Some apps are integral components of the device UI, and need
direct access to highly sensitive APIs. These apps are approved by a
trusted 3rd party (ie. carrier or manufacturer) app store for implicit
access to dangerous APIs.
>
direct access to highly sensitive APIs. These apps are approved by a
trusted 3rd party (ie. carrier or manufacturer) app store for implicit
access to dangerous APIs.
>
> Use cases: User might want to swap out their default phone dialer or SMS
client for a different one. Some APIs may be too difficult to secure so
such apps may only be granted privileges after the app store has obtained
certain assurances from the developer.
>
client for a different one. Some APIs may be too difficult to secure so
such apps may only be granted privileges after the app store has obtained
certain assurances from the developer.
>
> Technical characteristics: Largely the same as the previous "Installed
applications with WebAPI access" category, except for the extra trust
granted to it by the store.
>
applications with WebAPI access" category, except for the extra trust
granted to it by the store.
>
> Security & Privacy Characteristics: Implicit access to dangerous APIs
means the risk to the user or carrier should this type of app be
compromised is very high. For example, this type of app can dial a phone
number directly without any user involvement or knowledge.
>
> Scope: Security permissions are granted to code enumerated in the
manifest.
>
>
> _______________________________________________
means the risk to the user or carrier should this type of app be
compromised is very high. For example, this type of app can dial a phone
number directly without any user involvement or knowledge.
>
> Scope: Security permissions are granted to code enumerated in the
manifest.
>
>
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
Lucas Adamski
Mar 23, 2012, 3:41:30 PM3/23/12
to JOSE MANUEL CANTERA FONSECA, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
On Mar 23, 2012, at 1:51 AM, JOSE MANUEL CANTERA FONSECA wrote:
>> === Installed applications with WebAPI access ===
>
> Why don't you call them 'Trusted Installable Applications'? The user could
> also install a Web Application but which has not been discovered through
> an app store and as as result, it might not be trusted ...
>
Possible; I agree the current terminology is poor. I think we might have an hangup on "Trusted" and I do agree with the concerns raised around that. "Installable Web Applications" may be sufficient.
> also install a Web Application but which has not been discovered through
> an app store and as as result, it might not be trusted ...
>
>>
>> === Installed applications with OS-level API access ===
>
> Why don't we call them 'Trusted Core Applications'?
That seems closer to the mark.
>> Description: Some apps are integral components of the device UI, and need
>> direct access to highly sensitive APIs. These apps are approved by a
>> trusted 3rd party (ie. carrier or manufacturer) app store for implicit
>> access to dangerous APIs.
>
> Or they could be pre-installed on the device by the Carrier / Manufacturer
> ...
>
>>
> ...
>
>>
>> Use cases: User might want to swap out their default phone dialer or SMS
>> client for a different one. Some APIs may be too difficult to secure so
>> such apps may only be granted privileges after the app store has obtained
>> certain assurances from the developer.
>
>> client for a different one. Some APIs may be too difficult to secure so
>> such apps may only be granted privileges after the app store has obtained
>> certain assurances from the developer.
>
> And probably after the carrier manufacturer has verified them
>
>>
>
>>
>> Technical characteristics: Largely the same as the previous "Installed
>> applications with WebAPI access" category, except for the extra trust
>> granted to it by the store.
>
>> applications with WebAPI access" category, except for the extra trust
>> granted to it by the store.
>
> Or by the carrier / manufacturer
>
I agree with your 3 points above.
>
>
>> Security & Privacy Characteristics: Implicit access to dangerous APIs
>> means the risk to the user or carrier should this type of app be
>> compromised is very high. For example, this type of app can dial a phone
>> number directly without any user involvement or knowledge.
>>
>> Scope: Security permissions are granted to code enumerated in the
>> manifest.
>>
>
> What do you mean by 'Code Enumerated in the Manifest'?
Unless this has changed recently, I believe we are using appcache for installable apps. Appcache requires a manifest that contains an explicit list of assets to assure they can be cached locally and that the app will work offline and be performant when network connectivity is poor / inconsistent.
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html
Lucas.
Lucas Adamski
Mar 23, 2012, 3:52:49 PM3/23/12
to Adrienne Porter Felt, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
On Mar 23, 2012, at 8:09 AM, Adrienne Porter Felt wrote:
> I do think that having the concept of installation has nice security
> properties because there are some capabilities that the user should not be
> prompted about, but not every single website should have (it would be
> annoying).
>
> However, one aspect of the user experience worries me. When someone is
> given a link to Facebook.com/whatever/foo/bar.php, and the user has the app
> installed, which opens? The app or the site? It seems like it is
> undesirable for there to be two versions of the same "web presence" for the
> user to choose between; and one is more powerful but maybe doesn't
> understand normal links.
>
> (I'm sorry if this has already been discussed, the previous thread was too
> long for me to read it all.)
That's an excellent question, and I don't think that's been discussed so far. I doubt we'd implicitly assume that a URL that a user clicks on (in an email or browser for example) and map it to an application. What's more likely is that apps may want for register as handlers for some sort of app launch scheme.
> I do think that having the concept of installation has nice security
> properties because there are some capabilities that the user should not be
> prompted about, but not every single website should have (it would be
> annoying).
>
> However, one aspect of the user experience worries me. When someone is
> given a link to Facebook.com/whatever/foo/bar.php, and the user has the app
> installed, which opens? The app or the site? It seems like it is
> undesirable for there to be two versions of the same "web presence" for the
> user to choose between; and one is more powerful but maybe doesn't
> understand normal links.
>
> (I'm sorry if this has already been discussed, the previous thread was too
> long for me to read it all.)
Lucas.
Paul Theriault
Mar 26, 2012, 8:47:17 AM3/26/12
to Lucas Adamski, JOSE MANUEL CANTERA FONSECA, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list, dev-w...@lists.mozilla.org
>> What do you mean by 'Code Enumerated in the Manifest'?
> Unless this has changed recently, I believe we are using appcache for installable apps. Appcache requires a manifest that contains an explicit list of assets to assure they can be cached locally and that the app will work offline and be performant when network connectivity is poor / inconsistent.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html
> Lucas.
meant the signature of the application as described by the Web App
manifest, not the appcache manifest.
I'd suggest that for "Installable Web Applications" should be more
related to the Web App manifest, i.e. the domain or domains that make up
that web app, something like:
Scope: Security permissions are granted to the domain hosting the Web
App manifest
(or "Security permissions are granted to the domains/endpoints
enumerated in the manifest" if we move towards a multi-domain/multi-page
app scope as is being discussed in this thread:
https://groups.google.com/d/topic/mozilla.dev.webapps/90VfuxnmWYQ/discussion)
And then leave the trusted/core/os-level scope as "code enumerated in
the manifest", as these are the applications where we need to explicitly
enumerate the codebase, so that integrity of the code can be enforced.
But then the Web App manifest will need to be extended to outline how
this code is enumerated, as it doesn't currently AFAIK (maybe just by
referencing an appcache manifest)
- Paul
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
Lucas Adamski
Mar 26, 2012, 4:45:01 PM3/26/12
to ianG, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g
On 3/24/2012 1:27 AM, ianG wrote:
>> === Web pages ===
>> Description: A normal web page can request access to a certain set of WebAPIs.
>>
>> Use cases: Web pages would like to perform functions historically limited to plugins or other binary browser
>> extensions. They might want to capture audio or video input to stream to a server or process client-side, use
>> various cool input devices for games, enable desktop notifications for new emails or tweets, etc. It might
>> optionally be possible to "bookmark" a given web app, but this does not imply any additional trust.
>>
>> Technical characteristics: No manifest, does not need to be installed or cached locally, and has no client-visible
>> versioning scheme. No restrictions on transport or content outside of normal browser model (because it is just
>> normal browser content).
>>
>> so these APIs require explicit user opt-in at runtime, and should present users with a choice where they can be
>> realistically expected to understand the inherent security and privacy risks. Its possible these APIs may be limited
>> entirely to things that only present privacy or annoyance risk, but not security.
>>
>> Scope: Security permissions are granted for a fully qualified domain name.
>
>
> Who or what grants these security permissions?
>> realistically expected to understand the inherent security and privacy risks. Its possible these APIs may be limited
>> entirely to things that only present privacy or annoyance risk, but not security.
>>
>> Scope: Security permissions are granted for a fully qualified domain name.
>
>
The agent running the app does, technically. Whether that's a browser, B2G OS, or some other app container.
> It seems that we are assuming that the browser has these capabilities; can read audio/video and can export that as an
> API to the remote website. So the model then seems to reduce to something like: user clicks in her browser some site,
> which enacts the API which asks the browser to open some privileged channel. Browser being a good agent asks user for
> permission.
Not quite. It simply permits/denies the code in question to access to that API. That code is always technically
running locally (regardless of where from/how it was delivered). No APIs or channels are directly "exported" to any server.
>
>> === Installed applications with WebAPI access ===
>> Description: A web application installed from a specific server, discovered from one of potentially many web app stores.
>>
>> Use cases: Persistent apps that the user opens to perform specific tasks. They perform functions that native apps on
>> a given platform would be expected to perform. While some runtime dialogs might be expected, a typical feature-rich
>> app should not result in a flood of permission requests. Social networking is a typical use case, where a single app
>> may require access to camera/microphone for chat, contacts for integration, access photos, send SMS, trigger
>> notifications, determine user's location, etc.
>>
>> Technical characteristics: A app manifest is referred to from an app store and retrieved from the app host. An app
>> store is required (is it)? The app store can limit the privileges the app is granted. The app is stored in the
>> appcache on the client. The manifest contains version information and an explicit list of files that comprise the
>> app, so that the appcache can be effectively updated from the server when necessary. Otherwise app is always
>> instantiated from local appcache.
>>
>> Security& Privacy Characteristics: User makes choice to install an app, which implies a limited degree of trust.
>>
>> Use cases: Persistent apps that the user opens to perform specific tasks. They perform functions that native apps on
>> a given platform would be expected to perform. While some runtime dialogs might be expected, a typical feature-rich
>> app should not result in a flood of permission requests. Social networking is a typical use case, where a single app
>> may require access to camera/microphone for chat, contacts for integration, access photos, send SMS, trigger
>> notifications, determine user's location, etc.
>>
>> Technical characteristics: A app manifest is referred to from an app store and retrieved from the app host. An app
>> store is required (is it)? The app store can limit the privileges the app is granted. The app is stored in the
>> appcache on the client. The manifest contains version information and an explicit list of files that comprise the
>> app, so that the appcache can be effectively updated from the server when necessary. Otherwise app is always
>> instantiated from local appcache.
>>
>> That limited trust may permit implicit access to certain low-risk APIs, and explicit access to the bulk of the rest.
>> Implicit access to API's that could compromise the intergrity of the OS or expose the user to direct financial risk
>> is prohibited. Note there's a big difference between a user approving a OS mediated app dialog to dial a number, and
>> an app that can dial a phone # directly without user any involvement.
>>
>> Implicit access to API's that could compromise the intergrity of the OS or expose the user to direct financial risk
>> is prohibited. Note there's a big difference between a user approving a OS mediated app dialog to dial a number, and
>> an app that can dial a phone # directly without user any involvement.
>>
>> Scope: Security permissions are granted to code enumerated in the manifest.
>
> Again, as above, it seems that we are assuming a local agent on the user's computer to mediate this. Especially, in
>
> this case, the local agent (browser) will download an application that it understands, and run it internally in an
> environment of the browser's creation.
In this case yes, the proposal is they would be downloaded and stored in the appcache. This proposal is not without
controversy; many people would also like to maintain the current web application model which puts few security
constraints on content and does not require any code authentication. Unfortunately, this model is also insecure by default.
> Is that right? So this is the "browser plugin model" ?
No, its the browser app model. Apps can already prompt for certain APIs that require user interaction for consent
(plugin installation, addon installation, geolocation, file download / upload).
Plugins are for extending the browser's functionality for web apps.
> Then, there seems to be a missing category of applications, those being downloaded outside the assumed local agent's
> control. In which case, they cannot be controlled and they are potentially outside scope of the discussion.
>
> *but* not really, because they still exist, and the user has a choice in application technologies. These represent an
> uncontrollable competition, which represents a low-tide watermark. The competition means that the local download
> agent must do at least as good a job, and in some areas substantially better. Elsewise users+developers switch.
>
> So, it may be useful to list this "out of scope" set as the competition.
If a user chooses to download and install an app directly outside of the runtime container context, they might as well
be downloading a native application for desktop for all they know. It is true though that we aren't focusing on (and
don't have a story for) the offline or "unmanaged" installs.
>
>>
>> === Installed applications with OS-level API access ===
>> Description: Some apps are integral components of the device UI, and need direct access to highly sensitive APIs.
>> These apps are approved by a trusted 3rd party (ie. carrier or manufacturer) app store for implicit access to
>> dangerous APIs.
>>
>> These apps are approved by a trusted 3rd party (ie. carrier or manufacturer) app store for implicit access to
>> dangerous APIs.
>>
>> Use cases: User might want to swap out their default phone dialer or SMS client for a different one. Some APIs may
>> be too difficult to secure so such apps may only be granted privileges after the app store has obtained certain
>> assurances from the developer.
>>
>> be too difficult to secure so such apps may only be granted privileges after the app store has obtained certain
>> assurances from the developer.
>>
>> Technical characteristics: Largely the same as the previous "Installed applications with WebAPI access" category,
>> except for the extra trust granted to it by the store.
>
>
> This I'm not understanding, sorry. How can the store grant "trust" (a bad word) on a user's computer? Surely when
>> except for the extra trust granted to it by the store.
>
>
> the user downloads and installs the application, she is doing so in full responsibility, and in that act, to use the
> above terminology, she is granting "trust" to that application. It comes as it is - the developer did the
> construction, the app store is either shipping it or not. As is, or not.
> She may be doing this on the recommendation of the app store. But that's not the same as "granting".
A computer is probably not the most relevant example; phones are more interesting. In the event of very dangerous APIs,
we may not want to permit access to them unless a 3rd party is willing to vouch for the safety of that app. In the case
of the phone, the carrier might only permit a specific set of apps to replace the stock phone dialer, for example. The
user still chooses to install an app, but this way the store is explicitly providing this as a "phone dialer app". For
such environments, the alternative might simply be "don't support this API."
>
>> Security& Privacy Characteristics: Implicit access to dangerous APIs means the risk to the user or carrier should
>> this type of app be compromised is very high.
>
> Conceptually, all I am seeing to differentiate this group and the previous one is a personal judgement that the prior
>
> set of APIs are "probably ok" and the latter set are "possibly dangerous" ? As this seems to be rather vague, the
> distinction probably isn't enough to justify an architectural distinction. Which is long words to say, these two
> groups seem the same, it's just that the second group matters more (to some), and tests the architecture more (if
> their judgement means anything).
>
TBD.
>> For example, this type of app can dial a phone number directly without any user involvement or knowledge.
>
> manufacturer has "granted" some permissions that are considered to be highly interesting ("dangerous" ?) then we need
> to look at the fuller meaning of that.
>
> Dangerous means they can go wrong. If they never go wrong there isn't an issue and we don't care.
>
> In contrast to that, when they do go wrong, this is the moment when we care. We are forced to take care, we can no
> longer pretent. So let's look at that, as if it is important.
>
> Say the AngryBudgies app did go wrong and turned out to be HungryAlligators in disguise. It does damage (doesn't
> matter what).
>
> What now? This is where the rubber of a security system meets the road of reality. What happens when it all falls
> apart?
>
> Does Alice re-install? Buy a new computer? A new house? Does she damn Carol the Carrier on some ebay-like reputation
> outlet? Does she sue for damages? Does developer Carol's insurance fund pay out? Does Carol's private vigilante
> police force hunt down the Alligators and reinstall with prejudice? Does Bob the WebAPI builder form a standards
> committee to deal with this, and in the process shut out any user complaints?
>
> Without an answer to this, we're talking tech only. Worthless. We need to understand the full business cycle we're
> trying to protect, because only in that context do we understand the attacks.
>
> Maybe the answer is nothing? In which case we do "best efforts, all love, no responsibility" which is the case with
> most Internet security models. On the other hand, do we go an extra mile? Which?
>
Its "our" responsibility to build a model with the right incentives and mitigations in place to maximize the number of
great apps developers can build while minimizing the risk to our users. We are responsible for the overall health and
security of this ecosystem.
Its the developers responsibility to build great apps that don't put the user at risk, and their fault when they don't.
The current web app model makes this extremely hard to do well, and very easy to mess up. We can't expect web
developers to be security experts; its our responsibility to build a model that nudges them (sometimes forcefully)
towards taking the necessary precautions.
Its the app stores responsibility to provide apps that don't put users at undue security and privacy risk, and to remove
apps when they have done so. This is true both for malicious apps, and for apps with serious security issues.
Its the users responsibility to make informed decisions when choosing which apps to trust. Its everyone else's
responsibility to ensure they are presented with accurate information and relevant decisions to make sure they can do so
effectively.
Nobody is responsible for delivering a panacea, however.
Lucas.
Lucas Adamski
Mar 26, 2012, 8:01:45 PM3/26/12
to Paul Theriault, JOSE MANUEL CANTERA FONSECA, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list, dev-w...@lists.mozilla.org
On 3/26/2012 5:47 AM, Paul Theriault wrote:
>
>>> What do you mean by 'Code Enumerated in the Manifest'?
>> Unless this has changed recently, I believe we are using appcache for installable apps. Appcache requires a manifest
>> that contains an explicit list of assets to assure they can be cached locally and that the app will work offline and
>> be performant when network connectivity is poor / inconsistent.
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html
>> Lucas.
> When you stated "Code Enumerated in the Manifest" I had thought you meant the signature of the application as
> described by the Web App manifest, not the appcache manifest.
>
Good point. I'm thinking the best way forward might be to document that installed apps should be "strongly
>
>>> What do you mean by 'Code Enumerated in the Manifest'?
>> Unless this has changed recently, I believe we are using appcache for installable apps. Appcache requires a manifest
>> that contains an explicit list of assets to assure they can be cached locally and that the app will work offline and
>> be performant when network connectivity is poor / inconsistent.
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html
>> Lucas.
> When you stated "Code Enumerated in the Manifest" I had thought you meant the signature of the application as
> described by the Web App manifest, not the appcache manifest.
>
authenticated" and leave it at that until after we've enumerated the expected behavior of webAPIs for each application
type. That will really flesh out the risks inherent in each app category, and we can have a more productive discussion
on how to mitigate the resulting risk. Otherwise we're debating security model implementations (SSL vs code signing)
without having established what exactly we are trying to protect.
Lucas.
Paul Theriault
Mar 27, 2012, 12:34:44 AM3/27/12
to Ragavan Srinivasan, dev-w...@lists.mozilla.org, mozilla-d...@lists.mozilla.org, Mozilla B2G mailing list
(I don't want to speak on behalf of Lucas, but I suspect he may not be
on the dev-webapi list, so I am re-including the web-apps & B2G lists.
If we are going to just use one list, maybe it be webapps?)
I think the hypothesis behind the distinction between Web Apps and
"Trusted Core Web Apps" or whatever they get called is basically: some
critical permissions are going to require an additional level of
security in order for trust to be granted.
Defining which permissions are critical and what additional controls are
required will be easier to discuss once we have actually gone through
the APIs to determine what the permissions categories are going to look
like, which is the next step in cycle Lucas proposed.
On 3/25/12 6:12 AM, Ragavan Srinivasan wrote:
>
>
> Andreas Gal wrote:
>>> * When I see the last two classes of apps, I wonder if the
>>> distinction is actually between implicit trust/permissions vs.
>>> explicit and not WebAPI and OS-level?
>>
>> Web apps only use WebAPIs. I don't think "OS-level" is the right term
>> here.
>
> Right - so, are you saying there really are only two types (as opposed
> to the three Lucas laid out?) - Pages and Apps? And each of them may
> use WebAPIs.
>
>>> * Where does a complete client-side app that doesn't use appcache
>>> fit in? Eg: A calculator app that just zips up all the app
>>> resources and execution is all local.
>>
>> I don't think we should overload the spec thinking with alternative
>> cache models, which really a zip file is.
>
> My question wasn't as much about the OWA spec as much as the types of
> apps Lucas was trying to scope. I'm asking the question whether
> completely client-side apps fit into one of his existing types or if
> they are different enough to be their own type for the security model
> discussions.
>
> Ragavan
on the dev-webapi list, so I am re-including the web-apps & B2G lists.
If we are going to just use one list, maybe it be webapps?)
I think the hypothesis behind the distinction between Web Apps and
"Trusted Core Web Apps" or whatever they get called is basically: some
critical permissions are going to require an additional level of
security in order for trust to be granted.
Defining which permissions are critical and what additional controls are
required will be easier to discuss once we have actually gone through
the APIs to determine what the permissions categories are going to look
like, which is the next step in cycle Lucas proposed.
On 3/25/12 6:12 AM, Ragavan Srinivasan wrote:
>
>
> Andreas Gal wrote:
>>> * When I see the last two classes of apps, I wonder if the
>>> distinction is actually between implicit trust/permissions vs.
>>> explicit and not WebAPI and OS-level?
>>
>> Web apps only use WebAPIs. I don't think "OS-level" is the right term
>> here.
>
> Right - so, are you saying there really are only two types (as opposed
> to the three Lucas laid out?) - Pages and Apps? And each of them may
> use WebAPIs.
>
>>> * Where does a complete client-side app that doesn't use appcache
>>> fit in? Eg: A calculator app that just zips up all the app
>>> resources and execution is all local.
>>
>> I don't think we should overload the spec thinking with alternative
>> cache models, which really a zip file is.
>
> My question wasn't as much about the OWA spec as much as the types of
> apps Lucas was trying to scope. I'm asking the question whether
> completely client-side apps fit into one of his existing types or if
> they are different enough to be their own type for the security model
> discussions.
>
> Ragavan
Lucas Adamski
Mar 27, 2012, 2:46:31 PM3/27/12
to Paul Theriault, dev-w...@lists.mozilla.org, mozilla-d...@lists.mozilla.org, Ragavan Srinivasan, Mozilla B2G mailing list
On 3/26/2012 9:34 PM, Paul Theriault wrote:
> (I don't want to speak on behalf of Lucas, but I suspect he may not be on the dev-webapi list, so I am re-including the
> web-apps & B2G lists. If we are going to just use one list, maybe it be webapps?)
>
> I think the hypothesis behind the distinction between Web Apps and "Trusted Core Web Apps" or whatever they get called
> is basically: some critical permissions are going to require an additional level of security in order for trust to be
> granted.
>
> Defining which permissions are critical and what additional controls are required will be easier to discuss once we have
> actually gone through the APIs to determine what the permissions categories are going to look like, which is the next
> step in cycle Lucas proposed.
Yes, I think we need to go through the APIs and enumerate the potential risks (and whether access is implicit or
> (I don't want to speak on behalf of Lucas, but I suspect he may not be on the dev-webapi list, so I am re-including the
> web-apps & B2G lists. If we are going to just use one list, maybe it be webapps?)
>
> I think the hypothesis behind the distinction between Web Apps and "Trusted Core Web Apps" or whatever they get called
> is basically: some critical permissions are going to require an additional level of security in order for trust to be
> granted.
>
> Defining which permissions are critical and what additional controls are required will be easier to discuss once we have
> actually gone through the APIs to determine what the permissions categories are going to look like, which is the next
> step in cycle Lucas proposed.
explicit) in each category. If we end up with two categories of apps that look largely the same from a permission
standpoint, then I think it'll make sense to combine then. But its much easier to combine categories later than it is
to separate them further, which would likely result in rewinding the conversation back to the beginning. Its not clear
at this point that eliminating B2G OS apps clears up the picture much; we haven't discussed the security implications of
allowing Bluetooth and USB access for example.
Lucas.
P.S. I thought I signed up for the webapi list a few days ago but doesn't look like it "took". Regardless it would be
better to focus this conversation on the webapps list.
Lucas.
> On 3/25/12 6:12 AM, Ragavan Srinivasan wrote:
>>
>>
>> Andreas Gal wrote:
>>>> * When I see the last two classes of apps, I wonder if the
>>>> distinction is actually between implicit trust/permissions vs.
>>>> explicit and not WebAPI and OS-level?
>>>
>>> Web apps only use WebAPIs. I don't think "OS-level" is the right term
>>> here.
>>
>> Right - so, are you saying there really are only two types (as opposed to the three Lucas laid out?) - Pages and Apps?
>> And each of them may use WebAPIs.
>>
>>>> * Where does a complete client-side app that doesn't use appcache
>>>> fit in? Eg: A calculator app that just zips up all the app
>>>> resources and execution is all local.
>>>
>>> I don't think we should overload the spec thinking with alternative
>>> cache models, which really a zip file is.
>>
>> My question wasn't as much about the OWA spec as much as the types of apps Lucas was trying to scope. I'm asking the
>> question whether completely client-side apps fit into one of his existing types or if they are different enough to be
>> their own type for the security model discussions.
>>
>> Ragavan
>> _______________________________________________
>> dev-webapi mailing list
>> dev-w...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-webapi
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
Lucas Adamski
Apr 2, 2012, 1:58:26 PM4/2/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
Its been a very productive discussion, though I do think we have perhaps focused too much on the question of "installed vs not" and thereby created a bit of a false dilemma. For example, if we agree that random HTTP web content should be permitted to request access to a certain set of webAPIs, whether that content is "installed" via a manifest or not does not significantly change the risk inherent in granting it that set of privileges. This permits the use case of just turning a normal website into an app, without having to go through significant packaging. This is ok because that app can have no more privilege than a regular web page can request.
Now if there is a set of APIs that an app might have implicit access to, or APIs that present too much risk to have completely random web content request access to, then we need to have a category of application that the user can make a trust decision regarding (the app or publisher) before granting such privileges. This ensures that when the user decides to trust code from X, that can be a meaningful decision.
I'd like to propose a different way of framing these categories as:
a) unauthenticated content (typical web content): contains privileges that any content can request. Risk is generally limited to privacy, i.e. to what the user chooses to share via that API at that point in time. Safe enough for any content to request at any time. (risk: low severity)
b) authenticated content (trusted content): privileges that require the user to make some explicit trust decision based upon the identity of the requesting party BEFORE these privileges can be explicitly prompted for or implicitly granted. This requires code integrity as well as authenticity. These are privileges that we would not want random pages prompting for without the user first accepting the identity of the requesting party, and if abused the risk is limited to disclosure of confidential information / privacy / persistent annoyance / phishing, but not persistent system compromise (risk: moderate to high severity)
c) certified content (trusted content vouched for by 3rd party): privileges that the user has to make an explicit trust decision about based upon strong authentication AND vouched for by a trusted 3rd party. One use case for example are B2G APIs for implicit access to dialer and SMS. For an app to have direct access to them, it would need to be certified by the carrier or manufacturer in question. These are APIs that the average user cannot realistically make a risk judgement about and/or the misuse of which can result in local system compromise or direct financial impact (risk: critical severity).
Anticipated objections:
1) Your proposal means code signing: no it doesn't, we haven't decided what authentication means. So I suggest that we table the discussion of what specific mechanisms we use to authenticate the code (SSL, SSL + HSTS + CA pinning + CSP, code signing, widgets-digsig, etc.) until we have a better understanding of the risks inherent in each category of app. Threats before mitigations. :)
2) Your proposal requires installer packages: it doesn't, code authentication is orthogonal to packaging; packaging is just a delivery mechanism
3) Your proposal means all privilege are granted up front at app install: Nope, we should not confuse authentication with authorization. For authenticated apps the initial trust decision just grants the app the right to request those sensitive privileges. They could still be opt-in, opt-out or any combination thereof. This is TBD.
4) This isn't the web: today's web comes explicitly with a set of very limited privileges. As we grant it more privileges, the web needs to evolve to mitigate the additional risks.
Next steps: rather than debating packaging and signing, we should do the difficult work of talking through each API and determining the risk level (and proposed mitigations) for each of the categories above. This discussion will driven by identified use cases for each API, which ensure we can make the right experience/mitigation decisions. I will start sending those out shortly as our PM's prioritize them based upon use cases and schedule. I suspect some of these will be very quick, while others may become quite involved.
Once we've gone through a representative set of these APIs, we will then look at the installation experience, at which point we can have a far more informed discussion of the risks and merits of the various proposed approaches.
I am trying to keep this discussion focused on the dev-webapps mailing list, so if you could please send your responses there that would be ideal. Failing that I'll take a response on any other list over silence. :)
Thanks!
Lucas.
Now if there is a set of APIs that an app might have implicit access to, or APIs that present too much risk to have completely random web content request access to, then we need to have a category of application that the user can make a trust decision regarding (the app or publisher) before granting such privileges. This ensures that when the user decides to trust code from X, that can be a meaningful decision.
I'd like to propose a different way of framing these categories as:
a) unauthenticated content (typical web content): contains privileges that any content can request. Risk is generally limited to privacy, i.e. to what the user chooses to share via that API at that point in time. Safe enough for any content to request at any time. (risk: low severity)
b) authenticated content (trusted content): privileges that require the user to make some explicit trust decision based upon the identity of the requesting party BEFORE these privileges can be explicitly prompted for or implicitly granted. This requires code integrity as well as authenticity. These are privileges that we would not want random pages prompting for without the user first accepting the identity of the requesting party, and if abused the risk is limited to disclosure of confidential information / privacy / persistent annoyance / phishing, but not persistent system compromise (risk: moderate to high severity)
c) certified content (trusted content vouched for by 3rd party): privileges that the user has to make an explicit trust decision about based upon strong authentication AND vouched for by a trusted 3rd party. One use case for example are B2G APIs for implicit access to dialer and SMS. For an app to have direct access to them, it would need to be certified by the carrier or manufacturer in question. These are APIs that the average user cannot realistically make a risk judgement about and/or the misuse of which can result in local system compromise or direct financial impact (risk: critical severity).
Anticipated objections:
1) Your proposal means code signing: no it doesn't, we haven't decided what authentication means. So I suggest that we table the discussion of what specific mechanisms we use to authenticate the code (SSL, SSL + HSTS + CA pinning + CSP, code signing, widgets-digsig, etc.) until we have a better understanding of the risks inherent in each category of app. Threats before mitigations. :)
2) Your proposal requires installer packages: it doesn't, code authentication is orthogonal to packaging; packaging is just a delivery mechanism
3) Your proposal means all privilege are granted up front at app install: Nope, we should not confuse authentication with authorization. For authenticated apps the initial trust decision just grants the app the right to request those sensitive privileges. They could still be opt-in, opt-out or any combination thereof. This is TBD.
4) This isn't the web: today's web comes explicitly with a set of very limited privileges. As we grant it more privileges, the web needs to evolve to mitigate the additional risks.
Next steps: rather than debating packaging and signing, we should do the difficult work of talking through each API and determining the risk level (and proposed mitigations) for each of the categories above. This discussion will driven by identified use cases for each API, which ensure we can make the right experience/mitigation decisions. I will start sending those out shortly as our PM's prioritize them based upon use cases and schedule. I suspect some of these will be very quick, while others may become quite involved.
Once we've gone through a representative set of these APIs, we will then look at the installation experience, at which point we can have a far more informed discussion of the risks and merits of the various proposed approaches.
I am trying to keep this discussion focused on the dev-webapps mailing list, so if you could please send your responses there that would be ideal. Failing that I'll take a response on any other list over silence. :)
Thanks!
Lucas.
JOSE MANUEL CANTERA FONSECA
Apr 3, 2012, 5:23:15 AM4/3/12
to dev-w...@lists.mozilla.org
El 02/04/12 19:58, "Lucas Adamski" <lada...@mozilla.com> escribió:
and/or distributor of the app, right?
>These are privileges that we would not want random pages prompting for
>without the user first accepting the identity of the requesting party,
>and if abused the risk is limited to disclosure of confidential
>information / privacy / persistent annoyance / phishing, but not
>persistent system compromise (risk: moderate to high severity)
>
>c) certified content (trusted content vouched for by 3rd party):
>privileges that the user has to make an explicit trust decision about
>based upon strong authentication AND vouched for by a trusted 3rd party.
>One use case for example are B2G APIs for implicit access to dialer and
>SMS. For an app to have direct access to them, it would need to be
>certified by the carrier or manufacturer in question. These are APIs
>that the average user cannot realistically make a risk judgement about
>and/or the misuse of which can result in local system compromise or
>direct financial impact (risk: critical severity).
>
>Thanks!
> Lucas.
>_______________________________________________
>dev-b2g mailing list
>dev...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-b2g
>dev-b2g mailing list
>dev...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-b2g
Mounir Lamouri
Apr 3, 2012, 10:21:36 AM4/3/12
to dev-w...@lists.mozilla.org
On 04/02/2012 07:58 PM, Lucas Adamski wrote:
> 4) This isn't the web: today's web comes explicitly with a set of very limited privileges. As we grant it more privileges, the web needs to evolve to mitigate the additional risks.
Actually, your proposal concerns me because I believe that wouldn't help
> 4) This isn't the web: today's web comes explicitly with a set of very limited privileges. As we grant it more privileges, the web needs to evolve to mitigate the additional risks.
the web platform. If I got it correctly, you want to create three rings
of APIs and each ring will be allowed to some kind of content/apps. That
means the Web will not be able to access some of the APIs we are
designing thus those APIs will not be really part of the web platform. I
don't think this is the goal of the WebAPI effort and B2G.
--
Mounir
Benjamin Smedberg
Apr 3, 2012, 10:51:25 AM4/3/12
to Mounir Lamouri, dev-w...@lists.mozilla.org
users can understand and give informed consent. If there are APIs where
users cannot give informed consent (WebUSB comes to mind), we should
simply not make those part of the web platform. So yes, there is a point
where some APIs cannot be in general part of the web platform and
instead have to have brokered trust, which may involve more strict
codesigning/whatever restrictions than the web platform usually requires.
--BDS
Mounir Lamouri
Apr 3, 2012, 11:15:54 AM4/3/12
to dev-w...@lists.mozilla.org
On 04/03/2012 04:51 PM, Benjamin Smedberg wrote:
> "The web platform" currently involves limiting permissions to those that
> users can understand and give informed consent. If there are APIs where
> users cannot give informed consent (WebUSB comes to mind), we should
> simply not make those part of the web platform. So yes, there is a point
> where some APIs cannot be in general part of the web platform and
> instead have to have brokered trust, which may involve more strict
> codesigning/whatever restrictions than the web platform usually requires.
I definitely agree that some APIs should be hidden as much as possible
> "The web platform" currently involves limiting permissions to those that
> users can understand and give informed consent. If there are APIs where
> users cannot give informed consent (WebUSB comes to mind), we should
> simply not make those part of the web platform. So yes, there is a point
> where some APIs cannot be in general part of the web platform and
> instead have to have brokered trust, which may involve more strict
> codesigning/whatever restrictions than the web platform usually requires.
but those should be the exceptions, not the rule. Creating three rings
will make this a rule. In my opinion, an API that is not in the farther
ring will not be part of the web platform.
--
Mounir
Lucas Adamski
Apr 4, 2012, 4:42:05 PM4/4/12
to JOSE MANUEL CANTERA FONSECA, dev-w...@lists.mozilla.org
>> b) authenticated content (trusted content): privileges that require the
>> user to make some explicit trust decision based upon the identity of the
>> requesting party BEFORE these privileges can be explicitly prompted for
>> or implicitly granted. This requires code integrity as well as
>> authenticity.
>
> By authenticity do you mean that it is possible to identify the author
> and/or distributor of the app, right?
>
That's correct.
>> user to make some explicit trust decision based upon the identity of the
>> requesting party BEFORE these privileges can be explicitly prompted for
>> or implicitly granted. This requires code integrity as well as
>> authenticity.
>
> By authenticity do you mean that it is possible to identify the author
> and/or distributor of the app, right?
>
Lucas.
Jonas Sicking
Apr 5, 2012, 12:47:21 AM4/5/12
to Mounir Lamouri, dev-w...@lists.mozilla.org
On Tue, Apr 3, 2012 at 7:21 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> On 04/02/2012 07:58 PM, Lucas Adamski wrote:
>> 4) This isn't the web: today's web comes explicitly with a set of very limited privileges. As we grant it more privileges, the web needs to evolve to mitigate the additional risks.
>
> Actually, your proposal concerns me because I believe that wouldn't help
> the web platform. If I got it correctly, you want to create three rings
> of APIs and each ring will be allowed to some kind of content/apps. That
> means the Web will not be able to access some of the APIs we are
> designing thus those APIs will not be really part of the web platform. I
> don't think this is the goal of the WebAPI effort and B2G.
I don't think this is what it means.
> On 04/02/2012 07:58 PM, Lucas Adamski wrote:
>> 4) This isn't the web: today's web comes explicitly with a set of very limited privileges. As we grant it more privileges, the web needs to evolve to mitigate the additional risks.
>
> Actually, your proposal concerns me because I believe that wouldn't help
> the web platform. If I got it correctly, you want to create three rings
> of APIs and each ring will be allowed to some kind of content/apps. That
> means the Web will not be able to access some of the APIs we are
> designing thus those APIs will not be really part of the web platform. I
> don't think this is the goal of the WebAPI effort and B2G.
First of all the first category (or "ring") in Lucas' proposal
includes both "normal" web pages, as well as installed web apps.
Second, just because we might have a different UX in the different
categories for a given WebAPI, that doesn't mean that the API won't be
available in multiple "rings".
Finally, I think that in some cases we simply can't make an API secure
for normal web pages. For example I don't think that there is any
amount of prompts that would make it ok for a normal web page to send
a SMS, or to set settings which affects my ability to place phone
calls.
Another thing which could be cool, is if we could enable normal
websites to get into higher categories. I.e. if a website deploys the
security mechanisms that we decide are required to be in the
authenticated category, then maybe we can say that it's likely enough
to not get hacked that we can expose more APIs to it. I'm not sure if
this is something we should define for this first round of
discussions, but it's something that we could keep in mind and make
sure that we don't make impossible in the future.
/ Jonas
Jonas Sicking
Apr 6, 2012, 6:24:45 PM4/6/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
On Mon, Apr 2, 2012 at 10:58 AM, Lucas Adamski <lada...@mozilla.com> wrote:
> Its been a very productive discussion, though I do think we have perhaps focused too much on the question of "installed vs not" and thereby created a bit of a false dilemma. For example, if we agree that random HTTP web content should be permitted to request access to a certain set of webAPIs, whether that content is "installed" via a manifest or not does not significantly change the risk inherent in granting it that set of privileges. This permits the use case of just turning a normal website into an app, without having to go through significant packaging. This is ok because that app can have no more privilege than a regular web page can request.
>
> Now if there is a set of APIs that an app might have implicit access to, or APIs that present too much risk to have completely random web content request access to, then we need to have a category of application that the user can make a trust decision regarding (the app or publisher) before granting such privileges. This ensures that when the user decides to trust code from X, that can be a meaningful decision.
>
> I'd like to propose a different way of framing these categories as:
>
> a) unauthenticated content (typical web content): contains privileges that any content can request. Risk is generally limited to privacy, i.e. to what the user chooses to share via that API at that point in time. Safe enough for any content to request at any time. (risk: low severity)
>
> b) authenticated content (trusted content): privileges that require the user to make some explicit trust decision based upon the identity of the requesting party BEFORE these privileges can be explicitly prompted for or implicitly granted. This requires code integrity as well as authenticity. These are privileges that we would not want random pages prompting for without the user first accepting the identity of the requesting party, and if abused the risk is limited to disclosure of confidential information / privacy / persistent annoyance / phishing, but not persistent system compromise (risk: moderate to high severity)
> Its been a very productive discussion, though I do think we have perhaps focused too much on the question of "installed vs not" and thereby created a bit of a false dilemma. For example, if we agree that random HTTP web content should be permitted to request access to a certain set of webAPIs, whether that content is "installed" via a manifest or not does not significantly change the risk inherent in granting it that set of privileges. This permits the use case of just turning a normal website into an app, without having to go through significant packaging. This is ok because that app can have no more privilege than a regular web page can request.
>
> Now if there is a set of APIs that an app might have implicit access to, or APIs that present too much risk to have completely random web content request access to, then we need to have a category of application that the user can make a trust decision regarding (the app or publisher) before granting such privileges. This ensures that when the user decides to trust code from X, that can be a meaningful decision.
>
> I'd like to propose a different way of framing these categories as:
>
> a) unauthenticated content (typical web content): contains privileges that any content can request. Risk is generally limited to privacy, i.e. to what the user chooses to share via that API at that point in time. Safe enough for any content to request at any time. (risk: low severity)
>
>
> c) certified content (trusted content vouched for by 3rd party): privileges that the user has to make an explicit trust decision about based upon strong authentication AND vouched for by a trusted 3rd party. One use case for example are B2G APIs for implicit access to dialer and SMS. For an app to have direct access to them, it would need to be certified by the carrier or manufacturer in question. These are APIs that the average user cannot realistically make a risk judgement about and/or the misuse of which can result in local system compromise or direct financial impact (risk: critical severity).
I had a discussion with Lucas about these groups and we came to the
> c) certified content (trusted content vouched for by 3rd party): privileges that the user has to make an explicit trust decision about based upon strong authentication AND vouched for by a trusted 3rd party. One use case for example are B2G APIs for implicit access to dialer and SMS. For an app to have direct access to them, it would need to be certified by the carrier or manufacturer in question. These are APIs that the average user cannot realistically make a risk judgement about and/or the misuse of which can result in local system compromise or direct financial impact (risk: critical severity).
conclusion that it might be good to split up the a) group into two
groups:
a1) unauthenticated content (typical web content): contains privileges
that any content can request. Risk is generally limited to privacy,
i.e. to what the user chooses to share via that API at that point in
time. Safe enough for any content to request at any time. (risk: low
severity)
a2) "installed" unauthenticated content: Same as a1, but some
i.e. to what the user chooses to share via that API at that point in
time. Safe enough for any content to request at any time. (risk: low
severity)
privileges are automatically granted. No privileges that expose the
user to additional privacy or security risk are granted automatically.
However privileges which use device resources (harddrive space,
network bandwidth, CPU power) and privileges which could annoy the
user (replace context menus, set screen orientation).
So there are clearly APIs which have different UX between a1 and a2,
so it makes sense to split it into two separate groups. Also
considering that most applications will hopefully fall into either of
these categories, it makes sense to be more detailed in how we treat
them.
/ Jonas
Lucas Adamski
May 1, 2012, 11:23:45 PM5/1/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
Please reply-to dev-webapps.
There's been much discussion lately of the different types of applications and so I figured this would be a good time to
summarize the current state of discussion. From a security perspective, there are 3.5 types of applications. Confused
yet? Excellent!
==Types of applications==
1a) Normal web content. Not a type of application per our definition of installed apps, but part of the WebAPI security
continuum and so should be discussed here.
*No app store involved.
*No manifest or installation experience.
*No restrictions on origin or transport (i.e. HTTPS not required).
*All explicit permissions are granted at runtime, not persisted by default.
1b) Installed untrusted applications: Unauthenticated applications provide a manifest, and can optionally be obtained
through an app store.
*No restrictions on transport but limited to one app per origin (though an app may load assets and code from other
origins).
*Installation experience with permissions being opt-in at install and runtime, limited to permissions enumerated in the
manifest.
*No app store code reviews as they'd serve no purpose (app can change anytime without user or reviewer consent).
*No SSL indicators, so trust is limited only to content user is willing to share with any website, and maximum
privileges are likewise limited to what is available to normal web content.
*All explicit permissions are granted at runtime, not persisted by default.
2) Installed trusted application: Authenticated application approved by an app store, with an explicit list of assets
that comprise the app.
*App is reviewed and approved by app store.
*App store signs the app manifest which contains a list of assets and their corresponding hashes.
*App assets are verified & stored locally in appcache.
*Require a CSP policy of "script-src: 'self'; object-src: 'self'; style-src: 'self'" to mitigate content injection
attacks and maintain application integrity.
*Explicit permission grants are persisted by default.
3) Certified application: This category is reserved for apps that require approval by carrier or OEM due to risk of
device corruption or risk to critical functionality. These include apps such as the system settings app, default dialer
(to ensure emergency services are always accessible), core radio and power management, etc.
*All permissions are implicit.
*User cannot modify/disable permissions.
*Approval of certified apps is limited to explicit list of authorized app stores.
==Open questions for trusted apps==
Permission prompting mechanisms. This is currently being led by UX and we will have a detailed proposal to discuss shortly.
*Prompt for security permissions at runtime only, or install-time & runtime?
**Should permissions be visible or in a pulldown at install?
**Initial permission prompt at install or first launch?
**Check/uncheck permissions at install?
*Provide a permission rationale as approved by app store? Yes.
*Concerns that many apps could require a lot of runtime security prompts, resulting in a bad UX and ineffective security
model. One possible mitigation is to split permissions into Recommended (opt-out) and Optional (opt-in) for trusted
apps, as approved by app store, and reviewed/accepted by user at install time. So Camera API might be Recommended for a
camera app, but not for a cookbook app. Geolocation could be Recommended for a GPS navigation app, but not a Camera app.
*Magic button: Use implicit consent via normal user interactions when possible, but we don't have the time to fully
evaluate the technical and use-case risks specific to the magic button approach for 1.0. So we should rely on implicit
UI and web intents for untrusted content and apps, and assume most trusted apps will want permission decisions to be
persisted.
==Open questions for trusted & certified apps==
Need to decide on a package format that provides assurances on app integrity and authenticity, and also allows for
well-defined scope (domain) enforcement so integrity can be maintained at runtime
*We could extend appcache manifest to include hashes, and the app store would sign the whole thing (add magic crypto
dust here). This would allow app assets to still live on website, but have many of the benefits of code signing. This
has issues with defining a clear application scope (i.e. what does a CSP policy of 'self' mean.. we'd need to get
creative and invent a new domain)
*Use existing code/widget package format. We get the benefit of a well-tested format, and the developer doesn't have to
pay for domain registration, hosting, SSL certs, etc. We also get a well-defined domain for each app (ex. jar://myapp)
*Inventing our own Yet Another Installer Package seems like a waste of time, so lets not.
There's been much discussion lately of the different types of applications and so I figured this would be a good time to
summarize the current state of discussion. From a security perspective, there are 3.5 types of applications. Confused
yet? Excellent!
==Types of applications==
1a) Normal web content. Not a type of application per our definition of installed apps, but part of the WebAPI security
continuum and so should be discussed here.
*No app store involved.
*No manifest or installation experience.
*No restrictions on origin or transport (i.e. HTTPS not required).
*All explicit permissions are granted at runtime, not persisted by default.
1b) Installed untrusted applications: Unauthenticated applications provide a manifest, and can optionally be obtained
through an app store.
*No restrictions on transport but limited to one app per origin (though an app may load assets and code from other
origins).
*Installation experience with permissions being opt-in at install and runtime, limited to permissions enumerated in the
manifest.
*No app store code reviews as they'd serve no purpose (app can change anytime without user or reviewer consent).
*No SSL indicators, so trust is limited only to content user is willing to share with any website, and maximum
privileges are likewise limited to what is available to normal web content.
*All explicit permissions are granted at runtime, not persisted by default.
2) Installed trusted application: Authenticated application approved by an app store, with an explicit list of assets
that comprise the app.
*App is reviewed and approved by app store.
*App store signs the app manifest which contains a list of assets and their corresponding hashes.
*App assets are verified & stored locally in appcache.
*Require a CSP policy of "script-src: 'self'; object-src: 'self'; style-src: 'self'" to mitigate content injection
attacks and maintain application integrity.
*Explicit permission grants are persisted by default.
3) Certified application: This category is reserved for apps that require approval by carrier or OEM due to risk of
device corruption or risk to critical functionality. These include apps such as the system settings app, default dialer
(to ensure emergency services are always accessible), core radio and power management, etc.
*All permissions are implicit.
*User cannot modify/disable permissions.
*Approval of certified apps is limited to explicit list of authorized app stores.
==Open questions for trusted apps==
Permission prompting mechanisms. This is currently being led by UX and we will have a detailed proposal to discuss shortly.
*Prompt for security permissions at runtime only, or install-time & runtime?
**Should permissions be visible or in a pulldown at install?
**Initial permission prompt at install or first launch?
**Check/uncheck permissions at install?
*Provide a permission rationale as approved by app store? Yes.
*Concerns that many apps could require a lot of runtime security prompts, resulting in a bad UX and ineffective security
model. One possible mitigation is to split permissions into Recommended (opt-out) and Optional (opt-in) for trusted
apps, as approved by app store, and reviewed/accepted by user at install time. So Camera API might be Recommended for a
camera app, but not for a cookbook app. Geolocation could be Recommended for a GPS navigation app, but not a Camera app.
*Magic button: Use implicit consent via normal user interactions when possible, but we don't have the time to fully
evaluate the technical and use-case risks specific to the magic button approach for 1.0. So we should rely on implicit
UI and web intents for untrusted content and apps, and assume most trusted apps will want permission decisions to be
persisted.
==Open questions for trusted & certified apps==
Need to decide on a package format that provides assurances on app integrity and authenticity, and also allows for
well-defined scope (domain) enforcement so integrity can be maintained at runtime
*We could extend appcache manifest to include hashes, and the app store would sign the whole thing (add magic crypto
dust here). This would allow app assets to still live on website, but have many of the benefits of code signing. This
has issues with defining a clear application scope (i.e. what does a CSP policy of 'self' mean.. we'd need to get
creative and invent a new domain)
*Use existing code/widget package format. We get the benefit of a well-tested format, and the developer doesn't have to
pay for domain registration, hosting, SSL certs, etc. We also get a well-defined domain for each app (ex. jar://myapp)
*Inventing our own Yet Another Installer Package seems like a waste of time, so lets not.
Jim Straus
May 2, 2012, 11:34:49 AM5/2/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
Lucas -
On Background Apps and just to be explicit. If we assume that Background apps always have a UI component that shows up in the home screen, then can we state that when a background component needs a permission that hasn't been granted that the UI component will be opened and the prompt occur there? If we allow Background only apps, I'm not sure where the permission prompt will occur.
Actually, we may want to explicitly state that if an app that is not the currently viewed app and needs permissions that it the app needing the permission is made the currently viewed app.
-Jim Straus
On Background Apps and just to be explicit. If we assume that Background apps always have a UI component that shows up in the home screen, then can we state that when a background component needs a permission that hasn't been granted that the UI component will be opened and the prompt occur there? If we allow Background only apps, I'm not sure where the permission prompt will occur.
Actually, we may want to explicitly state that if an app that is not the currently viewed app and needs permissions that it the app needing the permission is made the currently viewed app.
-Jim Straus
Lucas Adamski
May 4, 2012, 2:36:05 PM5/4/12
to Jim Straus, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
On May 2, 2012, at 8:34 AM, Jim Straus wrote:
> Lucas -
> On Background Apps and just to be explicit. If we assume that Background apps always have a UI component that shows up in the home screen, then can we state that when a background component needs a permission that hasn't been granted that the UI component will be opened and the prompt occur there? If we allow Background only apps, I'm not sure where the permission prompt will occur.
> Actually, we may want to explicitly state that if an app that is not the currently viewed app and needs permissions that it the app needing the permission is made the currently viewed app.
> -Jim Straus
That's an interesting question. Could another approach be that the app needs to have focus to obtain the permissions, and that permission is blocked until it becomes foreground? I think a lot of the permissions really need apps to be focused before they can be granted anyway per our notification model. Its a pretty complicated problem though, depending on if you think of these as apps, or as services.
> Lucas -
> On Background Apps and just to be explicit. If we assume that Background apps always have a UI component that shows up in the home screen, then can we state that when a background component needs a permission that hasn't been granted that the UI component will be opened and the prompt occur there? If we allow Background only apps, I'm not sure where the permission prompt will occur.
> Actually, we may want to explicitly state that if an app that is not the currently viewed app and needs permissions that it the app needing the permission is made the currently viewed app.
> -Jim Straus
Lucas.
Jim Straus
May 4, 2012, 5:14:48 PM5/4/12
to Lucas Adamski, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Mozilla B2G mailing list
In general, I'd buy that permission prompts are deferred until an app comes into focus. Once the permission has been granted or denied, that is going to be sticky, so the app can keep using it in the background. I'm not sure we want to deny access to an API for which permission has been granted when an app is not the focus. Certainly not for every API. I'll have to review the API list to see if there are any that might need that treatment. If there are, we should add it to the API review template.
As for services, these might be things like an alternate keyboard that want access to APIs. There is no specific app for the alternate keyboards (I think the idea at the moment is that these services would have special tagging in the manifest, or register themselves when first installed). The services is invoked by an intent. At that point (at least for input) it does have a displayed component. As an example, a keyboard service may want access to an API (ok, these are a little bit of a stretch, but a keyboard service may want USB to interface to a hardware input device. Or someone got really clever and figured out how to watch your hands with the camera and provide a virtual keyboard). We could show a prompt at that point, but how does the user know it is the keyboard that wants the permission instead of the app that is open? And the notification system may get confusing as well.
Or we just punt it until we have a real use case and just use the must have app focus to have prompts appear (keyboard services never get app focus, so if they tried to use an API it would always be deferred).
-Jim Straus
As for services, these might be things like an alternate keyboard that want access to APIs. There is no specific app for the alternate keyboards (I think the idea at the moment is that these services would have special tagging in the manifest, or register themselves when first installed). The services is invoked by an intent. At that point (at least for input) it does have a displayed component. As an example, a keyboard service may want access to an API (ok, these are a little bit of a stretch, but a keyboard service may want USB to interface to a hardware input device. Or someone got really clever and figured out how to watch your hands with the camera and provide a virtual keyboard). We could show a prompt at that point, but how does the user know it is the keyboard that wants the permission instead of the app that is open? And the notification system may get confusing as well.
Or we just punt it until we have a real use case and just use the must have app focus to have prompts appear (keyboard services never get app focus, so if they tried to use an API it would always be deferred).
-Jim Straus
0 new messages