Musings

A few more blog-related notes.

1. Srijith has discovered a minor security flaw in MovableType’s handling of email notifications.

   Update 3/27/2004: At Ben Trott’s request, Srijith has pulled the details of the flaw from his web site (apparently, Ben claims never to have received Srijith’s vulnerability report). Reluctantly, I’ve decided to follow suit here at Musings. Supposedly, the fix is in MT 3.0. If that (or a standalone patch) is released in a timely fashion, I’ll be happy about my decision. Otherwise, I may have to revisit it…

   Update 3/27/2004: Oh, to heck with it! We’re not going to have another Comment-Throttling fiasco. “All will be well when MT 3.0 comes out.” is not a viable Security Policy. The exploit is out there, and MT users need to know about it in order to protect themselves.

   In brief, if a spammer (or other miscreant) leaves a comment of the form

   Innocent comment here.
   .
   Spam links here.

   (that’s a single period on a line by itself) only the upper part will be sent in the notification email(s), while the full comment will be posted to your blog. If you are using Sendmail, you should patch your MT installation.

   --- lib/MT/Mail.pm.orig Wed Mar 24 19:55:40 2004
   +++ lib/MT/Mail.pm      Wed Mar 24 19:58:06 2004
   @@ -85,7 +85,7 @@
        local $SIG{ALRM} = sub { CORE::exit() };
        return unless defined $pid;
        if (!$pid) {
   -        exec $sm_loc, "-t" or
   +        exec $sm_loc, "-oi", "-t" or
                return $class->error(MT->translate(
                    "Exec of sendmail failed: [_1]", "$!" ));
        }

2. My previous entry, as promised, uses SVG for figures. I’m curious as to how this works for various classes of users

   • Users with SVG-native builds of Mozilla
   • Users with the Adobe Plugin
   • Users with no SVG support in their browser (should fall back to a GIF image)

   Personally, I’m using the Adobe Plugin, and I find that scrolling past an SVG image, in Mozilla, is painfully slow. Safari doesn’t have this problem.

3. My Atom feed is now “official.” My RSS 0.91 feed is deprecated (though not dropped … yet).

4. Speaking of feeds and SVG figures, NetNewsWire is a little overzealous in dealing with the SVG figures in my full-content feeds (RSS 2.0 and Atom). I can see an Aggregator not wanting to deal with sorting out “good” <object> elements from “bad” ones, and instead just ignoring all <object> tags. But, just because you do that, why ignore the content of the <object> element? The content, in this case, is a GIF image, which is the fallback for those who can’t — or don’t wish to — deal with the SVG. NetNewsWire is perfectly happy displaying GIF images, but it doesn’t in this case, because the <img> element is ignored.

   I suppose I could strip out the <object> tags from my feed. But I don’t want to. Those whose client software (like NetNewsWire, ironically) is capable of handling an SVG figure ought to receive one.

Corrections to quartic Higgs self-coupling from stop and top loops.

We all learned on our grandfather’s knee that supersymmetry required a light Higgs. Back then, this was a cheering thought, for it meant that we would not have to wait too long for the Higgs to be discovered. The years passed, and the experimental lower bound on the mass of the Higgs crept slowly upwards. We now know that it must be heavier than 114 GeV or so.

Scott Thomas was in town the other week, and gave a very nice colloquium, explaining how serious the situation has become for the MSSM.

At tree level, $$m_h \lt m_Z \cos(2\beta)$$ where $\tan(\beta)= \langle H\rangle/\langle\tilde{H}\rangle$, and $H$ & $\tilde{H}$ give masses, respectively, to the up and down type quarks. The inequality becomes an equality in the limit that the mass of one of the other neutral scalars in the Higgs sector, $m_A\to\infty$.

With $m_Z = 91$ GeV, and $m_h\gt 114$ GeV, this bound is clearly violated. Fortunately, the one-loop corrections to the quartic self-coupling, depicted above tend to push this number up. $$m_h^2 = m_Z^2 \cos^2(2\beta)+\frac{6|\lambda_t|^2 m_t^2}{4\pi^2}\log(m_{\tilde{t}}/m_t)$$ Note that the supersymmetric cancellation between the two diagrams means that the result depends only logarithmically on the stop mass. To fit the current lower bound on $m_h$, the stop must be heavy $$m_{\tilde{t}} \gt 850\, \text{GeV}$$ And each time we push up the lower bound on the Higgs mass, the lower bound on the stop mass goes up exponentially.

Corrections to the quadratic Higgs self-coupling dominated by stop loops.

While the corrections to the quartic terms in the Higgs potential depend only logarithmically on the stop mass, the corrections to the quadratic terms are proportional to $m_{\tilde{t}}^2$. $$m^2 \sim |\mu|^2 - \frac{3 |\lambda_t|^2 m_{\tilde{t}}^2}{8\pi^2} \log (m_{\tilde{t}}/M)$$ where $M$ is a messenger mass, at which the loop-momentum integral is effectively cut off. (It’s precisely these radiative corrections that drive this term negative, and lead to the electroweak symmetry-breaking.)

To end up with an electroweak symmetry-breaking scale around $(100\, \text{GeV})^2$, one needs the $\mu$ parameter (the coefficient of $H\tilde{H}$ in the superpotential) to be in the TeV range, and its value must be tuned to within a few percent.

Personally, I can live with a fine-tuning in the 1% range. But you would not have to push the Higgs mass up too much further to make even me nervous.

Six Apart have announced their TypeKey service, a centralized Commenter Registration service. Commenters can register with TypeKey, and then sign in once to comment on any MovableType 3.0 blog.

I haven’t seen the details yet, but from what they’ve described, I am not too sanguine about the service. As I read it, there are three motivations for this sort of centralized Registration service.

Spam prevention

This sort of presumes that spammers will be too dumb to register their spambots with the service. Once the spambot is registered and signed-on with TypeKey, I expect it would function pretty much as before.

On the other hand, centralized registration does allow for centralized banning. If word gets back to the TypeKey administrators, they can disable the spammer’s Identity.

But what’s to prevent the spammer from registering hundred, or thousands of Identities for his spambot? The Slashdot trolls have pioneered “registration 'bots”, which register hundreds of throwaway Identities. What’s to prevent spammers from doing the same with TypeKey?

Troll Management

Individual blog owners can ban individual TypeKey Identities from commenting on their blogs. Not much of an impediment, if the troll can easily register another Identity.

Cracking down on trolls is a tricky business, and there are some very clever techniques for dealing with them. Merely forcing them to register isn’t enough.

Identity Theft

Can there be two Identities with the same website URL, but different email addresses? Surely there can. Can a registered user hide his email address on his Profile Page? You bet! No one wants to give the email spammers yet another opportunity to harvest your email address.

Well, then, there’s nothing to prevent me from registering with TypeKey in your name, with your Website URL and your biographical details, but with my (hidden) email address. Now I can sign into TypeKey and go around impersonating you at various blogs. The only non-fakeable detail in my TypeKey Profile — my throwaway Hotmail email address — is hideable. So it’s not really possible to establish my “identity”, based on what is revealed on that Profile.

Presumably, TypeKey won’t let two of us register with the same Username. “JohnSmith37” might be out of luck, but, if you go by a less-common name, you can, to some extent, protect yourself by making sure you’ve registered your favourite nom de plume before I get there. It won’t prevent me from registering a slight variant, with your biographical details, but it’s better than nothing. For purely defensive reasons, this should create a mass stampede to register with TypeKey, as soon as it opens for business.

As you know¹, I’ve had my own thoughts about Comment authentication, so perhaps I’m biased. But unreliable authentication can be worse than no authentication at all. It creates a false sense of assurance where there should be none.

Obviously, TypeKey does nothing to make any of these issues worse than before. But it does increase the hassle-factor: commenters must register, and must sign-in to use the service. So one really hopes that TypeKey would actually improve matters with respect to one or more of these problems. Doubtless, I’m missing something, and someone will correct me. But, from what I’ve seen, TypeKey seems to be a lot of bother, for not a lot of benefit.

Again, let me emphasize that I haven’t seen any of the implementation details. This post is based purely on the TypeKey Announcement. Still, I find the whole thing troubling enough to want to start the discussion now, before the official roll-out.

Update (3/23/2003): There’s now a TypeKey FAQ. It addresses some of the questions raised here and elsewhere. The clear focus is on TypeKey as an anti-spam device. By itself, it would be pretty useless. But they argue that, in conjunction with Comment Moderation (another new feature of MT 3.0), it could be rather effective. TypeKey-registered users, who’ve posted comments to your blog before could have their comments immediately posted. Everyone else (including the spammers) would have their comments relegated to a moderation queue. Depending on how you feel about Comment Moderation — more work for the blog owner, interrupts the flow of the conversation — that certainly could be effective. If most of your comments come from the same familiar set of people, TypeKey would allow you to turn on Comment Moderation with minimal disruption.

For myself, I view comment spam as a more-or-less solved problem (I,II,III), and I don’t anticipate turning on Comment Moderation to deal with it. Still, giving blog-owners a sense (even if partly illusory) of control over their comment section is a smart move by Six Apart.

Update (3/25/2003): Phil Ringnalda has also come to the conclusion that TypeKey could be useful in conjunction with Comment Moderation, as a way to whitelist “known” commenters. But, on reflection, I’m now of the opinion that PGP-signed comments provide a much better mechanism for whitelisting known commenters.

Urs Schreiber asked me to explain what “count[ing] the points on the Calabi-Yau, defined over the finite field $F_{p^k}$” means. I started to respond with a comment, but realized this might work better as a full-fledged post.

Consider the equation

Algebraic geometry is the study of the geometry of the space of solutions to algebraic equations such as this one. We might be interested in the affine variety, where $(x_1,x_2,x_3,x_4,x_5)\in \mathbb{C}^5$. Alternatively, we might take the $(x_1,x_2,x_3,x_4,x_5)\neq(0,0,0,0,0)$, and identify points $(x_1,x_2,x_3,x_4,x_5)\sim (\lambda x_1,\lambda x_2,\lambda x_3,\lambda x_4,\lambda x_5)$, $\forall \lambda\in \mathbb{C}^*$, a nonzero complex number. This yields the projective variety, the quintic hypersurface in $\mathbb{C}P^4$. This latter is a Calabi-Yau manifold, which makes it rather interesting for physicists.

Algebraic geometry is a hard subject. It’s hard because algebraic geometers don’t want to restrict themselves to the space (affine or projective) of solutions over the complexes. They’d like to study the space of solutions over arbitrary fields. So they need to set up the tools of geometry to work even when the equations are defined, say over a finite field.

One such field is $F_p$. Here, $p$ is a prime, and we do arithmetic over the integers modulo $p$. In $F_7$, $5=-2$ and $5 =1/3$ (since $5+2 = 0$ mod $7$ and $5 \times 3 =1$ mod $7$. Since $p$ is a prime, every nonzero integer in $\mathbb{Z}/p\mathbb{Z}$ is invertible modulo $p$.

A field is said to have characteristic-$k$ if adding the multiplicative identity element, $1$, to itself $k$ times gives the additive identity element, $0$. If you never get the additive identity element, the field is said to have characteristic-0. $\mathbb{Q}$, $\mathbb{R}$ and $\mathbb{C}$ are fields of characteristic-0. $F_p$ is a field of characteristic-$p$, with $p$ elements.

How about some more fields of characteristic $p$? Pick a polynomial $P(x)$ of degree $n$, with coefficient in $F_p$, which is is irreducible (i.e., which cannot be factored into lower-degree polynomials with coefficients in $F_p$). Define

the ring of polynomials (with coefficients in $F_p$), modulo the ideal generated by our chosen $P(x)$. Each equivalence class of polynomials has a representative of degree less than $n$. Moreover, since $P(x)$ was irreducible, each polynomial has a multiplicative inverse. So $F_{p^n}$ is a field of characteristic-$p$, with $p^n$ elements.

Exercise: Construct $F_{3^2}$, using the polynomial $x^2+1$, which is irreducible in $F_3$. Write out the 9 linear polynomials representing $F_3[x]/(x^2+1)$ and construct their multiplication table.

Now think about redoing everything you know about geometry (cohomology, vector bundles, sheaves, …) in characteristic-$p$. Number Theorists are typically interested in things like counting the number of solutions to equations like the quintic above, and avail themselves of the powerful tools of algebraic geometry to do it.

Whew!

OK, back to the quintic, defined with coefficients in $F_p$ (or $F_{p^n}$). Since the field is finite, so must the number of solutions of the quintic equation, in $F_p$. We can consider $\nu(\psi)$, the number of solutions to the affine equation, or $N(\psi)$, the number of solutions to the projective equation. They are simply related:

(we remove the origin and mod out by rescalings by nonzero elements of $F_p$), but Candelas and company prefer to write formulæ for $\nu(\psi)$, rather than for $N(\psi)$.

Now, here’s where the magic comes in. The periods of the holomorphic 3-form on the quintic Calabi-Yau, integrated over some basis of 3-cycles satisfy a Picard-Fuchs equation,

in the variable $\lambda=1/(5\psi)^5$. The independent solutions can be written as

where the $f_j(\lambda)$ are certain power series in $\lambda$.

Let $f^{(n)}_j$ be the power series truncated to the first $n+1$ terms.

Candelas et al can write down an exact expression for $\nu(\psi)$ in terms of the $f^{(n)}_j$. The full formula is a little complicated, but the first approximation to it is easy to state:

where $[p/5]$ is the integer part of $p/5$.

Of course, there’s nothing special about the quintic. They can do similar things for more complicated Calabi-Yau’s, and they can also get results over the fields $F_{p^n}$.

All of this is bound up in some mysterious way with Mirror Symmetry.

I don’t know what it all means, and neither do they, but their papers (I,II) make very intriguing reading.

Some random computer notes.

1. Installing Crypt::OpenPGP under MacOSX is a real bear. The basic steps are as follows.
   1. Install libpari.
   2. Install Math::Pari.
   3. Use CPAN to install Crypt::OpenPGP and all of its prerequisites.
   There’s a page on installing Math::Pari on MacOSX which will guide you through steps 1,2. Unfortunately, it badly needs to be updated for Pather, but it ought to give you the general idea. Once you’ve got Math::Pari installed, the rest is fairly easy. Just used CPAN to install Crypt::OpenPGP. It will prompt you to install all of the prerequisite modules first. There are a zillion of them. Many are required, but some are optional. All of the optional modules will compile except Crypt::IDEA. When it asks you whether to install a list of optional module which includes Crypt::IDEA, answer “no”. You’ll get asked again, later on, about the other optional module, but you don’t want it to even attempt to install Crypt::IDEA. After quite a bit of churning away, you should finally have a working copy of Crypt::OpenPGP.

2. I have an experimental Atom feed for this blog. It contains both a <summary type="text/plain"> and a <content type="application/xhtml+xml" mode="escaped"> element. The latter means, theoretically, that if there were a client which supported it, people could read my MathML-enabled posts in their Aggregator. This sounds far-fetched, but it really isn’t. Dave Hyatt has, at least, talked about the possibility of MathML support in Safari. If he and his team ever deliver on that, NetNewsWire users will get MathML support “for free.”

   My feed validates, but I would still like some feedback from real Atom mavens as to what I might be doing wrong and what could be improved.

   For instance, I think I am using the xml:base attribute incorrectly:

   <content type="application/xhtml+xml" mode="escaped" xml:lang="en" xml:base="<$MTBlogURL encode_xml="1"$>">

   That’s taken straight from the default MovableType Atom Template. Shouldn’t it be xml:base="<$MTEntryLink$>"?

   Unfortunately, NetNewsWire doesn’t seem to support xml:base at all, which makes it difficult to test my assumption in practice.

   (Update: Oh, to heck with it! The MT template is plainly wrong, and I shouldn’t need NetNewsWire to figure that out. Fixed.)

   If I decide to keep the new Atom feed, who would object if I were to drop the RSS 0.91 feed, and replace it with this one?

3. Speaking of validating feeds. Mark and Sam’s Validator has long complained about the onclick and onkeypress attributes which occur in certain anchor tags in my full-content RSS feed. These are not, strictly speaking, invalid (how could they be?), but they are flagged as examples of poor sportsmanship, anyway, much to my chagrin.

   I finally realized that I could use the tagmogrify plugin to strip these attributes out my feeds, and now the Feed Validator no longer complains.

4. Oh, yeah, OpenSSH 3.8p1 is out. Gotta keep up with the Joneses.

There’s a conference going on here at UT on Number Theory and Physics. Victor Batyrev, Philip Candelas, Daqing Wan and Dave Morrison are giving a series of lectures on the connections between Calabi-Yau Manifolds, Mirror Symmetry and Number Theory.

I’m sitting in Dave’s talk right now, and he’s patiently explaining Gauged Linear $\sigma$-Models to the mathematicians. Years ago, he probably would have said, “and now we take the symplectic reduction” ( or, more likely, “and now we take the GIT quotient”). Instead, he’s appealing to Lagrangian mechanics: minimizing the scalar potential, modding out by gauge transformations — the usual physicists’ way of thinking these about these things. Earlier in the day, Candelas responded to the question, “Why are we computing the periods of the holomorphic 3-form on a Calabi-Yau?” with, “Well, we want to be able to count the points on the Calabi-Yau, defined over the finite field $F_{p^k}$.”

Role reversal?

Seriously, though, the connections with Number Theory seem to be indicative of something very deep. I have this forlorn hope that if I sit through the lectures, some glimmer of understanding will emerge.

Later in the week, I’ll probably duck down to College Station to catch a bit of the Cosmology and Strings conference at Texas A&M.

I couldn’t stand the trailing

[OpenPGP Signature]

on PGP-signed comments any longer. Visually, it looked bad. And it was a markup-eyesore too, glommed onto the end of the Comment-Body, with just a few <br />s to set it off from the text of the comment.

So I fixed the CGI code to do it right. Much less visually jarring, and perfectly semantic XHTML. (OK, … 5 points off for using the phrase “semantic XHTML”; really, I’m not that sort of guy.)

I am also less than happy with the CGI code which generates the comment verification. It spits out perfectly acceptable XHTML; I’d just prefer the markup to be controlled by the templates, rather than by the CGI code. Much more flexible. If I get the energy, I’ll fix that too, and send my changes on to Srijith.

Update (3/30/2004): OpenPGPComment 1.5 incorporates this fix.

[Via Sean Carroll] Yet another stunning indictment of NASA’s decision to cancel further servicing of the Hubble Space Telescope (can’t let actual science stand in the way of a manned mission to Mars, now can we?).

The Hubble Ultra Deep-Field survey of the oldest and most distant galaxies ever seen.

I haven’t talked about the $a$-maximization proposal of Intriligator and Wecht, nor the interesting followup papers (I, II) by Kutasov and collaborators. But the recent paper by Csaki et al reminded me.

We know know that there is a wealth of interacting 4D $N=1$ superconformal field theories arising as the strongly-coupled fixed point of supersymmetric gauge theories with various matter content. We can’t say much about the physics of such theories, but one thing we ought to be able to calculate is the spectrum of chiral primaries in the theory, superconformal primary fields, $\mathcal{O}$, which saturate the bound

where $R$ is the charge under the $U(1)_R\in SU(2,2|1)$ superconformal symmetry. The difficult part is simply identifying which $U(1)_R$ symmetry of the microscopic theory becomes the R-charge of the superconformal algebra in the IR. In general, there can be a number of nonanomalous global $U(1)$ symmetries, and the desired R-charge is some linear combination

of a valid $U(1)$ R-charge, and the other global $U(1)$ symmetries of the theory. In general, there might be a further complication that the IR fixed point might have additional, “accidental” $U(1)$ symmetries. For instance, if some chiral field $X$ becomes free, and decouples from the rest of the SCFT (more generally, if the IR SCFT breaks up into decoupled sectors), then there is an accidental $U(1)_X$ symmetry, and the “true” R-charge of the SCFT may contain some admixture of $Q_X$.

In a conformal field theory, the $\beta$-function vanishes, and the trace anomaly in a curved background is given by $$\tensor{T}{_^\mu_\mu} = \frac{1}{120 (4\pi)^2} (c W^2 -\frac{a}{4} e)$$ where $W$ is the Weyl tensor,

and $e$ is the Euler density,

The trace-anomaly coefficients, $a,c$, are given by 't Hooft anomaly matching

Cardy conjectured that $a$ decreases along RG flows, $a_{\text{IR}}\lt a_{\text{UV}}$, and is non-negative in unitary four dimensional conformal field theories.

What Intriligator and Wecht showed was that the correct choice of $R$ could be determined by maximizing $a$,

Heuristically, this “explains” why $a_{\text{IR}}\lt a_{\text{UV}}$. A relevant perturbation typically breaks some of the global symmetries and so $a_{\text{IR}}$ is obtained by maximizing only within a subspace of the original parameter space in which one maximized $a_{\text{UV}}$. In any case, $a$-maximization allows one to determine $R$, and hence the spectrum of conformal weights of the chiral primaries.

Csaki et al study $SU(N)$ gauge theory with a 2-index antisymmetric tensor, $F$ fundamentals, and $N+F-4$ anti-fundamentals, as a function of $x=N/F$. Starting in the large-$N,F$ limit, the theory has a Banks-Zaks fixed point near $x\sim .5$. As one increases $x$, the theory remains in a nonabelian Coulomb (SCFT) phase. At some critical value of $x$, the meson $M=\overline{Q}Q$ becomes free and decouples. At a yet-higher value of $x$, $H=\overline{Q} A \overline{Q}$ become free and decouples. When $H$ decouples, the electric description ceases to be effective. For $F\geq 5$, one can use a series of Seiberg dualities to rewrite the theory as an $SU(F-3)\times Sp(2F-8)$ magnetic gauge theory with a superpotential. The $Sp(2F-8)$ is IR-free, whereas the $SU(F-3)$ is in a nonabelian Coulomb phase.

Quite an intricate story, really. And a real testament to how much progress we’ve made in understanding SUSY gauge theories in the past decade.

Since publicly proposing the idea a week and a half ago, I’ve noticed an increasing number of personal websites sporting

<link rel="pgpkey" type="application/pgp-keys" href="..." />

links to the owner’s PGP Public Key.

No, I don’t go around viewing the source of every weblog I visit. These links appear in the “More” menu of the Site Navigation Bar in Mozilla.

I’m really pleased to see this being rapidly adopted. But there are a couple of things that site owners can do to make it even more useful.

1. Give the <link> a title attribute, saying whose key it is (mine says “title="Jacques Distler's PGP Public Key"”). If you have a multi-author blog, put up a separate <link> for each author’s Public Key, and identify each one with a title attribute.
2. Make sure the key file(s) are served up as application/pgp-keys. Surfers who configure a Helper App in their browser for that MIME type can then add the Public Key to their Keychain with a single click.

I know I’m slow on the uptake, but Sean Carroll has a blog. I’ve added it to my BlogRoll. But you’ll note that, despite it having an Atom Feed, I haven’t syndicated it. mt-rssfeed doesn’t support Atom feeds yet, and Blogger, apparently, does some really funky stuff with the <summary> element of their Atom feeds.

I thought I’d write some more notes on the recent implementation of PGP-signed comments on this blog, which will appear in the next release (version 1.4) of the OpenPGPComment plugin for MovableType.

In my previous entry, I made the obvious point that commenters would like to avoid “identity theft,” and that PGP-signed comments provide protection against that. More broadly, from the point of view of having serious scientific discussions — as occasionally appear here or on the String Coffee Table — you do want some assurance that the person who left a comment really is who they said they are. In the end, we really do care who said what in the discussion.

The anonymous nature of the internet makes the problem of “identity” a hard one. In physics, when we encounter an intractably-hard problem, our most frequent dodge is to redefine the problem to one which admits a solution, and hope that the result is a “good-enough” stand-in for the original problem. In that spirit, I (re)defined the problem as reliably associating comments posted with the websites of the commenters.

For commenters who have an email address, but no web page, I don’t really have a solution, other than to fall back on the traditional PGP Web-of-Trust, which is designed to establish the connection between a signed message, an email address, and an actual person.

To associate a comment with the owner of a website, however, we have a relatively simple strategy. The owner of the website puts a

<link rel="pgpkey" type="application/pgp-keys" href="http://yoursite.com/path/to/yourkey.asc" />

on his homepage. When he posts a PGP-signed comment, and leaves the URL of his homepage, we can use the <link> on his homepage to find the keyfile containing his public key. The key is then stored on the keyring locally, for subsequent verifications of his comment(s). We allow multiple <link rel="pgpkey">’s on a page. So if you have a group blog (say), each author can have his own keyfile. Also, the key isn’t fetched when the comment is posted, but rather when the comment is first verified. You might want to get into the habit of checking the signature on your own comments after posting them. The first time you do that, your key will be downloaded and stored locally.

You’ll note, also, that when you click on a link to verify a comment, we display, not only the verification status and the “UID” information (usually, an email address), but also the URL of the homepage from which it was fetched.

Why?

Imagine we displayed only the UID (email address) associated to the key. Consider the following attack. Bob Evil has a website, nasty.net. Bob creates a public key in the name of Mary Goode, and put a <link rel="pgpkey"> pointing to it on his website. Mary has her own site, nice.com, and is unaware of Bob’s nefarious plans. Bob posts a comment here, in Mary’s name, leaving nasty.net as the URL. Say, on this first comment, we don’t notice the discrepancy (Mary has nothing to do with nasty.net). Having gotten his bogus key onto the keying, Bob can now return and post comments in Mary’s name, leaving nice.com as the URL. The comments will now verify as “Mary’s” (and display her UID) which is definitely bad for her.

The flaw was that we are really trying to verify the comment author’s website, whereas her PGP key is, typically, tied to her email address. The solution is to display the URL of the homepage (nasty.net) from which the key was originally fetched. Now Bob can never fool us into thinking his comments come from the owner of nice.com.

In terms of implementation, the public keys of commenters are stored in a standard GnuPG keyring (not your personal Public-keyring; this one has to be writable by the web-server!). We maintain a separate database of key-id/URL pairs. There’s a bit of a management issue, keeping those two synchronized. We’ll have to write some tools to address that, eventually.

Finally, I want to re-emphasize the importance of making this whole thing easy and transparent for the readers. If verifying PGP-signed comments is tedious, then readers won’t actually do it. In that situation, sporting the little comment-verification link is actually counter-productive. Readers will get into the habit of simply assuming that, if a comment is PGP-signed, it must be genuine. That’s worse than not having signed comments at all. An attacker can attach any-old PGP signature to his forged comment and readers, who might otherwise have been skeptical, will assume it to be genuine.

So start signing your own comments, and get into the habit of verifying the signatures on the comments of others.