-
Notifications
You must be signed in to change notification settings - Fork 0
Deployment Models
There are three deployment models supported by Cameo:
- Runtime: Cameo provides a runtime environment for executing Packaged and Hosted Web Applications. As the W3C defines them (http://runtime.sysapps.org/#packaged-applications), these are traditional web applications combined with a manifest file which indicates that a web application can be installed on the end-user’s device. Web Applications may install into whichever runtime the end-user happens to have configured on their operating system, with different runtimes providing potentially different APIs and functionality.
- 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.
- 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.
Each of the above deployment models have varying characteristics which influence which 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 runtime protect the user from malicious (intentional or exploited) applications?
- Platform Access: What capabilities are available to the application writer? If there are gaps in the standard APIs, can the application vendor extend the runtime with additional features for their application?
- Update: How is the runtime updated?
Security, platform access, and update capabilities for the Cameo Runtime are described below.
Access to privileged APIs requires the runtime 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 the runtime.
Attempts to access APIs not explicitly granted to the application are blocked by the runtime. Exploits in the runtime are further mitigated through sandboxing techniques.
This deployment model provides the highest level of end-user security.
Web applications running in the Cameo runtime execute completely within the confines of the HTML5 sandbox. As such, there is no mechanism for a web application to access additional platform capabilities.
The Cameo runtime 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 runtime 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 runtimes are updated.
If an application breaks between pay-for-upgrade releases due to an incompatibility introduced through a runtime update, who is going to support the end-user? Are those users going to be willing to pay more money for the next product release if they were left high and dry for several days while they waited for someone to figure out why they can no longer do whatever it was they were doing in that web application they bought last month?
The above is especially relevant in productivity applications vs. media consumption and communication environments.
Possible improvements to this scenario include supporting parallel runtime installation with an application compatibility matrix. In this model, applications indicate in their manifest or via the cloud "known good" and "known bad" runtime combinations. Generation of this information is application developer controlled as well as automatically cloud sourced based on automated installation phone-home feedback. The runtime is only updated on the end –user device to “known compatible” versions of the runtime for the applications the user has installed. This follows the “if it isn’t broken, don’t fix it” credo. Unlike a browser which has to continually update itself to fix security exploits or functionality bugs, a runtime only has to be updated on the user’s system if it fixes an application the user already has installed.
Having a well-documented release cycle allows application developers to proactively test their application with new runtime versions, and to then manually update their application’s compatibility details in the application manifest.
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, platform 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 runtime 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.
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 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 platform capabilities, yet do not have the means or desire to re-invent the ability to install a runtime onto various target operating systems and platforms. 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 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 platform capabilities.