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:
- “Tests and bugs speed up the turnaround time a lot. Without this it could go years before a browser vendor picked up or objected to a change (even if someone from that browser had given an a-OK for the change). Now some changes have patches in browsers before the change has landed in the spec.”
- “Writing tests also increases the quality of the spec, since problems become clear in the tests. It also seems reasonable to assume that the tests help getting interoperable implementations, which is the goal of the spec.”
- “I feel much more sure that when I make a spec change, I am doing all I can to get it implemented everywhere, in precisely the manner I intended.”
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
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 »
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.
A specification draft was first published under the name of “Web ECMAScript”, but later renamed to just “JavaScript”. As such, the JavaScript Standard was born.
Our work on the JavaScript Standard consisted of three tasks:
- 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.
Some remaining web compatibility issues are tracked in the repository for the ECMAScript spec, which javascript.spec.whatwg.org now redirects to. The rest of the contents of the JavaScript Standard have been upstreamed into ECMAScript, Annex B.
This is good news for everyone. Thanks to the JavaScript Standard, browser behavior has converged, increasing interoperability; non-standard features got well-defined and standardized; and the ECMAScript standard more closely matches reality.
Highlights:
The infamous “string HTML methods”: String.prototype.anchor(name), String.prototype.big(), String.prototype.blink(), String.prototype.bold(), String.prototype.fixed(), String.prototype.fontcolor(color), String.prototype.fontsize(size), String.prototype.italics(), String.prototype.link(href), String.prototype.small(), String.prototype.strike(), String.prototype.sub(), and String.prototype.sup(). Browsers implemented these slightly differently in various ways, which in one case lead to a security issue (and not just in theory!). It was an uphill battle, but eventually browsers and the ECMAScript spec matched the behavior that the JavaScript Standard had defined.
Similarly, ECMAScript now has spec text for String.prototype.substr(start, length).
ECMAScript used to require a fixed, heavily outdated, version of the Unicode Standard for determining the set of whitespace characters, and what’s a valid identifier name. The JavaScript Standard required the latest available Unicode version instead. ECMAScript first updated the Unicode version number and later removed the fixed version reference altogether.
ECMAScript Annex B, which specifies things like escape and unescape, used to be purely informative and only there “for compatibility with some older ECMAScript programs”. The JavaScript Standard made it normative and required for web browsers. Nowadays, the ECMAScript spec does the same.
The JavaScript Standard documented the existence of HTML-like comment syntax (<!-- and -->). As of ECMAScript 2015, Annex B fully defines this syntax.
The __defineGetter__, __defineSetter__, __lookupGetter__, and __lookupSetter__ methods on Object.prototype are defined in ECMAScript Annex B, as is __proto__.
So long, JavaScript Standard, and thanks for all the fish!
Posted in WHATWG | Comments Off on Sunsetting the JavaScript Standard
The HTML Standard defines how navigation works inside a browser tab, how JavaScript executes, what the overarching web security model is, and how all these intertwine and work together. Over the last decade, we’ve made immense progress in specifying previously-unspecified behavior, reverse-engineering and precisely documenting the de-facto requirements for a web-compatible browser. Nevertheless, there are still some corners of the web that are underspecified—sometimes because we haven’t yet discovered the incompatibility, and sometimes because specifying the behavior in a way that is acceptable to all implementers is really, really hard. What follows is an account of the latter.
Until recently, the HTML Standard lacked a precise definition of the WindowProxy, Window, and 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 Window object, though due the way browsers evolved it is never directly exposed. Instead, JavaScript code accesses the WindowProxy object, which serves as a proxy and security boundary for the Window object.)
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 WindowProxy and 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 Window objects.
To make matters more interesting, scripts in these different browsing contexts can access each other, through frame.contentWindow, self.opener, 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 WindowProxy and 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 WindowProxy or 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.
As JavaScript has many ways to inspect objects, WindowProxy and Location objects were forced to be exotic objects and defined in terms of JavaScript’s “meta-object protocol”. This means they have custom internal methods (such as [[Get]] or [[DefineOwnProperty]]) that define how they respond to the low-level operations that govern JavaScript execution.
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 Window, WindowProxy, and Location objects properly” pull request. The basic setup we ended up with is that WindowProxy and 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.)
Posted in WHATWG | 3 Comments »