Wandering Thoughts archives

Why CA-based SSL is not likely to be replaced any time soon

A whole lot of things have been written this year about better versions of SSL designed to get away from the many practical weaknesses of the current CA-based SSL model (you know, the one where CAs have terrible business practices, get compromised, and get leaned on by governments). Unfortunately, I don't think that any of them are likely to catch on any time soon, because of what is essentially the inverse of the false positives problem.

The reality is that forged SSL certificates are in general a very infrequent occurrence. All (or almost all) of the proposed solutions to them are at least moderately difficult; they involve additional code, additional infrastructure, additional TCP connections during SSL connections, disclosure risks for what you're making SSL connections to, and so on. In short, the proposed solutions add pain. And the reality of the world is that taking on pain (possibly a lot of it) in order to solve a rare problem is not a successful sales pitch anywhere outside of the mathematical side of security and cryptography. Especially, browser vendors are going to be naturally unenthused about anything that makes SSL connections worse in practice (slower, fail more often, etc) in order to deal with a rare occurrence.

The corollary of this is that any realistic replacement for CA-based SSL must be cheap and simple overall. My impression is that the only possible candidate for this is SSL certificate information in DNSSec-signed DNS records. This has the virtue that it needs almost no extra connections or queries, does not require any outside infrastructure, and does not disclose your browsing to third parties. It can also be deployed incrementally.

(It has the drawback that it only works for sites that have a DNSSec trust path to the root. If your TLD has not gone DNSSec yet, you lose even if you're all ready yourself.)

Blog entries should have visible dates (usually)

There are any number of blog packages (and blog design templates) that don't make the date of entries very obvious; it's not in the URL, it's not at the top of the page, and perhaps it's hiding in small type down at the bottom of the page. I've come to feel that this is a significant mistake, because of a combination of real blog usability and how blogs are written.

How blogs are written means that you probably never go back to revise and update old entries, even if the information in them is now out of date. However, many visitors are arriving at your entries through web searches and these searches will happily return those old entries, whether or not their information is still useful. So, how does a reader figure out whether or not what they're reading is still good or if it's now probably out of date? Their best clue is when the entry was written.

This is why I've come to believe that blog entries should have the date visible 'above the fold', somewhere around the entry title and other details. I don't think it has to be prominent, but I do think you should be able to find it easily when you look.

I also think it's possible to be clever about this. To view it one way, the older an entry is the more important its date becomes. This implies that you can start out with the date not very visible, perhaps in small type and mostly faded out, and then on older entries you can progressively increase the date's visibility by doing things like fading it in and making its text bigger. How fast this should happen depends on how fast you think entries potentially go stale.

A corollary is that some blogs don't need to do this at all, either because the content of their entries already makes it clear when they were written or because the content essentially never goes stale. My ire about blogs without dates is primarily directed to things like, say, blogs with technical information.

(I'm aware that WanderingThoughts fails on this; the date isn't in the URL and is only visible down at the bottom in small sized text. I'm going to have to think about how to fix that, but it's potentially complex in DWiki's architecture.)

Practical issues with REST's use of the Accept header

In full blown REST, a single resource can have multiple representations (formats). You decide which representation to ask for and to serve by what is in the HTTP Accept header of the HTTP request; if you want a HTML version of the URL you say that you will accept text/html and if you want a JSON version you ask for application/json (see eg).

The issue I have with this in practice is that it makes the Accept header part of the name of the specific representation of the resource (okay, this is really the MIME type). You cannot talk about, for example, 'the URL of the Atom feed'; you must specify both the URL and the type when you are talking about it. By 'talk about' I mean more than just 'share with people'. Any time you want to retrieve a specific representation of the resource, the tools you use to do this must be told the type as well as the URL, or must default to the right type.

(And if the tool doesn't support specifying the type or has an awkward procedure for this, you lose.)

This is a problem. To start with, we simply don't have an agreed on notation for 'a URL in a specific type' in the same sense that we have a notation for 'an URL'. Names and notation are important, and lack of good notation is a serious drawback because (among other things) it gets in the way of communication. Communication between people, communication between people and programs, and communication between programs (and even inside programs).

Of course, REST has a good reason for doing this. From my outsider perspective, the problem REST is solving is auto-discovering how to retrieve a specific representation of a resource. If you have a base URL, in a pure REST environment you now know how to retrieve any representation of the URL that's available. Want a JSON or an Atom feed version of URL <X>? Request <X> with an Accept of JSON or Atom (or what have you) and you're done. And this works for any initial default representation; you do not have to assume, eg, an initial HTML representation where you then parse <link> elements out of the <head> to discover the Atom feed URL.

Of course this raises questions in practice about what the equivalent of a URL is in another representation. For example, what is the proper Atom feed representation of the front page of a blog that shows only the most recent five entries: is it an Atom feed with only the five entries on the front page, or is it a full-sized Atom feed with more entries? I suspect that the proper REST answer is the former while most people would consider the latter to be more useful.

I'm a pragmatist. I care a lot about clear names and easy communication, and I live in a world of imperfect tools (many of which were designed before the Accept type became important this way). Thus while I can admire the intellectual purity and usefulness of the full blown REST approach, I don't agree with it in practice and I'm not likely to build services that work that way (unless there's a compelling technical need to avoid the discovery problem). Even if it's less pure, I'll park my different representations of more or less the same thing on different URLs; it's simply easier in practice.

Why I have comments here

Recently I read Comments Off (via) and what struck me about Matt Gemmell's framing of the issue is that he seems to view having comments as something that you do for your blog's readers. What this says to me is that Matt Gemmell and I have significantly different views of comments.

Let me tell you a little secret: I don't have comments here for my readers, at least not primarily; I have comments here for me. If that ever was to change, if I stopped feeling that comments were a benefit to me instead of just (possibly) my readers, then I'd stop having them (either quietly or not).

(If I had comments primarily for my readers, I would probably structure things here to make them more prominent.)

There's several ways that comments are a benefit for me. To start with, I enjoy reading them. People's comments here teach me things, they give me ideas, they correct my mistakes, they keep me on my toes and in general keep me honest, they're periodically entertaining, and they make me change my mind every so often (that's a random example). On top of that, I have received a few comments that are hugely valuable in their own right, to the point where I feel they have pretty much justified the entire effort to implement and manage comments here all by themselves.

(As examples, a comment led me to pca, which has for years been the only sane way to manage patches on Solaris. Another comment introduced me to dmenu, which in less than a year has significantly changed how I use my long standing environment. Both of these changed my computing life for the significantly better and I doubt I'd have found either on my own.)

If you don't feel that comments on your blog are there for you, if you're really only supporting comments for your readers, then I tend to agree with what Matt Gemmell says. I think that it's hard to arrange a setup where comments really benefit your readers, and doing so takes a lot of work and a certain amount of luck (plus you're probably going to have to become a community manager in addition to a blogger). In today's world, not supporting comments in this situation makes a lot of sense.

(To be very clear: I don't think that comments here degrade the experience for my readers. I just think that they're probably a neutral thing because I expect that most people don't read comments. And I can't expect them to; unless you go to a lot of effort to build a community that people find appealing, people generally are going to be coming to your blog because they want to read your writing, not other people's. (And I am no exception to this.))

However, as I've written before I do feel that there are practical reasons that people like comments, although maybe those reasons are lower in the modern web of Twitter and Facebook and so on.

(Matt Gemmell is clearly aware of the downsides of his decision, as shown by the followup email exchange he has at the bottom of his entry.)

Sidebar: an honorable mention

In the 'comments that justified having comments' category: if I read weighty things more promptly I would be able to count the pointer to Russ Cox's first article on regexps that was left here. Instead I only read the whole series when the second and third parts appeared a couple of years later and made Hacker News.