An incomplete sketch of a browser plugin/feature that would allow posts to be signed from an anonymous source. (hiding your IP isn't addressed; use something like Tor)
* Blocks of text that start and end with magic numbers are signed in-band in the style of "gpg --clearsign".
* The pubkey pair is automagically created on first use.
For legacy support with existing infrastructure (such as HN):
* When you submit a form with a <textarea>, the plugin provides a UI to sign the contents before submitting the form.
* When browsing a page that contains magic number wrapped text, the text is automagically verified and the key pinned.
* The structure of the signed text should allow the plugin to hide the magic numbers, signature, etc, so the text looks normal.
However, newer software would have other options:
* Define a mapping between the in-band data and a tag structure that holds the same data. This needs to be strictly defined, so it is possible to remove the tag structure and verify the original signed text. This gives full presentation control back to the website, while allowing individual posts on the page to be verified.
The big problem - as usual - is key distribution. In the latter case where it is easy to hide metadata with CSS, the public key can simply be included with the post. Unfortunately, in the legacy case I don't think there's a good way to include two pages of public key in each "--clearsign"d post.
I have considered, and even worked on, a Chrome extension for this exact purpose. Some hurdles I discovered:
* Websites do weird things with textareas. If it's a plain-ol HTML form, it's pretty easy to intercept and do what you want. It seems most websites intercept button clicks then pass your text around to twenty different JS functions and libraries before doing something useful with it. You wind up writing code to handle edge-cases more than anything else.
* To address your final comment, embedding the pubkey inside the text would defeat the entire purpose. A malicious actor (see recent Reddit controversy) can just create their own pubkey, sign the modified comment with it, and noone would be the wiser.
Some things I discovered, and found worked well:
* Keybase has a fantastic library for generating PGP keypairs in-browser. It really added that extra bit of "magic" to the extension.
* Chrome extensions can get CORS exemptions on a per-website basis, and uploading to a standard SKS keyserver is just a POST request that can be done by Javascript.
* Expanding on the last bullet point, verifying other user's comments was tricky. During development, I just downloaded all keys on the keyserver that were uploaded by my extension on a scheduled interval and stored them in localstorage. Unfortunately, I don't think this would scale.
If anyone is interested in picking up where I left off, I could upload the source to Github.
Could you commit to github? Im working on something similar and would like to check out what you got/maybe pick it up. Feel free to send me an email (in my HN profile)
* Blocks of text that start and end with magic numbers are signed in-band in the style of "gpg --clearsign".
* The pubkey pair is automagically created on first use.
For legacy support with existing infrastructure (such as HN):
* When you submit a form with a <textarea>, the plugin provides a UI to sign the contents before submitting the form.
* When browsing a page that contains magic number wrapped text, the text is automagically verified and the key pinned.
* The structure of the signed text should allow the plugin to hide the magic numbers, signature, etc, so the text looks normal.
However, newer software would have other options:
* Define a mapping between the in-band data and a tag structure that holds the same data. This needs to be strictly defined, so it is possible to remove the tag structure and verify the original signed text. This gives full presentation control back to the website, while allowing individual posts on the page to be verified.
The big problem - as usual - is key distribution. In the latter case where it is easy to hide metadata with CSS, the public key can simply be included with the post. Unfortunately, in the legacy case I don't think there's a good way to include two pages of public key in each "--clearsign"d post.