The moderation UI provided by Mailman 2.1.14, the version Mozilla uses (note: I don’t know if this is the latest version, and I don’t know if this UI is still present) looks like this. The controls for an individual message are as in this screenshot:

What is should look like is something like this:

I would love it if someone were to write a Greasemonkey script or similar which did this rearrangement. It would improve my life measurably. Any takers?

A word of praise for “Simple Scan”, the new scanning app in Ubuntu Lucid 10.04. Turn on your scanner, start the application, press “Scan”, watch the image appear before your eyes, drag some borders to crop, and press “Save”. It’s that simple. Great work.

Even more noteworthy: the interface they implemented is even simpler than the one in the spec, which is still option-heavy. Most commonly, when you try and implement a UI it ends up more complicated than the spec due to unforeseen edge cases.

With the release of Ubuntu 10.04 yesterday, it’s finally possible:

(Comparison). Of course, the number of possibilities for Caps Lock has now gone up from 10 to 14 (you can also now make Caps Lock an additional Hyper, Num Lock or Super if those are options you’ve been waiting for all your life), but at least the important one is there!

Another blogpost I wanted to read has disappeared into the ether, and it’s time for another usability rant – this time about Liferea. This is Ubuntu’s recommended feed reader – at least, it’s the only result of a search in the Ubuntu Software Centre for “feed reader” which is in the repository it provides support for. Although when I asked mpt, who works for Canonical in usability, what the official feed reader was, he said:

https://help.ubuntu.com/9.10/internet/C/internet-otherapps.html recommends Liferea. I think that’s as official as you’d get on that subject.

Which is hardly a ringing endorsement. Anyway, I moved to it for half my RSS feeds (the personal ones) to see if anything was better than Thunderbird’s frankly patchy feed reading support.

OK, it doesn’t have Thunderbird’s “thought you’d read this item? Let me give you another, unread copy of it in the feed” bug, but boy – did the developers actually sit down and try and read feeds with it? The usability is a nightmare.

The main way of reading feeds is an Unread virtual folder, which contains all of the unread items. As you read things and move to the next one, they disappear from here, although you can still find them in the folder for the individual feed.

There’s a “Next Unread Item” button, but no “Previous Unread Item” and no history. So if you accidentally move off the item you are reading, it immediately disappears from the Unread view (because you read it, duh) and there’s no way of finding it again! If you can’t remember which blog it’s in, you have to trawl through 50 feeds, looking at the topmost few entries, and see if you recognise it. And, as you start this process, you realise that the next unread item, which the cursor went to when it went off the one you wanted to read and are now chasing, is also now lost, because it got marked as read when it got highlighted and now you’ve moved the focus off that one too. And you can’t remember anything about that one at all.

Basically, they’ve implemented a browsing application without a Back button. Genius.

That’s OK, you think: I can create a Search folder for “all items newer than a week” and sort it by date, and find my lost items that way. Except that “date” is not one of the options in the search builder. You can search by whether it’s a podcast or not, but not when the wretched thing was written. Great. You have to create a folder of everything, which wedges your machine for 20 seconds every time you open it as it loads 5000 items into a data structure using some sort of naive n² algorithm.

There’s a Mark Items Read on the toolbar. Accidentally click it, and you’ve lost your “to read” queue entirely, with no way of getting it back. And it’s right next to the “Update All” button which is used regularly. “Mark Items Read” might as well be labelled “Cause Me To Scream in Frustration”.

• You can’t select multiple items. If you try, the first one gets deselected and, because it was now marked as read, disappears from the view!
• You can never find a feed you want, because the list is in the order they were added, and there’s no sort, only drag-and-drop. Hey, I can practise my manual quicksort!
• If you decide you want to keep an item in your “to read” queue, and so, having scanned it, press Ctrl-U to mark it back as unread, then Ctrl-N refuses to work. Presumably because it thinks “you’re on the next unread message already, dummy”.

Grr.

In the past, I have commented on the Facebook policy of showing email addresses as graphics rather than text. They sent a cease-and-desist to Chris Finke about his addon to convert them back to proper mailto: links.

I am pleased to announce that Facebook have relented! A Facebook spokesman said:

Showing email addresses in plain text makes it easier for people to use
the information to connect with their friends.

In the spirit of making it even easier for people to use the information to connect with their friends, I’d like to plug Chris Finke’s recently-released “Facebook Email Links” Firefox addon, which does the same thing as the old one, but without the need for OCR. Install it, and you will be able to email your Facebook friends using standards-based email with a single click.

And here’s a summary post to round off the series on So Long, And No Thanks For The Externalities (Part 1, Part 2, Part 3). :-)

The concluding points of the paper are that:

1. We should reduce the cost of security advice to users
2. We should offer advice whose cost is proportional to the victimization rate
3. We should retire advice that is no longer compelling
4. We should prioritize the advice we do give

I agree with all four. 3) and 4) in particular can be hard to persuade people of, particularly geeks and techies who, as well as understanding the advice easily themselves, are often people who like people to have “all the information”. Read some of the comments on my first post about passwords to see examples.

For SSL, I am hoping that we can get to a point where the main piece of security advice on the web is “check the name of the company is correct in the green box”. The EV vetting system should ensure a very low false issuance rate, and the revocation system should ensure minimal damage for any falsely-issued certs. That glance should hopefully take each person a half a second per site. It’s not the 0.36 seconds per user per day which the paper argues for, but it’s a whole lot closer than we are now.

I’m convinced we can’t protect users fully with zero user education. But we should minimise what that education is. And it shouldn’t involve reading URLs.

This is the (belated) third of three posts relating to So Long And No Thanks For The Externalities. At least I got them all out in the same decade :-)

First off, the author notes the often-found result that setting a site’s favicon to the lock symbol will help fool users (as will putting a lock in the page body). Although it won’t solve the entire problem, on general principles my view is that (now that tabbed browsing is established as the way everyone browses) we shouldn’t put favicons in the URL bar, only on the tabs. The principle is that the URL bar should be entirely trusted, and not controllable (apart from the contents of the URL, obviously) by the site being visited.

This, incidentally, is an issue with tabs-on-top. It puts the browser-controlled bit of the UI (the URL bar and toolbar) between two page-controlled bits of the UI (the title/favicon, and the page itself). That makes it harder to educate the user about what is trustworthy and what is not. I can’t see any way around the idea that some bits of the UI a user is faced with are trustworthy and some are not (unless you make it all untrustworthy). If there must be this split, keeping a geographical distinction between the two types must help. Logically, I’m a fan of tabs-on-top. But I can see security disadvantages too.

I absolutely agree that a goal of secure website UI design should be to minimise the number of errors encountered, while still maintaining security. Repeated warnings habituate users into ignoring them – although we have made them harder to ignore in recent Firefoxes. I would be very interested in research which looked at whether this has had an impact on the number of bad certificates out there. The trouble is that it’s hard to measure that number, because just because a scanner can’t trace a cert back to its root, that doesn’t mean that the intended users of that website can’t.

Unfortunately, some suggestions people commonly make for eliminating warnings (e.g. “just quietly show an HTTP UI if the cert is self-signed) have security holes at the edge cases.

STS is a great example of a way we can improve security without the user noticing anything different. For sites which use it, it entirely solves the problem raised in Section 5.2, where an attacker can intercept and redirect an initial HTTP request before the HTTPS session is established.

At the end of the section, the author makes the astonishing claim that:

In fact, as far as we can determine, there is no evidence of a single user being saved from harm by a certificate error, anywhere, ever.

Even if that were true, if we removed all certificate errors and just blindly trusted any SSL connection, the situation would change somewhat rapidly. They come close to admit this in the following sentence:

Of course, even if 100% of certificate errors are false positives it does not mean that we can dispense with certificates. However, it does mean that for users the idea that certificate errors are a useful tool in protecting them from harm is entirely abstract and not evidence-based. The effort we ask of them is real, while the harm we warn them of is theoretical.

The assertion that the benefit of certificate errors (a side effect of certificate checking) is not evidence-based is the same as the assertion that forbidding guns and grenades on planes reduces the risk of hijack is not evidence based. No-one wants to try the alternative to gather the evidence!

The fact that most phishing sites don’t use SSL is because users don’t look for SSL or site identity. And that’s a UI and education problem we could fix, if the world put its mind to it. After all, most people now automatically buckle up when they get in a car. And now we have EV, we can build a site identity system on rock rather than sand.

This is the second post about Cormac Herley’s paper called “So Long And No Thanks For The Externalities”, which highlights the cost to users of security advice.

He focusses on 3 areas of advice-giving: Password Rules, URL Reading (to avoid phishing) and Certificate Errors. This blogpost is about URL Reading.

His point is that teaching users to read URLs for protection from phishing is a lost cause. And I think he’s probably right. There is no way we can provide simple, reliable advice in this area – URL syntax is complex enough that anything simple isn’t reliable, and what’s reliable isn’t simple. We need a way to securely replace URLs with a human-readable, unambiguous, verifiable, site or business identifier. And that’s exactly what EV certificates are.

So stay tuned for tomorrow’s installment on Certificate Errors, where he has something to say about those :-)