-
Notifications
You must be signed in to change notification settings - Fork 0
Deployment Models
There are three deployment models supported by Cameo for applications: managed, 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 managed 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 need only 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 typically use the managed 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.)
To use the managed deployment model the application vendor creates a packaged or hosted web application, following Cameo's manifest and packaging specification. They then host their application on a website or in an application store. Upon downloading the application, the end-user (depending on OS integration) will either be automatically prompted to install the application into the Cameo environment, or the user will need to select the Cameo environment to open the downloaded file.
The managed deployment model provides the highest level of end-user security. End users do not need to trust the application vendor to be honest--Cameo restricts the application to only access capabilities the user or run-time have determined to be appropriate for the particular application.
Access to privileged APIs requires Cameo to trust the application sufficiently to grant access to those APIs. Trust may be established through end-user prompting, chain of trust, or other means. An 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 in Cameo itself.
Applications running in the managed Cameo environment execute in the confines of the HTML5 sandbox. As such, there is no mechanism for those applications to access additional native OS capabilities.
The managed Cameo run-time is updated as part of a process outside the control of the web application.
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 help keep applications which work from breaking when a new version of Cameo's managed environment is updated. This is accomplished by allowing applications to list Cameo major version number in their manifest file indicating which version of the managed run-time the application is known to work in.
NOTE: Supporting the above requires that multiple versions of the managed run-time can co-exist on the same system. The Cameo update infrastructure can remove versions which are no longer needed by any installed applications.
In the embedded (sometimes referred to as "WebView") deployment model, Cameo is used as a sub-component of a native application. This is analogous to 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. Cameo Embedded 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 instantiating Cameo Embedded 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.
An example implementation utilizing Cameo embedded could be an email client where there is an existing code base providing many native interaction elements, and the embedded view is only being used to display emails containing HTML content.
To use the embedded deployment model the application vendor creates an application on a supported operating system, written in C/C++. As part of the build process, the application links with the Cameo Embedded libraries (either dynamically or statically.) Within the application, when the embedded view is instantiated, the Cameo libraries will spawn off the necessary processes and infrastructure to manage the internal HTML viewport and JavaScript context. The application vendor can extend and manipulate the JavaScript context and HTML DOM using native code.
Because native applications are built and execute outside of a run-time environment, the end user must trust the application author not to be malicious. Cameo Embedded 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 Embedded 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.
Native applications built with Cameo Embedded are restricted from the native platform 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 Cameo Embedded do so by linking their application with specific Cameo libraries. The update of the application, and any of its components, is up to the application vendor and is not a capability provided by Cameo Embedded.
In Cameo's bootstrap deployment model, the application package is wrapped with an OS specific executable which can install the run-time 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 executable.
A packaged application will only work if a run-time exists on the target user’s computer. Bootstrapping the packaged application with Cameo allows the application developer to ensure that the target user has the run-time 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 run-time is installed on the system. If not, the bootstrap wrapper automatically downloads the run-time and installs it on the system prior to installing the packaged web application.
The offline version includes a full version of the run-time 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.
To use the bootstrap deployment model, the application vendor builds an application as if they were intending to use the managed deployment model. Once they have their packaged or hosted application, they provide that software to the bootstrap service, which will wrap that application in an OS specific installer. The cloud service then returns OS specific binaries to the developer for them to distribute.
In order for the Cameo bootstrapped application to be able to install the run-time, 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 run-time they bundle with the application to violate the sandbox restrictions. As such, 3rd party bootstrapped run-time must not install over the Cameo managed run-time.
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 run-time 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 run-time 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
Application vendors which use the cloud service to create the bootstrapped executable will install into and use the managed Cameo application run-time. As such, the run-time follows the same update methodology as the managed deployment model.
Application vendors that do not use the Cameo cloud service to bootstrap their application will not connect to the Cameo update server. They can, at their discretion, deploy their own update server and configure their application to connect to that server for updates.
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 in the managed Cameo application run-time.
A variation of the Bootstrap method is for a vendor 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 run-time onto various target operating systems and CPU architectures. Many of the motivations for using the embedded 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. This is the model that can be easily used for creating a Cordova like environment leveraging the managed Cameo run-time while exposing additional APIs by vendors that need additional native capabilities.
Application vendors providing a native plug-in or API extension are able to access all system capabilities. In addition, because the native plug-in can not be verified or contained by the managed run-time typically installed by Cameo, the bootstrap variation can not use the cloud service to sign the binary. In addition, the run-time must not be installed in the same location as the Cameo run-time and needs to install into a vendor specific location.