Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Reforming the W3C TAG

And so it has come to pass that W3C Technical Architecture Group (TAG) elections are afoot. Nominations have ended and the candidates have been announced. There are four seats open and nine candidates running, so it's worth understanding why anyone should vote for the reformers (myself, Yehuda Katz, Anne van Kesteren, Peter Linss, and Marcos Caceres). For general background, see my previous post. Here I'll include more specifics, so if that sounds boring, here's a kitten!

After doing much reading of TAG meeting minutes, f2f notes, issues, delivered products, and findings I've come to a sobering conclusion: the TAG isn’t focused on eliminating the biggest sources of developer pain today. Now, you can argue that this might not be their job, but I won't agree. It's the TAGs job to help ensure the health of the platform, both for publishers and search engines, but also for authors. And the web as a platform is in some real trouble today.

There doesn't seem to be a sense of urgency in the TAG about the corrosive effects of poor design and integration on the overall usability and health of the system. The Web to the TAG, as I can understand it through the meeting minutes and notes, is a collection of documents that represent internally-referential collections of data which are are linked to other documents, not a series of applications that are attempting ever more impressive feats of richness on a platform that stymies them every time you hit one of the seams. In reality it is (aspirationally) both things but the very real tensions between them don't appear in the TAG's work, leading me to believe that it doesn't comprehend the latter aspect of web development today and what that means for the future health and viability of the platform.

I drone on and on and on about layering because explaining each bit of the platform in terms of the one below it relieves much of the tension created by disconnected declarative forms and APIs. This matters because in today's web when you go ever so slightly off the path paved by a spec's use-cases, the drop-off is impossibly steep, and the only way to keep from risking life-threatening abstraction level transitions is to flood the entire canyon with JavaScript and hope you can still swim in the resulting inland sea of complexity. This is what our biggest, "best" webapps do today, relying on ENORMOUS piles of JavaScript that largely serve to re-create what browsers already do in the hopes of marginally extending that capability. It's simply nuts, but the TAG doesn't seem to acknowledge the threat this poses to everything it holds dear: linking, declarative forms,'s all about to be lost beneath the waves, and because the TAG doesn't understand the growing importance of JS, it seemingly doesn't see the threat. Declarative forms disappear first beneath imperatively-delivered complexity; lingua-franca APIs next. Without ways of getting what your app needs while keeping one foot on the declarative path, app developers do what they must; declarative data and relationships become "nice to haves" not "the way you do it". Layering provides easy steps between the levels of abstraction, avoiding the need to re-create what the platform was already doing for you along with whatever custom thing you need -- and it's not the TAG's current agenda.

If elected, I will work to fix that. The TAG is the right group to formulate and articulate a theory of good layering in the web platform's architecture and it's the only group at the W3C whose mission is to help spec authors wrestle with large-scale design and integration problems like this. My background is in apps, and JS, and browsers, and I work at one of the few places deeply invested in ensuring that we maintain a healthy, declarative web for the future. I care tremendously about the viability of the largely-declarative web. Through my work with Dimitry Glazkov and many others on Web Components I've done as much as anyone in the last decade to help build a bridge between the JS and declarative worlds. Dimitry and I created and led the team here at Google that have put Shadow DOM, CSS Variables, Custom Elements, Mutation Observers (and Object.observe) into specs and on the platform agenda, all with the explicit goal of creating better layering; explaining the magic in today's platform and drawing connections between the bits that had none before. And I think we need to keep building more of those bridges, but it's hard when W3C culture views that agenda with suspicion. Why would any WG concern itself with integration with specs outside its charter? It's the TAGs job to inject that global perspective. I believe the TAG should pursue the following work as a way of filling its charter:

If that sounds like meaningful progress to you, I'd appreciate your organization's vote; along with your consideration to vote for my fellow reformers: Yehuda Katz, Anne van Kesteren, Peter Linss, and Marcos Cáceres. AC reps for each organization can vote here and have 4 votes to allocate in this election. Voting closes near the end of the month, and it's also holiday season, so if you work at a member organization and aren't the AC rep, please, find out who that person in your organization is and make sure they vote. The TAG can't fix the web or the W3C, but I believe that with the right people involved it can do a lot more to help the well-intentioned people who are hard at work in the WGs to build in smarter ways that pay all of us back in the long run.

Origin(al) Sins

Video is now up from a talk I gave in October at OWASP's AppSec USA conference -- something of a departure from my usual speil:

Origin(al) Sins - Alex Russell from OWASP AppSec USA

I made some pretty glaring errors in the talk: you can't combine sandboxing with seamlessness for cross-origin content. It's something I'm hoping we can improve on in the browsers/specs, but it's not the current state of play. I also failed to mention that CSP is Mozilla's brain-child and they deserve huge credit for pushing it down the field. Similarly, I failed to mention that IE 10's CSP support is actually quite shite, supporting only the sandbox directive. Lastly, my objections to the OCAP worldview may have been oblique so, before the flames arrive in the comments, let me try again:

I think that you'll always end up with some variant of "object capabilities", if only through wrapper objects that hide protocol details. The OCAP world calls these "membranes" for particularly high-fidelity versions of this. When you have a word for it, it's probably common. Vending objects that represent capabilities is natural at some level, but I strongly resist the urge to take the pun too far. Don't get me wrong, I'm a huge fan of capabilities as the model for building apps that have real security by default; and I hope their pervasive use combined with more restrictive, separated execution contexts creates the world we all want to be in. My only quibble is on the developer ergonomics front. OCAP encourages the (perhaps naive) programmer to build many things inside the same "vat" (heap, context, whatever), leading to brittleness whereas protocols and true sandboxing can create secure boundaries that, importantly, look like boundaries. Systems that provide big "this is a security boundary!" disclaimers on their APIs while making it hard to screw them up stand a better chance of weathering the storms of human imperfection. Can you do OCAP right? Sure, it's possible, but as I argue in the talk, betting on humans to do the right thing is eventually and inevitably a loser. So I favor large, knobby interfaces over which you can send messages and no more. Wrap 'em up with an RPC But design a protocol with side-effects that are straight-forward to reason about on both sides -- not an object which can be easily intertwined with many others in a dense graph -- and you've got my vote. I'm even in favor of building those protocols and then wrapping them with easier-to-use APIs (call it "CAP->O", if you will), but eliding the step of a large boundary over which you can only send data, and making it relatively hard to cross? Nah, I'll be over here with the easy-to-reason about solutions that don't make my small-ish brain melt, thanks.

Also, I wasn't sure to what extent Doug was joking about "incompetent" programmers in his talk, so our disagreements may not be what they seem. Caveat emptor.

Thanks to Jeremiah and the other organizers for taking a risk and inviting someone who's been out of the security space for so long to give a talk. I promise to them that should they be so foolish in the future, I'll be sure to duck out and get one of my betters on the Chrome Security Team to stand in instead ;-)

Older Posts

Newer Posts