Main Page/Cloud Browser TF/Introduction cloud browser

introduction to the Cloud Browser

This article is meant as introduction to the cloud browser concept. It will highlight the differences with a "normal browser" (local browser) and the gaps we need to explore within the Task Force. To find detail information see: Cloud Browser Architecture.

Most people are familiar with a local browser. You have a content server with resources such as HTML, Javascript, media, etc. The local browser requests the resources usually through HTTP(S) and processes it (i.e. makes it viewable for the end-user). The local browser is attached to the operating system, which is responsible for starting and stopping the browser as well as providing OS-level resources such as CPU and memory. In addition, it provides hardware functionality such as a keyboard input or a display. In this article we will refer to this functionality as an appliance (i.e. a minimal set of functionality that identifies a type of hardware). The image below depicts a schematic overview of the local browser.

Obviously this is a very simplified diagram but let us focus on the main differences with the Cloud Browser which is depicted below.

in essence the architecture is quite the similar for the cloud browser but the missing part is the OS and therefore the available appliances. Probably the most apparent missing appliance is the display. In the Cloud Browser Task Force we identify the display appliance which will be implicitly part of the so-called client. The client has the responsibility to display the visual part of the cloud browser among other things.

Note that this is a conceptual diagram because the client will not communicate directly with the cloud browser. This is an important requirement we identified in the task Force. This is because we don't want to add specific cloud browser APIs, i.e., the cloud browser should act as a local browser. This allows a web application to migrate from a local browser to a cloud browser without any changes. The client therefore needs to communicate with something different. We call it orchestration, which is responsible for many things such as the communication between the client and cloud browser, session management, etc.

Note that both the client and orchestration are vendor specific. To be more precise, the client is a generic type of hardware such as a SmartTV or a set-top-box. Each client needs to implement a small part which should be standardised to be vendor interoperable. This is what we called the run time environment (RTE). The RTE is is responsible for rendering and communication. See also our communication use cases. The RTE should have a very small footprint and shouldn't (or at least at the minimum) try to interpret the user interaction. For example a key press should be passed to the orchestration which interprets the intention. This allows the orchestration to have full control of the behaviour. This is an essential requirement because the RTE doesn't have any context (e.g. application state and semantics)

Cloud browser TF challenges

interface

A large part of the work should be to specify a interface which allow the RTE and orchestration to communicate with each other. The assignment for the Task Force is to create use cases and requirement for this interface.

W3C API compatibility

This is not the only task. The infrastructure for the orchestration could become quite complex and is very dependent on the underlying network such-as IPTV vs broadcast, managed vs unmanaged, etc. The cloud browser vendors' challenge is to integrate with the different types of infrastructure. Here is a hypothetical infrastructure of a cloud browser on a broadcast network.

The cloud browser needs to abstract this complexity but some defined W3C APIs aren't designed to work in a cloud browser environment. A typical example would be the vibrate api. This API is specified to be used locally to turn on or off the vibration on an phone for example. Apart from the question of what should vibrate (perhaps a vibrate enabled remote control attached to the client) it is a synchronous API which doesn't work well in a distributed system. The Task Force will try to identify such gaps.

Similarly, it is not always straightforward how to interpret information provided by the APIs. For example the the video playback quality in MSE. Should it be interpreted as the quality from the cloud browser or the quality the end user actually perceives on the client? Such properties need to be identified so that all cloud browser vendors are provided the same information.

Accessibility

Accessibility has a high priority in this Task Force because the way an end user will receive the content is very different from that using a local browser. The client is unable to make any sense of the non-semantic source. Therefore assistive technology isn't able to connect to the client directly. Other means should be investigated to make this technology accessible. The initial thought is that an assistive technology device is seen as an appliance which directly (or via the RTE) communicates with the orchestration which uses the semantic data from the cloud browser to make it accessible as depicted in the image below.

Metrics

A non-technical difference is monetisation. A local browser consumes the resources from the end user (not directly from the end user but the application provider), while the cloud browser consumes the resources from a service provider. In both cases, there is a need to know who is consuming what resources. Additional metrics might be needed, which is up to the Task Force to identify.

Content protection

Another non-technical issue which could arise in a cloud browser is content protection. In the most simplistic view, everything is terminated in the cloud browser. For example, in the case of EME, this could be a problem because the media is send in the clear from the orchestration to the RTE. This may impact the architecture of the cloud browser substantially; so this has our full attention as well.

Cloud Browser TF Goal

The goal of this task force will be to provide enough use cases and requirements which will lead to updated specifications and, where necessary, new ones. Those specifications will result in interoperability between cloud browser vendors, i.e., without requiring any changes in the web applications as well as the clients.