From what I gather, Postel's Law has fallen a bit from favor -- according to some folks anyway.
> From 2015 to 2018, in a series of Internet Drafts, Martin Thomson argues that Postel's robustness principle actually leads to a lack of robustness, including security:[1]
Darned if I'm going to say Postel's wrong, but it feels like long-term pain to me. If you accept invalid input and process it, then you're saying that it's de-facto good input. Other systems come to depend on those undocumented extensions, and now you're stuck supporting it forever. I can imagine a million ways that could lead to security problems. Even if that weren't an issue, it's definitely a maintenance problem.
For example, suppose you specify that a web service accepts JSON. It also accepts things like `{foo:"bar"}` as identical to `{"foo":"bar"}`, because hey, it's clear what the client meant. Guess what: now you can never switch to using an off-the-shelf JSON parser. You were trying to be nice to the client, but screwed yourself up in the process. Don't do that.
We have long term pain and the Internet. It wasn’t inevitable. Making stuff just about work as quickly as possible was key to bootstrapping a global open network.
I don’t have evidence for this, or much of an argument. Just a hunch.
Fair point. And plenty of people have heard of Postel's Law, because he's smart as hell and has earned us paying attention to his words. You haven't heard about my Laws, perhaps the most popular being "duct tape can fix anything, ergo nanomachines smaller than a duct tape molecule can't work", because I'm just some rando on the Internet.
I think it was a perfectly reasonable rule of thumb for the time he said it. I'm 100% onboard a modern variant like "be liberal in what you accept by returning an appropriate error code instead of crashing", e.g. an HTTP 400 for invalid data instead of a 500.
eponymous laws often tend to function as thought-terminating cliches especially if taken to extremes.
hanlon's razor is another one: malice is a very real thing in the world, it's not at all the same thing as occam's "don't say the devil killed your crop when there's a perfectly good scientific explanation" razor. in this case it's actually "memetic mimicry" - one meme having successfuly adopted the "coloration" (form and tempo) of another for propagation, despite lacking the essential characteristic of the first.
once these memes become established, people rarely question them, even when the ground circumstances have changed, or in cases in which they were never true at all.
(tu quoque is another example of this - actually, if conduct is normalized by routine and broad acceptance of the practice, then collectively we have (apparently) decided it's acceptable. And in that case no, it's not a fallacy to point out that everyone is doing it. There is a kernel of truth that one wrong doesn't excuse another, but if we have accepted the practice then it's not really a wrong. And it is generally wrong to single out a particular participant while giving everyone else a pass, as this unequal enforcement of laws (or norms) easily becomes a tool of oppression and bias. This becomes the classic "everyone smokes weed, but only black people get arrested for it".)
As someone not too familiar with the underlying nuts and bolts of the internet, I wish the article had been a little more detailed about the direct aftermath of the "takeover". It wasn't clear to me if it was a permanent change that continued to this day or if it was just a temporary "demonstration". From wikipedia, it was apparently the latter, and was hastily reversed under heavy pressure from the US Government.
Sorry, but you completely misunderstand the point.
The point is that, in the real world, there are subtle variations outside of your control and de facto standards arise independently and have slight differences before official standardization can occur because of the need to ship product. Attempting to stomp your foot to demand others conform to your way is unrealistic, unreasonable, and childish. Utility is had in working-around quirky differences for maximum practical compatibility while persuasively encouraging projects with minor incompatibilities to adopt conforming behavior.
Sure, by all means; clear, specific requirements that precisely define are very welcome.
Then, once you've done that, recognise that what comes in will not match what you said and you can either have software that doesn't do what the users need and want it to do, or software that accepts input that doesn't quite match requirements.
A few years before 1998, one hacker in Argentina called a popular radio show to give instructions about how to make your computer faster. He told the audience to run debug in DOS [1] and clear the boot sector (if I remember well). I think it is the 'w' command.
You can read more from the following book (in Spanish) [2].
17 comments
[ 1.7 ms ] story [ 43.8 ms ] thread> From 2015 to 2018, in a series of Internet Drafts, Martin Thomson argues that Postel's robustness principle actually leads to a lack of robustness, including security:[1]
[1] https://datatracker.ietf.org/doc/html/rfc9413
For example, suppose you specify that a web service accepts JSON. It also accepts things like `{foo:"bar"}` as identical to `{"foo":"bar"}`, because hey, it's clear what the client meant. Guess what: now you can never switch to using an off-the-shelf JSON parser. You were trying to be nice to the client, but screwed yourself up in the process. Don't do that.
Postel's Law is really bad once malicious actors show up.
I don’t have evidence for this, or much of an argument. Just a hunch.
I think it was a perfectly reasonable rule of thumb for the time he said it. I'm 100% onboard a modern variant like "be liberal in what you accept by returning an appropriate error code instead of crashing", e.g. an HTTP 400 for invalid data instead of a 500.
hanlon's razor is another one: malice is a very real thing in the world, it's not at all the same thing as occam's "don't say the devil killed your crop when there's a perfectly good scientific explanation" razor. in this case it's actually "memetic mimicry" - one meme having successfuly adopted the "coloration" (form and tempo) of another for propagation, despite lacking the essential characteristic of the first.
once these memes become established, people rarely question them, even when the ground circumstances have changed, or in cases in which they were never true at all.
(tu quoque is another example of this - actually, if conduct is normalized by routine and broad acceptance of the practice, then collectively we have (apparently) decided it's acceptable. And in that case no, it's not a fallacy to point out that everyone is doing it. There is a kernel of truth that one wrong doesn't excuse another, but if we have accepted the practice then it's not really a wrong. And it is generally wrong to single out a particular participant while giving everyone else a pass, as this unequal enforcement of laws (or norms) easily becomes a tool of oppression and bias. This becomes the classic "everyone smokes weed, but only black people get arrested for it".)
"Be conservative in what you do, be liberal in what you accept from others."
Terrible advice. Far better is:
"Rigidly define what you do and rigidly define what you accept from others."
It works much better than on paper designs with rigid u I/o.
The point is that, in the real world, there are subtle variations outside of your control and de facto standards arise independently and have slight differences before official standardization can occur because of the need to ship product. Attempting to stomp your foot to demand others conform to your way is unrealistic, unreasonable, and childish. Utility is had in working-around quirky differences for maximum practical compatibility while persuasively encouraging projects with minor incompatibilities to adopt conforming behavior.
I didn't interpret it that way. Compatibility can be a great vector for attacks.
Then, once you've done that, recognise that what comes in will not match what you said and you can either have software that doesn't do what the users need and want it to do, or software that accepts input that doesn't quite match requirements.
You can read more from the following book (in Spanish) [2].
[1] https://montcs.bloomu.edu/Information/LowLevel/DOS-Debug.htm...
[2] https://www.iberlibro.com/primera-edicion/Llaneros-solitario...