Google - you get what you paid for

With a few exceptions Google services have the unacceptable feature to be associated with an account forever. So if you test say "feedburner" once, and then decide that this is yet another data kraken and never use it again (for years), it will still be listed in the Google accounts dashboard. In theory you could delete the complete account including blogs, mails, images, videos, docs, sites, etc. — in practice folks trying this often show up in the blogger help forum whining about their lost blog and images.

Episode 1: I sent a complaint about "google moderator" to Google's privacy officer. This is actually an obscure HTML form creating no confirmation mail and no ticket number. After weeks my privacy complaint still got no reply. I'll test it again when I get around to it, complete with screenshots of the HTML form, as this isssue might require an intervention by Hamburg's privacy officer.

Episode 2: My entry in "places" is associated with an off by two photo in "maps". After a considerable amount of time I figured out how to report this issue. This actually resulted in a timely mail answer, but the mail came from a noreply bounce address offering no way to answer. My report was that they swapped the photos for house X and X+2. Sh*t happens, this was incorrect, they systematically show X+2 for X for the given street. I have no way to fix my semi-erroneous report, this is stupid. Never send noreply mail if you are not a mail-bot, this infuriates customers and users. Why should they use valid and valuable mail-addresses, when the other side uses bounce-addresses?

Episode 3: The new Chrome "apps" store apparently records all installed apps, even after they were removed. I submitted a complaint about this, because I do not recall where or when I permitted this violation of my privacy, and I certainly do not know how to withdraw this permission.

mailto: URLs

If you think that mailto: URLs are rather boring in comparison with http: you have a point, most mailto: URLs in the wild are straight forward and simple. But the syntax specified in RFC 2368 was based on

1. the RFC 1738 URL specification (1994),
2. the old STD 11 in RFC 822 (1982).

Updating the mailto: specification therefore had to replace the old (and tricky) RFC 822 syntax by the new RFC 5234 ABNF in STD 68 published 26 years later (2008). The actual content of RFC 822 is the Internet Message Format as used in e-mail and now specified in RFC 5322, the successor of RFC 2822. For URIs we are now at STD 66 in RFC 3986 (2005) with various subtle differences from the eleven years older RFC 1738. You won't often see these differences, but clearly there was no such thing as IPv6 in URIs back in 1994. UTF-8 was rarely used, supported 31bit Unicode points, and permitted "overlong" encodings — not exactly the STD 63 rules in RFC 3629 (2003) we use today.

The general syntax for URIs in STD 66 and the specific syntax of e-mail addresses in RFC 5322 are not directly compatible, some characters permitted in addresses are not permitted "as is" in URIs and have to be "percent-encoded" based on the hex. UTF-8 encoding. It's a miracle that the new mailto: URI specification in RFC 6068 managed to close these gaps in 2010, twelve years after RFC 2368. There are lots of interesting examples in RFC 6068, my favourite is a clever use of In-Reply-To e-mail header fields. The complicated examples are also fascinating. If you create a complicated e-mail address your chances that it works anywhere in a mailto: URLs are now better. Well, at least it is specified, implementing it at the interface of browsers and mail user agents is another story. Well done, one "like" from me to RFC 6068.

Service Status Feeds

My favourite tool for 2009 and 2010 — while I was mostly offline — is Google Reader, the feed reader offered by Google for "popular browsers" (read: IE6, FF2, or better), because it dutifully kept all my subscriptions, and still works like a charme.

In a Gmail blog article Google reported a bug in the Gmail service, apparently my account belongs to the 99.98% not affected by this issue.  The article mentions an Apps Status Dashboard showing the published issues for various Google services including Gmail.  Some years ago I would have added this page to my bookmarks, and checked it when something went wrong.  Today it is much simpler to subscribe to the relevant RSS feed — hopefully this results in no updates when there are no known issues.

Two other examples of status feeds are Blogger and DynDNS.