Compare Revisions

Application security

Change Revisions

Revision 414755:

Revision 414755 by Sheppy on

Revision 435785:

Revision 435785 by ptheriault on

Application security
Application security
"Security", "Apps", "Mobile", "Firefox OS"
"Mobile", "Security", "Apps", "Firefox OS"

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
46    </p>
47    <h4 id="Hosted_apps_">
48      <span class="mw-headline" id="Hosted_apps">Hosted apps</spa
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<
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</
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
 >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"></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="" rel="nofollow">http://maps.googl
 ></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="" 
 >rel="nofollow"></a> has access to geolocati
 >on within App A. If App B then opens <a class="external free" hre
 >f="" rel="nofollow"><
 >/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="
 >.com" rel="nofollow"></a>, then <a class="e
 >xternal free" href="" rel="nofollow">http:/
 >/</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="" rel="nofollow">https://m
 ></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://" rel="nofollow"></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="" rel="nofollow">http://ma
 ></a>, that will open an iframe which will receive a 
 >set of cookies for the <a class="external free" href="http://maps
 >" rel="nofollow"></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://" rel="nofollow"></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="" re
 >l="nofollow"></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
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<
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</ 
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 
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="" rel="nofollow">http://w 
></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 
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="" rel="nofollow">http://maps.googl 
></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="" r 
>el="nofollow"></a> has access to geolocatio 
>n within app A. If app B then opens <a class="external free" href 
>="" rel="nofollow"></ 
>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: 
>//" rel="nofollow"></a>, the 
>n <a class="external free" href="" rel="nof 
>ollow"></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="" rel="nofollow" style="line-hei 
>ght: 1.572;"></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="" rel="nofollow">h 
>ttps://</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="" rel="nofoll 
>ow"></a>, that will open an iframe which wi 
>ll receive a set of cookies for the <a class="external free" href 
>="" rel="nofollow"></ 
>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="" rel="nofollow 
>"></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=" 
>" rel="nofollow"></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, 
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, 
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, 
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