Wandering Thoughts archives

Another problem with SSL identities

On top of SSL's general issue there is a practical problem with how SSL information is presented in browsers, one that makes it very difficult for anyone except very technical people to actually meaningfully verify who a SSL certificate is issued to.

The issue is simple: browsers normally only show you the name of the organization that the SSL certificate is issued to. But organization names are not unique, especially not across the entire world, which means that just the organization name alone tells people less than they think it does.

(In practice, certain sufficiently well known organizations do have unique names on the Internet, but this is just because no certificate authority is going to issue a certificate to a 'Google' that is not located in Mountain View (unless, of course, an accident happens, as it did once with Microsoft). Less well known organizations have no such protection.)

SSL recognized this right from the start, and SSL certificates have location information for the organization to disambiguate just this situation. Unfortunately, browsers have chosen to hide this information away in cryptic detailed SSL information dumps, instead of presenting it to users as part of the identity of who the certificate is issued to. The result is that even the rare careful user that actually checks is likely verifying less about who a SSL certificate is assigned to than they think they are.

Why your blog comments have less of an audience than new blog entries

Expanding on a remark in the previous entry: I think there are several reasons why your comments are likely to get less of an audience than new entries. First, in most blog setups new comments are less obvious to readers than new entries, as your readers have to go back by hand to look for them. This is especially so if people are only interested in a few comments.

It's possible to work around this with a different blog layout, but it does mean a moderately radical change from how people think of blog front pages and so on. I suspect that it would work better for a blog that already mingles quick links with regular articles, and I think you would want to promote only some of your comments this way, because many quick comment replies require too much context.

Second, I think that many comments are intrinsically less interesting than a new entry, because they are effectively expanding on some aspect of your original entry. They are thus for people who are so interested in the topic that they want even more, and not as interesting to people who were satisfied with your original entry in the first place. This isn't always the case, but to the extent that your comment replies are of general interest, you might as well make them full entries.

(And some comment replies are only going to be interesting to people who read the comment that you're replying to, since they're just correcting or reacting to those comments instead of expanding on your original entry.)

Another reason to avoid having comments

To go with my previous thoughts about the purposes of comments, here is another reason that people might want to not have them on their blog: they eat your limited time.

In a sense, comments on your blog carry with them an implicit duty to reply; while you can skip this, it may look odd and cause bad reactions. However, comments that you write will probably get less of an audience than a new entry. So if you only have a limited amount of time to write things for your blog, your time is better spent not having comments and just writing entries.

How true this is depends on how much of your time writing comments takes up. While many comment replies can be written quickly, I think that sooner or later you do run into comments that need about as much work as an entry. Sometimes those can be turned into actual entries (I do this a fair bit, although that's partly an interface issue), but not always; sooner or later you'll get comments that need replies that are too specialized or not interesting enough to make decent entries.

(This also ignores the time required to moderate comments, getting rid of spam and other undesirable things. Depending on the nature of your blog, this may be a significant time sink itself.)

SSL does not create trust

One of the stories that people tell about SSL on the web is that proper, valid SSL certificates create trust (and thus do all sorts of good things, like facilitating Internet commerce). This is, how shall I say it, not actually true.

Here's how SSL certificates fail to create trust:

• simply having an SSL certificate doesn't mean you're especially trustworthy, because anyone can get an SSL certificate.

• you might be able to trust an identity that's guaranteed by SSL, except SSL's idea of an identity is wrong for the Internet.

  (And even given that, certificate authorities have been fooled at least once for a high visibility case, and an unknown number of times for less visible people.)

• SSL solves the wrong problem. As lots of events demonstrate, the vulnerable point is not the network or a sophisticated man in the middle attack; the vulnerable point, and the most valuable place to compromise, is the web server itself. And a web server having an SSL certificate says nothing about how secure it is.

  (The other valuable thing to compromise is the person sitting in front of the computer; hence phishing attacks.)

• finally, and hugely, SSL creates no trust because it creates no legal basis for trust for anyone. There are no contracts with terms, no duty, no guarantees, no liability, no nothing. You pay some money and you get some magic bits, and that is it. No one is on the hook if something goes wrong.

Trust is created by people having a motivation to act in your interest. One of the ways that this can happen is that you pay them; another is that they pay you if something goes wrong (ie, liability). SSL involves neither, and as a result the presence of an SSL certificate means nothing more than that someone got an SSL certificate.

(Yes, trust can be created by reputation, but since anyone can get SSL certificates having a valid one says nothing about your reputation.)

Another way to look at this is to ask if there is anything that you can rely on, either practically or legally, if you see a proper SSL certificate. The answer is clearly no, for the reasons above; you have no legal reliance at all, you have no real assurance of who the website is, and you have no idea if the website is (still) secure even if they are a trustworthy business.

The conclusion is inescapable: in both practical and legal terms, SSL creates no trust at all. Any 'trust' it creates is both misplaced and entirely in the minds of users.

(It is hopefully obvious why misleading users about security issues is a very bad idea.)

(None of this is original to me, but I feel like writing it down in one place that I can point to. See here and the link in the comment here for some sources I learned from.)

One reason that it is so hard to challenge Google

Chris Linfoot has been reacting to Cuil, and in the process he shows one somewhat unexpected reason that it is so hard for a new search engine to challenge Google today. Not only do you have to build the necessary software and infrastructure, but it is crucial that your web spider be completely, utterly well behaved.

If your spider is not completely well behaved, people will notice, talk about it, and then block you. This results in you having less data to build your search results on and likely worsen the quality of those results, which is a killer; if you cannot produce search results at least as good as Google, no one is going to be very interested in you.

(That the sort of people who notice badly behaved spiders are the sort of technical people who might otherwise be your early adopters probably doesn't help, either. I know that I was predisposed against Cuil because of this issue.)

Now, I'd certainly hope that anyone who aspires to challenge Google can write a well behaved spider (and I'm not particularly sad that having one is a strong requirement). But bugs can and do happen, including in spiders, and this issue basically means that you need to have your spider more or less perfect all the time (or at least all the time that you are letting it crawl the net). I hope that you have a lot of internal tests for it, because you are going to need them.

To add to your challenges, I rather suspect that people don't often go back to reconsider robots.txt entries; once you're in, you're staying in unless something major happens. So a transient spider issue that you fixed in a week may have lingering effects for years (especially if 'block spider <X>, it is badly behaved' becomes a bit of folklore).

(Renaming your spider won't help, because then people will start jumping to the conclusion that you're trying to get around their robots.txt blocks, which is going to worsen your reputation all that much faster.)

As a side note: it is hopefully obvious that it doesn't matter if Google's web spider is sometimes badly behaved, because people will cut Google slack that they will not cut anyone else as a natural consequence of Google's current dominance.