Tip:
Highlight text to annotate it
X
Hello! My name is Adam Barth and I work on the Chrome team’s packaged apps effort.
I am here to talk to you about the security model of packaged apps.
Packaged apps have access to features and services that a normal web app would never
have access to. Users need to be confident that the apps they install will not behave
in unexpected ways that endanger their system. Chrome has a variety of defenses and protections
that make it easier for you to create safer apps.
The first is process and storage isolation. One of the foundations of the web security
model is that a web app or site on one domain is not allowed to affect the data held in
another. This same principle is upheld for packaged apps too. Even though an app is
installed, actions inside it should not be able to directly affect data in another.
Each packaged app runs in its own process, so if something goes awry it will not directly
affect apps running on the user’s system. The data stored in each app is also sandboxed
and isolated from other packaged applications installed on the user’s system. This means
that a file saved in the app will only be visible to the app and the user that created
it. Secondly, Chrome makes use of a technology
called Content Security Policy, commonly known as CSP. This technology helps protect users
and developers from common cross-site scripting attacks that can be found on the web. In
fact CSP is enforced by default for every packaged app.
Because packaged apps have access to even more features than a web app, CSP has disabled
some features that you might expect as a developer such as:
Inline scripts like click handlers and tags with code inside
and ‘eval’ and the ‘new function’ methods
We know that sometimes you need to use these features so we’ve introduced a feature called
“sandboxed pages”. These are pages in your app that use all the features of the
current web such as eval, new Function and inline script tags, but importantly have no
direct access to advanced packaged app features. The third protection in apps is the permissions
model. Apps can’t just use any feature they want. The user needs to have granted access
to this feature. You can easily declare your apps intent by configuring the permissions
that you need in the manifest file. For example you can declare that your app needs access
to the user’s video camera, or access to raw sockets.
Finally another security measure is the tag for web content.
Imagine you are building an RSS feed reader that will show news articles in the app experience.
Adding web content directly is dangerous, as you have no control over what external
authors are adding to their content. However the user experience demands that you show
the content. The tag is like an iframe in that it will allow you to embed
web content into your app from an external resource but it is entirely isolated from
your app. This was just a quick overview of the security
model for packaged apps. To learn more on how to develop packaged apps
visit developer.chrome.com/apps.