-
Notifications
You must be signed in to change notification settings - Fork 0
Deployment Models
There are three deployment models supported by Cameo for applications: shared, embedded, and bootstrapped.
Each of the models have characteristics which influence the approach an application vendor may choose. Some of those characteristics are:
- Security: How is access to privileged APIs mitigated? Does the user have to trust the author of the application? How does the run-time protect the user from malicious (intentional or exploited) applications?
- Native Access: What native capabilities are available to the application writer? If there are gaps in the standard APIs, can the application vendor extend the run-time with additional features for their application?
- Update: How is the run-time updated?
The following sections describe each of these deployment models in greater detail.
Cameo provides a shared application run-time environment for executing Packaged and Hosted Web Applications. The W3C defines these as traditional web applications combined with a manifest file indicating that a web application can be installed on the end-user’s device. The distinction between Packaged and Hosted is that the former provides all of the files necessary to run the web application within a single signed binary. Hosted applications provide a manifest file and connect to their origin-server to obtain additional resources (including, but not limited to, JavaScript, CSS, and HTML content.)
Application vendors looking to create OS and CPU independent applications leveraging HTML5 technologies will use the shared deployment model. If the application vendor wishes to take advantage of Cameo specific capabilities, they may do so--however that application will then only run in either the Cameo run-time, or a run-time that includes the Cameo APIs (via JavaScript poly-fill or other means.)
Access to privileged APIs requires Cameo to trust the web application sufficiently to grant access to those APIs. Trust may be established through end-user prompting, chain of trust, or other means. A web application is only granted access to privileged APIs which are explicitly requested in the application’s manifest file and granted to it by Cameo.
Attempts to access APIs not explicitly granted to the application are blocked by Cameo. Exploits in Cameo are further mitigated through sandboxing techniques.
This deployment model provides the highest level of end-user security.
Web applications running in the shared Cameo environment execute completely within the confines of the HTML5 sandbox. As such, there is no mechanism for those applications to access additional native OS capabilities.
The shared Cameo run-time is updated as part of a process outside the control of the web application.
Some features used in modern web applications are doing so based on draft or preliminary capabilities which are not part of a ratified standard. There is no guarantee that applications which work today in a given run-time will continue to work in the future. Unlike a traditional operating system, where platform API/ABI compatibility is maintained and the use of undocumented or experimental APIs is rare, the web ecosystem is continually evolving new APIs and technologies which are not finalized. Applications written using those APIs are subject to breakage as run-times are updated.
While Cameo strives to provide backward compatibility, we acknowledge that bugs will occur[1]. This is especially relevant in office productivity applications. As such, Cameo is designed with an update mechanism to account for this--preventing applications which work today from breaking when a new version of Cameo's shared environment is updated tomorrow. This is accomplished by allowing applications to list Cameo major version number in their manifest file indicating which version of the shared run-time the application is known to work in.
NOTE: Supporting the above requires that multiple versions of the shared run-time can co-exist on the same system, with the Cameo update infrastructure pruning and removing versions which are no longer needed by any installed applications.
- Embedded / WebView: Cameo is used as a component of a native application. This is analogous with the traditional Gecko, Qt WebKit, and CEF usage models. The embedder (native application) is responsible for providing their own installer and integration with the native operating system. The WebView abstracts the application writer from the complexities of the Chrome Content Module's multi-process architecture and provides default window UI integrations (such as combo-boxes).
Applications wishing to implement some of their user interface via native platform APIs and other parts using HTML and JavaScript can do so by embedding the Cameo WebView within the native application. Examples include integration with the operating system’s native system menu, taskbar, non-DOM window confined tooltip and element rendering, and window decoration.
Because native applications are built and execute outside of a runtime environment, the end user must trust the application author not to be malicious. The Cameo WebView helps to keep an embedding application secure against cross site scripting and injection attacks by running under a strict Content Security Policy. However, the consumer trust is between the end-user and the application vendor—Cameo WebView can not prevent the application vendor from circumventing default protections.
Due to the complexities of writing secure software and the prevalence of cross-site scripting and malicious injection, even within well intended software, it is recommended that any embedded view of web content in a hybrid application be instantiated with stringent CSP limitations, preventing inline scripting, eval() / function semantics allowing string-to-JavaScript conversion, and references to external application HTML, CSS, or JavaScript.
Cameo WebView based native applications are restricted only by the target operating systems’ default security model. In Windows, for example, native API access may be restricted based on the originating source of the executable. Native capabilities provided by the application may be exposed to the JavaScript executing within the run-time by extending the JavaScript namespace.
Applications built using the Cameo WebView do so by linking their application with a specific binary version of the Cameo WebView. The update of the application, and any of its components, is up to the application vendor and is not a capability provided by the Cameo WebView.
- Bootstrapped packaged application: The web application is wrapped with an OS specific executable which can install the runtime on the end-user’s system prior to installing the application. A variation of the bootstrapped model is to include vendor provided native extensions / plug-ins with the bootstrapped executables.
A packaged application can only work if a runtime exists on the target user’s computer. Bootstrapping the packaged application with the Cameo bootstrap allows the application developer to ensure that the target user has the runtime installed.
There are typically two modes of bootstrap packaging – online and offline. The _online _version wraps the packaged application with a small piece of code which, when executed, can determine if the runtime is installed on the system. If not, the bootstrap wrapper automatically downloads the runtime and installs it on the system prior to installing the packaged web application.
The _offline _version includes a full version of the runtime with the native installer. While this can increase the size of an application by tens of megabytes, it ensures that users can install the application without the ability to connect to any cloud services.
In order for the Cameo bootstrapped application to be able to install the runtime, it needs to execute with full native platform access. As such, the end user has to trust the provider of the bootstrapped application, which is distributed as an EXE or MSI on Windows, APK for Android, DMG for OSX, and so on.
If the bootstrapped binary is provided by a 3rd party, that 3rd party may have modified the runtime they bundle with the application to violate the sandbox restrictions. As such, 3rd party bootstrapped runtimes must not install into the common shared runtime area.
On Windows 8, the SmartScreen malware protection may prevent the user from being able to install the application if the application vendor is not recognized through the Microsoft reputation system. Due to how code signing works, it is not possible to provide a mechanism for the runtime itself to be signed and have the packaged application “attached” to the signed application.
To work with the SmartScreen software, either each application vendor will need to sign their application or the runtime will need to provide a cloud service where the vendor submits their packaged application, a secure cloud server bundles it with the bootstrapper, and digitally signs the resulting application with a trusted certificate.
TBD
TBD
TBD
The packaged application contained in the bootstrap does not have any access or capabilities beyond that which is provided to stand alone packaged applications – the application executes within the HTML packaged application security sandbox.
A variation of the Bootstrap method is to provide a native plug-in with the bootstrapped application. This usage is typically used by software vendors which need additional native capabilities, yet do not have the means or desire to re-invent the ability to install a runtime onto various target operating systems and CPU architectures. Many of the motivations for using the WebView model are shared with the motivation for using the Bootstrap + Native model.
Examples motivations for the Bootstrap + Native model include exposing new native platform capabilities, full file system access, and so on.
The Bootstrap Security above.
Application vendors providing a native plug-in or API extension are able to access all system capabilities.