Robert Lowe

So I read Scott Hanselman’s post on how to link Mastodon accounts to arbitrary domains and decided to give it a try for rmlowe.com.

Here’s the idea: I have a Mastodon account rmlowe@mastodon.online, but I’d like people to be able to find/mention me using, say, mastodon@rmlowe.com. I’d like to do this without running a Mastodon server.

As Scott points out, Mastodon uses WebFinger to look up accounts. Here’s how that works: a Mastodon account name has two parts, a “user” part (mastodon in the above example), and a “host” part (rmlowe.com in the above example). To look up account details, Mastodon takes the host part and sends a WebFinger request to a well-known endpoint on that host; for the example above that would be https://rmlowe.com/.well-known/webfinger. The WebFinger request must include a resource parameter whose value is syntactically a URI; Mastodon uses the ‘acct’ URI scheme, so an account would be identified as e.g. acct:mastodon@rmlowe.com. Think of this like a mailto: URI, except that there’s no implication that the account is accessible using mail protocols, or actually any other protocols. So the full WebFinger request, after encoding the parameter value, would be made to https://rmlowe.com/.well-known/webfinger?resource=acct%3Amastodon%40rmlowe.com.

If you follow that URL you’ll see a JSON response known as a JSON Resource Descriptor (JRD), which includes details about my actual Mastodon account at mastodon.online. If we were implementing WebFinger for a site that supports many accounts, as the Mastodon software would need to do, we’d obviously need some kind of dynamic lookup. However, a key insight here is that, since we want to link a hostname to just a single account, we can implement WebFinger by returning a static file! In other words, the value of the resource parameter will just be ignored. That’s what’s happening here — the file returned from rmlowe.com is simply an exact static copy of the response from mastodon.online, served from an S3 bucket.

In fact the only tricky detail here was the S3 configuration. rmlowe.com is served from an S3 bucket, and previously this was configured to simply redirect everything to blog.rmlowe.com (i.e. this site, a WordPress.com blog), as shown below.

Now, we need to redirect everything except the JRD at /.well-known/webfinger. It turns out that to do this we need to change the Hosting type to Host a static website.

Then, we can write some redirection rules (just one in this case) using JSON. The trick here is to redirect based on an HTTP response code — every URL path except the WebFinger path will get a 404 Not Found response from the S3 bucket.

[
    {
        "Condition": {
            "HttpErrorCodeReturnedEquals": "404"
        },
        "Redirect": {
            "HostName": "blog.rmlowe.com",
            "Protocol": "https"
        }
    }
]

With this configured, you can go to your favourite Mastodon instance and search for any account name with rmlowe.com as the host; it will resolve to my mastodon.online account.

This also works for @ mentions, as demonstrated by this toot.

So, as 2023 begins, I’m a little easier to find on Mastodon, and a little wiser about WebFinger.

Happy New Year!

A few hours ago I received the following apologetic email from Google. (Image here.)

Hello,

We are contacting you because a technical error caused a problem with your [redacted]@gmail.com account. Regrettably, this bug led to the loss of the audio files you had uploaded to your Google Docs account. Our engineers worked for days, but were unable to recover all of them. We have however recovered 1 out of 2 items, which are listed at the end of this email. We cannot provide you with the names of the files that were not recovered since they were fully deleted from our systems. We are very sorry.

We understand this error may have led you to question your trust in Google. We want to reassure you that we are making improvements to continue protecting your account. If you have any questions, please respond to this message.

With regret and a promise to do better,
The Google Docs Team

The information in the email checks out—I do indeed have a file in Google Docs with the same name as the one that was listed at the end of the email (uploaded for testing purposes as it happens), and another audio file that I believe I had uploaded is no longer there.

As it happens the missing file is not vital and was easily recoverable by other means. Nevertheless, my faith in the service is definitely shaken—I certainly have other data in Google Docs that I would be much more unhappy about losing. I’m curious how many other users have been similarly affected.

Aside from that, I find it interesting that the email refers specifically to audio files. Right now Google Docs doesn’t do anything special with audio files. What changes were going on under the hood that would cause audio files in particular to be affected?

Update: As TOMHTML points out in a comment, the problem was first reported over a month ago.