WebApps - Types of applications

[Lucas Adamski]

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

[Henri Sivonen]

On Fri, Mar 23, 2012 at 8:45 AM, Lucas Adamski <lada...@mozilla.com> wrote:
> === Installed applications with WebAPI access ===

...

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

This looks worryingly close to the Android security model that's known
to be bad, because:
1) The assumption that installation implies trust is wrong. The user
may just want quick access or access at all and may not trust the app
provider. (Personally, I don't trust game developers who want to read
my SMSs, make call, read my call logs or read my IMEI, but their games
might be fun to play.)
2) The user can't make an informed choice to grant "explicit access

to the bulk of the rest".

I think installation should grant implied access to APIs whose danger
level is "annoyance" (e.g. notifications) and "consumes resources"
(IndexedDB).

I think access to APIs whose danger level involves privacy should be
granted by the user in the context of an interaction that needs
privacy-sensitive access. This way, the user has a better idea of
understanding the context of the permission than in the case where the
user has to sign off to a manifest that grants "explicit access to the
bulk of the rest" up front.

I think a manifest of permissions should only be used by the developer
to self-impose a *permission cap* to mitigate bugs/compromises ahead
of time.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[JOSE MANUEL CANTERA FONSECA]

El 23/03/12 07:45, "Lucas Adamski" <lada...@mozilla.com> escribió:

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

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

Why don't we call them 'Trusted Core Applications'?

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

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.

Or by the carrier / manufacturer

>
>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'?

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

[Mounir Lamouri]

On 03/23/2012 09: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 ...

I believe those are called "bookmarked website", not applications.

--
Mounir

[Mounir Lamouri]

On 03/23/2012 07:45 AM, Lucas Adamski wrote:
> === 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.

IIUC, this last category of applications will be able to access some
APIs that are not available to website and regular installed applications?
Except WebTelephony, I don't see any API that would fit that category.

--
Mounir

[JOSE MANUEL CANTERA FONSECA]

El 23/03/12 11:33, "Mounir Lamouri" <mou...@lamouri.fr> escribió:

WiFi / Mobile Network Connection, Camera Low Level, App installation /
uninstallation ...

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

[Adrienne Porter Felt]

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

> === Installed applications with WebAPI access ===

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

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

[Kevin Chadwick]

On Thu, 22 Mar 2012 23:45:47 -0700
Lucas Adamski wrote:

Untrusted

> They might want to capture audio or video input to stream to a server or process client-side,

Input from?

What's the distinction here, only via e.g. a flash plugin with it's own
permissions? Stories of phones without camera covers being a corporate
security risk, spring to mind.


Trusted somewhat

[Lucas Adamski]

On Mar 23, 2012, at 1:28 AM, Henri Sivonen wrote:

> On Fri, Mar 23, 2012 at 8:45 AM, Lucas Adamski <lada...@mozilla.com> wrote:

>> === Installed applications with WebAPI access ===

> ...

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

> This looks worryingly close to the Android security model that's known
> to be bad, because:
> 1) The assumption that installation implies trust is wrong. The user
> may just want quick access or access at all and may not trust the app
> provider. (Personally, I don't trust game developers who want to read
> my SMSs, make call, read my call logs or read my IMEI, but their games
> might be fun to play.)
> 2) The user can't make an informed choice to grant "explicit access
> to the bulk of the rest".
>
> I think installation should grant implied access to APIs whose danger
> level is "annoyance" (e.g. notifications) and "consumes resources"
> (IndexedDB).

I feel like you built a bit of a strawman there, then tore it down. We haven't defined what this degree of trust implies, and I think that's the next step of talking through each API and deciding what sort of API access / controls should be implemented for each application category. Maybe "trust" is not even the right word; maybe its more about "assumptions" that a user would hold about how an app can behave vs. a web page.

> I think access to APIs whose danger level involves privacy should be
> granted by the user in the context of an interaction that needs
> privacy-sensitive access. This way, the user has a better idea of
> understanding the context of the permission than in the case where the

> user has to sign off to a manifest that grants "explicit access to the
> bulk of the rest" up front.

Probably, but we are jumping ahead a bit. :)
Lucas.

[Lucas Adamski]

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.

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

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

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

On Mar 23, 2012, at 3:30 AM, Mounir Lamouri wrote:

> On 03/23/2012 09: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 ...
>

> I believe those are called "bookmarked website", not applications.

True. Its an open question whether that's a different type of app, or simply a variant on the first category.
Lucas.

[Lucas Adamski]

On Mar 23, 2012, at 3:33 AM, Mounir Lamouri wrote:

> On 03/23/2012 07:45 AM, Lucas Adamski wrote:
>> === Installed applications with OS-level API access ===

>
> IIUC, this last category of applications will be able to access some
> APIs that are not available to website and regular installed applications?
> Except WebTelephony, I don't see any API that would fit that category.
>

Yes, but they may also have other implicit privileges that regular installable web apps would have to request explicitly, such as contacts, mobile connection, USB, etc.
Lucas.

[Lucas Adamski]

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

[Lucas Adamski]

Input from the device's built in camera / microphone. That's the relevant discussion to have when we talk about the camera (webRTC) APIs. Maybe explicitly requested access is generally ok, but implicit access may or may not ever be ok (say for trusted core apps). I suspect that's a long thread by itself.
Lucas.

[Henri Sivonen]

On Fri, Mar 23, 2012 at 9:26 PM, Lucas Adamski <lada...@mozilla.com> wrote:
> On Mar 23, 2012, at 1:28 AM, Henri Sivonen wrote:
>
>> On Fri, Mar 23, 2012 at 8:45 AM, Lucas Adamski <lada...@mozilla.com> wrote:
>>> === Installed applications with WebAPI access ===
>> ...
>>> 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.
>>
>> This looks worryingly close to the Android security model that's known
>> to be bad, because:

...

> I feel like you built a bit of a strawman there, then tore it down.  We haven't defined what this degree of trust implies

Sorry. I didn't mean to do that. I was taking "intergrity of the OS or
expose the user to direct financial risk" as the suggested bar and I
think that's not the right bar. Also, "explicit access to the bulk of
the rest" in the context of "install" "implies" trust seemed a lot
like up-front authorization.

[Paul Theriault]

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

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

[Scott Wilson]

On 23 Mar 2012, at 08:51, JOSE MANUEL CANTERA FONSECA wrote:

>
>
> El 23/03/12 07:45, "Lucas Adamski" <lada...@mozilla.com> escribió:
>

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

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

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

> Why don't we call them 'Trusted Core Applications'?
>

>> 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.
>
> And probably after the carrier manufacturer has verified them

See: http://www.w3.org/TR/widgets-digsig/

>
>>
>> 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.
>
> Or by the carrier / manufacturer
>
>>

>> 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'?

See: http://www.w3.org/TR/widgets-access/

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

[Scott Wilson]

On 26 Mar 2012, at 18:57, lkcl luke wrote:

> On Fri, Mar 23, 2012 at 10:12 AM, Scott Wilson
> <scott.brad...@gmail.com> wrote:
>> See: http://www.w3.org/TR/widgets-digsig/
>
> well now, scott - that is veeery interesting, and incredibly useful,
> because it is *exactly* the same thing - bar the file-formats - that
> all the top GNU/Linux Distributions do.
>
> thank you very much for this: i'll add it to the wiki in the section on
> https://wiki.mozilla.org/Apps/Security#Secure_Application_Distribution

np :)

>
> btw do you happen to know of any actual implementations (especially
> free software ones)?

There is a GSoC project to implement it in Apache Wookie, which already has student interest, so I'm sure we'll have an open source implementation by the end of Summer :)

On the commercial side, its been implemented by Opera, Nokia, Vodafone, Samsung, Obigo, RIM and a bunch of web TV platforms as its part of a lot of other spec stacks in the mobile and TV space such as WAC, MPEG-U, HbbTV, CMX (etc).

There have been some packaging and signing tools supporting the specs issued as part of SDKs, e.g. the Vodafone widget packager and the WAC SDK (I think Samsung/Limo wrote that one). I think the Blackberry webapps signing tools also uses widgets-digsig as Blackberry Widgets are W3C Widgets - I seem to remember RIM open-sourcing most of their Widgets code last year so that may be another lead.

>
> l.

[Mounir Lamouri]

On 03/23/2012 03:37 AM, JOSE MANUEL CANTERA FONSECA wrote:
> El 23/03/12 11:33, "Mounir Lamouri" <mou...@lamouri.fr> escribió:

>> On 03/23/2012 07:45 AM, Lucas Adamski wrote:

>>> === Installed applications with OS-level API access ===

>>> [...]

>>>
>>> Scope: Security permissions are granted to code enumerated in the
>>> manifest.
>>

>> IIUC, this last category of applications will be able to access some
>> APIs that are not available to website and regular installed applications?
>> Except WebTelephony, I don't see any API that would fit that category.
>

> WiFi / Mobile Network Connection, Camera Low Level, App installation /
> uninstallation ...

I think we should be very careful with forbidding all applications to
access a specific API. IMO, I think we should do that only if we have
very specific reasons (like WebTelephony).
It would be reasonable to mark some APIs as very sensitive so it would
require the app store to vouches the application. For example, WebSMS
might be very sensitive but I see no valid reason to just forbid it.

--
Mounir

[Mounir Lamouri]

On 03/26/2012 01:02 PM, lkcl luke wrote:

> On Mon, Mar 26, 2012 at 8:51 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
>> I think we should be very careful with forbidding all applications to
>> access a specific API. IMO, I think we should do that only if we have
>> very specific reasons (like WebTelephony).
>> It would be reasonable to mark some APIs as very sensitive so it would
>> require the app store to vouches the application. For example, WebSMS
>> might be very sensitive but I see no valid reason to just forbid it.
>

> [...]
>
> if SMS isn't protected, thieves *will* start creating applications
> that steal people's money, or work out ways to compromise the B2G
> application if it doesn't have proper security in place.

I never said it shouldn't be protected but *forbidden*.
That's two very different things. I would understand we make this API
harder to use but it should not be *impossible* to use.

--
Mounir

[Paul Theriault]

My expectation was that things like SMS would be split in the parts
which could be dangerous (e.g. send a message, since that costs the user
money, can be used to sign-up for paid services, at least here in
Australia anyway) and other less sensitive parts. For example, your
trusted core app might have access to directly send SMS messages, since
it needs to be the one which presents a trusted interface for sending
(ie the one the user recognizes as the "sms app"). Less privileged apps
might not be able to send directly, but they could send the data to the
trusted SMS app for it to send. (which I guess might be part of web
activities?). And less trusted apps might be able to request to other
less sensitive SMS functions like reading sms messages, depending on the
user's privacy settings. (Although on reflection, SMS used frequently
for 2-factor authentication, so that changes that threat model somewhat,
but this is a different discussion)

I agree though that just flat-out banning of certain APIs would be a bad
thing for the capability of web apps in general.

[Scott Wilson]

On 26 Mar 2012, at 19:38, lkcl luke wrote:

> On Mon, Mar 26, 2012 at 7:30 PM, Scott Wilson
> <scott.brad...@gmail.com> wrote:
>>
>> On 26 Mar 2012, at 18:57, lkcl luke wrote:
>>
>>> On Fri, Mar 23, 2012 at 10:12 AM, Scott Wilson
>>> <scott.brad...@gmail.com> wrote:
>>>> See: http://www.w3.org/TR/widgets-digsig/
>>>
>>> well now, scott - that is veeery interesting, and incredibly useful,
>>> because it is *exactly* the same thing - bar the file-formats - that
>>> all the top GNU/Linux Distributions do.
>>>
>>> thank you very much for this: i'll add it to the wiki in the section on
>>> https://wiki.mozilla.org/Apps/Security#Secure_Application_Distribution
>>
>> np :)
>>
>>>
>>> btw do you happen to know of any actual implementations (especially
>>> free software ones)?
>>
>> There is a GSoC project to implement it in Apache Wookie, which already has student interest, so I'm sure we'll have an open source implementation by the end of Summer :)
>

> eyy, superb.

>
>> On the commercial side, its been implemented by Opera, Nokia, Vodafone, Samsung, Obigo, RIM and a bunch of web TV platforms as its part of a lot of other spec stacks in the mobile and TV space such as WAC, MPEG-U, HbbTV, CMX (etc).
>>
>> There have been some packaging and signing tools supporting the specs issued as part of SDKs, e.g. the Vodafone widget packager and the WAC SDK (I think Samsung/Limo wrote that one). I think the Blackberry webapps signing tools also uses widgets-digsig as Blackberry Widgets are W3C Widgets - I seem to remember RIM open-sourcing most of their Widgets code last year so that may be another lead.
>

> wow. that's... rather cool. that gives plenty of leads for the B2G
> team to investigate (hope you don't mind but i'm just going to
> cut/paste most of what you've just written up onto the wiki, so it's
> not lost in the noise).

(Not at all, glad to help...)

> but... that actually means that it's a standard that's *already*
> being adopted by the very telcos (vodafone, RIM) that B2G is targetted
> at. interesting.

The W3C Widgets family of specs was developed very much with mobile in mind, so its been adopted in one form or another by a lot of telcos and can be used on a variety of handsets and OS's. You can even make them run on a Nokia Series 40 :-o

(I also seem to remember a note about B2G from Telefonica about it supporting WAC)

((There was some communication between Moz OWA and the Widgets groups ages back, but it sort of fizzled, partly as I think at W3C the focus was on packaged and installed apps, and OWA was more into app store APIs. And the people with the patience to contribute to both communities moved on))

>
> hey, you wouldn't happen to know if any of the implementors of W3C
> XML Digital Widgets adopted SSL at all, would you? the primary
> expertise of the mozilla team is of course in SSL, and the continued
> recommendation to use it has me deeply concerned.


Hmm don't know - maybe worth a quick post to public-nati...@w3.org

>
> l.

[Lucas Adamski]

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

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

> Who or what grants these security permissions?

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.

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

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

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

> This I'm not understanding, sorry. How can the store grant "trust" (a bad word) on a user's computer? Surely when
> 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.
>

> OK. So this "badness" leads to another point. If (for whatever logic) we are led to the point where a carrier /
> 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]

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

[Lucas Adamski]

On 3/26/2012 12:51 PM, Mounir Lamouri wrote:
> I think we should be very careful with forbidding all applications to

> access a specific API. IMO, I think we should do that only if we have
> very specific reasons (like WebTelephony).
> It would be reasonable to mark some APIs as very sensitive so it would
> require the app store to vouches the application. For example, WebSMS

> might be very sensitive but I see no valid reason to just forbid it.
>
> --
> Mounir
> _______________________________________________

Well, I think we can agree that if we bar all apps from accessing a certain API, then there's no reason to implement it.
:) I think the key questions will be
a) what's the worst damage that could result if that API is abused
b) what are the possible mitigations to a)

When the damage is severe and we can't mitigate the risk, then access to that API may be heavily restricted. webUSB
comes to mind as an example of that.
Lucas.

[Paul Theriault]

My understanding from the previous thread, was that this doesn't need to
be treated as a different type of Web App. The level of trust that a
store can grant depends on how much that user trusts that store (i.e. is
the store registered in the device as a trusted store). You can still
install an app from an untrusted store, or even a website can ask to
have itself installed, however it wont be possible for apps installed in
this manner to gain very many (or any?) privileges beyond that of a
regular web page since the granting App Store isn't trusted.


On 3/24/12 6:42 AM, Lucas Adamski wrote:
> On Mar 23, 2012, at 3:30 AM, Mounir Lamouri wrote:

>
>> On 03/23/2012 09: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 ...

>> I believe those are called "bookmarked website", not applications.
> True. Its an open question whether that's a different type of app, or simply a variant on the first category.
> Lucas.

[Paul Theriault]

(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

[Asa Dotzler]

On 3/26/2012 6:58 PM, Paul Theriault wrote:
> My understanding from the previous thread, was that this doesn't need to
> be treated as a different type of Web App. The level of trust that a
> store can grant depends on how much that user trusts that store (i.e. is
> the store registered in the device as a trusted store). You can still
> install an app from an untrusted store, or even a website can ask to
> have itself installed, however it wont be possible for apps installed in
> this manner to gain very many (or any?) privileges beyond that of a
> regular web page since the granting App Store isn't trusted.

Can you describe what you mean by "regular web page" here? I was under
the, perhaps wrong, impression that "the Web is the platform" and that
all these nifty new APIs were going to be available to Web developers
targeting browsers.

Has that changed? Am I just confused? Or are you suggesting that what
we're actually building is a non-Web stack that just happens to use the
popular languages of the Web?

- A

[Lucas Adamski]

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

[Paul Theriault]

By regular web page, I mean a page that is not installed as an App. My
assumption was that not all of the new APIs would be available to web
pages (or maybe they would be available, but their use might require
some kind of user interaction on web pages, where as on web apps they
might just be available - it depends on which permission you are
talking about). All I was trying to say was that a web app installed
from a less trusted store is not a different type of web app, it is
just a web app with a lower level of permissions available to it, or
that is how I understood the original proposal for app stores.

On Tue Mar 27 13:07:53 2012, Asa Dotzler wrote:
> On 3/26/2012 6:58 PM, Paul Theriault wrote:

>> My understanding from the previous thread, was that this doesn't need to
>> be treated as a different type of Web App. The level of trust that a
>> store can grant depends on how much that user trusts that store (i.e. is
>> the store registered in the device as a trusted store). You can still
>> install an app from an untrusted store, or even a website can ask to
>> have itself installed, however it wont be possible for apps installed in
>> this manner to gain very many (or any?) privileges beyond that of a
>> regular web page since the granting App Store isn't trusted.
>

> Can you describe what you mean by "regular web page" here? I was under
> the, perhaps wrong, impression that "the Web is the platform" and that
> all these nifty new APIs were going to be available to Web developers
> targeting browsers.
>
> Has that changed? Am I just confused? Or are you suggesting that what
> we're actually building is a non-Web stack that just happens to use
> the popular languages of the Web?
>
> - A

[Lucas Adamski]

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.

[Jonas Sicking]

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)
>
> 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
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
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]

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.

[Jim Straus]

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 Adamski]

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.

[Jim Straus]

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