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.
=== 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 <i>belong</i> 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 - i.e. 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.
To additionally secure applications 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 large set of URLscookies for the http://maps.google.com website. If the user then navigates inside web content area, such as browsersi.e. inside the <iframe mozbrowser>, to http://maps.google.com, we have added this will use different cookies and different permissions than the top level app. Another example where this is useful is in a "browserContent flag"Yelp-like app. The browserContent flag allows each 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 have not onehttp://yelp.com). If it does, but two sandboxesthe website will only receive the Yelp website, one for rather than the Yelp app. So there is no way that the restaurant website can mount an attack against the app itself, and one for since the contained Yelp website won't share any "web content" that it openspermissions or data with the Yelp app. For example The security model can be shown in a simple picture <pre>+---------------------------------+| APP-001 |---->App-Sandbox| ----->Cookie-A| ----->indexedDBStorage-A| || +--------------------------+ || + http://maps.google.com +-------->Internal-Sandbox| +--------------------------+ || | | || | |-->Cookie-B| | |-->indexedDBStorage-B| | +------------------+ | || | | maps.google.com | | || | +------------------+---------->iFrame opened in web-app| | | |---------->Cookie-C| | | | |------->indexedDBStorage-C| | | | | || | | | | || | +------------------+ | || +--------------------------+ || |+---------------------------------+
Say that the MyBrowser app is loaded from the https://mybrowser.com domain. This is the domain where the scripts and resources which comprises the browser app itself.
If a page in this app creates a <iframe mozbrowser> we will inside this iframe always use a separate sandbox than the sandbox used by the app. I.e. if this iframe is navigated to https://mybrowser.com, this 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 than when opened by the app itself, outside of the <iframe mozbrowser>.
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, i.e. inside the <iframe mozbrowser>, to http://maps.google.com, this will use different cookies and different permissions than the browser-integration iframe.
Another example where this is useful is in a yelp+---------------------------------+| APP-002 |---->App-Sandbox| -----like app. Yelp has the ability to visit a restaurants 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 <iframeCookie-D| -----> pointing back to indexedDBStorage-D| || +--------------------------+ || + http://yelpmaps.google.com +-------->Internal-Sandbox| +--------------------------+ || | | || | |-->Cookie-E| | |-->indexedDBStorage-E| | +------------------+ | || | | maps. If it does, it will only receive the yelp website, rather than the yelp appgoogle. So there is no way that the restaurant website can mount an attack against the com | | || | +------------------+---------->iFrame opened in web-app since the contained yelp website won't share any permissions or data with the yelp app itself.| | | |---------->Cookie-E| | | | |------->indexedDBStorage-E| | | | | || | | | | || | +------------------+ | || +--------------------------+ || |+---------------------------------+</pre>
=== Apps can run content from many domains ===
