Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postel’s Principle is a Bad Idea

programmingisterrible.com

Post reply on HN
Print view View original

11–20 of 62 posts

Re: Postel’s Principle is a Bad Idea

#11

Post by YZF »

There are times when you want to build for robustness and times you want to be more concise. If you have control over the set of inputs (e.g. by formalizing it and using the right tools) that's great but there's usually some overhead involved in doing that. My argument would be that security is orthogonal to robustness - just because you accept input that is outside the originl specification doesn't mean that you should do that insecurely. The robust (liberal) implementation and the limited (conservative) implementation simply support different protocols, they can do either with security holes or without. Does this increase the attack "surface"? It may or may not.

A bigger problem is when the liberal implementations become the de-facto standard.

Re: Postel’s Principle is a Bad Idea

#13

Post by ams6110 »

_delirium wrote: post #10
DanBC wrote: post #8

Earlier quoted context omitted.

Postel wrote it in 1980. (First found in RFC760[1]) Since then we've had computer viruses, worms, and other malware; we've had hackers, crackers, spies, criminals, and semi-competent people flooding the Internet; we have people not just making accidental requests but fuzzing and fusking to try to break things or bypass controls. It's a great principle for the human stuff, but it feels really outdated for technical st…

I agree, Postel's principle makes a lot of sense in context, if you view it as a bunch of mostly good-faith people attempting to bootstrap communication in a new medium. Then it's clear that to get things working, you want to forgive errors on the receiving side (to the extent you can do so), but send as clean and unproblematic output as you can. Basically what a sensible, not-anally-bureaucratic human who's trying t…

Agreed. Today, I think "fail fast" is a much better principle.

Re: Postel’s Principle is a Bad Idea

#14

Post by MichaelGG »

The authors of the SIP spec published another spec (RFC4475[1]) called "SIP torture tests", where they seem to take a perverse glee in showing how messed up their "human readable" syntax can get.

They even use the phrase "infer" in several places, encouraging systems to take obviously malformed packets and try to figure out what they meant.

Being liberal in accepting input, apart from security issues, seems to create a worse situation. Implementation A messes up something, but B seems to be OK with it. C then accidentally requires it, while D rejects it. Depending on how large and responsive the vendors behind those implementations are, you end up with a nasty state of affairs, with random hacks here and there.

It's hard enough to create unambiguous, comprehensible, specifications. Telling implementations to be liberal only makes it worse.

Re: Postel’s Principle is a Bad Idea

#15

Post by caf »

Quite apart from security, Postel's Principle can hurt the capacity to make backwards-compatible feature additions in the future.

For example, if you have a set of unused flag bits documented as "reserved, must be zero", then a receiver that silently ignores non-zero bits allows senders that erroneously set those bits to propagate. This is fine, until one day in a future standard you want to define new behaviour for one of those bits, and find you can't - because there's large numbers of senders out there that erroneously set it but don't have any idea about the new behaviour.

Re: Postel’s Principle is a Bad Idea

#16

Post by tedunangst »

benatkin wrote: post #12

I'd be more interested in reading a paper called How JSON escaped Postel's Principle which included discussion on the ambiguity being pushed to other areas, such as date parsing.

Once upon a time, somebody wrote a json parser that used an existing date parser because component reuse is the shizzle. Then somebody updated the date parser to handle more formats because they were using it in a different project. Congratulations, now you have a json parser that eats a multitude of date formats. (Some liberties with facts taken, but building a tower out of flexible components results in a flexible tower.)

Re: Postel’s Principle is a Bad Idea

#19

Post by MichaelGG »

gruseom wrote: post #3
tptacek wrote: post #2

Postel's Principle was very important for bootstrapping adoption of TCP/IP, but it's mostly a curse in mature systems. It doesn't even help new implementors; instead, it deceives them into thinking that they've achieved interoperability when instead they've accidentally built dependencies on other people's implementation details. That said, I wouldn't suggest that our Insertion, Evasion paper presented an argument re…

when instead they've accidentally built dependencies on other people's implementation details I think it would be very interesting if you could give an example or two of this.

Here's the general outline.

Vendor A writes a parser that is helpful and is liberal and infers missing quotes and stuff. Vendor B writes something that's mostly to spec, but accidentally doesn't properly quote things. It works fine, because A is liberal and infers these quotes.

Vendor C comes along and builds exactly to spec. But despite being perfectly to spec, it doesn't interop because B sends invalid data! But B is a big vendor, and their stuff works with A.

So now C must add a hack to their parser to deal with the fact that, because A was liberal, B got their implementation wrong.

One example is the loose routing parameter, "lr". It has no value, you just add the name of the parameter "uri;lr" in contrast to other parameters like "tag=bla". Some implementations send "lr=on", and that should be mostly harmless. Except other implementations take that to mean "lr" has a value, and no longer accept just "lr" as turning the feature on.

SIP is full of these things, many of them in the parsing layer alone, let alone actual semantics of what things mean. Browsers are another example: vendor A decides to allow closing tags out of order - how do you do handle such unspecified stuff cross browser?

Re: Postel’s Principle is a Bad Idea

#20

Post by MichaelGG »

mmahemoff wrote: post #18

Browser tolerance for HTML errors is one of the main reasons the web took off so fast.

Citation needed? Is there any reason to believe that if the browsers had insisted on wellformed documented and provided errors like "error at line X, table tag not closed" that people would not have been able to fixup documents? I don't believe that's would have stopped things.

But that exact behaviour, trying to infer intent, meant that tons of unspecified behaviour had to be added to all browsers to try to mimic which each one did to handle totally invalid cases.

So, even if leniency did make it easier to create a web page, it also contributed greatly to the already difficult task of creating consistent cross-browser rendering.

Look at JavaScript, and the recent semi-colon debacle with Bootstrap and some other tool. Having "implementer defined" leniency just means you'll get multiple interpretation and problems.

Post reply on HN