Contents: HTML validity HTML issues File signatures Https Footer

What's this?

(Validity and authenticity of files on this site)

What's HTML validity?

Each page on this site should have a link to the World Wide Web Consortium's HTML validation service. This makes it easier for me to write valid HTML, and if I get it wrong, it might make it easier for you to tell me what the problem is if my invalid page doesn't display correctly in your browser. Conversely, if my valid page doesn't display correctly in your browser, then either I've misused the standard (in which case you can complain loudly at me), or else your browser doesn't implement the standard (in which case you can complain loudly at whoever wrote your browser).

Invalid HTML is difficult to deal with, because if it displays badly, then it's not always clear whether that's my fault for writing the code that way, or your browser's fault for not compensating for my ineptitude. Sticking to standards helps to avoid this kind of ambiguous problem, and means that I can expect that as long as I've understood the standard, my pages will work in your standards-compliant browser.

Known compatibility issues

I'm aware of the following issues with the HTML and CSS on this site:

  • Internet Explorer doesn't support the :before or :after pseudo-elements from CSS2. As a result, the footer of each page doesn't look as good in IE as in a more up-to-date browser. Personally, I recommend you get Firefox, but it's your call.
  • Latest News: I've figured out a hack that will ensure that the footers work either in both CSS1 and CSS2 browsers. It could go wrong if some browser is a halfway house between the two, specifically if it supports either :before or > direct-parent specifiers, but not both.

What are file signatures?

Pages (and some other files) on this site are signed with my PGP Key. You can get an up-to-date version of my key from a public keyserver (such as that operated from MIT).

You can learn more about PGP and public key cryptography from The GNU Privacy Handbook, or from many other sources. For the purposes of this site, there are three benefits:

  1. You can check for yourself using any PGP software package that the information on this site really was signed by the key linked to above. Once you know that, and if you also know that this key really is my key, then you know that what you're reading is what I intended you to see. In other words, you know that the pages weren't forged by someone else pretending to be me.
  2. I can't deny at a later date that I really wrote the message, at least not without claiming that the system doesn't work. It's debateable whether this is really a benefit, since sometimes it's useful to be able to "have no recollection" of what has been said. But that's my risk, not yours. This fact and the one above mean that digital signatures work the same way as real signatures.
  3. You can use PGP software to encrypt a message using the key linked to above. Once you've done that, and if you also know that this key really is my key, then you know that only I can read the message. If you also sign the message, then I can send an encrypted response back to you. In other words, nobody can eavesdrop on our conversations.

If you wish to take advantage of these facts, then your big question is "how do I know that the key linked to above really is yours?". Just because it's on my site doesn't necessarily mean I put it there - for example my web hosts might have abused their administrator privileges to create another key in my name and replace my key with that false one. Your ISP might be doing the same thing by altering what you see. Or there might be someone else interfering. But my web hosts don't have the secret part of my key, and neither does your ISP, and in fact hopefully neither does anyone else in the world, so if you're sure of my key then we're good to go.

The simplest way to be sure of my key is that if you know me personally, you can ask me what the fingerprint of my key is. You do this in a way which means that nobody could possibly imitate me, such as a face-to-face meeting. Then you can compare that fingerprint with the fingerprint of the key which signs these pages. If they don't match, then you should be suspicious as to why. If they do match, then either I really did sign the pages, or else my private key has been compromised. There's no other possibility, at least none that any expert in cryptology is willing to tell us about.

So, if all goes according to plan, we can communicate securely. But certain things might cause my key to become compromised, meaning that somebody else has found a way to use my key in the same way that I do, so that they can impersonate me or decrypt messages intended for me. Here are all the ways that this can happen - communication using my public key is secure if none of these has happened:

  1. The algorithms used aren't secure, or there's a mistake in the code one of us is using. Personally I'm willing to take that chance. If you think differently then you can't benefit from this system. Latest News: SHA-1, one of the algorithms used in the signing process, has been found to be somewhat less safe than its theoretical maximum. Jon Callas, who knows a bit about PGP, has said that "It's time to walk, but not run, to the fire exits". So I'm not terribly worried, but I'll switch to a better hashing alogirithm once one is integrated into my PGP software. If you're verifying signatures which use SHA-1, and the date is a lot of years since 2005, then you should bear in mind that technology may have moved on to the point where it is possible, within certain constraints, to fake a signature.
  2. The code that one of us is using is deliberately malicious. In the case of the code at my end, then I think that's very unlikely. The source code is subject to widespread public scrutiny, and I made a reasonable effort when I downloaded it to ensure that I was getting the real thing. Someone with access to my PC might be able to replace my software with a malicious version. The code at your end is your responsibility.
  3. Someone has found out my private key. This is the most likely problem, but still pretty unlikely. They'd have to get access to my PC (or to a copy that I'd chosen to store elsewhere). If they can run code on my PC (like a virus, say), then they might be able to get at the private key directly. Otherwise, the private key is itself always stored encrypted, so they'd also have to find out or guess the passphrase used to encrypt it. This should be quite difficult, unless they use covert surveillance to watch me type it in, or else they torture, threaten or bribe me to reveal it to them. In the UK, the Home Office can do this legally (well, they probably can't torture me legally, but they can threaten me with prosecution and imprisonment).

In summary, the two weakest points are that I might be forced to reveal my private key, and that the physical or network security of my PC might be breached in order to find it out. But if you send me a message, then that message could of course be directly obtained by either of these means. So the encryption system is probably "good enough" for most purposes, and in particular it's good enough to deal with the fact that both web pages and e-mail are completely open to being eavesdropped, intercepted and modified by anyone with access to the channel of communication.

Isn't all this standards-compliance and cryptography incredibly pedantic?

Yes. But they don't cost me much effort, they don't cost you any effort at all if you don't want them to, they're things that I think are worth knowing, and they might come in handy some day.

Why don't you just use https for authentication of your web pages?

Because I don't want to spend money on a CA certificate, I don't want to encourage people to knock massive holes in their security model by forcing them to accept an untrusted certificate, and certificates are even harder to distribute out-of-channel than PGP keys. Plus I'm keen to encourage myself and others to use PGP, because it's a good way to get a fairly sophisticated understanding of various security concepts.

If my site ever deals with confidential data then https is probably the only viable solution, but for authentication alone it isn't worth the hassle.