This document summarizes how technologies currently developed in W3C apply to the Cloud context. This is a subset of our generic HTML5Apps roadmap highlighting standard work that is relevant to EU R&D projects developing Cloud software, in particular at the PAAS and SAAS layers.
- Core Web Design and Development
- Media and Real-Time Communications
- Usability and Accessibility
- Device Interaction
- Network Integration
- Application Lifecyle
- Payment and Services
- Performance & Tuning
- Security & Privacy
Document structure
Features in this roadmap are organized around the application foundations for the Open Web Platform, a set of high-level components that application developers rely on to build their Web-based content and services.
The following application foundations are considered in this document: core web design and development, media and real-time communications, usability and accessibility, device interaction, application lifecycle, payment and services, performance & tuning, and security & privacy. In addition, it covers topics related to network integration.
Beyond the areas covered below, the following W3C areas are relevant for Cloud services:
- the W3C Web of Things activity is also very relevant, as it focuses on servers ranging from micro-controllers to cloud based server farms where large numbers of sensors, high message through put and big data are very much to the fore. W3C’s contribution in this area focuses on metadata as an enabler to implementing an abstraction layer that sits above the platforms and protocols, a bit like the Web itself sits on top of lower level Internet protocols.
- most of the Cloud computing API work is based URIs and REST, concepts developed by the W3C and IETF, so these needs to be tracked as well.
- Efficient XML (EXI) is used by a lot of frameworks for exchanging structured data.
- Cloud programmers should pay attention to MMI, the multimodal interface activtities of W3C, since in addition to integrating multiple UI modalities, e.g., GUI, speech, touch and gesture, the scope of the latest charter of the multimodal interaction Working Group includes combination of cloud services and multiple input/output modalities provided by more than one devices.
The Web as an application development platform
In each category of features, a table summarizes for each feature:
- which W3C specification defines the feature,
- which W3C group is responsible of the said specification,
- the stage of the specification in the W3C Recommendation track (see below),
- the estimated stability of the feature, i.e. how little the author expects it to change, from an early draft that can still evolve a lot, to a finished document with only minor expected changes,
- a link to the latest editors draft of the document, and a representation of the recent editing activity;
- some qualitative indication on availability of implementations on mobile devices, based on data collected primarily from Can I Use… and mobile HTML5, completed with data from Mozilla developer network, QuirksMode, JWPlayer's state of HTML5 video, Chromium Dashboard, Internet Explorer Platform status, the Device APIs Working Group Implementation status as well as the author’s understanding of the mobile devices market (see also the code used to generate the support icons)
- When available, a link to a relevant tutorial on WebPlatform Docs, and to relevant on-line training courses on W3DevCampus
- a link to the test suite for the said feature, and when relevant, a github ribbon to access the underlying git repository.
W3C creates Web standards by progressing documents through its Recommendation track, with the following stages:
- “Editors drafts” represent the current view of the editors of the specification but have no standing in terms of standardization.
- “Working Drafts” (WD) are early milestones of the Working Group progress.
- “Last Call Working Drafts” signal that the Working Group has determined that the specification fulfills its requirements and all the known issues have been resolved, and thus requests feedback from the larger community.
- “Candidate Recommendations” (CR) trigger a call for implementations where implementors are invited to implement the specification and send feedback; Working Groups are expected to show the specification gets implemented by running test suites they have developed.
- “Proposed Recommendations” (PR) manifests that the group has gathered sufficient implementation experience, and triggers the final review by W3C Members
- “W3C Recommendations” (Rec) are stable and completed Web standards; these documents only get updated rarely, through the “Edited Recommendation” process, as a results from errata collected by Working Groups.
For groups that have adopted it, the 2014 update of the W3C Process simplifies a bit the progression by removing the Last Call stage — instead of a single global call for review addressed to the whole community, Working Groups are empowered with solicitting reviews from their various related communities as long as they can demonstrate sufficient wide review of the specification before requesting transition to Candidate Recommendation.
Prior to starting standardization, a Working Group needs to be chartered, based on input from W3C Members, often through the organization of a workshop, or after the reception of a W3C Member Submission.
W3C has set up Community Groups, a mechanism that allows anyone to do experimental work within the W3C infrastructure, under IPR rules that are compatible to transition the work to the W3C standardization process.
1. Core Web Design and Development
Overall, he Graphics and Layout layers are not very relevant for the Cloud programmers, they are part of the UI considerations. That being said, the Web provides a valuable portable layers for Cloud application UIs, allowing them to concentrate on the lack of standards at the PAAS/IAAS level.
However, IndexedDB and background synchronisation create a good combination needed for Cloud storage so it is something Cloud designers should track.
Some of this data need to be encrypted, the Web Cryptography API from the Web Cryptography Working Group exposes strong cryptography primitives to Web applications, and can be bound to pre-provisioned keys via the WebCrypto Key Discovery API.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Developers doc | Test suite |
---|---|---|---|---|---|---|---|---|
Cloud storage | Indexed Database API | Web Applications | Stable | Finished | Well deployed | Good coverage | ||
Web Background Synchronization | Web Applications | N/A | Early draft | Last updated April 2015 | None | None | ||
Encrypted storage | Web Cryptography API | Web Cryptography | Stable | Last updated November 2014 | Well deployed | Early start | ||
WebCrypto Key Discovery | Web Cryptography | Early work | Last updated May 2014 | None | None |
2. Media and Real-Time Communications
More and more, sharing/streaming media is a big use case for cloud technologies, as the cloud makes everything faster and appear closer on the net, large binary objects in particular.
The natural distribution of media on a given Web page, coming from different servers, in different authenticated streams, should lead to a Cloud friendly architecture but Cloud designers are not always at the table to raise their requirements.
HTML5 adds two tags that dramatically improve the integration of multimedia content on the Web: the <video>
and <audio>
tags. Respectively, these tags allow embedding video and audio content, and make it possible for Web developers to interact much more freely with that content than they would through plug-ins. They make multimedia content first-class citizens of the Web, the same way images have been for the past 20 years.
The playback content can be streamed, augmented and completed via Media Source Extensions that lets developers buffer and generate media content in JavaScript.
To cater for the needs of some content providers, a proposal to enable playback of protected content, Encrypted Media Extensions is an API that is under consideration in the HTML Working Group.
While the new HTML5 tags allow to play multimedia content, the HTML Media Capture defines a markup-based mechanism to access captured multimedia content using attached camera and microphones, a very common feature on mobile devices. The Web Real-Time Communications Working Group and the Device APIs Working Group are building together an API (getUserMedia
) to directly manipulate streams from camera and microphones, as well as an API to record these streams into files, and another API to use access to cameras to take photos programatically. This makes it easy for Cloud-based media processing content to obtain content from end-user devices.
Beyond capturing and recording, two additional APIs add multimedia manipulation capabilities to the Web platform. We have already mentioned the Canvas 2D Context API: it enables modifying images, which in turn opens up the possibility of video editing.
In a similar vein, the Audio Working Group is working on an API that that makes it possible to modify audio content, as well as analyze, modify and synthesize sounds, the Web Audio API.
The Web Real-Time Communications Working Group is the host of specifications for a wider set of communication opportunities:
- Peer-to-peer connection across devices,
- P2P Audio and video streams allowing for real-time communications between users.
The combination of all these features marks the starting point of the Web as a comprehensive platform for multimedia, both for consuming and producing. The rising interest around bridging the Web and TV worlds (manifested through the W3C Web and TV Interest Group) should strengthen that trend in the coming months. Mobile devices are expected to take a growing role in many users TV experience, providing a “second screen” experience, where users can find more information on or interact with a TV program they're watching via their mobile devices.
3. Usability and Accessibility
UI considerations are not very relevant for the Cloud programmers, but the Web provides a valuable portable layer for cloud applications UIs.
4. Device interaction
A primary use case for Cloud technologies in the near future will be to handle data gathered from the myriad of sensors that get build and distributed in devices all over the planet.
Web technologies can increasingly be used to interact with these sensors.
The Geolocation API provides a common interface for locating the device, independently of the underlying technology (GPS, WIFI networks identification, triangulation in cellular networks, etc.).
Web applications can also now access orientation and acceleration data via the DeviceOrientation Event Specification.
A number of APIs for other sensors are under development: the Battery Status API, the Proximity Events API, the Ambient Light Events API or the proposed Ambient Humidity Events API. The Device APIs Working Group has started an effort to propose a unification pattern for these various sensors.
As already mentioned in the section on multimedia, there is ongoing work on APIs to open up access to camera and microphone streams.
A Web Bluetooth Community Group was started to develop a Bluetooth API for browsers with a particular goal of supporting Bluetooth Low Energy devices.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Developers doc | Test suite |
---|---|---|---|---|---|---|---|---|
Geolocation | Geolocation API Specification | Geolocation | Finished | Finished | Widely deployed | Good coverage | ||
Motion sensors | DeviceOrientation Event Specification | Geolocation | Stabilizing, but with planned updates | Last updated August 2014 | Well deployed | Started | ||
Battery Status | Battery Status API | Device APIs | Stable | Last updated August 2015 | Growing | Good coverage | ||
Proximity sensors | Proximity Events | Device APIs | Likely to evolve substantially | Last updated September 2015 | Very limited | Started | ||
Ambient Light sensor | Ambient Light Events | Device APIs | Likely to evolve significantly | Last updated September 2015 | Very limited | Started | ||
Humidity sensor | Ambient Humidity Events | Device APIs | N/A | Unofficial draft | Last updated October 2013 | None | N/A | |
Generic Sensors | Generic Sensor API | Device APIs | Early draft | Last updated June 2015 | N/A | N/A | ||
Camera & Microphone streams | Media Capture and Streams | Device APIs and Web Real-Time Communications | Stabilizing | Last updated August 2015 | Growing | started | ||
Bluetooth | Web Bluetooth | Web Bluetooth Community Group | Not on standards track | Early draft | Last updated August 2015 | Experimental | N/A |
5. Network Integration
Interacting with the network is key to any Cloud-oriented application or service.
The Web platform is growing a number of APIs that facilitate establishing network connectivity in different contexts.
XMLHttpRequest (the basis for Ajax development) is a widely deployed API to load content from Web servers using the HTTP and HTTPs protocol: the W3C specification (formerly known as XMLHttpRequest Level 2) was meant to document the existing deployed API (with the ability to make requests on servers in a different domain, programmatic feedback on the progress of the network operations, and more efficient handling of binary content), but that work is now likely to be done only in the WHATWG. The WHATWG fetch API also provides a more powerful Promise-based alternative.
The Beacon API aims at letting developers queue unsupervised HTTP requests, leaving it to the browser to execute them when appropriate, opening the door for better network optimizations.
Early work on a Web Background Synchronization API would provide a robust Service Worker-based mechanism to enable Web applications to download and upload content in the background, even in the absence of a running browser.
By default, browsers do not allow to make request across different domains (or more specifically, across different origins, a combination of the protocol, domain and port) from a single Web page; this rule protects the user from having a Web site abusing their credentials and stealing their data on another Web site. Sites can opt-out of that rule by making use of the Cross-Origin Resource Sharing mechanism, opening up much wider cooperation across Web applications and services.
XMLHttpRequest is useful for client-initiated network requests, but mobile devices with their limited network capabilities and the cost that network requests induce on their battery (and sometimes on their users bill) can often make better use of server-initiated requests. The Server-Sent Events API allows triggering DOM events based on push notifications (via HTTP and other protocols.)
Early work on a Push API would allow Web applications to receive server-sent messages whether or not the said Web app is active in a browser window. An IETF Working Group charter is under discussion to standardize the protocol aspects of the mechanism.
The WebSocket API, built on top of the IETF WebSocket protocol, offers a bidirectional, more flexible, and less resource intensive network connectivity than XMLHttpRequest.
The work on Web Real-Time Communications will also provide direct peer-to-peer data connections between browsers with real-time characteristics, opening the way to collaborative multi-devices Web applications.
Of course, an important part of using network connectivity relies on being able to determine if such connectivity exists, and the type of network available. The HTML5 onLine DOM flag (and its associated change event, ononline
) signals when network connectivity is available to the Web environment.
The network-information API, which was supposed to address discovery of the network characteristics, has been abandoned for the time being due to lack of clear supporting use cases.
The Resource Timing API offers to measure precisely the impact of the network on the time needed to load various resources, offering another approach to adapt a Web app to its network environment.
6. Application Lifecycle
While Cloud services are potentially always in operation, their usage by end-users depend on their proper integration in the clients that they interact with, whose lifecycles depend on many parameters: battery, network connectivity, visibility on the device, etc.
These notions are part of the overall application lifecycle: how applications get installed, shown to the user in applications list, started, stopped, woken up from remote notifications, synced up when the device goes on-line.
These various capabilities are brought the Web platform through different mechanisms.
Although the notion of installed Web applications is still not well-defined, there are several components to the notion of installation that are under development.
Packaging on the Web describes a Web-adapted format to make Web content available in a singe file for ease of download, sharing or archiving.
Whether packaged or not, users rely on a variety of metadata (name, icons) to identify the apps they want to use among their list of regularly used applications. The JSON-based manifest format lets developers group all these metadata in a single JSON file.
HTML5’s ApplicationCache
enables access to Web applications off-line through the definition of a manifest of files that the browser is expected to keep in its cache.
While relatively well deployed, the current approach has shown some strong limitations in terms of how much developers can control what gets cached when. The Web Applications Working Group has thus been developing a more powerful approach, ServiceWorker.
Not only does Service Worker enables Web applications to work seamlessly off-line or in poor network conditions, it also creates a model for Web applications to operate when they have not been opened in a browser window, or even if the browser itself is not running.
That ability opens the door for Web applications that run in the background and can react to remotely triggered events.
The Task Scheduler API makes it possible to trigger a task at a specified time via the Web app service worker. While the System Applications Working Group in which this API was developed has closed, the ServiceWorker-based approach taken in the specifications may make it an interesting starting point for further work in this space.
Similarly, the new geofencing API enables to wake up a Web app when a device enters a specified geographical area.
The Push API enables Web applications to subscribe to remote notifications that, upon reception, wake them up. Native applications have long enjoyed the benefits of greater user engagement that these notifications bring, and soon Web applications will share that ability.
Likewise, the Web Background Synchronization specification will enable Web applications to keep their user data up to date seamlessly, by running network operations in the background.
The Page Visibility specification lets developers detect when their application is in the foreground, and thus adapt their operations and resource consumption accordingly.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Developers doc | Test suite |
---|---|---|---|---|---|---|---|---|
Packaging | Packaging on the Web | TAG and Web Applications | Early draft | Last updated February 2015 | None | N/A | ||
Manifest for a web application | Web Applications | Early draft | Last updated August 2015 | Limited | N/A | |||
Offline Web Apps | ApplicationCache in HTML5 | HTML | Stable (but Service Workers will be the preferred approach when available) | Finished | Well deployed | None | ||
Service Workers | Web Applications | Early draft | Last updated September 2015 | Limited | Well started | |||
Scheduled tasks | Task Scheduler API Specification | System Applications | Retired | Early draft | Last updated October 2014 | None | None | |
Geofencing | Geofencing API | Geolocation | Just started | Last updated June 2015 | None | None | ||
Remote Notifications | Push API | Web Applications | Early draft, now with Service Workers | Last updated August 2015 | Limited | N/A | ||
Background Sync | Web Background Synchronization | Web Applications | N/A | Early draft | Last updated April 2015 | None | None | |
Foreground detection | Page Visibility | Web Performance | Finished | Well deployed | Good coverage |
7. Payment and Services
Our new W3C activity on payment is already looking at Cloud integration, eg. differences between eWallets that reside in your phone or in the cloud, or more generally any payment card details managed either on a secure element or on the cloud. Of course, the things people buy online, the actual data or resource may be outsourced to a cloud service provider and so communication and protocols must be developed in this context.
Meanwhile, HTML5.1 provides specific help for autocomplete of credit card details, making it easier to pay via credit cards once these details have been entered once.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Developers doc | Test suite |
---|---|---|---|---|---|---|---|---|
Integrated payment | Credit card details autocomplete in HTML 5.1 | HTML | Early draft | undefined | Very limited | None |
8. Performance & Tuning
The work started by the Web Performance Working Group on Navigation Timing, Resource Timing, Performance Timeline and User Timing, gives tools to Web developers for optimizing their Web applications. The work on the Frame Timing API aims at providing detailed information on the frame-per-second obtained when an application is running on the user device.
The Resource Hints and Preload specifications let developers optimize the download of resources by enabling to delay either the download or the execution of the downloaded resource.
The proposed work on Efficient Script Yielding offers the opportunity to Web developers to use more efficiently asynchronous programming, but has so far gained very limited traction.
The requestIdleCallback
API similarly proposes a way for scheduling an operation at the next opportunity when the app is not processing another operation.
Beyond optimization of resources, the perceived reactivity of an application is also a critical aspect of the mobile user experience. The thread-like mechanism made possible via Web Workers allows keeping the user interface responsive by offloading the most resource-intensive operations into a background process.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Developers doc | Test suite |
---|---|---|---|---|---|---|---|---|
Timing hooks | Navigation Timing | Web Performance | Finished | Well deployed | Good coverage | |||
Resource Timing | Web Performance | Stable | Last updated August 2015 | Growing | Well started | |||
Performance Timeline | Web Performance | Finished | Limited | Started | ||||
User Timing | Web Performance | Finished | Growing | Well started | ||||
Frame Timing | Web Performance | Early draft | Last updated June 2015 | None | None | |||
Network prioritization | Resource Hints | Web Performance | Early draft | Last updated August 2015 | Growing deployment | None | ||
Preload | Web Performance | Early draft | Last updated September 2015 | None? | None | |||
Priority handling | Efficient Script Yielding | Web Performance | Early draft | Last updated April 2014 | Very limited | None | ||
Threading | Web Workers | Web Applications | Stable | Last updated May 2014 | Well deployed | Good coverage |
9. Security & Privacy
Clearly a big intersection with the Cloud, and all Cloud programmers should follow this work if they want to write secure cloud web apps, concerned with identity, encryption, etc.
The first line of defense for users, and the unit of isolation for Web apps is the same-origin policy that roughly limits what a Web application can access to content and data hosted on the same origin, i.e. the combination of URL scheme, domain name and port.
For legacy reasons, this policy is not as stringent on some parts of the Web platform, exposing users to greater attack surface via cross-site scripting or cross-site request forgery. To enable Web application authors to reduce the attack surface beyond what legacy requires, the Content Security Policy (level 2) offers hooks that severely limits damages that an attacker could hope to achieve.
To further strengthen the integrity of their applications, Web developers can make use of the proposed Subresource integrity mechanism, that makes it possible to block man-in-the-middle attacks or compromised third-parties providers.
Entry Point Regulation provides another layer of strengthening and offers to filter the type of HTTP requests that can be made from external sites, reducing risks of cross-site script and cross-site request forgery.
In applications that aggregate content from multiple (possibly untrusted) sources, the HTML5 iframe
sandbox makes it possible to restrict what kind of interactions third-party embedded content can make use of.
As described earlier, the Web Cryptography API provides the necessary tools to encrypt data for storage and transmission from within Web applications, with access pre-provisioned keys via the WebCrypto Key Discovery API.
There are discussions to bring the capabilities of hardware-security modules to the Web, to enable access to high-security operations for encryption, payment, identity proof, etc., embodied in a draft charter for a Hardware Security Working Group.
For users that wish to indicate their preferences not to be tracked across Web applications and sites, the Tracking Preference Expression (also known as Do No Track) enables browsers to communicate explicitly their wish to content providers, and to determine whether a given content provider asserts fulfilling that wish.
To facilitate the authentication of users to on-line services, the Web Application Security Working Group is proposing a credential management API that lets developers interact more seamless with user-agent-managed credentials.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Developers doc | Test suite |
---|---|---|---|---|---|---|---|---|
Strengthened security | Content Security Policy Level 2 | Web Application Security | Stable | Last updated August 2015 | Well-deployed | Well started | ||
Subresource Integrity | Web Application Security | Just started | Last updated August 2015 | Limited | None | |||
Entry Point Regulation | Web Application Security | Just started | Last updated June 2015 | None | None | |||
Sandboxed iframe in HTML5 | HTML | Stable | Finished | Widely deployed | None | |||
Encryption | Web Cryptography API | Web Cryptography | Stable | Last updated November 2014 | Well deployed | Early start | ||
WebCrypto Key Discovery | Web Cryptography | Early work | Last updated May 2014 | None | None | |||
Tracking protection | Tracking Preference Expression (DNT) | Tracking Protection | Stabilizing | undefined | Good deployment | None | ||
Identity management | Credential Management Level 1 | Web Application Security | Early draft | Last updated September 2015 | None | N/A |
Acknowledgments
Thanks to Art Barstow, Anssi Kostiainen, Jo Rabin, J. Manrique López, Mounir Lamouri, Marcos Caceres, François Daoust and Ronan Cremin for their contributions to this document.
This document is produced through the HTML5Apps project, funded by the European Union through the Seventh Framework Programme (FP7/2013-2015) under grant agreement n°611327 - HTML5 Apps.