Infrequently Noted

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

Two Governments, Both Alike In Dignity

Disclaimer: I'm engaged to Frances Berriman, the front-end lead at the UK's Government Digital Service. She did not approve this post. It is, however, the product of many of our discussions. You'll understand shortly why this is relevant.

It seems entirely rational to be skeptical about governments doing things well. My personal life as a migrant to the UK is mediated by heaving bureaucracies, lawyer-greased wheels, and stupefyingly arbitrary rules. Which is to say nothing of the plights of my friends and co-workers -- Google engineers, mostly -- whose migration stories to the US are horrifying in their idiocy. Both the US and UK seem beholden to big-stupid: instead of trying to attract and keep the best engineers, both countries seem hell-bent to keep them out. Heaven forbid they make things of value here (and pay taxes, contribute to society, etc.)! It takes no imagination whatsoever for me to conjure the banality and cruelty that are the predictable outcomes of inflexible, anachronistic, badly-formulated policy.

You see it perhaps most clearly when this banality is translated to purely transactional mediums. PDFs that you must fax -- only to have a human re-type the results on the other end. Crazy use of phones (of course, only during business hours). Physical mail -- the slowest and worst thing for a migrant like myself -- might be the most humane form of the existing bureaucracy in the US. Your expectations are set at "paper", and physical checks and "processing periods" measured in weeks feel somehow of a piece. It has always "worked" thus.

It's befuddling then to have been a near witness to nothing short of the wholesale re-building of government services here in the UK to be easiest to navigate by these here newfangled computrons. And also just flat-out easy. The mantra is "digital by default", and they seem to be actually pulling it off. Let me count the ways:

  1. High-level policy support for the effort
  2. Working in the open. Does your government do its development on github?
  3. Designing services for the humans that use them, not the ones who run them
  4. Making many processes that were either only-physical or damn infuriating near-trivial to do online
  5. Making key information understandable. Give the UK "limited corporation" page a view. Now compare to the California version. Day, meet night.
  6. Saving both government and citizens massive amounts of money in the process.

They even have a progress bar for how many of the ministries have been transformed in this way.

Over the same timeframe I've known a few of the good folks who have put themselves in the position of trying to effect changes like this at Code for America. It's anathema in the valley to say anything less than effusive about CFA -- anything but how they're doing such good, important work. How CFA has the potential to truly transform the way citizens and government interact. Etc, etc. And it's all true. But while CFA has helped many in the US understand the idea that things could be better, the UK's Government Digital Service has gone out and done it.

So what separates them?

First, the sizes of the challenges need to be compared. The US has 5x the population, an economy that's 6x larger, and a federalist structure that makes fixing many problems more daunting than most UK citizens can possibly imagine. Next, it should be noted that London is a better place to try to hire the Right People (TM). Yes, it's much more expensive to live here, but software salaries are also much lower (both in relative and absolute terms). There wasn't as much tech going on here as in the valley to start with, and the gold-rush to produce shiny but less competent versions of existing websites for world+dog (aka: "the app ruse") hasn't created the engineering hiring frenzy here that it has stateside.

There's also a general distrust in the American psyche about the core proposition of the government doing good things. Public-spiritedness seems to so many of my generation a sort of dusty nostalgia that went the way of hemp and tie-dye. Close encounters with modern American government do little to repair the image. But all of those seem surmountable. The US has more of everything, including the Right People (TM). Indeed, the UK is managing an entire first-world's set of services on a smaller GDP.

Why then do US public services, to be blunt, largely still suck? The largest differences I've observed are about model. Instead of having a mandate to change things from the inside, the organizational clout to do it, and enough budget to make a big dent out of the gates (e.g. CFA is in the painful position of needing to be invited while at the same time trying to convince talented and civic-minded engineers and designers to work for well below industry pay for a limited time on projects that don't exist yet.

Put yourselves in the shoes of a CFA Fellow: you and your compatriots are meant to help change something important in the lives of citizens of a municipality that has "invited" you but which is under no real pressure to change, has likely moved no laws or contracts out of the way to prepare for your arrival, and they know you're short-timers. Short-timers that someone else is taking all the risk on and paying for?

What lasting change will you try to effect when you know that you've got a year (tops) and that whatever you deliver must be politically palatable to entrenched interests? And what about next year's Fellows? What will they be handed to build on? What lasting bit of high-leverage infrastructure and service-design will they be contributing to?

The contrast between that and the uncomfortably-named "civil servants" of the GDS could not be more stark. I don't get the sense that any of them think their job is a lifetime assignment -- most assume they'll be back at agencies any day now, and some of the early crop have already moved on in the way nerds tend to do -- but at the pub they talk in terms of building for a generation, doing work that will last, and changing the entire ethos of the way services are produced and consumed. Doing more human work. And then they wake up the next morning and have the authority and responsibility to go do it.

I don't want to be down on CFA. Indeed, it feels very much like the outside-government precursor to the GDS: mySociety. mySociety was put together by many of the same public-spirited folks who initially built the Alpha of what would a year later become and the GDS. Like CFA, mySociety spent years pleading from the outside, making wins where it could -- and in the process refining ideas of what needed to change and how. But it was only once the model changed and they grabbed real leverage that they were able to make lasting change for the better.

I fear CFA and the good, smart, hard-working people who are pouring their lives into it aren't missing anything but leverage -- and won't make the sort of lasting change they want without it. CFA as an organization doesn't seem to understand that's the missing ingredient.

America desperately needs for its public services to make the same sort of quantum leap that the UK's are making now. It is such an important project, in fact, that it cannot be left to soft-golved, rose-tinted idealism. People's lives are being made worse by mis-placed public spending, badly executed projects, and government services that seem to treat service as an afterthought.

CFA could be changing this, and we owe it to ourselves and our friends there to ask clearly why that change hasn't been forthcoming yet. The CFA Fellows model has no large wins under its belt, no leverage, and no outward signs of introspection regarding its ability to deliver vs. the GDS model. Lets hope something larger is afoot beneath that placid surface.

Update: I failed to mention in the first version of this post that the one of the largest philosophical differences between the two countries is the respective comfort levels with technocratic competence.

There exists a strain of fatalism about government in the US that suggests that because government doesn't often do things well, it shouldn't try. It's a distillation of the stunted worldviews of the libertarian and liberal-tarian elite and it pervades the valley. Of course governments that nobody expects anything of will deliver crappy service; how could it be otherwise?

What one witnesses here in the UK is the belief that regardless of what some theory says, it's a problem when government does its job badly. To a lesser degree than I sense in years past, but still markedly moreso than in the US, the debate here isn't about can the government get good at something, but why isn't it better at the things the people have given it responsibility for?

As a result, the question quickly turns how one can expect a government to manage procurement of technical, intricate products for which it's the only buyer (or supplier) without the competence to evaluate those products -- let alone manage operations of them.

Outsourcing's proponents had their go here and enormous, open-ended, multi-year contracts yielded boondoggle after boondoggle. By putting contractors in a position of power over complexity, and starving the in-house experts of staffing and resources to match, the government forfeited it's ability to change its own services to meet the needs of citizens.

What changed with was that the government decided that it had to get good at the nuts and bolts of delivering the services, outsourcing bits and pieces of small work, but owning the whole and managing it in-house. Having the Right People (TM) working on your team matters. If they're at a contractor, they have a different responsibility and fiduciary duty. When the ownership of the product is mostly in-house, ambiguities borne of incomplete contract theory are settled in favor of the citizen (or worst case, government) interest, not the profit motive.

The folks say "government should only do what only government can do", but my observation has been that that's not the end of the discussion: doing it well and doing it badly are still differentiable quantities. And doing better by citizens is good. Clearing space to do good is the essential challenge.

Cassowary on NPM

I continue to work on-and-off on the JS Cassowary port and now, thanks to some help from Isaac, new packages are up on NPM. The API is still marginally unstable and I expect we'll be undergoing re-licensing sometime in the near future, but it's very near a 0.1 release.

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 ;-)

Layers of Confusion

I missed a Plus post by Ian Hickson back from August but I saw it today through the magic of the twitters. It contains quite a lot to quibble about, but I want to home in on something he wrote in the comments in response to Will Sargent, RE: one of my posts on layering in the platform:

...I don't really share his vision. I think JS is an important part of the Web, but I don't see it as any more core to the Web than CSS, HTML, the DOM APIs, HTTP, etc. Most of the proposals I've seen to take JS and build a platform on it tend to fall down on #3, #4, and #5. In particular, I think fundamentally #3 and #4 basically force the platform to have a declarative part (the declarative XAML part of .NET is how it managed to address #4, for instance, and the declarative design of XHTML2 and RDF are how they manage to address #3). That doesn't have to mean that the code part is a secondary part, though. I think the Web has reached a point where you can think of the DOM as the core, with JS and the HTML syntax layered atop that (much like how in .NET there's objects that can be represented in XAML or generated from C#), which puts the JS part on par with the HTML part in terms of importance to the platform.

This is either me not articulating my "vision" clearly, Hixie mis-understanding my point(s), or some combination thereof. So I'll try again in 4 paragraphs:

I make no claims about the relative importance of HTML, CSS, JS, DOM or any of the rest. It honestly feels silly to talk about the platform that way. I argue something very, very different: HTML, DOM, and (to a lesser extent) CSS should all conceptually bottom out at JS. I'm not saying "go write a browser in JS"...that's also non-sequitur. JS must, of course, appeal in turn to C/C++ so a "browser written in JS" would need privileged APIs provided by C/C++ or something lower level.

What I'm saying is something very direct: there's no other ubiquitous programming language for the web. JS is the only game in town. As a result, when we describe imperative behavior in prose (as the HTML5 spec does) that behavior could, in theory, be implemented in JS (or some sub/super-set). Since HTML, DOM, and CSS aren't Turing-complete, they naturally belong at a "higher level" in the web platform stack.

Now, all of this sounds dangerously academic and perhaps nuts...but consider that we have to expose APIs for nearly all of this stuff. Whenever we add something to HTML, CSS, etc., it always comes with some sort of API. Now, that could be a good API, or it could be an obtuse turn around the parser after some terrible string concatenation.

I'm claiming that you get better APIs when you design your imperative explanation of the declarative stuff -- which you MUST do for specs to be sane -- in JS. This means designing new APIs to help you accomplish the task at hand as you go. Doing it that way ends you up with the types, APIs, and security boundaries you're going to need in the end anyway. Doing it the other way, patching crap onto the side later without explaining how the declarative stuff "works", just leads to the pain and constant need for case-by-case revision that we see in today's web APIs.

That's the whole argument in 4 'grafs. It's subtle, but I hope not terribly controversial. Importantly, nothing about it demands giving up on any of Hixie's 5 arguments. He can keep 'em all and still get a well-layered platform. We've got enough examples of doing it wrong under our belt to see how painful the badly-layered web is today. We can end this insanity -- not by claiming that any part of the platform is "more important" -- by explaining the platform in layers, higher levels in terms of the lower levels.

Older Posts

Newer Posts