WebAPI Security Discussion: Open Web App API

[Lucas Adamski]

Please reply-to dev-w...@lists.mozilla.org

Name of API: Open Web App API
Reference: https://developer.mozilla.org/en/OpenWebApps/The_JavaScript_API

Brief purpose of API: The Open Web Apps JavaScript API is a programmatic interface for installing Web apps and for managing a client-side collection of Web apps that a user has installed.

General Use Cases:
* Install an app - navigator.mozApps.install(url, [install_data])
* A web page can check if it is installed - navigator.mozApps.getSelf()
* Return a list of installed apps installed by this domain - navigator.mozApps.getInstalled()

Inherent threats:
* Installation grants some minor additional privileges
* Access to install an app on another domain introduces risks
* Privacy (users can be identified by list of apps)

Threat severity: Low for Installation API, High for Management API

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Just the general cases as above.
Authorization model for normal content: Explicit for install (OS Mediated), Implicit for check status
Authorization model for installed content:Explicit for install (OS Mediated), Implicit for check status
Potential mitigations: getInstalled() only returns the apps installed by the current domain

== Trusted (authenticated by publisher) ==
Use cases for authenticated code:
A "dashboard" can manage and launch Apps on the users behalf
A "dashboard" can monitor the state of logged in applications
Authorization model: Implicit, execpt Remove App is Explicit (OS Mediated)
Potential mitigations:

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Same as trusted
Authorization model: Implicit
Potential mitigations:

Note: not sure if management functions belong in trusted or privileged. This is probably a subject for discussion.

[Jim Straus]

How about un-install an app, update an app (assuming that the app has a cached component and we can distinguish when cached components change, and also that we desire that the user can control when an app is updated).
I also think that the risks for some of the APIs vary. For example, getSelf() doesn't seem like a risk. un-install an app seems much higher (if an app can un-install others locally stored data would be lost), and the list of installed apps has the potential for fingerprinting (though also potentially useful for an app developer cross-selling another of their apps if you don't have it already). Maybe we just group the permissions into two buckets with the low/no risk APIs always granted and the others needing permission.

> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps

[Jordano Francisco (UK)]

Hi,

As far as I know, you can do an uninstall now. Regarding the update
functionality I guess it will work a bit different, each time you visit a
new web app, if the cache manifest changes, or even if you don't have an
offline version and you are always using the online one, the system will
automatically download for you the new elements of the app.

Cheers,
F.

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


This electronic message contains information from Telefonica UK, Telefonica Europe or Telefonica Digital which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email.


Switchboard: +44 (0)113 272 2000
Email: feed...@o2.com

Telefonica UK Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85
Telefonica Europe plc 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 05310128. VAT number: GB 778 6037 85
Telefonica Digital Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 7884976. VAT number: GB 778 6037 85

[Fabrice Desré]

On 04/16/2012 10:22 AM, Jim Straus wrote:
> How about un-install an app, update an app (assuming that the app has a cached component and we can distinguish when cached components change, and also that we desire that the user can control when an app is updated).
> I also think that the risks for some of the APIs vary. For example, getSelf() doesn't seem like a risk. un-install an app seems much higher (if an app can un-install others locally stored data would be lost), and the list of installed apps has the potential for fingerprinting (though also potentially useful for an app developer cross-selling another of their apps if you don't have it already). Maybe we just group the permissions into two buckets with the low/no risk APIs always granted and the others needing permission.

uninstall() is a method of the application object itself. Since you can
only get apps that you installed from (using getInstalled()) or yourself
(using getSelf()) this mitigates the risks. Only apps having high
privileges can use mgmt.getAll() to see cross-stores installs.

Fabrice
--
Fabrice Desré
b2g Team
Mozilla Corporation

[Lucas Adamski]

Updated proposal. Please reply-to dev-w...@lists.mozilla.org

Name of API: Open Web App API
Reference: https://developer.mozilla.org/en/OpenWebApps/The_JavaScript_API

Brief purpose of API: The Open Web Apps JavaScript API is a programmatic interface for installing Web apps and for managing a client-side collection of Web apps that a user has installed.

General Use Cases:
* Install an app - navigator.mozApps.install(url, [install_data])
* A web page can check if it is installed - navigator.mozApps.getSelf()
* Return a list of installed apps installed by this domain - navigator.mozApps.getInstalled()

Inherent threats:
* Installation grants some minor additional privileges
* Access to install an app on another domain introduces risks
* Privacy (users can be identified by list of apps)

Threat severity: Low for Installation API, High for Management API

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Just the general cases as above.
Authorization model for normal content: Explicit for install (OS Mediated), Implicit for check status
Authorization model for installed content: Explicit for install (OS Mediated), Implicit for check status
Potential mitigations: getInstalled() only returns the apps installed by the current domain

== Trusted (authenticated by publisher) ==
Use cases for authenticated code:
A "dashboard" can manage and launch Apps on the users behalf
A "dashboard" can monitor the state of logged in applications

Authorization model: Implicit, except Remove App is Explicit (OS Mediated)
Potential mitigations:
* uninstall() is a method of the application object itself. Since you can only get apps that you installed from (using getInstalled()) or yourself (using getSelf()) this mitigates the risks. [fabrice]

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Same as trusted
Authorization model: Implicit

Potential mitigations: Only apps having high privileges can use mgmt.getAll() to see cross-stores installs. [fabrice]

[Lucas Adamski]

On Apr 21, 2012, at 10:35 PM, Thinker K.F. Li wrote:

> Hi,
>
> Although we donwload pages automatically if the cache manifest changes,
> but the new cache will only be used for next time of launching.
>
> I concern more about faults of networks. Internet is not always stable
> and secured. For some buggy implementations of infrastructures, the
> cache manifest can be broken or touched. We can not tell, for now, if a
> copy of the cache manifest is complete or not. These situation can kill
> the app from the offline cache. More worse is that you get only a part
> of lauch path or a changed copy, but you don't know it, and it can not
> used to trigger an updating (no manifest attribute of html tag). The
> only thing you can do is to reinstall it after an uninstalling if you
> aware it.
>
> So, I think app manifests and cache manifests need some kind of integral
> checking. We also need to provide a way that the user can control when
> to udpate. I don't like to update the apps when I was jailed behind
> some kind of firewall (national level, sigh!).
>

Not related to Open Web Apps API per se, but that is the intent of authenticated (trusted) and certified apps. The authenticity and integrity of the app would be verified, assuring that the user received the same unmodified & complete app that the app store reviewed and approved.

Now if you're asking about unauthenticated apps, its true that providing the integrity checks without authenticity verification would still provide some useful benefits. Thanks!
Lucas.

[Jim Straus]

Along the lines of Thinker's remarks about controlling when to update, some updates may be large (a new set of maps for an offline navigation app is a good example) and I might not want to update them when on a paid or slow pipe (cellular). Also, I sometimes don't update if comments indicate an app has become less stable (I'll wait for a follow on update) or has lost some portion of functionality.
-Jim Straus

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

[Lucas Adamski]

On 4/18/2012 11:18 AM, Fabrice Desré wrote:
> On 04/16/2012 10:22 AM, Jim Straus wrote:
>> How about un-install an app, update an app (assuming that the app has a cached component and we can distinguish when
>> cached components change, and also that we desire that the user can control when an app is updated).
>> I also think that the risks for some of the APIs vary. For example, getSelf() doesn't seem like a risk. un-install
>> an app seems much higher (if an app can un-install others locally stored data would be lost), and the list of
>> installed apps has the potential for fingerprinting (though also potentially useful for an app developer
>> cross-selling another of their apps if you don't have it already). Maybe we just group the permissions into two
>> buckets with the low/no risk APIs always granted and the others needing permission.
>

> uninstall() is a method of the application object itself. Since you can only get apps that you installed from (using

> getInstalled()) or yourself (using getSelf()) this mitigates the risks. Only apps having high privileges can use

> mgmt.getAll() to see cross-stores installs.
>

> Fabrice

I was just scrubbing the web API security discussions, and this thread jumped out at me. After discussing with Jonas
I'm still concerned that we need to have a consistent experience when installing and uninstalling apps is concerned. If
a user happens to discover app B through random website (or app) A, then they won't expect that website A now has the
ability to uninstall that app without user consent. The typical pattern there is site A would send the user to an
established app store which the user would then visit to manage their apps.

If random site A now has the ability to uninstall it, they could delete app B when/if the user randomly ends up on site
A again (even if for a technically valid reason, like a malicious app), without the user ever being aware of
when/how/why it disappeared. This seems like a crappy experience all around.

So I think we always need UI for app installation and uninstallation to maintain user sovereignty over their device.
Lucas.