At the start of this month, I posted a simple note and question:

Thoughts yesterday lunch w @bcrypt: @W3C specs too big/complex. How do we simplify WebAPIs to reduce security surface?

With follow-up:

And @W3C needs a Security (#s6y) group that reviews all specs, like #i18n & #a11y (WAI) groups do. cc: @bcrypt @W3CAB

Which kicked off quite a conversation on Twitter (18 replies shown on load, 53 more dynamically upon scrolling if various scripts are able to load & execute).

Security & Privacy Reviews

Buried among those replies was one particularly constructive, if understated, reply from Mike West:

[…] mikewest.github.io/spec-questionnaire/security-privacy/ is an initial strawman for security/privacy self-review.

A good set of questions (even if incomplete) to answer in a self-review of a specification is an excellent start towards building a culture of reviewing security & privacy features of web standards.

While self-reviews are a good start, and will hopefully catch (or indicate the unsureness about) some security and/or privacy issues, I do still think we need a security group, made up of those more experienced in web security and privacy concerns, to review all specifications before they advance to being standards.

Such expert reviews could also be done continuously for "living" specifications, where a security review of a specification could be published as of a certain revision (snapshot) of a living specification, which then hopefully could be incrementally updated along with updates to the spec itself.

Specification Section for Security & Privacy Considerations

In follow-up email Mike asked for feedback on specifics regarding the questionnaire which I provided as a braindump email reply, and offered to also submit as a pull request as well. After checking with Yan, who was also on the email, I decided to go ahead and do so. After non-trivially expanding a section, very likely beyond its original intent and scope (meta-ironically so), it seemed more appropriate to at least blog it in addition to a pull request.

The last question of the questionnaire asks:

Does this specification have a "Security Considerations" and "Privacy Considerations" section?

Rather than the brief two sentence paragraph starting with Not every feature has security or privacy impacts, which I think deserves a better reframing, I've submitted the below replacement text (after the heading) as a pull request.

Reducing Security Surface Towards Minimum Viability

Unless proven otherwise, every feature has potential security and/or privacy impacts.

Documenting the various concerns that have cropped up in one form or another is a good way to help implementers and authors understand the risks that a feature presents, and ensure that adequate mitigations are in place.

If it seems like a feature does not have security or privacy impacts, then say so inline in the spec section for that feature:

There are no known security or privacy impacts of this feature.

Saying so explicitly in the specification serves several purposes:

1. Shows that a spec author/editor has possibly considered (hopefully not just copy/pasted) whether there are such impacts.
2. Provides some sense of confidence that there are no such impacts.
3. Challenges security and privacy minded individuals to think of and find even the potential for such impacts.
4. Demonstrates the spec author/editor's receptivity to feedback about such impacts.

The easiest way to mitigate potential negative security or privacy impacts of a feature, and even discussing the possibility, is to drop the feature.

Every feature in a spec should be considered guilty (of harming security and/or privacy) until proven otherwise. Every specification should seek to be as small as possible, even if only for the reasons of reducing and minimizing security/privacy attack surface(s).

By doing so we can reduce the overall security (and privacy) attack surface of not only a particular feature, but of a module (related set of features), a specification, and the overall web platform. Ideally this is one of many motivations to reduce each of those to the minimum viable:

1. Minimum viable feature: cut/drop values, options, or optional aspects.
2. Minimum viable web format/protocol/API: cut/drop a module, or even just one feature.
3. Minimum viable web platform: Cut/drop/obsolete entire specification(s).

Questions and Challenges

The above text expresses a specific opinion and perspective about not only web security, web standards, but goals and ideals for the web platform as whole. In some ways it raises more questions than answers.

How do you determine minimum viability?

How do you incentivize (beyond security & privacy) the simplification and minimizing of web platform features?

How do we confront the various counter-incentives?

Or rather:

How do we document and cope with the numerous incentives for complexity and obfuscation that come from so many sources (some mentioned in that Twitter thread) that seem in total insurmountable?

No easy answers here. Perhaps material for more posts on the subject.

Thanks to Yan for reviewing drafts of this post.

Update 2015-03-31

Thanks to Mike West accepting my pull request, my above suggested edit and additional text is now inline in the Security & Privacy Questionnaire!