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'

Say what you like about Dreamhost, their customer service rocks.

I’ve been using Boxbe for some time as an email whitelist service to quarantine all email not from my contacts (if sent to one of my catch-all email addresses). This works great to stop SPAM while still letting me review easily for any potential ham. There are two problems with this approach: (1) it’s slow (2) it requires proxying all my mail through 4 different mailboxes.

So I was looking for some solutions. The Dreamhost support people (after I finally explained to them what whitelisting is) told me how to do it with their server-side filters. Unfortunately, since they’ve disabled procmail support, this requires creating hundred of filters by hand through a weird web GUI. Not awesome, and certainly not feasible.

So I was also in touch with the Boxbe people to see if things could be improved from their end. I asked three things.

I asked if they could please allow importing GMail address books without the use of a GMail password, so that I could keep them in sync without exporting my contacts to a file all the time.

The response: “Currently, there are no plans in the works for this.”

I asked if they could add a view to see approved email similar to how they have a view for waitlisted emails.

The response: they pointed me at their waitlist view, as though that solved the problem.

I asked if they could ping Dreamhost to get the ban on forwarding catch-all email addresses to Boxbe lifted.

The response: “At this time, Boxbe is a stand-alone application service, but we will pass this along to our Product Development team.”

All in all, an awful customer service experience, they really need some new
Managing Leads strategies. I then found out they have a GetSatisfaction forum. I checked it out, and found that any real problems posted there are replied to with robot-like requests for the user to email support. I really don’t think they get it.