-
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?
- WORA: Write Once, Run Anywhere. How well is it the WORA concept supported for a given distribution model?
- Update: How is the runtime updated?
Access to privileged APIs requires that the runtime trusts the web application. The mechanism by which trust is established between the runtime and the web application could be through end-user prompting, through a chain of trust, or via 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 may be further mitigated through the use of a multi-process process architecture and process sandboxing.
Assuming the end-user trusts the runtime, this distribution model provides the highest level of end-user security.
Web applications execute completely within the confines of the HTML5 sandbox. There is no mechanism by which a web application can access additional platform capabilities (excluding exploits.)
In terms of the ability for an application vendor to leverage native or platform specific functionality, this distribution model provides the least flexibility.
Applications which adhere to ratified HTML5 standards will (in general) benefit from the “write once, run anywhere” ideal, provided the application takes into account responsive and adaptive design principles. However, history has shown that adherence to standards does not necessarily mean applications will operate in any standards compliant environment. Each runtime brings with it its own nuances in regard to timing, operation, or implementation of standards. Those variances may impact the functionality of an application.
Since the Cameo runtime uses the same Blink core on each supported operating system, Cameo hosted applications will support, as much as possible, the goals of the WORA ideal.
Web Applications run within a common environment, shared by other web applications, where the 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 application compatibility matrix. In this model, applications indicate in their manifest or via the cloud known good or 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 runtime 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 execute outside of a runtime environment, the end user must trust the application author not to be malicious. The runtime can help keep an embedding application secure against cross site scripting and injection attacks by running under a strict Content Security Policy, however the trust is between the end-user and the application vendor—the application vendor could have changed the default runtime enforcement policies.
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 are restricted only by the target operating systems’ default security model. In Windows, for example, the 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.
The portion of the application contained within the embedded web view is platform agnostic.
In this model the application developer links with a runtime, builds OS and CPU specific binaries, and must validate on every target platform. Application and runtime installation and update is managed by the application vendor.
A packaged application can only work if a runtime exists on the target user’s computer. Bootstrapping the packaged application with a native installer 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 can determine if the runtime is installed. If so, it requests the runtime to install the application. If not, the bootstrap wrapper automatically downloads the runtime and installs it on the system.
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 bootstrap application to be able to install the runtime, it needs to execute with full platform access. As such, the end user has to trust that the provider of the bootstrapped application (distributed as an EXE or MSI on Windows, APK for Android, DMG for OSX, and so on.)
If the bootstrap 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 Embedded 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.