Application security

  • Revision slug: Mozilla/Firefox_OS/Security/Application_security
  • Revision title: Application security
  • Revision id: 401129
  • Created:
  • Creator: crcr
  • Is current revision? No
  • Comment

Revision Content

{{draft}}

Firefox OS includes new APIs which provide Open Web Apps access to a range of native device capabilities, such as access to cameras, bluetooth, network connections and other APIs not previously exposed to the Web.  A variety of security mechanisms have also been introduced to increase the trustworthiness of apps to the point where they can be trusted with these new APIs. The key Open Web App security controls are:

  • Apps are explicitly installed and launched, rather than being casually navigated to in a browser. Apps must be installed prior to use, and security controls govern the update and removal of apps to protect the user.
  • Access to new Web APIs is controlled by a permissions system, where an app must declare the permissions it intends to use prior to installation. In order to gain access to more powerful APIs, apps must meet certain requirements and be reviewed, approved, and signed by a marketplace such as the Firefox Marketplace.
  • Apps are sandboxed so they can only see their own resources (cookies, offline storage, IndexedDB databases, and so on). Even if two apps happen to load a page with the same URL, these two pages are not considered same-origin because they are running inside separate apps.

Application Types & Lifecycle

The table below summarizes the different types of Open Web Apps and describes the format, installation, and update process.

Web App Types
Type Delivery Permission Level Installation Updates
Web Hosted or Packaged Less-sensitive permissions that are not dangerous to expose to unvalidated Web content Installed from anywhere Can be updated transparently to the user or explicitly through a marketplace, depending on where the app was installed from, and the delivery mechanism.
Privileged Packaged Privileged APIs which require validation and authentication of the app Installed from a trusted marketplace Updated via a trusted marketplace, user prompted to approve download and installation of updates.
Certified Packaged Powerful and dangerous APIs which are not available to third-party apps. Pre-installed on the device Updated only as part of system level updates.

App types

Firefox OS supports three types of apps: web, privileged, and certified. An app's type is declared in its manifest, and determines the list of permissions it may request.

  • Web Apps: Most third-party apps will be "Web" Apps, which is the default type, and doesn't grant the App any additional permissions besides those already exposed to the web. Web Apps can be installed from any website, without any further verification, but as a
  • Privileged Apps: These Apps are allowed to request increased permissions, and as such Privileged Apps must be verified and signed by a Marketplace
  • Certified Apps: Certified Apps can currently only be pre-installed on the device.

For further details of the three types, see Manifest and Packaged apps.

App delivery

Apps can be delivered by two different mechanisms: hosted or packaged.

Hosted apps

A hosted app consists solely of an application manifest file on the developer's Web server. Often the manifest will also point to an appcache manifest which allows an app to be cached for faster startup and to enable offline usage, but otherwise doesn't affect the app at all. From a security point of view, hosted apps work very much like normal websites. When a hosted app is loaded, the URL of the loaded pages are the normal URLs that those pages have on their web server. So to link to a specific page or resource in the app, the same URL is used as when linking to that page or URL on the website.

Packaged apps

A packaged app is an Open Web App that has all of its resources (HTML, CSS, JavaScript, app manifest, and so on) contained in a zip file, instead of having its resources on a Web server. For details of this format, see Packaged apps

App Installation

Apps are installed using the Apps Javascript API:

  • Hosted apps: Hosted apps are installed by calling navigator.mozApps.install(manifestURL), where manifestURL is a URL that specifies the location of the app. For further details, see Installing Apps.
  • Packaged apps: For packaged apps, the main application manifest is stored inside the package itself, so that it can be signed. There is a second "mini-manifest" that is used to start the installation and update process on the marketplace. See Installing Packaged Apps and Packaged apps for more information.

In order to secure an app wants to be installed, we have to ensure that it's not possible to trick a website into hosting an application manifest. This is done by requiring that the manifest is served with a specific mime-type, application/x-web-app-manifest+json. This restriction is relaxed when the manifest file, and thus the app manifest, is same-origin with the page that requested the app to be installed.

Updates

The update process for apps is described in Updating apps.

Permissions

Apps may be granted additional privileges on top of the ones granted to normal websites. By default an application has no permissions on top of the ones normal webpages have. An app can request additional permissions by enumerating the permissions in its manifest. Enumerating a permission does not guarantee that an app will be granted the permission. The Web runtime may decide to not grant access.

Manifest declaration

For each additional permission that an app wants, the manifest has to explicitly enumerate that permission along with a human-readable description of why the app wants that permission. This description will be used at various points in the device UI, and is also used when the app is reviewed. For further detail on manifests, see App manifest.

Granting permissions

 

Revoking permissions

 

Web app sandbox

Data stored per app

Each appl runs in a separate sandbox, meaning that all data stored by an app is separate from all data stored by another app. This includes things like cookie data, localStorage data, indexedDB data, and site permissions.

This means that if the user has two apps installed, app A and app B, these apps will have completely different sets of cookies, different local data, and different permissions. This even applies if both of these apps open an <iframe> that points to the same origin. For example, if both app A and app B open an <iframe> pointing to "http://www.mozilla.org", they will both render the website, however the website will be fetched and rendered with different cookies in the two apps.

A result of this is that if the user logs in to Facebook, for example, while using app A, this in no way affects app B's ability to interact with the user's account on Facebook. The login cookie that Facebook sets when the user logs in using app A is only available in app A. If app B open an <iframe> to Facebook, the cookie wouldn't be there and so when app B opens Facebook, it receives the Facebook login page rather than the user's account.

Apps can't open each other

This means that apps can't open other apps by using <iframe>s. If app A creates an <iframe> with src set to the URL of app B, this won't actually open app B in the <iframe>. It will simply open the website located at that URL. It will not use any of app B's cookies and so it will behave no differently than if app B wasn't installed on the user's device.

This applies even for packaged apps (more about them below). App A may not open packaged app B  using an <iframe> pointing to the app:// URL of app B under normal circumstances. Web content also may not access app:// URLs. Attempting to access an app:// URL from Web content or without the proper permssion will fail and return an error. And App A can access contents of app B if app A has the webapps-manage permission which is only available to certified apps.

The same thing happens if the top-level frame of app A is navigated to a URL for app B. We always know for a given frame which app is opened in it, and so when attempting to load the app B URL in the app A frame, this will behave exactly like the two situations described above. That is, in no way will app B's resources, like cookies or other local data, be used.

Motivation

There are both benefits and downsides to this approach. The downside is that if the user interacts with the same website through several apps, he or she will have to log in in every app. Likewise, if a website wants to store data locally, and the user interacts with this website in several apps, the data will end up getting duplicated in each app, which could be a problem if it's a large amount of data.

The main benefit of this approach is that it's a more stable model. There is no way that several apps could interact with each other through a third-party website in unexpected ways such that installing an app causes another app to stop working. When an app is uninstalled there is no way that data for another app could be lost, or that another app will stop working due to functional dependence of the uninstalled app.

There are also large security benefits. A user can safely use his AwesomeSocial app to log in to Facebook without having to worry that the SketchGame app can mount any types of attack for getting at the user's Facebook data by exploiting bugs or other shortcomings in the Facebook website.

There are also good privacy benefits. The user can safely install the PoliticalPartyPlus app without having to worry that MegaCorpEmployee app will be able to detect that the app was installed or what data it has created.

Sandboxed permissions

And just like website data is sandboxed per app, so are permission grants. If app A loads a page from http://maps.google.com and that page requests to use geolocation and the user says "yes and remember this decision for all times," this only means that http://maps.google.com has access to geolocation within app A. If app B then opens http://maps.google.com, that page won't have access to geolocation unless the user grants that permission again for app B.

And just like in the normal browser, permissions are separated by origin. This means that if app A is granted permission to use geolocation, this does not mean that all origins running in app A have the permission to use geolocation. If app A opens an <iframe> to http://maps.google.com, then http://maps.google.com still has to ask the user for permission before geolocation access is granted.

Browser API sandbox

To additionally secure applications that open a large set of URLs, such as browsers, we have added a browserContent flag. The browserContent flag allows each app to have not one, but two sandboxes, one for the app itself, and one for any Web content that it opens. For example, say that the MyBrowser app is loaded from the https://mybrowser.com domain. This is the domain where the scripts and resources are loaded within. The scripts and resources belong to this domain.

Now, if a page in this app creates an <iframe mozbrowser>, a different sandbox is created and used for this <iframe>, which is different from the sandbox used by the app. That is, if this iframe is navigated to https://mybrowser.com, it will result in different cookies being used inside the <iframe mozbrowser>. Likewise, the contents inside the <iframe mozbrowser> will see different IndexedDB and localStorage databases from the ones opened by the app.

This also applies if the MyBrowser app wants to create integration with, for example, Google maps, to implement location-based browsing. If the app opens an <iframe> to http://maps.google.com, that will open an iframe which will receive a set of cookies for the http://maps.google.com website. If the user then navigates inside Web content area, that is, inside the <iframe mozbrowser>, to http://maps.google.com, this will use different cookies and different permissions than the top level app.

Another example where this is useful is in a Yelp-like app. Yelp has the ability to visit a restaurant's website directly in the app. By using <iframe mozbrowser> to open the restaurant website, the Yelp app ensures that the restaurant website can't contain an <iframe> pointing back to Yelp's app (which points to http://yelp.com). If it does, the website will only receive the Yelp website, rather than the Yelp app. So there is no way that the restaurant website can mount an attack against the app since the contained Yelp website won't share any permissions or data with the Yelp app.

App malware threat model

 
App type Signing Privilege level defaultCSP Install path Queries Risk Mitigation
install run update
Certified signed full API yes firmware image none low reviews, firmware updates
sideloading high sideload restriction, gonk-level cleanup
Packaged signed whitelisted API yes Marketplace Marketplace none Marketplace medium reviews, updates, gonk-level cleanup
sideloading none none? high sideload restriction, gonk-level cleanup
Web API no Marketplace Marketplace Marketplace low

reviews, updates, gonk-level cleanup

sideloading none none? medium sideload restriction
unsigned Web API no download URI download URI none none? low Safe Browsing for URI
sideloading none none? medium sideload restriction
Hosted/Web unsigned Web API no Marketplace Marketplace Web app URI Marketplace low reviews, updates?, Safe-browsing for app URI
download URI download URI none? medium Safe Browsing for download and app URI
sideloading none none? low sideload restriction, Safe Browsing for app URI

 

Revision Source

<div>
  {{draft}}</div>
<p>Firefox OS includes new APIs which provide Open Web Apps access to a range of native device capabilities, such as access to cameras, bluetooth, network connections and other APIs not previously exposed to the Web.&nbsp; A variety of security mechanisms have also been introduced to increase the trustworthiness of apps to the point where they can be trusted with these new APIs. The key Open Web App security controls are:</p>
<ul>
  <li>Apps are explicitly installed and launched, rather than being casually navigated to in a browser. Apps must be installed prior to use, and security controls govern the update and removal of apps to protect the user.</li>
  <li>Access to new Web APIs is controlled by a permissions system, where an app must declare the permissions it intends to use prior to installation. In order to gain access to more powerful APIs, apps must meet certain requirements and be reviewed, approved, and signed by a marketplace such as the Firefox Marketplace.</li>
  <li>Apps are sandboxed so they can only see their own resources (cookies, offline storage, IndexedDB databases, and so on). Even if two apps happen to load a page with the same URL, these two pages are not considered same-origin because they are running inside separate apps.</li>
</ul>
<h2 id="Application_Types_.26_Lifecycle"><span class="mw-headline" id="Application_Lifecycle">Application Types &amp; Lifecycle</span></h2>
<p>The table below summarizes the different types of Open Web Apps and describes the format, installation, and update process.</p>
<table>
  <caption>
    Web App Types</caption>
  <thead>
    <tr>
      <th scope="col">Type</th>
      <th scope="col">Delivery</th>
      <th scope="col">Permission Level</th>
      <th scope="col">Installation</th>
      <th scope="col">Updates</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Web</td>
      <td>Hosted or Packaged</td>
      <td>Less-sensitive permissions that are not dangerous to expose to unvalidated Web content</td>
      <td>Installed from anywhere</td>
      <td>Can be updated transparently to the user or explicitly through a marketplace, depending on where the app was installed from, and the delivery mechanism.</td>
    </tr>
    <tr>
      <td>Privileged</td>
      <td>Packaged</td>
      <td>Privileged APIs which require validation and authentication of the app</td>
      <td>Installed from a trusted marketplace</td>
      <td>Updated via a trusted marketplace, user prompted to approve download and installation of updates.</td>
    </tr>
    <tr>
      <td>Certified</td>
      <td>Packaged</td>
      <td>Powerful and dangerous APIs which are not available to third-party apps.</td>
      <td>Pre-installed on the device</td>
      <td>Updated only as part of system level updates.</td>
    </tr>
  </tbody>
</table>
<h3 id="App_types">App types</h3>
<p>Firefox OS supports three types of apps: web, privileged, and certified. An app's type is declared in its <a href="/en-US/docs/Apps/Manifest" title="/en-US/docs/Apps/Manifest">manifest</a>, and determines the list of permissions it may request.</p>
<ul>
  <li><strong>Web Apps:</strong> Most third-party apps will be "Web" Apps, which is the default type, and doesn't grant the App any additional permissions besides those already exposed to the web. Web Apps can be installed from any website, without any further verification, but as a</li>
  <li><strong>Privileged Apps</strong>: These Apps are allowed to request increased permissions, and as such Privileged Apps must be verified and signed by a Marketplace</li>
  <li><strong>Certified Apps: </strong>Certified Apps can currently only be pre-installed on the device.</li>
</ul>
<p>For further details of the three types, see <a href="/en-US/docs/Apps/Manifest#type" title="/en-US/docs/Apps/Manifest#type">Manifest</a>&nbsp;and <a href="/en-US/docs/Apps/Packaged_apps#Types_of_packaged_apps" title="/en-US/docs/Apps/Packaged_apps#Types_of_packaged_apps">Packaged apps</a>.</p>
<h3 id="App_delivery">App delivery</h3>
<p>Apps can be delivered by two different mechanisms: hosted or packaged.</p>
<h4 id="Hosted_apps_"><span class="mw-headline" id="Hosted_apps">Hosted apps </span></h4>
<p>A hosted app consists solely of an <a class="external text" href="/en-US/docs/Apps/Manifest" rel="nofollow">application manifest</a> file on the developer's Web server. Often the manifest will also point to an appcache manifest which allows an app to be cached for faster startup and to enable offline usage, but otherwise doesn't affect the app at all. From a security point of view, hosted apps work very much like normal websites. When a hosted app is loaded, the URL of the loaded pages are the normal URLs that those pages have on their web server. So to link to a specific page or resource in the app, the same URL is used as when linking to that page or URL on the website.</p>
<h4 id="Packaged_apps"><span class="mw-headline" id="Packaged_apps">Packaged apps</span></h4>
<p><strong>A packaged app</strong> is an Open Web App that has all of its resources (HTML, CSS, JavaScript, app manifest, and so on) contained in a zip file, instead of having its resources on a Web server. For details of this format, see<a href="/en-US/docs/Apps/Packaged_apps" title="Apps/Packaged_apps"> Packaged apps</a>.&nbsp;</p>
<h3 id="App_Installation"><strong>App Installation</strong></h3>
<p>Apps are installed using the <a href="/en-US/docs/JavaScript_API" title="/en-US/docs/JavaScript_API">Apps Javascript API</a>:</p>
<ul>
  <li>Hosted apps: Hosted apps are installed by calling <code>navigator.mozApps.install(manifestURL)</code>, where <code>manifestURL</code> is a URL that specifies the location of the app. For further details, see <a href="/en-US/docs/DOM/Apps.install">Installing Apps</a>.</li>
  <li>Packaged apps: For packaged apps, the main application manifest is stored inside the package itself, so that it can be signed. There is a second "mini-manifest" that is used to start the installation and update process on the marketplace. See <a href="/en-US/docs/DOM/Apps.installPackage">Installing Packaged Apps</a> and<a href="/en-US/docs/Apps/Packaged_apps" title="Apps/Packaged_apps"> Packaged apps</a> for more information.</li>
</ul>
<p>In order to secure an app wants to be installed, we have to ensure that it's not possible to trick a website into hosting an application manifest. This is done by requiring that the manifest is served with a specific mime-type, <code>application/x-web-app-manifest+json</code>. This restriction is relaxed when the manifest file, and thus the app manifest, is same-origin with the page that requested the app to be installed.</p>
<h3 id="Updates"><span class="mw-headline" id="Updates">Updates</span></h3>
<p>The update process for apps is described in <a href="/en-US/docs/Apps/Updating_apps" title="Apps/Updating_apps">Updating apps</a>.</p>
<h2 id="Permissions">Permissions</h2>
<p>Apps may be granted additional privileges on top of the ones granted to normal websites. By default an application has no permissions on top of the ones normal webpages have. An app can request additional permissions by enumerating the permissions in its manifest. Enumerating a permission does not guarantee that an app will be granted the permission. The Web runtime may decide to not grant access.</p>
<h3 id="Manifest_declaration">Manifest declaration</h3>
<p>For each additional permission that an app wants, the manifest has to explicitly enumerate that permission along with a human-readable description of why the app wants that permission. This description will be used at various points in the device UI, and is also used when the app is reviewed. For further detail on manifests, see <a href="/en-US/docs/Apps/Manifest" title="Apps/Manifest">App manifest</a>.</p>
<h3 id="Granting_permissions">Granting permissions</h3>
<p>&nbsp;</p>
<h3 id="Revoking_permissions">Revoking permissions</h3>
<h2 id=".C2.A0">&nbsp;</h2>
<h2 id="Web_app_sandbox">Web app sandbox</h2>
<h3 id="Data_stored_per_app_"><span class="mw-headline" id="Data_stored_per_app">Data stored per app </span></h3>
<p>Each appl runs in a separate sandbox, meaning that all data stored by an app is separate from all data stored by another app. This includes things like cookie data, localStorage data, indexedDB data, and site permissions.</p>
<p>This means that if the user has two apps installed, app A and app B, these apps will have completely different sets of cookies, different local data, and different permissions. This even applies if both of these apps open an <code>&lt;iframe&gt;</code> that points to the same origin. For example, if both app A and app B open an <code>&lt;iframe&gt;</code> pointing to "<a class="external free" href="http://www.mozilla.org" rel="nofollow">http://www.mozilla.org</a>", they will both render the website, however the website will be fetched and rendered with different cookies in the two apps.</p>
<p>A result of this is that if the user logs in to Facebook, for example, while using app A, this in no way affects app B's ability to interact with the user's account on Facebook. The login cookie that Facebook sets when the user logs in using app A is only available in app A. If app B open an <code>&lt;iframe&gt;</code> to Facebook, the cookie wouldn't be there and so when app B opens Facebook, it receives the Facebook login page rather than the user's account.</p>
<h3 id="Apps_can't_open_each_other_"><span class="mw-headline" id="Apps_can.27t_open_each_other">Apps can't open each other </span></h3>
<p>This means that apps can't open other apps by using <code>&lt;iframe&gt;</code>s. If app A creates an&nbsp;<span style="font-family: 'Courier New', 'Andale Mono', monospace; line-height: normal;">&lt;iframe&gt;</span>&nbsp;with <code>src</code> set to the URL of app B, this won't actually open app B in the <code>&lt;iframe&gt;</code>. It will simply open the website located at that URL. It will not use any of app B's cookies and so it will behave no differently than if app B wasn't installed on the user's device.</p>
<p>This applies even for packaged apps (more about them below). App A may not open packaged app B&nbsp; using an <code>&lt;iframe&gt;</code> pointing to the <code>app://</code> URL of app B under normal circumstances. Web content also may not access <code>app://</code> URLs. Attempting to access an <code>app://</code> URL from Web content or without the proper permssion will fail and return an error. And App A can access contents of app B if app A has the <code>webapps-manage</code> permission which is only available to certified apps.</p>
<p>The same thing happens if the top-level frame of app A is navigated to a URL for app B. We always know for a given frame which app is opened in it, and so when attempting to load the app B URL in the app A frame, this will behave exactly like the two situations described above. That is, in no way will app B's resources, like cookies or other local data, be used.</p>
<h3 id="Motivation"><span class="mw-headline" id="Motivation">Motivation</span></h3>
<p>There are both benefits and downsides to this approach. The downside is that if the user interacts with the same website through several apps, he or she will have to log in in every app. Likewise, if a website wants to store data locally, and the user interacts with this website in several apps, the data will end up getting duplicated in each app, which could be a problem if it's a large amount of data.</p>
<p>The main benefit of this approach is that it's a more stable model. There is no way that several apps could interact with each other through a third-party website in unexpected ways such that installing an app causes another app to stop working. When an app is uninstalled there is no way that data for another app could be lost, or that another app will stop working due to functional dependence of the uninstalled app.</p>
<p>There are also large security benefits. A user can safely use his AwesomeSocial app to log in to Facebook without having to worry that the SketchGame app can mount any types of attack for getting at the user's Facebook data by exploiting bugs or other shortcomings in the Facebook website.</p>
<p>There are also good privacy benefits. The user can safely install the PoliticalPartyPlus app without having to worry that MegaCorpEmployee app will be able to detect that the app was installed or what data it has created.</p>
<h3 id="Sandboxed_permissions"><span class="mw-headline" id="Sandboxed_Permissions">Sandboxed permissions</span></h3>
<p>And just like website data is sandboxed per app, so are permission grants. If app A loads a page from <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> and that page requests to use geolocation and the user says "yes and remember this decision for all times," this only means that <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> has access to geolocation within app A. If app B then opens <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, that page won't have access to geolocation unless the user grants that permission again for app B.</p>
<p>And just like in the normal browser, permissions are separated by origin. This means that if app A is granted permission to use geolocation, this does not mean that all origins running in app A have the permission to use geolocation. If app A opens an <code>&lt;iframe&gt;</code> to <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, then <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> still has to ask the user for permission before geolocation access is granted.</p>
<h3 id="Browser_API_sandbox">Browser API sandbox</h3>
<p>To additionally secure applications that open a large set of URLs, such as browsers, we have added a browserContent flag. The browserContent flag allows each app to have not one, but two sandboxes, one for the app itself, and one for any Web content that it opens. For example, s<span style="line-height: 1.572;">ay that the MyBrowser app is loaded from the </span><a class="external free" href="https://mybrowser.com" rel="nofollow" style="line-height: 1.572;">https://mybrowser.com</a><span style="line-height: 1.572;"> domain. This is the domain where the scripts and resources are loaded within. The scripts and resources </span><i style="line-height: 1.572;">belong</i><span style="line-height: 1.572;"> to this domain.</span></p>
<p>Now, if a page in this app creates an <code>&lt;iframe mozbrowser&gt;</code>, a different sandbox is created and used for this <code>&lt;iframe&gt;</code>, which is different from the sandbox used by the app. That is, if this iframe is navigated to <a class="external free" href="https://mybrowser.com" rel="nofollow">https://mybrowser.com</a>, it will result in different cookies being used inside the <code>&lt;iframe mozbrowser&gt;</code>. Likewise, the contents inside the <code>&lt;iframe mozbrowser&gt;</code> will see different IndexedDB and localStorage databases from the ones opened by the app.</p>
<p>This also applies if the MyBrowser app wants to create integration with, for example, Google maps, to implement location-based browsing. If the app opens an <code>&lt;iframe&gt;</code> to <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, that will open an iframe which will receive a set of cookies for the <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> website. If the user then navigates inside Web content area, that is, inside the <code>&lt;iframe mozbrowser&gt;</code>, to <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, this will use different cookies and different permissions than the top level app.</p>
<p>Another example where this is useful is in a Yelp-like app. Yelp has the ability to visit a restaurant's website directly in the app. By using <code>&lt;iframe mozbrowser&gt;</code> to open the restaurant website, the Yelp app ensures that the restaurant website can't contain an <code>&lt;iframe&gt;</code> pointing back to Yelp's app (which points to <a class="external free" href="http://yelp.com" rel="nofollow">http://yelp.com</a>). If it does, the website will only receive the Yelp website, rather than the Yelp app. So there is no way that the restaurant website can mount an attack against the app since the contained Yelp website won't share any permissions or data with the Yelp app.</p>
<h3>App malware threat model</h3>
<table class="standard-table" summary="Summary foobar">
  <caption>
    &nbsp;</caption>
  <thead>
    <tr>
      <th rowspan="2" scope="col">App type</th>
      <th rowspan="2" scope="col">Signing</th>
      <th rowspan="2" scope="col">Privilege level</th>
      <th rowspan="2" scope="col">defaultCSP</th>
      <th rowspan="2" scope="col">Install path</th>
      <th colspan="3" scope="col">Queries</th>
      <th rowspan="2" scope="col">Risk</th>
      <th rowspan="2" scope="col">Mitigation</th>
    </tr>
    <tr>
      <th scope="col">install</th>
      <th scope="col">run</th>
      <th scope="col">update</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td rowspan="2">Certified</td>
      <td rowspan="2">signed</td>
      <td rowspan="2">full API</td>
      <td rowspan="2">yes</td>
      <td>firmware image</td>
      <td colspan="3" rowspan="2" style="background-color: rgb(255, 204, 0);">none</td>
      <td style="background-color: rgb(204, 255, 204);">low</td>
      <td>reviews, firmware updates</td>
    </tr>
    <tr>
      <td>sideloading</td>
      <td style="background-color: rgb(255, 0, 0);">high</td>
      <td>sideload restriction, gonk-level cleanup</td>
    </tr>
    <tr>
      <td colspan="1" rowspan="6">Packaged</td>
      <td colspan="1" rowspan="4">signed</td>
      <td rowspan="2">whitelisted API</td>
      <td rowspan="2">yes</td>
      <td>Marketplace</td>
      <td style="background-color: rgb(102, 255, 0);">Marketplace</td>
      <td rowspan="4" style="background-color: rgb(255, 204, 0);">none</td>
      <td style="background-color: rgb(102, 255, 0);">Marketplace</td>
      <td style="background-color: rgb(255, 255, 0);">medium</td>
      <td>reviews, updates, gonk-level cleanup</td>
    </tr>
    <tr>
      <td>sideloading</td>
      <td style="background-color: rgb(255, 204, 0);">none</td>
      <td>none?</td>
      <td style="background-color: rgb(255, 0, 0);">high</td>
      <td>sideload restriction, gonk-level cleanup</td>
    </tr>
    <tr>
      <td rowspan="2">Web API</td>
      <td rowspan="2">no</td>
      <td>Marketplace</td>
      <td style="background-color: rgb(102, 255, 0);">Marketplace</td>
      <td style="background-color: rgb(102, 255, 0);">Marketplace</td>
      <td style="background-color: rgb(204, 255, 204);">low</td>
      <td>
        <p>reviews, updates, gonk-level cleanup</p>
      </td>
    </tr>
    <tr>
      <td>sideloading</td>
      <td style="background-color: rgb(255, 204, 0);">none</td>
      <td>none?</td>
      <td style="background-color: rgb(255, 255, 0);">medium</td>
      <td>sideload restriction</td>
    </tr>
    <tr>
      <td rowspan="2">unsigned</td>
      <td rowspan="2">Web API</td>
      <td rowspan="2">no</td>
      <td>download URI</td>
      <td style="background-color: rgb(204, 255, 0);">download URI</td>
      <td rowspan="2" style="background-color: rgb(255, 204, 0);">none</td>
      <td>none?</td>
      <td style="background-color: rgb(204, 255, 204);">low</td>
      <td>Safe Browsing for URI</td>
    </tr>
    <tr>
      <td>sideloading</td>
      <td style="background-color: rgb(255, 204, 0);">none</td>
      <td>none?</td>
      <td style="background-color: rgb(255, 255, 0);">medium</td>
      <td>sideload restriction</td>
    </tr>
    <tr>
      <td rowspan="3">Hosted/Web</td>
      <td rowspan="3">unsigned</td>
      <td rowspan="3">Web API</td>
      <td rowspan="3">no</td>
      <td>Marketplace</td>
      <td style="background-color: rgb(102, 255, 0);">Marketplace</td>
      <td rowspan="3" style="background-color: rgb(204, 255, 0);">Web app URI</td>
      <td style="background-color: rgb(102, 255, 0);">Marketplace</td>
      <td style="background-color: rgb(204, 255, 204);">low</td>
      <td>reviews, updates?, Safe-browsing for app URI</td>
    </tr>
    <tr>
      <td>download URI</td>
      <td style="background-color: rgb(204, 255, 0);">download URI</td>
      <td>none?</td>
      <td style="background-color: rgb(255, 255, 0);">medium</td>
      <td>Safe Browsing for download and app URI</td>
    </tr>
    <tr>
      <td>sideloading</td>
      <td style="background-color: rgb(255, 204, 0);">none</td>
      <td>none?</td>
      <td style="background-color: rgb(204, 255, 204);">low</td>
      <td>sideload restriction, Safe Browsing for app URI</td>
    </tr>
  </tbody>
</table>
<p>&nbsp;</p>
Revert to this revision