The WHATWG Blog

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

Author Archive

Defining the WindowProxy, Window, and Location objects

Thursday, May 12th, 2016

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 »

Standards development happening on GitHub

Monday, February 1st, 2016

(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 issue”. (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.

Posted in WHATWG | Comments Off on Standards development happening on GitHub

HTML Standard now more community-driven

Monday, January 25th, 2016

It’s been several months now since maintenance of the HTML Standard moved from a mostly-private Subversion repository to the whatwg/html GitHub repository. This move has been even more successful than we hoped:

Aside from defining the HTML language, the HTML Standard defines the processing model around script execution, the fundamentals of the web’s security model, the web worker API for parallel script execution, and many more aspects that are core to the web platform. If you are interested in helping out, please reach out on IRC or GitHub.

Posted in WHATWG | Comments Off on HTML Standard now more community-driven

Rolling out TLS and HSTS

Monday, September 15th, 2014

All whatwg.org and html5.org domains, including subdomains, are now available over TLS. We are also enabling HSTS though this is not done everywhere just yet. If you find Mixed Content issues be sure to let us know or provide a pull request on GitHub.

Update: TLS and HSTS are now deployed everywhere on both domains. We also submitted the domains to the HSTS preload list.

Posted in WHATWG | 1 Comment »

Relationship update on HTML Living Standard and W3C HTML5

Friday, July 20th, 2012

In an email to the WHATWG mailing list Ian Hickson explained how the relationship between the WHATWG and W3C effort around HTML has evolved. It is recommended reading if you want to know the details.

In summary, we will remain focused on improving HTML and related technologies to address the needs of users, developers, and user agents. The W3C HTML WG has decided to focus on producing a snapshot: HTML5. We anticipate the net effect to be accelerated development of the HTML Living Standard.

Posted in W3C, WHATWG | 2 Comments »