October 10, 2023

s16e12: Mitigation Strategies; The Unbearable Necessity of Portability; Tactical Binding Covenants

s16e12: Mitigation Strategies; The Unbearable Necessity of Portability; Tactical Binding Covenants

0.0 Context Setting

Tuesday, 10 October, 2023 in Portland, Oregon and a day that has started out with desultory rain and that will continue as such throughout the rest of the day because that's what Portland is like. And to be honest, I'm glad, because this is "normal" and not "an unprecedented, once in a hundred years event".

One big thing split into two things today.

A quick note: if your expense account still exists, scroll down to the bottom for "let my boss pay" and upgrade to a paid subscription. I'd appreciate it!

---

1.0 Some Things That Caught My Attention

1.1 Mitigation Strategies

I have been reading Cory Doctorow's book, The Internet Con: How to Seize the Means of Computation¹. For me, at least, it has been a pretty easy read: lots of nodding along, and even more "ah yes, Cory's done the research here".

A long, long time ago (over half my lifetime ago, I've just realized), I used to be a law student. This was on the one hand great, because I had convinced myself I wanted to study law, and in retrospect, not that bad a thing to have studied. (This is an incredibly privileged position, yes). It was less great because for a long while, "law", and as always there are nuances, relies on a lot of detail and not just synthesizing the big/medium picture and shape. Turns out, quite a lot of it, especially at the beginning, hinges on being able to produce and recall from memory specific case citations. This is not great for my brain. My brain is able to remember the point of the case and the interesting part of the case and the relevant part but not, unfortunately, the detail part. That part is boring.

Two things have caught my attention so far.

1.2 The Unbearable Necessity of Practical Portability

The first is a specific subset of interoperability, that of portability. The point of interoperability is that it's a reflection of the inherent nature of computing that any computer (yes, universal Turing computers etc) can do what any other computer can compute, it's just a matter of time (which therefore means a matter of your patience or, in some cases, how long you expect to live). There is nothing in principle -- in fact -- that prevents what one computer does being operable upon by another computer. All the methods of impeding interoperability, whether technical or socio-political-legal-economic, are just tactics to stall interoperability.

Sometimes interoperability is built in as a result of ideology or philosophy. Mastodon, the federated social network built upon the ActivityPub protocol (the Mastodon API provides access to an implementation of the ActivityPub protocol), provides for interoperability in the sense that an individual user can export their data in terms of posts and their social graph, in the form of following/follower relationships, then schlep that off to another Mastodon instance. The fact that this data is exported in common and documented formats, along with its implementation of the ActivityPub standard, makes interoperability significantly easier for those wishing to interoperate.

Anyway. I'm getting ahead of myself. Interoperability is a tactic, a method, of achieving something. It is one tactic necessary, in Doctorow's view, to achieve the following:

• lowering the likelihood that services will grow too big² and reach intolerable³ switching costs, resulting in lock-in
• a diversity of service providers
• room for innovation and improvement
• competition

Now, Mastodon is big. It is the dominant implementation and service provider in the "federated social network" space. This isn't necessarily a bad thing, because alternative implementations have cropped up and as people find communities better suited to their needs (for example, due to moderation decisions or focus of topic or, as I'll point out, changes in operator and ownership), they have been able to move from the largest instances to smaller, more focussed ones.

But they've only been able to move sort of, and here's where I see a technical problem that needs coordinated solving.

The deal with Mastodon is that while you move your identity to a new host and your following/followers graph more-or-less moves with you to the new host, what doesn't move with you is your post history. What happens is that all of your posts should stay at their original locations. As a product decision, this makes sense: you probably don't want to break links to your original posts.

Your posts don't move with you, so your identity or posting history starts to become fractured. This might matter more to some people than others, but the important part here is that it does matter to some people.

In this sense, you want interoperability so that you can have identity and post history portability.

I can think of ways you can do this, but this is also the kind of thing that developers and standards setters, like the w3c group that defined ActivityPub in the first place, are usually best suited to address and think about. Here's three, anyway, bearing in mind that I haven't read the ActivityPub spec lately and they may not even work due to its Federated nature:

• the original post host (heh)could just leave everything where it is, doing nothing different than what it does now;
• the new post host could ingest the post history and backfill a timeline republishing the actual content of those posts, but not push those posts out as they're historical posts. This would make it easy/easier to browse your post history, if that's important to you (you wouldn't have to skip to a different account to continue browsing history). This also has the benefit of re-hosting your posts on a server with different control than the one you're migrating from.
• in the same way that posts can be edited and those posts are propagated out (in a best effort, I think?), the original post host (heh) might edit all your old posts to redirect to their new location on the new host post. This is probably the most effort?

Portability of posts is important for another reason: it's entirely possible that the host of your Mastodon account just... disappears for a bunch of reasons:

• the entire host is taken down out of operator malice
• your account is taken down, out of operator malice
• your account is taken down due to mistaken moderation based on malicious reporting
• due to a security breach and malicious activity
• by accident, because accidents happen
• because of hardware failure and a lack of backups

So there's a difference, and it sounds trite, between portability and practical or usable portability. The difference in degree between "I have a backup of my posts on my computer or email" and "people can still see my posts" is not small; it's a yawning chasm of utility.

There is a good story here, though, and it's even one that involves the network formerly known as Twitter. Twitter still (and is legally bound, in some jurisdictions) to provide you with all of your data, which includes your post history. Some very nice people on the internet produced multiple ways for you to take your Twitter post history and re-publish it on a site that you're able to operate.

This gets back to one of Doctorow's original points, so central that it forms the subtitle of his book: that these principles and tactics are vital to seizing the means of computation, and what seizing the means of computation means at the very least practical, personal control and agency.

One particular reason why this is in my mind right now is because just in the last 48 hours, Zecharias Zelalem⁴, a freelance journalist, switched Mastodon accounts from journa.host to dair-community social. The short version of the reason why they switched is:

• Journa.host, the instance they first joined, was run by journalists with verifiable credentials, and espoused a community environment that Zelalem wanted to be a part of
• Last week, the server was taken over -- without notice -- by a new owner/operator, the existing owner/operator of newsie.social. Jeff Brown, the new owner/operator doesn't appear to have a history as a journalist.

Zelalem goes into more detail in their thread⁵.

This is a classic example of someone who has a body of work, who has a post history that's professionally relevant, and switched instances/hosts because of the behavior and fear of a new owner. Change of ownership can happen at any time, and current implementation of Mastodon doesn't allow for portability of historical identity.

(That said, I haven't yet looked for or am aware of easy-to-use tools that republish your posts).

This is doubly important, because as Tim Bray pointed out in the thread:

[there's] a real issue there that’s not getting enough airtime: Most Fediverse instances have a weak sustainability story: Some Geek put up a server and there are volunteer mods and Patreon donations and hope.⁶

Professional institutions (i.e. long-running bodies that have a history of sustainability) are one organization that might be ideally placed to offer stability of identity as a benefit, at least, and funnily enough I wrote about the possibility of journalists' unions offering instances pretty much exactly a year ago⁷. Evan Prodromou, an author of the ActivityPub spec came up with the same conclusion in the same thread.⁸.

1.3 Tactical Binding Covenants

I mean, in a way, it'd be far more interesting for me to be a law student today rather than twenty five years ago, because all the interesting stuff that I thought was going to happen with the internet and "law" applies to it has now happened more or less earlier/lately/more seriously/terribly than I thought (which I admit is a rather large caveat).

One specific tactic Doctorow suggests in order to bring about change is to use government procurement as a mechanism to require interoperability, and in the context of his book, he is totally right. I'm going to add some more implementation detail and notes based on my experience working with technology in government over the past few years.

First, this makes sense. It is entirely right and within government power -- both state and federal, in the U.S. -- to mandate interoperability and set requirements for interoperability. Indeed, I'd argue that most procurements, especially to do with computer systems or digital services by now include "interoperability" as practical boilerplate these days. But we're not just talking about software interoperability, we're also talking about requiring the absence or explicitly allowing the circumvention of software methods of preventing interoperability. Doctorow's accessible example:

maybe you can't make HP give up its ink-gouging grift [ed: in using DRM to prevent the use of non-HP ink cartridges with HP printers], but if the U.S. government announced that no federal department could buy a printer unless it accepted third-party ink, either HP would crave, or one of its rivals would

Let's talk about this kind of software-mediated "digital lock" enabled anti-competition and lock-in and how it might be mandated away by government procurement. Or at least, how I'd make the argument and push for the change:

First, all it takes is somebody to go first. If something makes sense, then in many cases the impediment to change is the fear of fucking something up. I empathise with this! I too fear of fucking up. I fear bringing down a bunch of shit not only on me, but those I may be formally responsible for.

Next, I'd go find someone sympathetic to the argument.

Not just Cory's argument, but support by analogy and comparison. Like this: in my user research with the state of California, one of the things that always comes up is dissatisfaction with procurement. One particular example was the procurement of headphone/microphone headsets to support remote working during Covid. There's the boring stuff, like it taking too long, and then the other stuff, like the existence of an existing contract meaning procurement "had" to go with the more expensive option even if a cheaper, better option existed (sometimes due to the procurement office's lack of experience in evaluating the particular thing being bought.)

But think of it this way: the fact that there's choice is because there's a wired standard of your regular 3.5mm plug and however many rings is required to support mono/stereo audio and a microphone input. That's it. Even if you went wireless, there are standard protocols over Bluetooth and profiles for wireless headsets/microphones.

My argument with the amenable procurement office or director or whomever actually sets the rules would be this: it would be fucked up if you ended up buying computers that would only work with one kind of headset, right? Or only one kind of monitor? They might ostensibly work better with one kind of headset (i.e. Apple) or monitor (ditto), or the support contract might be better, but the point is you have a choice and you can switch. But crucially, the reason why you can switch isn't because you have a procurement requirement, it's because in this case, you have an interoperable industry standard. But what if you mandated such a standard?

All it takes is one person. Let's just say that in the past, all it's taken is a conversation with one person, at the right level, to insert a single sentence in a letter which would achieve the above.

Doctorow suggests another procurement-related approach, one less technical and instead more legal:

If every vendor selling to any branch of local, state or federal government has a binding nonaggression pact against adversarial interoperators, that opens whole swathes of products and services to reverse engineering and improvement

That's Doctorow's underling point: not to use procurement rules to mandate interoperability in the first place, because for a whole host of reasons, that hasn't worked, or hasn't gone far enough.

Instead what he's suggesting is to use procurement as a stick, or a carrot if you want those lucrative government contracts, to ensure that vendors promise not to sue or harass interoperators, those who engage in competitive compatibility (i.e. reverse engineering), on behalf of public-sector agencies.

This would be a big deal. It would be subject to the usual battery of protests. It would matter for every single piece of physical hardware that's restricted by digital locks or DRM to original manufacturer hardware. We're already in an environment where vendors effectively ensure that even screenshots of massive software systems like unemployment insurance are treated as confidential from state government to state government.

The allure of this is that like I mentioned above, all it takes is someone to go first. All it takes is someone in some part of government, with the right amount of paper, to be just that fed up with the status quo, to be that annoyed about spending all this money, but who doesn't know of any way around it. Because in that frustration, cultivated over decades now, is desperation for an approach that might work, even it might take a while, and even if it will result in pain from vendor protests, of which I can guarantee there will be vendor protests.

---

Eesh. 2,689 words today, and I'm only about 60% through Doctorow's book.

How are you doing today?

Best,

Dan

---

How you can support Things That Caught My Attention

Things That Caught My Attention is a free newsletter, and if you like it and find it useful, please consider becoming a paid supporter, at pay-what-you want.

Let my boss pay!

Do you have an expense account or a training/research materials budget? Let your boss pay, at $25/month, or $270/year, $35/month, or $380/year, or $50/month, or $500/year.

Paid supporters get a free copy of Things That Caught My Attention, Volume 1, collecting the best essays from the first 50 episodes, and free subscribers get a 20% discount.