Standardizing UI, and other Crazy Ideas

Decision making, by nerovivoStandards make the web go ’round.  I hope it doesn’t come as too much of a surprise that Mozilla cares a lot about standards, or that a significant percentage of the community, myself included, participate in active standards groups, be they W3C, WHATWG, industry consortia, or other.

They are often, to be honest, a slog.  Anything important enough to be standardized is important enough to attract a variety of interests and motivations, and being in the middle of multiple, divergent forces can be just as fun as it sounds.  They are usually noble slogs, though.  An open web needs a set of linguas franca. As it matures, people invent new creoles to express new ideas, and so our standards need to constantly evolve and add that new wealth to the growing lexicon of awesome.

A little while ago though, the W3C decided to try something sort of odd.  They formed up a working group to look at standardizing security UI.

Standardizing. UI.

To anyone who has designed a user interface, that sort of feels like standardizing art. Not that we are quite so full of hubris as to imagine ourselves Caravaggios, but UI design is a complex interplay of functionality, ergonomics, and subjective experience.  There are general principles, sure, but it’s a very different beast from, say, CSS2 margin properties, where everyone can at least agree that there ought to be a single correct result, even if they disagree about what that result should be or how to obtain it.

Nevertheless, boldly forth they have gone and established the Web Security Context working group with a pretty broad charter. Capturing current best practice is certainly fair game, but it is equally permissible for the group to try to move the state of the art forward.  We’re active members, as are Opera and Konqueror (though not Apple or MS), but like most standards bodies, the group includes folks from academia, from other companies, and from various interested groups as well.

This workgroup has put out its First Public Working Draft (FPWD), which means I have two things to ask you, or maybe ask of you.  In marketing, I believe they call this the Call to Action, so if you were looking for it, here it is!

The first thing I would ask, if you are at all interested, is that you to read it and remark upon it.  The group needs public comment, and you fabulous people are ably placed to provide it.

This first draft was kept deliberately inclusive, to make sure that the majority of recommendation proposals got public airings. So if your main criticism is just “too much,” that is unsurprising, but still welcome, feedback.

The second thing is harder.

We participate in this group for all the reasons mentioned above, and I personally take that participation seriously.  Even on the sketchy topic of standardized UI, I think there’s potential. A document which all browsers conform to as a baseline guide, which says things like “Don’t let javascript arbitrarily resize windows, because it lets this spoofing attack happen,” is a valuable one.  At Mozilla, we talk about things like making the mobile web a better place, for example. One thing we can do right up front in that world is spare this new generation of browser implementors (and their users!) from rediscovering our mistakes the hard way.  This standard could help do that.

But this draft is also defining new UIs, new interactions, new metaphors for online browsing.  The academics in the group have offered to gather usability data on several proposed recommendations, but at a fundamental level, I have asked the group a couple times whether it’s right to use a standard to do this kind of work at all.  I think several of the proposed requirements sound like interesting, probably fruitful UI experiments.  But that’s not the same as “Standards-compliant user agents MUST …”

My second question is this: as members of the Mozilla community, is this an effort that you want me (or people like me) participating in, and helping drive to final publication?

I’m still engaged on the calls and the mailing list – I still see good things coming out of the group, and I have my own opinions about how to best contribute.  But as an employee of Mozilla, I feel an obligation to steward my own resources responsibly, and to expend them on things that the community finds valuable, so it’s important for me to hear how people feel about the value of this work.

Opinions? Suggestions? Funny anecdotes?

8 comments

  1. 4.6.8.2
    This comment is not normative.

    While I can’t say that I actually read that document, here is a quick brain dump of the very high level security UI design patterns that I would love to see standardized across browsers:

    -use of the lock icon
    -color of the location bar
    -use of customs official imagery as a metaphor for identity (we need to release all of the platform specific artwork we have into the public domain)
    -url formating that highlights ETLD+1
    -url formating for IP address domains (perhaps red?)

  2. You mention that some of these things “sound like interesting, probably fruitful UI experiments.” And also that some members of academia have offered to do research on the proposals; it seems like more data is a worthy end in itself, even if all we get is a “nothing makes any difference.” My guess though is that some UI decisions will have measurable security implications and that it would become obvious that at least some of those items Alex just mentioned should be standardized. Or at least implemented. Or it might at least elevate some discussions to using data.

  3. You mention that some of these things “sound like interesting, probably fruitful UI experiments.” And also that some members of academia have offered to do research on the proposals; it seems like more data is a worthy end in itself, even if all we get is a “nothing makes any difference.” My guess though is that some UI decisions will have measurable security implications and that it would become obvious that at least some of those items Alex just mentioned should be standardized. Or at least implemented. Or it might at least elevate some discussions to data conversations instead of “this is new and scares me” conversations.

  4. The biggest problem with this spec is that it tries to replace the PKI model with the SSH model. This forces browsers to maintain a history of https sites you have visited, which is bad for privacy. It seems to allow all kinds of attacks that were not previously possible:

    1. If you search Google for “bank of america” and then click a link to https://www.bankofamerica.com/ for the first time, you’ll no longer get an error page or error dialog; the only indicator that something is wrong will be the absense of security indicators. Users who are new to the browser are unlikely to notice that something is wrong, and those who notice the “https” and correct domain will be misled into thinking they are at the real Bank of America site.

    2. You connect to an untrusted wireless network to check http://icanhascheezburger.com/. A MITM attacker sets up iframes pointing to https://www.paypal.com/ and many other sites. When you go home, you can’t connect to paypal, because your browser has stored information from the attacker’s cert and expects to see it now. (Note that this kind of thing isn’t a problem for SSH itself, because you wouldn’t explicitly try to connect to an important computer for the first time while using an untrusted network.)

    3. A store you trust requests your credit card number, then asks your browser to send that information to a payment processor, which is at a different site but also uses https. But since you haven’t visited the payment processor before, the browser allows the connection to the payment processor to be MITMed.

    4. A MITM attacker poisons your cookie for an https site with something that causes XSS when you visit the real site.

    I don’t understand why the spec authors felt a need to make this drastic change to the https protocol. PKI works fine for the Web, and is getting both better and cheaper every year thanks to TLS SNI and the division of certs into good EV certs and cheap DV certs. The SSH model works for SSH because you explicitly request each connection, but it does not work for the Web, with its many types of interconnections between sites. And there’s already a way for super-cheap sites to get “protection against passive attacks”: the HTTP upgrade header.

  5. This is a brilliant idea W3C. It may be very painful but it should hopefully reduce UI spoofing which browsers are now making even easier by allowing access to .showModalDialog() and with easily-copied core UI like remember password moving to “Information Bars” instead of genuine chrome.

    I understand your concerns about dictating UI however if there is ever a reason to do just that, it’s user security.

  6. > My second question is this: as members of the Mozilla community, is this an effort that you want me (or people like me) participating in, and helping drive to final publication?

    Absolutely not, on several grounds. (manual trackback)

  7. I think we should seperate “documenting a standard” and “having a standardisation committee” here. I think it would be a good thing, if you defined a usability standard, and documented it. I don´t think that it would be a good idea to try to develop it by a standardisation committee. But please document your concept and your rules, so that other vendors can implement the same if they like it, and don´t have to reinvent or reverse-engineer it.