mozilla

Compare Revisions

Application security

Change Revisions

Revision 414755:

Revision 414755 by Sheppy on

Revision 435785:

Revision 435785 by ptheriault on

Title:
Application security
Application security
Slug:
Mozilla/Firefox_OS/Security/Application_security
Mozilla/Firefox_OS/Security/Application_security
Tags:
"Security", "Apps", "Mobile", "Firefox OS"
"Mobile", "Security", "Apps", "Firefox OS"
Content:

Revision 414755
Revision 435785
n11      Firefox OS includes new APIs which provide Open Web Apps acn11      The key Web App security controls introduced by FirefoxOS a
>cess to a range of native device capabilities, such as access to >re:
>cameras, bluetooth, network connections and other APIs not previo 
>usly exposed to the Web.  A variety of security mechanisms h 
>ave also been introduced to increase the trustworthiness of apps  
>to the point where they can be trusted with these new APIs. The k 
>ey Open Web App security controls are: 
n14      <li>Apps are explicitly installed and launched, rather thann14      <li>Web Apps are explicit installed and launched, rather th
> being casually navigated to in a browser. Apps must be installed>an being casually navigated to in a browser. Apps must be install
> prior to use, and security controls govern the update and remova>ed prior to use, and security controls govern the update and remo
>l of apps to protect the user.>val of Apps to protect the user.
n16      <li>Access to new Web APIs is controlled by a permissions sn16      <li>Access to new Web APIs is controlled by a permissions s
>ystem, where an app must declare the permissions it intends to us>ystem, where an App must declare the permissions it intends to us
>e prior to installation. In order to gain access to more powerful>e prior to installation. In order to gain access to more powerful
> APIs, apps must meet certain requirements and be reviewed, appro> APIs, the Apps meet certain requirements, and be reviewed, appro
>ved, and signed by a marketplace such as the Firefox Marketplace.>ved and signed by a Marketplace.
n18      <li>Apps are sandboxed so they can only see their own resoun18      <li>Web Apps are sandboxed so they can only see their own r
>rces (cookies, offline storage, IndexedDB databases, and so on). >esources (cookies, offline storage IndexedDB databases and so on)
>Even if two apps happen to load a page with the same URL, these t>. Even if two apps happen to both load a page with the same URL, 
>wo pages are not considered same-origin because they are running >these two pages are not considered same-origin as they are runnin
>inside separate apps.>g inside seperate Apps.
n21    <h2 id="Application_Types_.26_Lifecycle">n21    <h3 id="App_Types">
22      <span class="mw-headline" id="Application_Lifecycle">Applic22      App Types
>ation Types &amp; Lifecycle</span> 
23    </h3>
24    <p>
25      FirefoxOS supports three types of Web Apps: "<strong>web</s
 >trong>", "<strong>privileged</strong>" and "<strong>certified</st
 >rong>". An App's type is declared in it's <a href="/en-US/docs/Ap
 >ps/Manifest" title="/en-US/docs/Apps/Manifest">manifest</a>, and 
 >determines the list of permissions it may request.
26    </p>
27    <ul>
28      <li>
29        <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 w
 >eb. Web apps can be installed from any website, without any furth
 >er verification. They can also be <a href="/en-US/docs/Web/Apps/P
 >ackaged_apps" title="/en-US/docs/Web/Apps/Packaged_apps">packaged
 ></a> but this does not allow any addition permissions.
30      </li>
31      <li>
32        <strong>Privileged Apps</strong>: These apps are allowed 
 >to request increased increased permissions, and as such <em>privi
 >leged</em> apps must be verified and signed by a Marketplace
33      </li>
34      <li>
35        <strong>Certified Apps:</strong> Certified apps can curre
 >ntly only be pre-installed on the device.
36      </li>
37    </ul>
38    <p>
39      For further details of the three types, see the <a href="/e
 >n-US/docs/Apps/Manifest#type" title="/en-US/docs/Apps/Manifest#ty
 >pe">App Manifest</a> documention.
40    </p>
41    <h3 id="App_Delivery">
42      App Delivery
43    </h3>
44    <p>
45      Apps can be delivered by two different mechanisms in Firefo
 >x OS: hosted or packaged. Regular webs can be delivered via eithe
 >r mechanism, where as privileged and certified apps must be packa
 >ged.
46    </p>
47    <h4 id="Hosted_apps_">
48      <span class="mw-headline" id="Hosted_apps">Hosted apps</spa
 >n>
49    </h4>
50    <p>
51      A hosted app consists solely of an <a class="external text"
 > href="/en-US/docs/Apps/Manifest" rel="nofollow">application mani
 >fest</a> file on the developer's web server. Often the manifest w
 >ill also point to an appcache manifest which allows an app to be 
 >cashed for faster startup and to enable offline usage, but otherw
 >ise doesn't affect the app at all. From a security point of view,
 > hosted apps work very much like normal websites. When a hosted a
 >pp is loaded, the URL of the loaded pages are the normal URLs tha
 >t 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.
52    </p>
53    <h4 id="Packaged_apps">
54      <span class="mw-headline" id="Packaged_apps">Packaged apps<
 >/span>
55    </h4>
56    <p>
57      <strong>A packaged app</strong> is an Open Web App that has
 > all of its resources (HTML, CSS, JavaScript, app manifest, and s
 >o 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/do
 >cs/Apps/Packaged_apps" title="Apps/Packaged_apps">Packaged apps</
 >a>.&nbsp;
58    </p>
59    <h3 id="App_Installation">
60      <strong>App Installation</strong>
61    </h3>
62    <p>
63      Apps are installed via the <a href="/en-US/docs/JavaScript_
 >API" title="/en-US/docs/JavaScript_API">Apps Javascript API</a>:
64    </p>
65    <ul>
66      <li>Hosted Apps: Hosted Apps are installed by calling <code
 >>navigator.mozApps.<a href="/en-US/docs/Web/API/Apps.install" tit
 >le="/en-US/docs/Web/API/Apps.install">install</a>(manifestURL)</c
 >ode>, where manifestURL is a URL which specificies the location o
 >f the App. For further details, see <a href="/en-US/docs/DOM/Apps
 >.install">Installing Apps</a>.
67      </li>
68      <li>Packaged Apps: Hosted Apps are installed by calling <co
 >de>navigator.mozApps.<a href="/en-US/docs/Web/API/Apps.installPac
 >kage" title="/en-US/docs/Web/API/Apps.installPackage">installPack
 >age</a>(packageURL)</code>. For the Packaged Apps, the main appli
 >cation manifest is stored inside the package itself, so that it i
 >s signed. There is a second 'mini-manifest' which is used to star
 >t the install process. See <a href="/en-US/docs/DOM/Apps.installP
 >ackage">Installing Packaged Apps</a> and <a href="/en-US/docs/App
 >s/Packaged_apps" title="Apps/Packaged_apps">Packaged apps</a> for
 > more information.
69      </li>
70    </ul>
71    <p>
72      In order to secure that an app really wants to be installed
 > as a web app we have to ensure that it's not possible to trick a
 > website into hosting an application manifest. This is done by re
 >quiring that the manifest is served with a specific mime-type, "a
 >pplication/x-web-app-manifest+json". This restriction is relaxed 
 >when the manifest app, and thus the app manifest, is same-origin 
 >with the page that requested the app to be installed.
73    </p>
74    <h3 id="Updates">
75      <span class="mw-headline" id="Updates">Updates</span>
76    </h3>
77    <p>
78      The update process for Apps is described here:&nbsp; <a hre
 >f="/en-US/docs/Apps/Updating_apps" title="Apps/Updating_apps">Upd
 >ating apps [en-US]</a>
79    </p>
80    <h2 id="Permissions">
81      Permissions
82    </h2>
83    <p>
84      Applications can be granted additional privileges on top of
 > the ones granted to normal websites. By default an application h
 >as no permissions on top of the ones normal webpages have. In ord
 >er to get additional permissions, the first step is for the app t
 >o enumerate the additional permissions it wants in the applicatio
 >n manifest.
85    </p>
86    <h3 id="Manifest_Declaration">
87      Manifest Declaration
88    </h3>
89    <p>
90      For each additional permission that an app wants, the manif
 >est has to explicitly enumerate that permission along with a huma
 >n-readable description of why the app wants access to that permis
 >sion. This description will be surfaced at various points in the 
 >UI, and is also used when the app is reviewed. For further detail
 > on manifests, see <a href="/en-US/docs/Apps/Manifest" title="App
 >s/Manifest">App manifest</a>.
91    </p>
92    <h3 id="Granting_Permissions">
93      Granting Permissions
94    </h3>
95    <p>
96      &nbsp;
97    </p>
98    <h3 id="Revoking_Permissions">
99      Revoking Permissions
100    </h3>
101    <h2 id=".C2.A0">
102      &nbsp;
103    </h2>
104    <h2 id="Web_App_Sandbox">
105      Web App Sandbox
106    </h2>
107    <h3 id="Data_stored_per_app_">
108      <span class="mw-headline" id="Data_stored_per_app">Data sto
 >red per app</span>
109    </h3>
110    <p>
111      Each application runs in as a separate sandbox, meaning tha
 >t all data stored by an application is separate from all data sto
 >red by another application. This includes things like cookie data
 >, localStorage data, indexedDB data and site permissions.
112    </p>
113    <p>
114      This means that if the user has two apps installed, App A a
 >nd App B, these apps will have completely different set of cookie
 >s, different local data and different permission. This even appli
 >es if both of these apps open an &lt;iframe&gt; which point to th
 >e same origin. I.e. if both App A and App B open an &lt;iframe&gt
 >; pointing to "<a class="external free" href="http://www.mozilla.
 >org" rel="nofollow">http://www.mozilla.org</a>", they will both r
 >ender the website, however the website will be fetched and render
 >ed with different cookies in the two apps.
115    </p>
116    <p>
117      A result of this is that if the user logs in to, for exampl
 >e, facebook while using App A, this in no way affects App Bs abil
 >ity to interact with the users account on facebook. The login coo
 >kie that facebook sets when the user logs in using App A is only 
 >available in App A. If App B open an &lt;iframe&gt; to facebook, 
 >the cookie wouldn't be there and so when App B opens facebook, it
 > receives the facebook login page rather than the users account.
118    </p>
119    <h3 id="Apps_can't_open_each_other_">
120      <span class="mw-headline" id="Apps_can.27t_open_each_other"
 >>Apps can't open each other</span>
121    </h3>
122    <p>
123      This means that apps can't open other apps by using iframes
 >. If App A creates an iframe with the src set to the URL of App B
 >, this won't actually open App B in the iframe. It will simply op
 >en the website located at that URL. It will not use any of App B'
 >s cookies and so it will behave no different than as if App B was
 >n't installed on the user's device.
124    </p>
125    <p>
126      This applies even for packaged apps (more about them below)
 >. If App A tries to open the packaged App B by using an &lt;ifram
 >e&gt; pointing to the app:// URL of App B, this will simply fail 
 >to load. If this results in a 404, or some other type of error is
 > still to be determined, but it will definitely fail to load. And
 > it will fail in the same way no matter if App B is installed on 
 >the user's device or not, as to make it impossible for App A to d
 >etermine if App B is installed.
127    </p>
128    <p>
129      The same thing happens if the top-level frame of App A is n
 >avigated to a URL for App B. We always know for a given frame whi
 >ch 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 sit
 >uations described above. I.e. in no way will App B's resources, l
 >ike cookies or other local data, be used.
130    </p>
131    <h3 id="Motivation">
132      <span class="mw-headline" id="Motivation">Motivation</span>
133    </h3>
134    <p>
135      There are both benefits and downsides to this approach. The
 > downside is that if the user interacts with the same website thr
 >ough several apps, he/she will have to log in in every app. Likew
 >ise, if a website wants to store data locally, and the user inter
 >acts with this website in several apps, the data will end up gett
 >ing duplicated in each app which could be a problem if it's a lar
 >ge amount of data.
136    </p>
137    <p>
138      The main benefit of this approach is that it's a more stabl
 >e model. There is no way that several apps could interact with ea
 >ch other through a 3rd party website in unexpected ways such that
 > installing an app causes another app to stop working. When an ap
 >p 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.
139    </p>
140    <p>
141      There are also large security benefits. A user can safely u
 >se his AwesomeSocial app to log in to facebook without having to 
 >worry that the SketchGame app can mount any types of attack for g
 >etting at the users facebook data by exploiting bugs or other sho
 >rtcomings in the facebook website.
142    </p>
143    <p>
144      There are also good privacy benefits. The user can safely i
 >nstall the PoliticalPartyPlus app without having to worry that Me
 >gaCorpEmployeeApp will be able to detect that the app was install
 >ed or what data it has created.
145    </p>
146    <h3 id="Sandboxed_Permissions">
147      <span class="mw-headline" id="Sandboxed_Permissions">Sandbo
 >xed Permissions</span>
148    </h3>
149    <p>
150      And just like website data is sandboxed per app, so are per
 >mission grants. If App A loads a page from <a class="external fre
 >e" href="http://maps.google.com" rel="nofollow">http://maps.googl
 >e.com</a> and that page requests to use geolocation and the user 
 >says "yes, and remember this decision for all times", this only m
 >eans that <a class="external free" href="http://maps.google.com" 
 >rel="nofollow">http://maps.google.com</a> has access to geolocati
 >on within App A. If App B then opens <a class="external free" hre
 >f="http://maps.google.com" rel="nofollow">http://maps.google.com<
 >/a>, that page won't have access to geolocation unless the user g
 >rants that permission again.
151    </p>
152    <p>
153      And just like in the normal browser, permissions are separa
 >ted by origin. This means that if App A is granted permission to 
 >use Geolocation, this does not mean that all origins running in A
 >pp A have the permission to use Geolocation. If App A opens an &l
 >t;iframe&gt; to <a class="external free" href="http://maps.google
 >.com" rel="nofollow">http://maps.google.com</a>, then <a class="e
 >xternal free" href="http://maps.google.com" rel="nofollow">http:/
 >/maps.google.com</a> still has to ask the user for permission bef
 >ore geolocation access is granted.
154    </p>
155    <h3 id="Browser_API_Sandbox">
156      Browser API Sandbox
157    </h3>
158    <p>
159      To additionally secure applications that open a large set o
 >f 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:
160    </p>
161    <p>
162      Say that the MyBrowser app is loaded from the <a class="ext
 >ernal free" href="https://mybrowser.com" rel="nofollow">https://m
 >ybrowser.com</a> domain. This is the domain where the scripts and
 > resources are loaded within. The scripts and resources <i>belong
 ></i> to this domain.
163    </p>
164    <p>
165      Now, if a page in this app creates an &lt;iframe mozbrowser
 >&gt; a different sandbox is created and used for this &lt;iframe&
 >gt;, which is different from the sandbox used by the app - i.e. i
 >f this iframe is navigated to <a class="external free" href="http
 >s://mybrowser.com" rel="nofollow">https://mybrowser.com</a>, it w
 >ill result in different cookies being used inside the &lt;iframe 
 >mozbrowser&gt;. Likewise, the contents inside the &lt;iframe mozb
 >rowser&gt; will see different IndexedDB and localStorage database
 >s from the ones opened by the app.
166    </p>
167    <p>
168      This also applies if the MyBrowser app wants to create inte
 >gration with, for example, google maps, to implement location-bas
 >ed browsing. If the app opens an &lt;iframe&gt; to <a class="exte
 >rnal free" href="http://maps.google.com" rel="nofollow">http://ma
 >ps.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. I
 >f the user then navigates inside web content area, i.e. inside th
 >e &lt;iframe mozbrowser&gt;, to <a class="external free" href="ht
 >tp://maps.google.com" rel="nofollow">http://maps.google.com</a>, 
 >this will use different cookies and different permissions than th
 >e top level app.
169    </p>
170    <p>
171      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 &lt;iframe mozbrowser&gt; to open the restaura
 >nt website, the Yelp app ensures that the restaurant website can'
 >t contain an &lt;iframe&gt; pointing back to Yelp's <b>app</b> (w
 >hich points to <a class="external free" href="http://yelp.com" re
 >l="nofollow">http://yelp.com</a>). If it does, the website will o
 >nly 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 permiss
 >ions or data with the Yelp app.
172    </p>
23    </h2>173    <h2>
174      App Security Summary
24    <p>175    </h2>
176    <p>
25      The table below summarizes the different types of Open Web 177      The table below summarizes the different types of FirefoxOS
>Apps and describes the format, installation, and update process.> Apps, describes the format, installation and updates process for
 > Open Web Apps running on Firefox OS.
n40            Permission Leveln192            Permission Model
n59            Less-sensitive permissions that are not dangerous to n211            Less sensitive permissions which are not dangerous to
>expose to unvalidated Web content> expose to unvalidated web content
n65            Can be updated transparently to the user or explicitln217            Can be updated transparent to user or explicitly via 
>through a marketplace, depending on where the app was installed>a marketplace, depending on where the App was installed from, and
> from, and the delivery mechanism.> the delivery mechanism.
nn225            Packaged &amp; Signed
226          </td>
227          <td>
228            Privileged APIs which require validation and authenti
 >cation of the App
229          </td>
230          <td>
231            Installed from a trusted marketplace
232          </td>
233          <td>
234            Updated via a trusted marketplace, user prompted to a
 >pprove download and installation of updates.
235          </td>
236        </tr>
237        <tr>
238          <td>
239            Certified
240          </td>
241          <td>
n76            Privileged APIs which require validation and authentin
>cation of the app 
77          </td>
78          <td>
79            Installed from a trusted marketplace
80          </td>
81          <td>
82            Updated via a trusted marketplace, user prompted to a
>pprove download and installation of updates. 
83          </td>
84        </tr>
85        <tr>
86          <td>
87            Certified
88          </td>
89          <td>
90            Packaged
91          </td>
92          <td>
93            Powerful and dangerous APIs which are not available t245            Powerful and dangerous APIs which are not available t
>third-party apps.>Third-Party Apps.
t104    <h3 id="App_types">t
105      App types
106    </h3>
107    <p>
108      Firefox OS supports three types of apps: web, privileged, a
>nd certified. An app's type is declared in its <a href="/en-US/do 
>cs/Apps/Manifest" title="/en-US/docs/Apps/Manifest">manifest</a>, 
> and determines the list of permissions it may request. 
109    </p>256    <p>
110    <ul>257      <strong>Note</strong>: For version 1.0 of Firefox OS, altho
 >ugh web apps can be installed from any website/marketplace, privi
 >leged apps can only be installed from the Mozilla Marketplace, as
 > support for multiple trusted marketplaces is not yet complete.
111      <li>
112        <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 w 
>eb. Web Apps can be installed from any website, without any furth 
>er verification, but as a 
113      </li>
114      <li>
115        <strong>Privileged Apps</strong>: These Apps are allowed 
>to request increased permissions, and as such Privileged Apps mus 
>t be verified and signed by a Marketplace 
116      </li>
117      <li>
118        <strong>Certified Apps:</strong> Certified Apps can curre
>ntly only be pre-installed on the device. 
119      </li>
120    </ul>
121    <p>
122      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#Typ 
>es_of_packaged_apps" title="/en-US/docs/Apps/Packaged_apps#Types_ 
>of_packaged_apps">Packaged apps</a>. 
123    </p>
124    <h3 id="App_delivery">
125      App delivery
126    </h3>
127    <p>
128      Apps can be delivered by two different mechanisms: hosted o
>r packaged. 
129    </p>
130    <h4 id="Hosted_apps_">
131      <span class="mw-headline" id="Hosted_apps">Hosted apps</spa
>n> 
132    </h4>
133    <p>
134      A hosted app consists solely of an <a class="external text"
> href="/en-US/docs/Apps/Manifest" rel="nofollow">application mani 
>fest</a> file on the developer's Web server. Often the manifest w 
>ill also point to an appcache manifest which allows an app to be  
>cached for faster startup and to enable offline usage, but otherw 
>ise doesn't affect the app at all. From a security point of view, 
> hosted apps work very much like normal websites. When a hosted a 
>pp is loaded, the URL of the loaded pages are the normal URLs tha 
>t 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. 
135    </p>
136    <h4 id="Packaged_apps">
137      <span class="mw-headline" id="Packaged_apps">Packaged apps<
>/span> 
138    </h4>
139    <p>
140      <strong>A packaged app</strong> is an Open Web App that has
> all of its resources (HTML, CSS, JavaScript, app manifest, and s 
>o 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/do 
>cs/Apps/Packaged_apps" title="Apps/Packaged_apps">Packaged apps</ 
>a>.&nbsp; 
141    </p>
142    <h3 id="App_Installation">
143      <strong>App Installation</strong>
144    </h3>
145    <p>
146      Apps are installed using the <a href="/en-US/docs/JavaScrip
>t_API" title="/en-US/docs/JavaScript_API">Apps Javascript API</a> 
>: 
147    </p>
148    <ul>
149      <li>Hosted apps: Hosted apps are installed by calling <code
>>navigator.mozApps.install(manifestURL)</code>, where <code>manif 
>estURL</code> is a URL that specifies the location of the app. Fo 
>r further details, see <a href="/en-US/docs/DOM/Apps.install">Ins 
>talling Apps</a>. 
150      </li>
151      <li>Packaged apps: For packaged apps, the main application 
>manifest is stored inside the package itself, so that it can be s 
>igned. There is a second "mini-manifest" that is used to start th 
>e 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/Packa 
>ged_apps">Packaged apps</a> for more information. 
152      </li>
153    </ul>
154    <p>
155      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 manifes 
>t is served with a specific mime-type, <code>application/x-web-ap 
>p-manifest+json</code>. This restriction is relaxed when the mani 
>fest file, and thus the app manifest, is same-origin with the pag 
>e that requested the app to be installed. 
156    </p>
157    <h3 id="Updates">
158      <span class="mw-headline" id="Updates">Updates</span>
159    </h3>
160    <p>
161      The update process for apps is described in <a href="/en-US
>/docs/Apps/Updating_apps" title="Apps/Updating_apps">Updating app 
>s</a>. 
162    </p>
163    <h2 id="Permissions">
164      Permissions
165    </h2>
166    <p>
167      Apps may be granted additional privileges on top of the one
>s granted to normal websites. By default an application has no pe 
>rmissions on top of the ones normal webpages have. An app can req 
>uest additional permissions by enumerating the permissions in its 
> manifest. Enumerating a permission does not guarantee that an ap 
>p will be granted the permission. The Web runtime may decide to n 
>ot grant access. 
168    </p>
169    <h3 id="Manifest_declaration">
170      Manifest declaration
171    </h3>
172    <p>
173      For each additional permission that an app wants, the manif
>est has to explicitly enumerate that permission along with a huma 
>n-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 man 
>ifests, see <a href="/en-US/docs/Apps/Manifest" title="Apps/Manif 
>est">App manifest</a>. 
174    </p>
175    <h3 id="Granting_permissions">
176      Granting permissions
177    </h3>
178    <p>
179      &nbsp;
180    </p>
181    <h3 id="Revoking_permissions">
182      Revoking permissions
183    </h3>
184    <h2 id=".C2.A0">
185      &nbsp;
186    </h2>
187    <h2 id="Web_app_sandbox">
188      Web app sandbox
189    </h2>
190    <h3 id="Data_stored_per_app_">
191      <span class="mw-headline" id="Data_stored_per_app">Data sto
>red per app</span> 
192    </h3>
193    <p>
194      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, index 
>edDB data, and site permissions. 
195    </p>
196    <p>
197      This means that if the user has two apps installed, app A a
>nd app B, these apps will have completely different sets of cooki 
>es, different local data, and different permissions. This even ap 
>plies if both of these apps open an <code>&lt;iframe&gt;</code> t 
>hat 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="ext 
>ernal free" href="http://www.mozilla.org" rel="nofollow">http://w 
>ww.mozilla.org</a>", they will both render the website, however t 
>he website will be fetched and rendered with different cookies in 
> the two apps. 
198    </p>
199    <p>
200      A result of this is that if the user logs in to Facebook, f
>or example, while using app A, this in no way affects app B's abi 
>lity to interact with the user's account on Facebook. The login c 
>ookie that Facebook sets when the user logs in using app A is onl 
>y 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 ope 
>ns Facebook, it receives the Facebook login page rather than the  
>user's account. 
201    </p>
202    <h3 id="Apps_can't_open_each_other_">
203      <span class="mw-headline" id="Apps_can.27t_open_each_other"
>>Apps can't open each other</span> 
204    </h3>
205    <p>
206      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: no 
>rmal;">&lt;iframe&gt;</span>&nbsp;with <code>src</code> set to th 
>e URL of app B, this won't actually open app B in the <code>&lt;i 
>frame&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 behav 
>e no differently than if app B wasn't installed on the user's dev 
>ice. 
207    </p>
208    <p>
209      This applies even for packaged apps (more about them below)
>. App A may not open packaged app B&nbsp; using an <code>&lt;ifra 
>me&gt;</code> pointing to the <code>app://</code> URL of app B un 
>der normal circumstances. Web content also may not access <code>a 
>pp://</code> URLs. Attempting to access an <code>app://</code> UR 
>L 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 avai 
>lable to certified apps. 
210    </p>
211    <p>
212      The same thing happens if the top-level frame of app A is n
>avigated to a URL for app B. We always know for a given frame whi 
>ch 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 sit 
>uations described above. That is, in no way will app B's resource 
>s, like cookies or other local data, be used. 
213    </p>
214    <h3 id="Motivation">
215      <span class="mw-headline" id="Motivation">Motivation</span>
216    </h3>
217    <p>
218      There are both benefits and downsides to this approach. The
> downside is that if the user interacts with the same website thr 
>ough several apps, he or she will have to log in in every app. Li 
>kewise, if a website wants to store data locally, and the user in 
>teracts with this website in several apps, the data will end up g 
>etting duplicated in each app, which could be a problem if it's a 
> large amount of data. 
219    </p>
220    <p>
221      The main benefit of this approach is that it's a more stabl
>e model. There is no way that several apps could interact with ea 
>ch other through a third-party website in unexpected ways such th 
>at installing an app causes another app to stop working. When an  
>app is uninstalled there is no way that data for another app coul 
>d be lost, or that another app will stop working due to functiona 
>l dependence of the uninstalled app. 
222    </p>
223    <p>
224      There are also large security benefits. A user can safely u
>se his AwesomeSocial app to log in to Facebook without having to  
>worry that the SketchGame app can mount any types of attack for g 
>etting at the user's Facebook data by exploiting bugs or other sh 
>ortcomings in the Facebook website. 
225    </p>
226    <p>
227      There are also good privacy benefits. The user can safely i
>nstall the PoliticalPartyPlus app without having to worry that Me 
>gaCorpEmployee app will be able to detect that the app was instal 
>led or what data it has created. 
228    </p>
229    <h3 id="Sandboxed_permissions">
230      <span class="mw-headline" id="Sandboxed_Permissions">Sandbo
>xed permissions</span> 
231    </h3>
232    <p>
233      And just like website data is sandboxed per app, so are per
>mission grants. If app A loads a page from <a class="external fre 
>e" href="http://maps.google.com" rel="nofollow">http://maps.googl 
>e.com</a> and that page requests to use geolocation and the user  
>says "yes and remember this decision for all times," this only me 
>ans that <a class="external free" href="http://maps.google.com" r 
>el="nofollow">http://maps.google.com</a> has access to geolocatio 
>n 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 gr 
>ants that permission again for app B. 
234    </p>
235    <p>
236      And just like in the normal browser, permissions are separa
>ted by origin. This means that if app A is granted permission to  
>use geolocation, this does not mean that all origins running in a 
>pp A have the permission to use geolocation. If app A opens an <c 
>ode>&lt;iframe&gt;</code> to <a class="external free" href="http: 
>//maps.google.com" rel="nofollow">http://maps.google.com</a>, the 
>n <a class="external free" href="http://maps.google.com" rel="nof 
>ollow">http://maps.google.com</a> still has to ask the user for p 
>ermission before geolocation access is granted. 
237    </p>
238    <h3 id="Browser_API_sandbox">
239      Browser API sandbox
240    </h3>
241    <p>
242      To additionally secure applications that open a large set o
>f URLs, such as browsers, we have added a browserContent flag. Th 
>e browserContent flag allows each app to have not one, but two sa 
>ndboxes, one for the app itself, and one for any Web content that 
> it opens. For example, s<span style="line-height: 1.572;">ay tha 
>t the MyBrowser app is loaded from the</span> <a class="external  
>free" href="https://mybrowser.com" rel="nofollow" style="line-hei 
>ght: 1.572;">https://mybrowser.com</a> <span style="line-height:  
>1.572;">domain. This is the domain where the scripts and resource 
>s are loaded within. The scripts and resources</span> <i style="l 
>ine-height: 1.572;">belong</i> <span style="line-height: 1.572;"> 
>to this domain.</span> 
243    </p>
244    <p>
245      Now, if a page in this app creates an <code>&lt;iframe mozb
>rowser&gt;</code>, a different sandbox is created and used for th 
>is <code>&lt;iframe&gt;</code>, which is different from the sandb 
>ox used by the app. That is, if this iframe is navigated to <a cl 
>ass="external free" href="https://mybrowser.com" rel="nofollow">h 
>ttps://mybrowser.com</a>, it will result in different cookies bei 
>ng used inside the <code>&lt;iframe mozbrowser&gt;</code>. Likewi 
>se, the contents inside the <code>&lt;iframe mozbrowser&gt;</code 
>> will see different IndexedDB and localStorage databases from th 
>e ones opened by the app. 
246    </p>
247    <p>
248      This also applies if the MyBrowser app wants to create inte
>gration with, for example, Google maps, to implement location-bas 
>ed browsing. If the app opens an <code>&lt;iframe&gt;</code> to < 
>a class="external free" href="http://maps.google.com" rel="nofoll 
>ow">http://maps.google.com</a>, that will open an iframe which wi 
>ll 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, t 
>hat 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. 
249    </p>
250    <p>
251      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 ba 
>ck 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 moun 
>t an attack against the app since the contained Yelp website won' 
>t share any permissions or data with the Yelp app. 
252    </p>
253    <h3 id="App_malware_threat_model">
254      App malware threat model
255    </h3>
256    <table class="standard-table" summary="Summary foobar">
257      <caption>
258        &nbsp;
259      </caption>
260      <thead>
261        <tr>
262          <th rowspan="2" scope="col">
263            App type
264          </th>
265          <th rowspan="2" scope="col">
266            Signing
267          </th>
268          <th rowspan="2" scope="col">
269            Privilege level
270          </th>
271          <th rowspan="2" scope="col">
272            defaultCSP
273          </th>
274          <th rowspan="2" scope="col">
275            Install path
276          </th>
277          <th colspan="3" scope="col">
278            Queries
279          </th>
280          <th rowspan="2" scope="col">
281            Risk
282          </th>
283          <th rowspan="2" scope="col">
284            Mitigation
285          </th>
286        </tr>
287        <tr>
288          <th scope="col">
289            install
290          </th>
291          <th scope="col">
292            run
293          </th>
294          <th scope="col">
295            update
296          </th>
297        </tr>
298      </thead>
299      <tbody>
300        <tr>
301          <td rowspan="2">
302            Certified
303          </td>
304          <td>
305            required
306          </td>
307          <td rowspan="2">
308            full API
309          </td>
310          <td rowspan="2">
311            yes
312          </td>
313          <td>
314            firmware image
315          </td>
316          <td colspan="3" rowspan="2" style="background-color: rg
>b(255, 204, 0);"> 
317            none
318          </td>
319          <td style="background-color: rgb(204, 255, 204);">
320            low
321          </td>
322          <td>
323            reviews, firmware updates
324          </td>
325        </tr>
326        <tr>
327          <td>
328            optional
329          </td>
330          <td>
331            sideloading
332          </td>
333          <td style="background-color: rgb(255, 0, 0);">
334            high
335          </td>
336          <td>
337            sideload restriction, gonk-level cleanup
338          </td>
339        </tr>
340        <tr>
341          <td colspan="1" rowspan="6">
342            Packaged
343          </td>
344          <td colspan="1">
345            signed
346          </td>
347          <td rowspan="2">
348            whitelisted API
349          </td>
350          <td rowspan="2">
351            yes
352          </td>
353          <td>
354            Marketplace
355          </td>
356          <td style="background-color: rgb(102, 255, 0);">
357            Marketplace
358          </td>
359          <td rowspan="4" style="background-color: rgb(255, 204, 
>0);"> 
360            none
361          </td>
362          <td style="background-color: rgb(102, 255, 0);">
363            Marketplace
364          </td>
365          <td style="background-color: rgb(255, 255, 0);">
366            medium
367          </td>
368          <td>
369            reviews, updates, gonk-level cleanup
370          </td>
371        </tr>
372        <tr>
373          <td colspan="1">
374            optional
375          </td>
376          <td>
377            sideloading
378          </td>
379          <td style="background-color: rgb(255, 204, 0);">
380            none
381          </td>
382          <td>
383            none?
384          </td>
385          <td style="background-color: rgb(255, 0, 0);">
386            high
387          </td>
388          <td>
389            sideload restriction, gonk-level cleanup
390          </td>
391        </tr>
392        <tr>
393          <td colspan="1">
394            signed
395          </td>
396          <td rowspan="2">
397            Web API
398          </td>
399          <td rowspan="2">
400            no
401          </td>
402          <td>
403            Marketplace
404          </td>
405          <td style="background-color: rgb(102, 255, 0);">
406            Marketplace
407          </td>
408          <td style="background-color: rgb(102, 255, 0);">
409            Marketplace
410          </td>
411          <td style="background-color: rgb(204, 255, 204);">
412            low
413          </td>
414          <td>
415            reviews, Marketplace updates, gonk-level cleanup
416          </td>
417        </tr>
418        <tr>
419          <td colspan="1">
420            optional
421          </td>
422          <td>
423            sideloading
424          </td>
425          <td style="background-color: rgb(255, 204, 0);">
426            none
427          </td>
428          <td>
429            none?
430          </td>
431          <td style="background-color: rgb(255, 255, 0);">
432            medium
433          </td>
434          <td>
435            sideload restriction, gonk-level cleanup
436          </td>
437        </tr>
438        <tr>
439          <td rowspan="2">
440            unsigned
441          </td>
442          <td rowspan="2">
443            Web API
444          </td>
445          <td rowspan="2">
446            no
447          </td>
448          <td>
449            download URI
450          </td>
451          <td style="background-color: rgb(204, 255, 0);">
452            download URI
453          </td>
454          <td rowspan="2" style="background-color: rgb(255, 204, 
>0);"> 
455            none
456          </td>
457          <td>
458            none?
459          </td>
460          <td style="background-color: rgb(204, 255, 204);">
461            low
462          </td>
463          <td>
464            URI blacklist checks
465          </td>
466        </tr>
467        <tr>
468          <td>
469            sideloading
470          </td>
471          <td style="background-color: rgb(255, 204, 0);">
472            none
473          </td>
474          <td>
475            none?
476          </td>
477          <td style="background-color: rgb(255, 255, 0);">
478            medium
479          </td>
480          <td>
481            sideload restriction
482          </td>
483        </tr>
484        <tr>
485          <td rowspan="3">
486            Hosted/Web
487          </td>
488          <td rowspan="3">
489            unsigned
490          </td>
491          <td rowspan="3">
492            Web API
493          </td>
494          <td rowspan="3">
495            no
496          </td>
497          <td>
498            Marketplace
499          </td>
500          <td style="background-color: rgb(102, 255, 0);">
501            Marketplace
502          </td>
503          <td rowspan="3" style="background-color: rgb(204, 255, 
>0);"> 
504            Web app URI
505          </td>
506          <td style="background-color: rgb(102, 255, 0);">
507            Marketplace
508          </td>
509          <td style="background-color: rgb(204, 255, 204);">
510            low
511          </td>
512          <td>
513            reviews, Marketplace updates, app URI blacklist check
514          </td>
515        </tr>
516        <tr>
517          <td>
518            download URI
519          </td>
520          <td style="background-color: rgb(204, 255, 0);">
521            download URI
522          </td>
523          <td>
524            none?
525          </td>
526          <td style="background-color: rgb(255, 255, 0);">
527            medium
528          </td>
529          <td>
530            download and app URI blacklist checks
531          </td>
532        </tr>
533        <tr>
534          <td>
535            sideloading
536          </td>
537          <td style="background-color: rgb(255, 204, 0);">
538            none
539          </td>
540          <td>
541            none?
542          </td>
543          <td style="background-color: rgb(204, 255, 204);">
544            low
545          </td>
546          <td>
547            sideload restriction, app URI blacklist check
548          </td>
549        </tr>
550      </tbody>
551    </table>
552    <p>
553      &nbsp;

Back to History