The point of signing the articles is so that either the end users, or “independent online repositories” can store articles and/or signatures and still prove later that it is the original author’s work. Also, the signature clearly marks beginning and ending content, which facilitates external verification.

As an author, my goal is to create content that is easily verifiable should anyone wish to archive it. I figure, if small bloggers can be responsible publishers, perhaps someday larger media sources will pick up the same habits.

Thank you all for your insightful comments!

I think what is needed is for a external “librarian” to date, sign and take a copy of your article. Then in your publication, you’d show that timestamp, verify the librarian’s signature, and you can show the diffs from previous authenticated copies of the same content. The librarian would be someone you can trust, verifiably, such as the library of a university, or a city public library. But still you need to store multiple copies of the content, or devise some other protocol in which you store only diffs, in such a way that you can reconstruct the original source.

The remaining problem will be how to identify that a story a librarian signs is not new, and is in fact linked to previous signed versions of the same copy (the home of the story can change locations during the life of the content, such as initially appearing on page 1, but then revised and moved to page 2, etc or initially appearing at /2009/01/19/, then at /2009/02/10, etc.)

I thoroughly enjoy your blog, thank you!

The current SSL infrastructure is most appropriate here. We already have a list of certificate authorities in our browsers that begin the chain of trust. ISPs can do whatever they want with an encrypted channel, but any modification or attempted eavesdropping will be worthless or detectable short of a complete overhaul of the system designed to grant ISPs eavesdropping powers. If my web servers certificate is falsified by your ISP, it simply will not work. The false certificate will not correlate with my web server’s private key, nor will the false certificate be properly trusted by a root authority, causing your web browser to spit out errors about an invalid certificate. I will not go deeply into man-in-the-middle attacks here, however rest assured that SSL/TLS have been designed with them in mind.

So in short, if you want verifiable content that cannot be modified in transit just force SSL across your entire website. This is not a common practice because of the additional server load, but it accomplishes exactly what you want without any new research or infrastructure required.

It is possible you would NEVER be able to see the true certificate for a site/user, as it could always be replaced – at least through any official channels. And if you find a certificate for “philosecurity.org” on some random other website, you still have the trust issue: Is this a real certificate, was it replaced by the ISP’s filter, or is someone trying to spread their own faked certificate? More likely, you’d never even suspect something was up, since the certificate you get is the one you’ve always gotten (even though it is an illegitimate certificate).

You’d need something that doesn’t go through your ISP in order to verify the source. On the paranoid side, EVERYTHING could be compromised – every VPN tunnel, SSL connection you make could be the victim of a man-in-the-middle attack, unless you’ve got a certificate that you can fully trust.

Realistically, this is probably not going to happen, and there will likely always be ways around the ISP, to get past their filtering (VPNs being the big one).

However, for the majority of users, if their browser tells them the PGP signature matches, then they’d never bother to check into it further. In short, they’d have a faked PGP certificate and never realize it. It is totally within the realm of a large government content filter to do this attack (or just filter out all the PGP stuff entirely), and quite likely, if it ever became very popular.

Of course git’s hash algorithm isn’t crypto-quality (nothing is?), it’s just good enough to differentiate file blobs, but I’m pretty sure there’s a way to sign your commits properly.