otsukare Thoughts after a day of work

Security and Technical Specifications Review

I was reading Tantek's blog post about Simplifying Standards & Reducing Their Security Surface: Towards A Minimum Viable Web Platform. He mentionned:

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.

I was about to send an email to tantek about it. But then I remembered that if it fits in an email, it's probably worth a blog post with a permanent URI and something people can link to in the future.

Reviews are a difficult exercise. When I was working at W3C, I spent nearly 5 years reviewing every single specification coming out of the press for quality issues. First when we were working on creating Quality Guidelines for Specification editors and then on trying to apply these guidelines. The Quality Assurance Working Group ended up creating the QA Framework: Specification Guidelines. The thing I really like about this document is its format, which is basically for each requirement/good practice.

  1. Requirement/Good Practice (concise and imperative sentence)
  2. What does it mean? (explain the topic in simple words)
  3. Why care? (explain why it's important)
  4. Related (give additional resources about the topic)
  5. Techniques (give a practical step by step how-to for meeting the requirement)
  6. Examples (extract some real examples already published here and there)

This makes the document a very easy piece to cite and cherry pick at will. It's also more interesting to read. I can say that our first version of the QA Framework was really not digestible.

Back to the security review. In the Specification Guidelines, we mentionned

In addition to conformance, there are several other topics that should be addressed when writing a specification, such as accessibility, internationalization, security, and device independence. These topics are not directly in the scope of this document, but are evoked in section 3.3

And then in section 3.3:

First and foremost, W3C specifications need to frame and define technologies that meet the requirements of the particular deliverable, fulfill the charter of the Working Group, and advance W3C's mission to extend the exchange of information through the Web to everyone. Thus, accessibility, internationalization and device independence are general requirements that must be considered in the specification of all Web technologies. (Specification developers should consult the technical reports index for an up-to-date profile of W3C publications in all areas.)

[…]

A Working Group should designate participants to monitor the application of accessibility, internationalization and device independence to their specifications at the earliest point possible. These participants can be the points of contact with the relevant W3C Activities and can seek feedback on their group's adopted solutions.

A good start for the security questions you may want to ask yourself have been published by Mike West. To note that security and privacy are very hard topics because there are strongly tied to contexts and cultural expectations. There are things which seem obvious in a context but put in another context doesn't make sense. Tantek is reaching a point where he says:

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

Yes and not only for the attack surface but the ability to review and implement itself the specification. Reviewing a giant specification is a daunting task. Been there, done that. Things we can see, hold in your hand, manipulate, break down and put together again are more likely to reveal themselves than a huge pile of characters that you need to read making a graph on the side. I have also the impression that we make security a bigger issue than it should be because of the way we are engineering interactions, services and protocols. If we create giant Web services with single point of communications, we create by design a giant security issue. We give the possibility for example to a company or an organization to monitor all communications. If we design things in a more decentralized way then we greatly reduce the threat and the security still an important topic has less consequences. Or if you prefer, we do not need the same security level for a house and a bank.

Anyway interesting discussions going on about security and reviews.

PS: Oh yes! Completely unrelated, I quit twitter. Yes. 410 Gone. The account has been totally erased.

Otsukare!