WebApps - Types of applications

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

WebApps - Types of applications

Lucas Adamski-2
== 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.


_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebApps - Types of applications

JOSE MANUEL CANTERA FONSECA


El 23/03/12 07:45, "Lucas Adamski" <[hidden email]> escribió:

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

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
>[hidden email]
>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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebApps - Types of applications

Scott Wilson-11

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

>
>
> El 23/03/12 07:45, "Lucas Adamski" <[hidden email]> escribió:
>
>> == 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 ===
>
> 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
>> [hidden email]
>> 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
> _______________________________________________
> dev-webapi mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-webapi

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebApps - Types of applications

Adrienne Porter Felt
In reply to this post by Lucas Adamski-2
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.)

On Thursday, March 22, 2012, Lucas Adamski <[hidden email]> wrote:
> == 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.
>
>
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebApps - Types of applications

Kevin Chadwick-2
In reply to this post by Lucas Adamski-2
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
> where a single app may require access to camera/microphone for chat
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebApps - Types of applications

Lucas Adamski-2
In reply to this post by JOSE MANUEL CANTERA FONSECA

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.

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebApps - Types of applications

Lucas Adamski-2
In reply to this post by Adrienne Porter Felt
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.

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebApps - Types of applications

Lucas Adamski-2
In reply to this post by Kevin Chadwick-2
On Mar 23, 2012, at 11:29 AM, Kevin Chadwick wrote:

> 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 where a single app may require access to camera/microphone for chat

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.



_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebApps - Types of applications

ianG-2
In reply to this post by Lucas Adamski-2
On 23/03/12 17:45 PM, Lucas Adamski wrote:
> == Goal ==
> Determine a baseline for the different types of applications in the B2G app ecosystem.


Excellent, let's get them on the whiteboard.  This gives some meat to
the sandwich.  Now for some flavouring...


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

Who or what grants these security permissions?  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.


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

Is that right?  So this is the "browser plugin model" ?



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.


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

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

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



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



Good start!

iang
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebApps - Types of applications

Paul Theriault
In reply to this post by Lucas Adamski-2

>> 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
> _______________________________________________
> dev-b2g mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebApps - Types of applications

Scott Wilson-11
In reply to this post by Scott Wilson-11

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

> On Fri, Mar 23, 2012 at 10:12 AM, Scott Wilson
> <[hidden email]> 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.

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebApps - Types of applications

Scott Wilson-11
In reply to this post by Scott Wilson-11

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

> On Mon, Mar 26, 2012 at 7:30 PM, Scott Wilson
> <[hidden email]> wrote:
>>
>> On 26 Mar 2012, at 18:57, lkcl luke wrote:
>>
>>> On Fri, Mar 23, 2012 at 10:12 AM, Scott Wilson
>>> <[hidden email]> 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 [hidden email]

>
> l.

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebApps - Types of applications

Lucas Adamski-2
In reply to this post by ianG-2


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.

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebApps - Types of applications

Lucas Adamski-2
In reply to this post by Paul Theriault
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.

> 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
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebApps - Types of applications

ianG-2
In reply to this post by Lucas Adamski-2
On 27/03/12 07:45 AM, Lucas Adamski wrote:
[snip]

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

In which case, "we" are responsible for answering if the question of
what happens when the app goes tropo or rogue or steals all the money.
Because that is directly a question of the right incentives and
mitigations :)


> Its the developers responsibility to build great apps that don't put the user at risk, and their fault when they don't.


Wwhen they don't, what are "we" going to do about it?

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

Some skeleton under that fine facade of marketing words - what happens
when it goes wrong?

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


Ah, sorry, red flag!  This is old 1990s security writings that are now
reversed, upturned, deprecated, dead.

Firstly, reliance on the users to make informed choices is a known bad.
  Epic fail.  Indeed, it's so well known that users make no informed
choices, and cannot be relied upon to make informed choices, and can't
reasonably do so anyway, that the claim is one of the biggest deception
of the business.  We know they can't, don't and won't - to say otherwise
risks deception.

Users instead rely totally on their brands and their friends to protect
them, end of story.  This is why Apple is so successful - it worked out
that it had to take a complete and over-arching responsibility.  And why
Microsoft lost the 00s, because it didn't.  Remember Bill Gates memo?
He said we have to take responsibility for security - and his
organisation failed to do that.  End of Microsoft decade.

This is why the Firefox security GUI is not on the chrome - because the
vast majority of users can't cope with any security info, let alone the
complicated, wrong, confused and deceptive information that is thrown at
them if they dig deep and ask what's going on.  BTW, that's practically
Mozilla policy, to not show the user any info.

(BTW, in case you are wondering about this, there is about half a decade
of security UI research that makes that case.  Over in the CA world,
they have thrown in the towel on this debate - vendors are the relying
parties.  Vendors are responsible for looking after the reliance issues
to do with CAs.   That's because they do, already, and can.  While users
don't, never did and cannot.  Very bitter debate, but over now.)


> Nobody is responsible for delivering a panacea, however.


It's tricky!  And, not only because by the time you get where you're
going with those 1990s design assumptions like reliance, here's what
you'll be up against:

http://www.ibtimes.com/articles/316996/20120320/apple-iwallet-iphone-5-feature-mobile-payments.htm

Just one quote:

"However, unlike [their competition], Apple promises its service to be
highly secure and reliable."

And they will achieve that.



iang



PS: in the above quote, they are taking aim at ... what is called
Internet transactions ... which happens to be credit cards ... over SSL.
  See where this is going?
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebApps - Types of applications

Kevin Chadwick-2
On Sat, 31 Mar 2012 20:28:14 +1100
ianG wrote:

> "However, unlike [their competition], Apple promises its service to be
> highly secure and reliable."
>
> And they will achieve that.

On what basis do you believe that, just transport security.

I have a solution for this and Apple and Google are way off anything
that would make me choose to use it.

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebApps - Types of applications

ianG-2
On 1/04/12 03:21 AM, Kevin Chadwick wrote:
> On Sat, 31 Mar 2012 20:28:14 +1100
> ianG wrote:
>
>> "However, unlike [their competition], Apple promises its service to be
>> highly secure and reliable."
>>
>> And they will achieve that.
>
> On what basis do you believe that,

Because I can see their business mind, and how they integrate it into
the product.  The business model drives the product, not the other way
around.  Consider it top-down not bottom-up.  The problem with bottom-up
designs is that you can't see far enough up the pyramid to see what it
is you are supporting.  But you have a lot of fun building great
supporting building blocks, so you carry on :)

(I'll leave aside the problems with top-down :)

> just transport security.


If you've got transport security, you've got nothing.

Transport security is an old idea going back to the days of ISO's 7
layer model.  Layer 5, from memory.  It's a building block approach -
"and now we add the security module and our job is done."  Curiously,
security layering was one of the bad ideas that the Internet didn't
eliminate.  Much to our cost.


> I have a solution for this and Apple and Google are way off anything
> that would make me choose to use it.


Well, ok.  I understand that you don't want to simply copy them.  And
you probably can't - you have a different resource mix.

But, they are the competition - so they deserve comparison if not copying.

A simplistic comparison here was code reviews.  Apple makes it "safe" by
doing reviews of code.  They also create barriers to get in.  If you
muck up you're kicked out - that's a punishment, you lose all your input
costs.

My question was, what happens when an app goes postal?  Well, Apple have
an answer.


iang
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Types of applications - Proposal and next steps

Lucas Adamski-2
In reply to this post by Scott Wilson-11
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.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Types of applications - Proposal and next steps

Kevin Chadwick-2
Looks like a good start.

especially

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

If the devs can find the time, a short list of requested permissions
and a more fine grained advanced menu would be good. The hardest part
being making sure they are difficult to generically bypass as Google
have found out.

Also an app dev being able to mark some of the requested permissions as
essential perhaps with an optional comment to flag up for an "are you
sure" in the advanced menu without actually forcing that permission
would be good even if devs often just request all permissions to save
themselves time?
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] Types of applications - Proposal and next steps

Jonas Sicking-2
In reply to this post by Lucas Adamski-2
On Mon, Apr 2, 2012 at 10:58 AM, Lucas Adamski <[hidden email]> 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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
12