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.
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
controlling distributors, a purpose for which it is working well
(as opposed to being to prevent copyright violations, a purpose for
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
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
This has led to a chilling effect in the security research
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.
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
Back in 2012, the WHATWG set out to document the differences between the ECMAScript 5.1 specification and the compatibility and interoperability requirements for ECMAScript implementations in web browsers.
- figuring out implementation differences for various non-standard features;
- filing browser bugs to get implementations to converge;
- and finally writing specification text for the common or most sensible behavior, hoping it would one day be upstreamed to ECMAScript.
That day has come.
The infamous “string HTML methods”:
Similarly, ECMAScript now has spec text for
ECMAScript Annex B, which specifies things like
-->). As of ECMAScript 2015, Annex B fully defines this syntax.
__lookupSetter__ methods on
Object.prototype are defined in ECMAScript Annex B, as is
Until recently, the HTML Standard lacked a precise definition of the
Location objects. As you might imagine, these are fairly important objects, so having them be underdefined was not great for the web. (Note that the global object used for documents is the
WindowProxy object, which serves as a proxy and security boundary for the
Each navigable frame (top-level tab,
<iframe> element, et cetera) is called a browsing context in the HTML Standard. A browsing context has an associated
Window object. As you navigate a browsing context, the associated
Window object changes. But the whole time, the
WindowProxy object stays the same. Ergo, one
WindowProxy object is a proxy for many
To make matters more interesting, scripts in these different browsing contexts can access each other, through
window.open(), et cetera. The same-origin policy generally forbids code from one origin from accessing code from a different origin, which prevents evil.com from prying into bank.com. The two legacy exceptions to this rule are the
Location objects, which have some properties that can be accessed across origins.
document.domain makes this even trickier, as it effectively allows you to observe a
Location object as cross-origin initially, and same-origin later, or vice versa. Since the object remains the same during that time, the same-origin versus cross-origin logic needs to be part of the same object and cannot be spread across different classes.
Defining this all in detail has been a multi-year effort spearheaded by Bobby Holley, Boris Zbarsky, Ian Hickson, Adam Barth, Domenic Denicola, and Anne van Kesteren, and completed in the “define security around
Location objects properly” pull request. The basic setup we ended up with is that
Location objects have specific cross-origin branches in their internal method implementation. These take care to only expose specific properties, and even for those properties, generating specific accessor functions per origin. This ensures that cross-origin access is not inadvertently allowed through something like
Object.getOwnPropertyDescriptor(otherWindowProxy, "window").get. After filtering, a
WindowProxy object will forward to its
Window object as appropriate, whereas a
Location object simply gives access to its own properties.
Having these objects defined in detail will make it easier for implementations to refactor, and for new novel implementations like Servo to achieve web-compatibility. It will reduce debugging time for web developers after implementations have converged on the edge cases. And it drastically simplifies extending these objects, as well as placing new restrictions upon them, within this well-defined subsystem. Well-understood, stable foundations are the key to future extensions.
(Many thanks to Bobby Holley for his contributions to this post.)
One thing we’ve been meaning to do more of is tell our blog readers more about new features we’ve been working on across WHATWG standards. We have quite a backlog of exciting things that have happened, and I’ve been nominated to start off by telling you the story of
charset attributes applied. The end result can be seen in a number of places in the HTML Standard, most notably in the definition of the
script element and the scripting processing model sections. At the request of the Edge team, we also added support for worker modules, which you can see in the section on creating workers. (This soon made it over to the service workers spec as well!) To wrap things up, we included some examples: a couple for
<script type="module">, and one for module workers.
Of course, specifying a feature is not the end; it also needs to be implemented! Right now there is active implementation work happening in all four major rendering engines, which (for the open source engines) you can follow in these bugs:
And there's more work to do on the spec side, too! There's ongoing discussion of how to add more advanced dynamic module-loading APIs, from something simple like a promise-returning
self.importModule, all the way up to the experimental ideas being prototyped in the whatwg/loader repository.
(This post is a rough copy of an email I sent to the mailing list.)
I wanted to remind the community that currently all WHATWG standards are being developed on GitHub. This enables everyone to directly change standards through pull requests and start topic-based discussion through issues.
GitHub is especially useful now that the WHATWG covers many more topics than “just” HTML, and using it has already enabled many folks to contribute who likely would not have otherwise. To facilitate participation by everyone, some of us have started identifying relative-easy-to-do issues across our GitHub repositories with the label “good first bug”. (See also good first bugs on Bugzilla. New issues go to GitHub, but some old ones are still on Bugzilla.) And we will also continue to help out with any questions on #whatwg IRC.
You should be able to find the relevant GitHub repository easily from the top of each standard the WHATWG publishes. Once you have a GitHub account, you can follow the development of a single standard using the “Watch” feature.
There are no plans to decommission the mailing list — but as you might have noticed, new technical discussion there has become increasingly rare. The mailing list is still a good place to discuss new standards, overarching design decisions, and more generally as a place to announce (new) things.
When there’s a concrete proposal or issue at hand, GitHub is often a better forum. IRC also continues to be used for a lot of day-to-day communications, support, and quick questions.