Running for the W3C TAG
I’m running for the W3C TAG this year. I was thrilled to see that we got 9 candidates with a wide set of complementary skills and focuses. Tess and Sangwhan have done a great job on the TAG and provide unique perspectives, so it would be a shame if they weren’t re-elected. Lea will provide an important connection to web developers, so it would also be a shame if she weren’t elected. That leaves one more seat for which the right choice is less clear. More than one of the remaining candidates would do a great job in that seat, and I wish there were more seats to put us in, but there aren’t, so you should vote for me.
You should vote for me because I care about many of the same things you care about, and I have deep experience making them compatible with the Web’s strengths and other people’s constraints, and then negotiating them into browsers.
If you work for a member of the W3C, please encourage your AC rep to vote by January 5.
Powerful capabilities §
I designed the Web Bluetooth API and the security UI that gave Chrome, Edge, Samsung Internet, and Opera the confidence to ship it. That security UI enabled a series of follow-on device APIs like WebUSB, Web Serial, WebHID, and Web NFC. These and many of the other Fugu APIs demonstrate how we sometimes have to trade off between capability, safety, and other concerns, but other times we can design features that do better on several axes than what was previously possible.
Taking Bluetooth as an example, it’s clearly less safe to give someone else’s code access to any of your Bluetooth devices, than to turn off that radio. We have a capability-vs-safety tradeoff here, and we can pick various points along that tradeoff:
- Disallow all Bluetooth access.
- Allow you to give a device’s manufacturer permission to access their devices, but nobody else.
- Allow you to give anyone permission to access devices.
But we could also have picked a design that isn’t at the Pareto frontier of the tradeoff: if you want to grant a program access to one device, you’d have to grant access to all of your devices at once. This is what all operating systems except the Web do for Bluetooth. So when designing the Web Bluetooth UI, I had an opportunity to move closer to the Pareto frontier when looking at the computer as a whole, even though we also had to shift along that frontier—trade off capability against safety—when looking at the Web by itself.
If you think we need to look for creative ways to add capabilities, security, and privacy when we can do it without sacrificing the others, while also deliberately choosing the tradeoffs when we do need to sacrifice something, vote for me.
An even playing field §
We all benefit when people and businesses with innovative ideas get a chance to show that those ideas are better than the status quo, and we lose those ideas when the systemic effects of the existing architecture give large players an advantage. As Mark Nottingham recently pointed out, the Web’s architecture is “extremely well-adapted to enabling creation of platforms (on top of it) that accrue network effects, where decentralised solutions could have emerged.” The TAG is the right group within the W3C to make recommendations about long-term architectural changes that could resist this pressure.
The TAG is going to need help to make the right tradeoffs here, and to find the right points of leverage to get our changes adopted widely. The tradeoffs can be tricky: sometimes centralization in one area is helping to offset the power of centralized actors in another area. If we introduce a Web feature that decentralizes that first area without also decentralizing the second area, we could cause even more-concentrated power over the whole system. We need to come up with guidelines for making that tradeoff.
The W3C also can’t just adopt a Recommendation for a decentralizing API and expect that developers and users will automatically adopt it. We need to design incentives and evolutionary pressures that are strong enough to overcome the network effects and status quo bias that led to the current centralization. Browsers are one of the strongest levers the W3C has to get its standards adopted, and as a voice within Chrome, I can help figure out how to get access to and use that power.
Productive discussions §
My style is to try to find a way to make everyone in a discussion happy. Often that means noticing where participants are talking past each other or using the same words for different concepts. This was one of my primary contributions as chair of the C++ Library Evolution Working Group. Other times, I’ve had to invent or help the participants invent a way for everyone to get most of what they want, like in the case of the Web Bluetooth chooser UI. In the worst case, I try to find a shared understanding of a small set of core disagreements, which we can continue to discuss even after we’ve picked one or the other side for the immediate decision.
In the W3C, I started the Target Privacy Threat Model to document the places we both agree and disagree about what privacy guarantees the web platform should provide. In addition to focusing privacy discussions on areas we disagree, this model helps feature teams design their features under the right set of constraints. Previously, feature teams would design a feature without knowing what privacy advocates would say about it, and then get into a fight at the end of their development about what parts of the feature they needed to cut. Like the TAG’s Design Principles, the Privacy Threat Model avoids surprises and lets the experts focus on difficult or truly-controversial cases.
Privacy and other human rights §
The W3C has long had a focus on making sure the Web protects certain human rights. The Accessibility, Internationalization, and Privacy horizontal reviews have made sure our Recommendations consider those needs. Both the Accessibility and Privacy groups have recently been doing a good job of considering the end-to-end implications of technical decisions. Accessibility folks have been finding designs such that web developers who are targeting and testing for non-disabled users will accidentally serve users with disabilities as well, and Privacy folks have been defining a threat model to set limits on what a privacy-hostile developer could do with the complete web platform. On the TAG, I will insist that we keep that wide focus over our systems’ higher-order effects, even when the developers between us and our users have different priorities.
More recently, the IETF has created a Human Rights Protocol Considerations research group, and the TAG has started writing a set of Ethical Web Principles. These extend the set of rights that we consider fundamental for users on the Web, and for people affected by the Web. We have much less experience turning these principles into concrete API designs. I’d like to work with the IETF group and draw on the breadth and depth of experience represented by people working in the W3C to turn our principles into tangible change.
What about Google? §
Several groups are concerned about the amount of power Google has in the web ecosystem, and likely worry that electing me will just increase that power. While I do have some biases from working in Google’s environment and having more access to pro-Google arguments, I’m also happy to publicly disagree with Google policy when it’s wrong. Being on the TAG will help me route critical opinions to the right people within Google and will help convince those decision-makers that their preferences have been given a fair hearing if the TAG decides against them.
Vote for me! And the other great candidates! §
Again, the voting deadline is January 5, and every AC member’s vote will be important. If I’m elected, I’m really excited to work with the amazing people running here or already on the TAG. If not, I’m still confident that we’ll have an excellent TAG to shepherd the Web’s architecture for the next year. Happy holidays!