Hello, Warm welcome to the W3C Web & Machine Learning workshop.

I am Dominique Hazael-Massieux, I am part of the W3C technical staff and have been working with the Workshop Program Committee in organizing this virtual event.

You can find me on twitter and github as @dontcallmeDOM (but do call me Dom).

This talk aims to give a very high-level overview of the specificities of what we call the Web platform for those of you who may not be as familiar with how browsers work.

Since a lot of the existing Machine Learning development happens in non-Web environments, the Program Committee thought it would be useful that we build a shared understanding of these specificities and how it impacts the deployment of new technologies in Web browsers.

So what is it that we call the Web platform?

The simplest way to approach that question is through a technology stack lens: most devices with an internet connection provide their users with at least one browser that can fetch content over HTTP (and a few other network protocols) , render HTML content styled with Cascading Style Sheets (CSS) and interpret JavaScript code that can interact with that content through a set of APIs called the Document Object Model (DOM).

Browsers also provide a large and growing number of JavaScript APIs that enable interacting with various hardware and OS capabilities.

For the past couple of years, browsers have also provided a native-performance bytecode called WebAssembly that among other things let compile existing non-JavaScript codebase into browser-runnable applications.

So that's for the technology stack that constitutes the Web platform.

But there are four key aspects I want to highlight today that make browsers a unique execution environment.

A first aspect is that browsers are built with networking as a core design point this means that it is relatively easy to bring in resources from different network sources, but it also comes with constraints in that usage: in particular, a lot of the trust and security boundaries are anchored in network identifers, mostly via DNS and certificates.

A second aspect is that browsers are designed as user agents they are positioned to be the agent of end users.

They are expected to keep the user in control and help ensure their needs are fulfilled W3C pays particular attention to considerations of security, privacy, accessibility and internationalization when it comes to user needs.

To respect that position agent of the user, it is often necessary to impose limits to what developers can do in the code that browsers will run for them.

A third important aspect is that all the technologies that constitute the platform are defined through open standardization processes, including naturally in W3C, and these standards are implemented in multiple competing products and are made available freely to developers and end-users alike.

Finally, browsers are available on most end-user devices, no matter their operating system and their hardware, including computing architectures and capabilities.

In particular, technologies made available through browsers need to be as device- and platform-independent as possible, and provide accommodations for situations where they cannot be.

With that characterization in mind, what does it imply when it comes to bringing a new technology such as machine learning to the Web platform ?

A first characteristic is that in most cases, any technology that requires imperative programming will need to be exposed via JavaScript, and thus inherits the specificities of the JavaScript language: JavaScript operates under a single-threaded event loop.

This means developers mostly aren't exposed to concurreny issues, which is a good thing, but it also creates constraints in how programs can be architected.

In particular, in browsers, the main JavaScript event loop can block the rendering or interactivity of the page that loaded it so running blocking synchronous operations or other heavy processing in that context can very rapidly deteriorate the user experience.

Various mechanisms are available to enable developers to run different pieces of their code concurrently, most notably asynchonous APIs, workers and worklets, but they come with their own set of execution constraints.

The high level consideration to keep in mind is that technologies that require heavy CPU operations need to carefully integrate with these architectural constraints.

A second characteristic is that from within a Web application, most interactions with the network will by default be limited to the domain of where the application is hosted (more specifically, its origin), and access to other network destinations will only be granted if that other destination opts-in to it.

This helps limit exposures to private resources in local networks (for instance a home network or an enterprise network).

In the context of machine learning, this means that for instance, loading a trained model from a third party service would need to conform to this constraint and may also need additional sandboxing to respect the end user security and privacy.

A third similar characteristic, and one of rapidly growing importance, is that browsers limit what identifiable information can be tracked across Web sites: while a lot of parties attempt to identify users as they browse through different Web sites, browsers attempt to give users control on what gets shared and when and how to limit what gets shared without user awareness.

In particular, a lot of the recent evolutions in how “cookies” are managed, how data gets stored and how much uniquely-identifiable data is exposed in APIs (that data can be used to “fingerprint” a particular user or a particular device), a lot of these evolutions can have deep impact in how new Web technologies get designed.

As a final characteristic to call attention to in the context of bringing Machine Learning to the Web, Web technologies need to be designed to run across many different platform and architectures.

Machine learning tends to be very compute-intensive and thus would generally need a lot of optimization to run as efficiently as possible; while these optimizations are definitely relevant in the context of the Web platform, they need to be exposed to developers in a way that let browsers run these optimizations on all the devices they operate on.

In some cases, the lack of specific hardware makes running a given application likely not worth it various mechanisms of feature detection and context establishment have been deployed in other technologies (for instance, detecting the availability of virtual reality gear in WebXR) and they let developers determine if and how to adapt their application to the specific end user context, while preserving as much as possible the user privacy.

For people coming from other execution environments, these constraints can sometimes appear overwhelming, and in truth, they can in fact be pretty challenging to address in a number of cases a good chunk of the open standardization process that W3C hosts revolve around finding the right trade-offs among the competing needs they represent.

Naturally, these constraints don't exist in a vacuum they are the pilars that have enabled the Web platform to grow to be the most deployed software platform, available to more than 4 billion people around the globe, and with the largest community of developers available.

W3C has built processes, culture and institutional knowledge to ensure that the Web platform keeps pace with the evolving capabilities of computing devices while preserving the characteristics that make the Web the most universal platform available.

I hope the presentations and discussions at the workshop will pave the way for Machine Learning to bring its capabilities to the service of the many billions of users that rely on Web browsers in their daily life, and I hope this presentation helped better understand what it means to bring Machine Learning capabilities to the Web platform.

Thank you for your time.