Please leave your sense of logic at the door, thanks!

HTML and shared memory

You’d think that the HTML Standard would be pretty far removed from shared memory considerations, but as it happens HTML defines a parser for HTML which is intertwined with script execution, defines a way to instantiate new global objects through the iframe element, defines a way to instantiate new threads (and even processes, depending on the implementation) with workers, and all the various infrastructure pieces that go along with that. Finally, it also defines a message-based communication channel to communicate between those threads and processes.

That still doesn’t give us shared memory. For that, JavaScript needed to evolve and gain a new SharedArrayBuffer class: a sibling to ArrayBuffer, with the ability to be accessed from several threads at once. And on top of that we needed to do some work to make it play nicely with all the various globals the web platform provides and make sure it worked with the message-passing system (which you probably know as postMessage()), all while trying to avoid violating constraints that would make programming with SharedArrayBuffer objects a nightmare.

We ended up making several changes (and to make sure they all end up being interoperable we wrote accompanying tests):

As always, nothing is perfect and there are some gotchas without a good solution:

Although the above covers the integration of shared memory into the foundations of the web platform, there is still ongoing work on allowing specific APIs to accept and operate on shared memory. This requires changes to IDL to introduce a mechanism for safelisting APIs that can operate on SharedArrayBuffer objects, as well as updating specifications to use that new safelisting mechanism, and of course writing tests for these spec changes. This work is still ongoing, but at least now it can build on top of a solid foundation.

Posted in Browser API | No Comments »

Working mode

In a previous post we’ve already explained how interoperability is important to the WHATWG. Without it, we’re writing fiction, and in the world of standards that is no good.

From a similar perspective, we’ve now more clearly documented how the WHATWG creates standards. The Working Mode document describes what is expected of editors and contributors, what criteria any changes to standards must fulfill, and gives guidelines for conflicts and tests.

What has changed the most since 2004 is requiring tests and implementer support for any changes made. These should help ensure that decisions need not be revisited again. Documenting our processes is also new and is born out of necessity due to the wider range of standards the WHATWG maintains.

We appreciate any feedback on the Working Mode document as it can undoubtedly be refined further.

Posted in WHATWG | No Comments »

Improving interoperability

The goal of the WHATWG’s Living Standards is to achieve interoperable implementations. With an ever-evolving web platform, we want changes to our standards to reach all implementations quickly and reliably, but from time to time there have been mishaps:

Three months ago, we changed the process for the HTML Standard to encourage writing tests and filing browser bugs for normative changes. (Normative means that implementations are affected.) This was the first step on a path towards improving interoperability and shortening the feedback cycle, and it has thus far exceeded our own expectations:

As an example, see Remove "compatibility caseless" matching where 3 of the 4 browser bugs are now fixed, or Add <script nomodule> to prevent script evaluation where all vendors have indicated support, and WebKit has a patch to implement the proposed feature and are contributing their tests to web-platform-tests—even before the standard’s pull request has landed.

Note in particular that this has not amounted to WHATWG maintainers writing all new tests. Rather, we are a community of maintainers, implementers and other contributors, where tests can be written to investigate current behavior before even discussing a change to the standard, or where the most eager implementer writes tests alongside the implementation.

We have been using this process successfully for other WHATWG standards too, such as Fetch, URL, and Streams. And today, we are elevating this process to all WHATWG standards, as now documented in the WHATWG contributor guidelines.

Posted in WHATWG | Comments Off on Improving interoperability


Welcome to the newest standard maintained by the WHATWG: the Infra Standard! Standards such as DOM, Fetch, HTML, and URL have a lot of common low-level infrastructure and primitives. As we go about defining things in more detail we realized it would be useful to gather all the low-level functionality and put it one place. Infra seemed like a good name as it’s short for infrastructure but also means below in Latin, which is exactly where it sits relative to the other work we do.

In the long term this should help align standards in their vocabulary, make standards more precise, and also shorten them as their fundamentals are now centrally defined. Hopefully this will also make it easier to define new standards as common operations such as “ASCII lowercase” and data structures such as maps and sets no longer need to be defined. They can simply be referenced from the Infra Standard.

We would love your help improving the Infra Standard on GitHub. What language can further be deduplicated? What is common boilerplate in standards that needs to be made consistent and shared? What data types are missing? Please don’t hesitate to file an issue or write a pull request!

Posted in What's Next, WHATWG | Comments Off on Infra

DRM and Web security

For a few years now, the W3C has been working on a specification that extends the HTML standard to add a feature that literally, and intentionally, does nothing but limit the potential of the Web. They call this specification "Encrypted Media Extensions" (EME). It's essentially a plug-in mechanism for proprietary DRM modules.

Much has been written on how DRM is bad for users because it prevents fair use, on how it is technically impossible to ever actually implement, on how it's actually a tool for controlling distributors, a purpose for which it is working well (as opposed to being to prevent copyright violations, a purpose for which it isn't working at all), and on how it is literally an anti-accessibility technology (it is designed to make content less accessible, to prevent users from using the content as they see fit, even preventing them from using the content in ways that are otherwise legally permissible, e.g. in the US, for parody or criticism). Much has also been written about the W3C's hypocrisy in supporting DRM, and on how it is a betrayal to all Web users. It is clear that the W3C allowing DRM technologies to be developed at the W3C is just a naked ploy for the W3C to get more (paying) member companies to join. These issues all remain. Let's ignore them for the rest of post, though.

One of the other problems with DRM is that, since it can't work technically, DRM supporters have managed to get the laws in many jurisdictions changed to make it illegal to even attempt to break DRM. For example, in the US, there's the DMCA clauses 17 U.S.C. § 1201 and 1203: "No person shall circumvent a technological measure that effectively controls access to a work protected under this title", and "Any person injured by a violation of section 1201 or 1202 may bring a civil action in an appropriate United States district court for such violation".

This has led to a chilling effect in the security research community, with scientists avoiding studying anything that might relate to a DRM scheme, lest they be sued. The more technology embeds DRM, therefore, the less secure our technology stack will be, with each DRM-impacted layer getting fewer and fewer eyeballs looking for problems.

We can ill afford a chilling effect on Web browser security research. Browsers are continually attacked. Everyone who uses the Web uses a browser, and everyone would therefore be vulnerable if security research on browsers were to stop.

Since EME introduces DRM to browsers, it introduces this risk.

A proposal was made to avoid this problem. It would simply require each company working on the EME specification to sign an agreement that they would not sue security researchers studying EME. The W3C already requires that members sign a similar agreement relating to patents, so this is a simple extension. Such an agreement wouldn't prevent members from suing for copyright infringement, it wouldn't reduce the influence of content producers over content distributors; all it does is attempt to address this even more critical issue that would lead to a reduction in security research on browsers.

The W3C is refusing to require this. We call on the W3C to change their mind on this. The security of the Web technology stack is critical to the health of the Web as a whole.

- Ian Hickson, Simon Pieters, Anne van Kesteren

Posted in Multimedia, W3C | 7 Comments »