Wandering Thoughts archives

Bad slide navigation on the web and understanding why it's bad

As usual, I'll start with my tweet:

If the online copy of your slide presentation is structured in 2D, not just 'go forward', please know that I just closed my browser window.

This is sort of opaque because of the 140 character limitation, so let me unpack it.

People put slide decks for their presentations online using various bits of technology. Most of the time how you navigate through those decks is strictly linear; you have 'next slide' and 'previous slide' in some form. But there's another somewhat popular form I run across every so often, where the navigation down in the bottom right corner offers you a left / right / up / down compass rose. Normally you go through the slide deck by moving right (forward), but some slides have more slides below them so you have to switch to going down to the end, then going right again.

These days, I close the browser window on those slide presentations. They're simply not worth the hassle of dealing with the navigation.

There are a number of reasons why this navigation is bad on the web (and probably in general) beyond the obvious. To start with, there's generally no warning cue on a slide itself that it's the top of an up/down stack of slides (and not all slides at the top level are). Instead I have to pay attention to the presence or absence of a little down arrow all the way over on the side of the display, well away from what I'm paying attention to. It is extremely easy to miss this cue and thus skip a whole series of slides. At best this gives me an extremely abbreviated version of the slide deck until I realize, back up, and try to find the stacks I missed.

This lack of cues combines terribly with the other attribute of slides, which is that good slides are very low density and thus will be read fast. When a slide has at most a sentence or two, I'm going to be spending only seconds a slide (I read fast) and the whole slide deck is often a stream of information. Except that it's a stream that I can't just go 'next next next' through, because I have to stop to figure out what I do next and keep track of whether I'm going right or down and so on. I'm pretty sure that on some 'sparse slides' presentations this would literally double the amount of time I spend per slide, and worse it interrupts the context of my reading; one moment I'm absorbing this slide, the next I'm switching contexts to figure out where to navigate to, then I'm back to absorbing the next slide, then etc. I get whiplash. It's not a very pleasant way to read something.

Multi-option HTML navigation works best when it is infrequent and clear. We all hate those articles that have been sliced up into multiple pages with only a couple of paragraphs per page, and it's for good reason; we want to read the information, not navigate from page to page to page. The more complicated and obscure you make the navigation, the worse it is. This sort of slide presentation is an extreme version of multi-page articles with less clear navigation than normal HTML links (which are themselves often obscured these days).

I don't think any of this is particularly novel or even non-obvious, and I sure hope that people doing web design are thinking about these information architecture issues. But people still keep designing what I think of as terribly broken web navigation experiences anyways, these slide decks being one of them. I could speculate about why, but all of the reasons are depressing.

(Yes, including that my tastes here are unusual, because if my tastes are unusual it means that I'm basically doomed to a lot of bad web experiences. Oh well, generally I don't really need to read those slide decks et al, so in a sense people are helpfully saving my time. There's an increasing number of links on Twitter that I don't even bother following because I know I won't be able to read them due to the site they're on.)

Sidebar: Where I suspect this design idea got started

Imagine a slide deck where there you've added some optional extra material at various spots. Depending on timing and audience interest, you could include some or all of this material or you could skip over it. This material logically 'hangs off' certain slides (in that between slide A and F there are optional slides C, D, and E 'hanging off' A).

This slide structure makes sense to represent in 2D for presentation purposes. Your main line of presentation (all the stuff that really has to be there) is along the top, then the optional pieces go below the various spots they hang off of. At any time you can move forward to the next main line slide, or start moving through the bit of extra material that's appropriate to the current context (ie, you go down a stack).

Then two (or three) things went wrong. First, the presentation focused structure was copied literally to the web for general viewing, when probably it should be shifted into linear form. Second, there were no prominent markers added for 'there is extra material below' (the presenter knows this already, but general readers don't). Finally, people took this 2D structure and put important material 'down' instead of restricting down to purely additional material. Now a reader has to navigate in 2D instead of 1D, and is doing so without cues that should really be there.

Why your Apache should have mod_status configured somewhere

Recently, our monitoring system alerted us that our central web server wasn't responding. I poked it and indeed, it wasn't responding, but when I looked at the server everything seemed okay and the logs said it was responding to requests (a lot of them, in fact). Then a little bit later monitoring said it was responding again. Then it wasn't responding. Then my attempt to look at a URL from it worked, but only really slowly.

If you're a long-term Apache wrangler, you can probably already guess the cause. You would be correct; what was going on was that our Apache was being hit with so many requests at once that it was running out of worker processes. If it got through enough work in time, it would eventually pick up your request and satisfy it; if it didn't, you timed out. And if you were lucky, maybe you could get a request in during a lull in all the requests and it would be handled right away.

Once we'd identified the overall cause, we needed to know who or what was doing it. Our central web server handles a wide variety of URLs for a lot of people, some of which can get popular from time to time, so there were a lot of options. And nothing stood out in a quick scan of the logs as receiving a wall of requests or the like. Now, I'm sure that we could have done some more careful log analysis to determine the most active URLs and the most active sources over the last hour or half hour or something, but that would have taken time and effort and we still might have missed sometime. Instead I took the brute force approach: I added mod_status to the server's configuration, on a non-standard URL with access restrictions, and then I looked at it. A high volume source IP jumped out right away and did indeed turn out to be our problem.

Apache's mod_status has a bad reputation as an information leak and a security issue, and as a result I think that a lot of people don't enabled it these days. Our example shows why you might want to reconsider that. Mod_status offers information that's fairly hard to get in any other way and that's very useful (or essential) when you need it, and it's definitely possible to enable it securely. Someday you will want to know who or what is bogging down your server (or at least what it's doing right now), and a live display of current requests is just the thing to tell you.

(This should not be surprising; live status is valuable for pretty much anything. Even when this sort of information can be approximated or reconstructed from logs, it takes extra time and effort.)

Why I think Let's Encrypt won't be a threat to commercial CAs for now

One of the questions these days is what effects Let's Encrypt and their well publicized free TLS certificates will have on existing commercial CAs. While LE has become a very popular CA and there have been some amusing signs of nervousness from existing CAs, my personal belief is that Let's Encrypt is not going to be a threat to the business of commercial CAs for the medium term, say the next few years.

One reason I say this is pragmatic past history. LE is not the first or only free SSL CA, and that existing free SSL CA does not seem to have made any particularly large dent in the business of other CAs. Now, there are certainly some differences between LE and this other CA that makes this not quite an apples to apples situation; LE is very well known now and issues short-duration certificates through easy automation, while the other free CA is less well known and issues year long certificates through a more annoying and onerous web-based process that not everyone can take advantage of. However, I think it's still a sign of some things.

(The other free CA also charges for certificate revocation or early replacement, which did not endear them to a lot of people during Heartbleed.)

Beyond that, there are a number of potential reasons that Let's Encrypt certificates are not necessarily all that compelling for many organizations. In no particular order:

• LE doesn't issue wild card certificates.
• Even with their recently raised rate limits, 20 new certificates a week is still potentially a real limit for decent sized organizations (who can have a lot of hosts and subdomains they want TLS certificates for).
• The short duration of LE certificates pretty much requires developing and deploying new automation to automatically renew and roll over LE certificates. With commercial CAs, a moderate sized place can just buy some certificates and be done for the next few years, with minimal staff time required.

  (At least some CAs will even mail you helpful reminder emails when your certificates are approaching their expiry times.)

Finally, as a commodity basic TLS DV certificates are already available for very little money. It's my impression that a lot of organizations are not that price sensitive about TLS certificates; they simply don't care that they could save $10 or $20 a year per certificate, because the aggregate savings are not worth thinking about at their size. They might as well go with whatever is either simpler for them now or already familiar. Let's Encrypt is compelling for the price sensitive hobbyist, but for a decent sized organization I think it's only interesting for now.

(And for a large organization, the rate limits probably make it infeasible to rely on LE for new certificates.)

However, I do expect this to change over the longer term. What will really threaten existing CAs is the addition of turn-key integration of LE certificates in more and more pieces of software. Once you can set an option in your web server of choice to automatically get and maintain LE certificates for each virtual host you have or add, I think that a lot of people in a lot of organizations will just turn that option on rather than wrestle with all of the little hassles of commercial CAs. Once LE becomes the easiest choice, existing CAs have much less to offer to anyone who fits into LE's rate limits (basically CAs are down to 'we'll sell you wild-carded DV certificates').

(I'm ignoring EV certificates as another thing entirely, but if CAs feel actively threatened by LE I expect them to start trying to push EV certificates much more strongly. One obvious danger sign would be if CAs start trying to persuade browser vendors to restrict certain JavaScript or browser capabilities to only EV-validated sites instead of all HTTPS sites.)

(This is sort of an elaboration of a comment I left on Tanguy Ortolo's entry about this issue (via Planet Debian).)

Why I don't use HTTP Key Pinning and I'm not likely to any time soon

One of the additional security measures you can take for a HTTPS web site is HTTP Public Key Pinning. HPKP is designed to guard against the fundamental SSL CA problem by limiting what validly signed keys can be used for your website. This way it doesn't matter if an attacker gets one of the zillion different CAs out there to issue a certificate for your website; hopefully a lot of browsers won't accept it anyways because you've told them better. A number of people like the idea of HPKP and are sad that it is used only by a trace number of websites out there.

I have looked a bit at HPKP and I'm not going to use it any time soon (either on my personal sites or at work). Fundamentally HPKP has several problems for most people. First, it's relatively hard to even set up HPKP so that it works. To simplify, a valid HPKP configuration requires you to have either a second spare TLS certificate or a second CA that you're confident you'll get a TLS certificate from if you need another one. If you go with a spare TLS certificate, you must make sure this TLS certificate is always recoverable; if you lose both your primary and your secondary certificates, you are off the air until your HPKP pinning times out. With the second CA, you must be absolutely sure that you can get a TLS certificate from the CA if you need it, and of course you're vulnerable if an attacker can get a TLS certificate for you from that specific CA.

(Note that as far as I know, you cannot specify 'this current TLS certificate or any certificate from my current CA'; your backup key must be completely independent from your current one. Also technically you don't need your secondary TLS certificate to be issued and signed by a CA, just to be pregenerated and known. This may give you some freedom. And you can specify more than one backup pin.)

Measurements in the field indicate that a lot of people get this one wrong (here's one source). Either they serve HPKP headers with only one pin or they provide two pins that aren't fully independent.

The second problem is that HPKP is very dangerous, and the more it protects you the more dangerous it is. If you set up a valid HPKP configuration and then lose both your live pin and your backup pin, you've bricked your site for people who have your HPKP information saved. The more specific your pins are and the longer you advertise them as valid, the more you're protected but also the easier it is to lose them and the longer the damage from a loss will last.

The final problem with HPKP for most sites is that it protects against what is now a very rare event that's quite risky for the attacker. It's vanishingly unlikely that your typical HTTPS site is going to be targeted by someone who can generate a valid TLS certificate for it and is willing to (quite possibly) burn a compromised CA by attacking you. This makes the reward of deploying HPKP very small compared to the risks.

If you're a big high risk site that attackers would get a big payoff from compromising, sure, HPKP makes a lot of sense. But then if you're this sort of site, you've probably already done things like ask the Chrome team to pre-pin your TLS certificates. If you'd never even dream of bugging the Chrome team for that (partly because you're too small and partly because it's a massive risk if something goes wrong), strong HPKP doesn't really make much sense.

(It might make sense to deploy reporting-only HPKP, but then you have to find or set up a reporting endpoint and then monitor things for reports, which should normally be big alerts (assuming you got your HPKP pinning right). Even with services like this, that's a fair amount of work for a fairly low likelihood risk.)

(Note that HPKP pinning can get complicated fast, since you can pin more than your current key plus one backup. With my current low level of knowledge, I'm not going to try to say anything more than that.)