There are many cases where the web could not reach its full potential. A resource limited device may only able to support a minor subset. Similarly, the web may not work on all infrastructure the same way. The Cloud Browser Solution prevent those limitations by shifting the Browser to the Cloud. This solution enables new markets and provides the full web feature set to any device. This Note explains the main building blocks for the technology. Furthermore, it provides use cases and requirements to be fully functional within the web ecosystem.

This is an Interest Group Note from the Cloud Browser Task Force. The Cloud Browser Task Force is part of the Media and Entertainment Interest Group. It has no official standing of any kind and does not represent the support or consensus of any standard organisations or contributor.

Introduction

The web becomes feature-rich. Media capturing, web workers, and many other features ensure an engaging experience. Increasing features impacts hardware resources usage. Not all features work on a resource-constrained device. An application will use features depending on the device capabilities. Managing all those device differences is complex. This is especially true for devices used in the media and entertainment industry. Devices in this industry have a longevity and are resource-constrained. A typical example is a set-top-box which has a lifespan of 8 years. Furthermore, updating those devices are discouraged because of the risk a device will fail. Consequently, it is limited in web features. Compared with a desktop computer or mobile phone the web experience is very different.

Content providers would like to provide the same experience to all devices. There are numerous reasons such as: they would not have to discriminate their uses based on the device; branding and communications are only needed for one experience; implementation and design are easier without having to deal with a variety of experiences. However, providing the same experience to a variety of devices is difficult.

The industry is shifting to another approach. Leading content providers will not use a general purpose web browser anymore; instead, they will use a constrained, customised, web browser. Some will constrain to a subset of the web specifications. Some will constrain to their own proprietary language. Others will constrain to a (native) javascript framework. Their approach assures (near) the same experience on each device.

Several web browser on a single device is not desirable. The device will only be able to handle a few. Each web browser will add burden to the hardware resources. This limits the set of possible applications on a device. Furthermore, the end user will lose the coherent experience from a general purpose web browser. Moving to different web browsers will slightly change the experience. It may use other page transitions or use other key shortcuts. Likewise, each web browser needs to be configured independently. For example enabling an accessibility feature needs to be done per web browser. Also, web developers will find it harder to develop for multiple browsers with their own constrains such-as javascript only. The authoring complexity will be moved from device diversity to language diversity.

Cloud Browser addresses these issues by putting the browser into a powerful server, or cloud. The execution is shifted to the cloud, where the user interface is rendered and send to the Client Device. The main purpose of the client device is presenting the user interface to the end user. This solution makes it possible to provide a uniform experience for a large range of devices. Furthermore, it reduces the need for resource intensive processing on the client device and helps to deploy new browser technologies faster.

Providing the web technology to a non-internet infrastructure is difficult. The Cloud Browser is agnostic to infrastructures. The Cloud Browser is terminated in the cloud and is able to use any infrastructure to the client. A typical example is a broadcast infrastructure where the client is not able to connect to a web server.

A great number of users experiencing the Cloud Browser Technology today. The technology is based on the foundation of the World Wide Web. However, there are differences with the World Wide Web traditional (client-server) model. This causes incompatibilities. The Cloud Browser Task Force will explorer this—as a joined effort between a variety of stakeholders. The task force provides requirements, use cases and a formalised architecture of a Cloud Browser Technology. This group note is the result and will be used for further standardisation on the Cloud Browser Technology.

Cloud Browser compared to a local browser

Most people are familiar with local browsers. A content server serves resources such as HTML, Javascript, and media. The local browser requests the resources and makes the User Interface perceivable for the end-user. The local browser operates in the operating system. Starting and stopping the browser is the responsibility of the operating system. In addition, it provides hardware functionality such as keyboard inputs. A Cloud Browser differ in various aspects:

• An operating system or desktop environment is not interacting with the web browser.
• The server executes the browser but displaying the user interface is on the client device.
• Resources such as memory or CPU are not used on the Client Device.
• The Cloud Browser is not directly connected to the Client Device hardware.

Cloud Browser compared with a split browser

A split browser, or transformation proxy, transform the content to the most appropriate format for the client device. The Cloud Browser is comparable but different.

• Split browsers provide the best possible representation but are limited by the client capabilities. The split browser could optimise the content but the client needs to process the content. A Cloud Browser terminates everything on the server. Therefore, circumvent the problem of client capability constraints.
• The Cloud Browser exists in the cloud. The initiator or client device is triggering events but is not responsible for the resources nor the representation.
• A Split browser "transforms" the content. The Cloud Browser acts as a local browser; therefore, don't alter the content.

Cloud Browser compared with a thin/fat paradigm

In a thin/fat paradigm, all processing is done on the server and the user interface is provided to a thin- or zero-client. Cloud Browser is very comparable but has three key differences:

• In a thin/fat paradigm, there are dependencies on an underlying operating system. The Cloud Browser only provides the web browser without dependencies.
• The Cloud Browser may complement a device, virtually. There is a strict separation between device and server in a thin/fat paradigm. In a Cloud Browser solution, the conceptual model for a device is different. A device is a hybrid of functionality between the apparatus and the orchestration.
• The Cloud Browser leverage client capabilities where applicable.

Terminology

Architecture

The following section provides the Cloud Browser Architecture. The goal is a consistent architecture between Cloud Browser vendors.

Single Stream

In the Single Stream approach, the orchestration provides both, the user interface and the media streams.

This approach executes the Web Application in the Cloud Browser and delivers the user interface to the Cloud Browser Client. A typical use case: the user starts the Client Device. The Cloud Browser Client triggers a signal. The signal is received and resolved in the orchestration. It delegates further processing to the Cloud Browser. The Cloud Browser request, download, and parse the resources. These resources include HTML, CSS, and JavaScript. JavaScript is processed and executed. User Interface painting commands are sent to the Graphic Library.

In case the Web Application requests a media stream from a Media Server. The Graphic Library will combine the media stream together with the User Interface. The Orchestration sent a single media stream to the Cloud Browser Client; encoded by a Client Device supported codec. The Cloud Browser Client decode and present the stream to the Client Device display.

Double Stream

With a Double Stream approach, the Cloud Browser renders the user interface only, while the media is delivered from another source. The User Interface and media streams are delivered separately to the Client Device, which then has to combine both of these streams. The Cloud Browser Client present them to the end-user in a unified form. This approach leverages the video delivery infrastructures. A typical example of a delivery infrastructure is broadcast networks. Here the media is sent to all receivers at ones. Rerouting the traffic is not desired.

This approach executes the Web Application and delivers the User Interface to the Cloud Browser Client as the single stream approach. A media stream is delivered Out Of Band from another source. Blending is done on the Cloud Browser Client. The user interface is usually provided as a sequence of images which a Client Device could process within its own Graphic Library.

Use Cases

Cloud Browser Use Cases are split into two categories. Communication and execution.

Communication uses cases

Enabling a Cloud Browser solution will need communication between a Cloud Browser Client and the Orchestration. Outcomes from these use cases will lead to new standards.

Execution Use Cases

Execution Use Cases describe the challenges that the Cloud Browser encounter. Some use cases will work on a local browser but are problematic on a Cloud Browser. These use cases will be used to extend or modify existing standards.

                  var support = videoElement.canPlayType('type=\'video/mp4; codecs="avc1.42E01E, mp4a.40.2"\); 
                  if (support == "probably") console.log("natively supported") 
                  else if (support == "virtually") console.log("supported by transcoding")
                

Acknowledgments

Special thanks to Oliver Friedrich, Nilo Mitra, Kaz Ashimura and Steve Morris for there contributions to this document.