Comments on: Standardizing UI, and other Crazy Ideas

By: max

max — Fri, 01 Aug 2008 20:53:43 +0000

very good)

By: Philipp

Philipp — Fri, 11 Jan 2008 23:46:22 +0000

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.

By: Iang (why it's not a good idea...)

Iang (why it's not a good idea...) — Fri, 11 Jan 2008 19:42:27 +0000

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

By: pd

pd — Fri, 11 Jan 2008 10:14:40 +0000

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.

By: Jesse Ruderman

Jesse Ruderman — Fri, 11 Jan 2008 05:40:11 +0000

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.

By: quodlibetor

quodlibetor — Thu, 10 Jan 2008 18:29:23 +0000

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.

By: quodlibetor

quodlibetor — Thu, 10 Jan 2008 18:28:47 +0000

By: Alex Faaborg

Alex Faaborg — Thu, 10 Jan 2008 16:09:52 +0000

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