Postel's Law and the Three Ring Circus

Complex systems are by definition high dimensional. We often build them with fault tolerance and soft "failure modes" to prevent catastrophic events. However, the dimensionality and complexity mean that almost every sufficiently complex system is ALWAYS running in a "degraded" mode. However once this is normalized, the failure when it occurs is usually catastrophic, and determining proximate cause (often work grouped as "root cause"), much less fixing it, is made even more difficult.

The rapid exponential growth in complexity seen in semi over many decades has created guardrails (eg horrific yield/field failures) in modeling and verification that prevent a lot of problems. I do worry that as Moore slows (multi-chip modules are not Dennard scaling) we will lose some of this anti-fragility.

Of course the other side of this is Muntzing (the removal of any part that doesn't cause immediate failure):

https://en.wikipedia.org/wiki/Muntzing

If only we'd had that attitude in the 90s when html parsers proliferated. Instead we got tag soup and well, whatever this is: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...

> https://datatracker.ietf.org/doc/draft-thomson-postel-was-wr...

The original draft had an excellent name, and expressed a strong position. It was picked up and the consensus was published as RFC 9413 in mid-2023.

I think this may be a scissor statement for developers [0] as people seem to really be on one side or the other.

I remember years ago I wrote a Java package to sit on top of DOMs and let you query and manipulate in memory. People at my company liked it and so maybe like 20-30 people used it as the in memory store for passing info around this workflow engine. Anyway, I assumed you would always have a DOM or some Nodes and if you didn’t, allowed null pointer exceptions to throw in the right places (what I thought was right).

Some people liked starting with null and populating later and my logic would blow them up. My response was “fix your code, don’t do that.” My package was clearly documented for what to do and when.

But one day another senior dev came to me to plead the case for some mids who were writing all this extra code to prehandle those nulls. I still didn’t change my package because I thought it was most efficient to use it properly than to add in extra logic that sort of broke the interface. I did tell them that I welcomes a pull request to add the functionality.

Looking back, I wish I had been more liberal in what I accepted because it was causing a lot of emotional pain by people sort of lobbying others.

“Minimal bugs” depends on where in the stack you look.

[0] https://slatestarcodex.com/2018/10/30/sort-by-controversial/

I immediately thought about LibreOffice and MS Office. The compatibility has improved a lot, but things do break. And it is a showstopper for many users who receive documents by other people made in MS Office, or request MS Office files. It don't think the compatibility has to be 100% perfect, but visible breakage is an absolute showstopper for many users. I've recommended using LibreOffice to a small family business, but when existing documents showed up visually misaligned, they had to switch back. In this case it really doesn't matter who is to blame. For normal people who have things to do, the only thing that matters is whether they get the results they need or not. 99% won't complain to either MS or LibreOffice, they will just throw out the open product and just pay the commercial one and move on with their business.

Similarly, maybe your new browser fully and faithfully implements all the web standards down to the letter. But if it doesn't load Instagram, or Reddit or whatever popular site, then users won't care whether the blame lies with the website or the browser. They don't even have the granularity required for that in their mental model to distinguish these things. They see: when using Chrome, things work, when using the alternative browser, things are broken. Conclusion: use Chrome. It's like this in many cases. You can stomp your foot and stand up for rigor or whatever, but it won't change reality that you merely insist that it changes.

HTML is a great example in my opinion. XHTML failed because it was trying to close the barn door after the horse had bolted a decade ago.

XHTML was a reaction to an existing issue: that HTML is absolutely hellish to parse to the point that in the 90s half the web officially endorsed either IE or Netscape to be used for that particular website. Not to speak of anyone actually trying to do something clever with the contents of web pages.

Had XHTML worked it'd have been a huge quality of life improvement. The problem was that it was too late and that it was introduced into an ecosystem not prepared for it because everyone had long built on the assumption that you can just haphazardly generate chunks of HTML and insert them into the middle of other chunks of HTML.

Also, XHTML's error messages would probably be appreciated more today. Today we appreciate that allowing an HN poster to just drop random tags into a post is a terrible idea, so the fact that if on XHTML an user just leaves an unclosed tag the entire page fails to render, it's a good thing. It's a sign that you're doing handling of user data terribly wrong and it needs fixing post-haste. But back when XHTML showed up security was such an afterthought that barely anyone cared, and they just wanted things to work, dammit.

In the end we solved it first by a bigger push on standardization because people finally got sick of it, and later by Chrome just eating the browser market.

XHTML failed for exactly one reason – Internet Explorer, with overwhelming market share, did not support it. If you served it as text/html then it would parse it, but not apply any of the XHTML parsing rules, it would just treat it as weird HTML.

The history of the web is littered with copious examples of what the article talks about. Here’s one example: HTTP has a Content-Type header that indicates the media type being transferred. Sometimes, web developers would screw up and serve things with the wrong media type. For instance, serving CSS files as text/plain instead of text/css.

Now, if no action were taken by browser vendors, the resolution would be simple: the developer would see that the styling on their site was completely broken, and fix it. But Internet Explorer decided to be “liberal in what it accepted”, and instead of respecting the Content-Type header, they used content sniffing to guess. This meant that when a web developer screwed up, and they only tested on the 90%+ market share Internet Explorer, they would think everything was fine but it would be broken in every browser but Internet Explorer.

After a while, so many sites were broken in Firefox that Firefox had to follow the non-standard behaviour as well. Leaving other minority browsers broken. At this point, the behaviour a browser needs to implement to render a website successfully is not what is written in the specifications, but copying unpredictable guessing from proprietary code. You can see how that’s harmful to interoperability, right? Even though interoperability is the entire purpose of Postel’s Law?

It gets worse though, because this content sniffing was happening all over, not just to CSS. So if a website said that something was a PNG image, if that image’s metadata contained the wrong sequence of bytes, it would get interpreted as an HTML document. This is important because PNGs don’t contain any kind of scripting, while HTML documents do.

So this opened up an attack vector: make a polyglot file that contains malicious JavaScript, and upload it as an image to a website. Then link to that image, and Internet Explorer users will execute the JavaScript in the security context of that website, resulting in a successful XSS attack. Even though the website served it as an image, not HTML, Internet Explorer would “be liberal” and do its best to interpret it as badly-broken HTML.

At some point, Internet Explorer came up with an authoritative: true parameter that opted out of this behaviour. Sometimes. Then they tried again with X-Content-Type-Options: nosniff. Meanwhile, web developers who just wanted to serve user-provided images without opening themselves up to attack vectors needed to follow all these twists and turns instead of just reading the spec. Ever wonder why opening an image URL on so many sites triggers a download? It’s because for many years it was the only safe way to avoid an image being interpreted as HTML.

This has happened over and over and over and over again on the web. Did you know that Netscape Navigator would interpret Unicode characters that merely look like angle brackets as if they were actually angle brackets? Consider the impact on security that one had. Remember the “samy is my hero” MySpace worm? That was down to browsers “helpfully” ignoring newlines in the javascript pseudo-protocol.

Postel’s law has been downright poisonous for security and interoperability. We would all be much better off with strict parsers.

As someone who has dealt with a lot of syslog over the years... There are RFCs which specify the overall structure and the correct timestamp format, but many tools (open and closed source alike) follow the following "standard" instead:

"Just print a timestamp in some format, then maybe the hostname if you feel like it, and then your message"

For the best case example design your code with the goal of failure and properly describing failure states for the users benefit. The success state should be a narrow exception provided the input is formatted exactly as the specification describes.

This greatly lowers the acceptance criteria to test for and instead forces a greater focus on negative tests and error conditions.

Great example for minor cosmetic changes that pointlessly break stuff. I see this a lot in Python libraries, seems to be a culture thing. Renaming arguments, moving stuff into different subpackages, just so much churn. Yeah, I get it, it may be slightly more consistent, or feels cleaner, but in many cases it's quite subjective but library authors seem quite prone to just deprecate it, then deprecate the new version again soon after... It's like they don't realize that there's code out there that uses it. This is why code "rots". When I complain about software churn and the waste of effort to keep existing code functional, people point to security vulnerabilities etc., but that should be possible to do without a bunch of pointless renames and refactors.

Case in point: `collections.MutableMapping` was moved to `collections.abc.MutableMapping` in Python 3.10, breaking a bunch of nice libraries that provide useful data structures. And why? Because it looked more tidy and conceptually comforting for some Python devs.

https://stackoverflow.com/questions/70870041/cannot-import-n...

This can be super demotivating. Someone at some point in their lives made a useful tool, but then moved on, maybe they were a grad student at the time, and now they have a family, etc. And we are cut off from their contributions because they can't keep up with slightly adjusting the code to the whims of language and library authors every month or two.

Some other languages are much better about not breaking existing code, e.g. Java.