The real world is mutable (and consequences for system design)

January 26, 2020

Every so often I see people put together systems on the Internet that are designed to be immutable and permanent (most recently Go). I generally wince, and perhaps sigh to myself, because sooner or later there are going to be problems. The reality of life is that the real world is not immutable. I mean that at two levels. The first is that sometimes people make mistakes and publish things that they very strongly wish and need to change or retract. Pretending that they do not is ignoring reality. Beyond that, things in the real world are almost always mutable and removable because lawyers can show up on your doorstep with a court order to make them so, and the court generally doesn't care about what problems your choice of technology has created for you in complying. If the court says 'stop serving that', you had better do so (or have very good lawyers).

It's my view that designing systems without considering this creates two problems, one obvious and one not obvious. The obvious one is that on the day when the lawyers show up on your front door, you're going to have a problem; unless you enjoy the varied and generally unpleasant consequences of defying a court order, you're going to have to mutate your immutable thing (or perhaps shut it down entirely). If you're having to do this from a cold start, without any advance consideration of the issue, the result may be disruptive (and obviously shutting down entirely is disruptive, even if it's only temporary as you do a very hasty hack rewrite so that you can block certain things or whatever).

The subtle problem is that by creating an immutable system and then leaving it up to the courts to force you to mutate it, you've created a two-tier system. Your system actually supports deletions and perhaps modifications, but only for people who can afford expensive lawyers who can get those court orders that force you to comply. Everyone else is out of luck; for ordinary people, any mistakes they make are not fixable, unlike for the powerful.

(A related problem is that keeping your system as immutable as possible is also a privilege extended more and more to powerful operators of the service. Google can afford to pay expensive lawyers to object to proposed court orders calling for changes in their permanent proxy service; you probably can't.)

As a side note, there's also a moral dimension here, in that we know that people will make these mistakes and will do things that they shouldn't have, that they very much regret, and that sometimes expose them to serious consequences if not corrected (whether personal, professional, or for organizations). If people design a system without an escape hatch (other than what a court will force them to eventually provide), they're telling these people that their suffering is not important enough. Perhaps the designers want to say that. Perhaps they have strong enough reasons for it. But please don't pretend that there will never be bad consequences to real people from these design decisions.

PS: There's also the related but very relevant issue of abuse and malicious actors, leading to attacks such as the one that more or less took down the PGP Web of Trust. Immutability means that any such things that make it into the system past any defenses you have are a problem forever. And 'forever' can be a long time in Internet level systems.


Comments on this page:

By John Carter at 2020-01-27 14:32:15:

I think Rich Hickey has a good take on this.... if you add a time dimension to it.

...the world is immutable, whatever was, was, and cannot be changed.

What view, of what was, you wish to display now... that is the mutable bit.

But once you have displayed... lawyers are going to argue that you did so then and no amount of taking it down later will change that fact.

By theamk at 2020-01-28 10:38:05:

Note that immutable does not have to mean available.

In particular, a rule saying "published package versions always refer to a same hash" is perfectly compatible with court orders, mistakes and so on. For better user friendliness, one should probably have an append-only, immutable list of revoked package versions - this will allow tooling to distinguish between revocation and misconfiguration.

(one argument for replacing files could be malware: "foo 1.11 was infected, I want to replace it with a good one". But this is pretty complex yask for all caches - it is much easier to revoke foo 1.11 and re-publisher clean version under foo 1.12.)

Written on 26 January 2020.
« How big our Prometheus setup is (as of January 2020)
More badly encoded MIME Content-Disposition headers »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jan 26 22:06:11 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.