Was Googling this today and couldn’t find an answer. Wrote support. They don’t support it.

Does Dreamhost support mod_ssl and SSLVerifyClient? I tried putting the following in my .htaccess at singpolyma.net/catest, but nothing happened

Sorry, but I’m afraid not! While we do have mod_ssl, there is no
SSLVerifyClient. Sorry about any trouble this causes you!

If you have any other questions, just let me know!

Today I received a threat from Facebook about an old F8 app of mine called “The Wall” because it was designed to look identical to the Facebook wall (back when that was a separate area of one’s profile) but actually tie data back to a datastore on one’s own website. (Only Chris Shiels ever used it).

They claim to have a trademark on the word “wall”. I wonder what the superwall people (or anyone with the Unix command “wall” installed, which is where Facebook got the name from in the first place) are going to do.

The email is below:

To the developer of The Wall (6506538869):

During an automated check, our system found that your application name contains a variation on the disallowed term “wall.” Application names may not contain Facebook trademarks without the express prior written permission of Facebook.

Please change your application name within two weeks of receiving this email. Failure to comply will result in our system automatically changing your application name to “Unnamed Application #6506538869”

If you believe your application name has been selected in error, please contact us through the Developer Help form at http://www.facebook.com/dev-help?category=Name+Appeal&app_id=6506538869&issue_location=Developer+App&title=Appeal+to+use+%22The+Wall%22+%286506538869%29 .

Thanks,
The Facebook Team

First off, why would one want to do this? Well, cryptographic security is useful in communications medium other than email, and sometimes one may not have an email address for the person one is contacting. Also, a public key got from someone’s profile page is more likely to be their current key than the one got off a keyserver. Finally, if the discovery is done over TLS (or upcoming XRD signing techinques) then one can use the PKI to verify that the public key is, at very least, the one the owner of the URL claims. Which, for pseudonymous communications, may often be enough.

I will here propose three different ways to make this discovery work. Consumers must try all three. Publishers may publish more than one.

Content Negotiation

A public key represents a person. If a URL represents a person (such as on a profile page), then were that page’s data to be represented in the OpenPGP key format, one would get the user’s OpenPGP public key.

Send the header Accept: application/pgp-keys along with an HTTP GET request. If the Content-Type on the response is application/pgp-keys then the body is the user’s OpenPGP public key.

Links

If a GET or HEAD request is performed on the URL and in the headers is a Link header with rel=me and type=application/pgp-keys, then the URL of that link is the user’s OpenPGP public key.

If the Content-Type header of the GET request is text/html or application/xhtml+xml, then look in the page for <a> and <link> tags with rel=me and type=application/pgp-keys. If there is such a tag, then its href attribute is the URL to the user’s OpenPGP key.

LRDD+XRD

If LRDD discovery is performed on an endpoint, leading to the discovery of an XRD document containing a section like the following:

<Link>
<Rel>http://www.iana.org/assignments/relation/me;
<MediaType>application/pgp-keys</MediaType>
<URI>...</URI>
</Link>


Then the URI is the URI of the user’s OpenPGP key.

Security Considerations

The URLs used in all methods above should be either HTTPS URIs secured using TLS and a certificate issued by a CA known to the client, or data URIs.

Application to Other Crytography Schemes

Everything in this document applies equally well to public keys for any cryptography scheme, as long as the MIME types are changed appropriately.

I’ve been complaining about the state of GUI toolkits and standards, etc, for some time now. Even (and especially) in the FLOSS world we have so many incompatible ways to do GUIs, it’s crazy. No one can bother to write a GUI in every possible toolkit (or usually even in more than one!) so we end up with multiple projects all working on the same thing, but “in X toolkit/style”.

I was looking at the output of the Qt Designer (GUI drag-n-drop tool for the Qt toolkit) a couple weeks ago and realised something: the output is very hackable! In fact, many of the GUI designer tools out there have text or XML files that can be processed. To convert between them, all it would take is mapping the classes, properties, and events between the different toolkits.

Of course, that got me thinking. Mapping Qt to Gtk and Tk etc al, then mapping Gtk to Qt and Tk et al would be a rediculous proposition. Each toolkit or format would add an increasing number of bidirectional mapping requirements to any software.

The solution was pretty obvious. Create an intermediate data model that can represent GUIs from any toolkit and just write input/output filters. The strategy has a side-benefit too: such a data model could form the basis for discussion between different toolkits and formats on their similarities and where they could be brought closer together. Ideally, very simple GUI programs could be source-compatible between, say, Qt and Gtk.

So, how to determine the best way to model this data? Research and a wiki of course! Document existing toolkits and formats and what widgets/properties/events/layout stragegies they have, and see what the common patterns are.

So far I have at least widgets documented for Gtk, Qt, HTML forms, XForms, XUL, and wxWidgets. I have identified common widget and property patterns and common layout patterns. I have already started writing software to read and write GladeXML and should start on Qt Designer output soon.

It’s an age-old practise in computing: limiting text files to a maximum of 80 characters per line (sometimes as little as 72 is suggested). Problems have previously been identified with this practise, but the prevelance of full-sized computer terminals has limited people’s exposure to the problem outside of email quoting.

I have been reading Cory Doctorow‘s short stories and novels on my Google Ion (Android-based phone) for a while now using auduaReader, which is so far the best ebook program I’ve found for the platform. Doctorow distributes his books as text files folded to 80 columns. This has never been a problem on my laptop (where it simply means I do not have to call fold before less), but on my phone it is atrocious. The abuse of newlines in places with no real semantics means the reader is unable to reflow the text in a suitable way for the small screen, and as a result every “line” becomes two and a half lines, like so:

This would have originally been
one long line of text. It will
get folded funny.

You can imagine how atrocious that gets when reading a whole book!

All text viewers and editors can wrap and reflow text themselves these days. Lets promise to use newlines to mean “new line” and not “word wrap”.

EDIT: I have written a perl one-liner that easily reflows wiki-style text where double line-breaks are paragraphs and single line breaks can be ignored. This 80% works on Doctorow files, but munges some sections:

perl -0e '$_=<>; s/(?<!\n)\r?\n(?!\r?\n)/ /g; print'