Postel’s Principle is a Bad Idea
programmingisterrible.com
Postel’s Principle is a Bad Idea
1–10 of 62 posts
Re: Postel’s Principle is a Bad Idea
#2Postel'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 regarding the Principle in either direction. Even if we forbad leniency, there'd still be ambiguous standards.
Re: Postel’s Principle is a Bad Idea
#3Postel'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.
Re: Postel’s Principle is a Bad Idea
#4As a counterpoint, perhaps it is reasonable, if interpreted more strictly.
Taking the perl-over-c-stdlib example (but I think it applies in other cases), if the "perl layer" was more strict in what it sent to the stdlib layer, there would have been no problem.
i.e. the error is in thinking of only the network as the place to apply the maxim. In fact, you should scrupulously adhere to every interface you pass data to (internal or external) - and interpret as reasonably as possible all interfaces you receive data from.
[I'd agree that the latter pt can be weakened. But it does help interop - and if you clean up your act before you hit the next layer then you limit any damage.]
Re: Postel’s Principle is a Bad Idea
#5Postel'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.
I should do better than this, but my flight to SF takes off in just over an hour, so for now: the first paper this article linked to (I wrote it with Tim Newsham) is a study in how you can compare implementation details between two TCP/IP stacks and use them to sneak traffic past a middlebox that assumes one interpretation or the other. The example that comes to mind is putting data in a TCP SYN segment.
Re: Postel’s Principle is a Bad Idea
#6Postel'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.
Two off the top of my head:
* A classic would be IE's abuse of TCP RST: http://www.stroppykitten.com/cms/index.php?option=com_conten...
* A decent chunk of email server code (SMTP & IMAP implementations in particular) is there to handle erroneous client behaviours. The worst cases are those where the workaround leads to misbehaviours (or less optimal behaviours) for conforming clients. If I remember correctly, the popular Outlook series of clients is a notorious source of such warts. A number of SMTP sender libraries will skip over significant parts of the protocol state machine; configuring a mail server to handle that degenerate case can weaken its anti-spam provisions.
Re: Postel’s Principle is a Bad Idea
#7Postel'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.
Windows software is a similar case - a program works on one version of Windows due to accidental dependencies on Windows implementation details (e.g. memory management), and then fails on the next version of Windows when the underlying implementation changes. Raymond Chen has written about the huge difficulty for Windows to maintain backwards compatibility with "broken" programs. New versions of Windows provide special-case handling for old applications so they will still run. See http://www.joelonsoftware.com/articles/APIWar.html and scroll way down to "The Two Forces at Microsoft" for a long discussion of this, and how Apple is much stricter.
Re: Postel’s Principle is a Bad Idea
#8As a counterpoint, perhaps it is reasonable, if interpreted more strictly. Taking the perl-over-c-stdlib example (but I think it applies in other cases), if the "perl layer" was more strict in what it sent to the stdlib layer, there would have been no problem. i.e. the error is in thinking of only the network as the place to apply the maxim. In fact, you should scrupulously adhere to every interface you pass data to…
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 stuff.
Re: Postel’s Principle is a Bad Idea
#9It seems to me it is a very valid principle in many areas.
For instance, the STEP file standard very clearly states that all input files must be 7-bit ASCII. Many of the programs that generate these files (including earlier versions of my own) paid no attention to this and wrote out 8-bit values in strings if the user requested it. Clearly this behavior is wrong. (The principle agrees: "Be conservative in what you do.")
However, rejecting an entire CAD file merely because the text strings in it used an illegal encoding is downright silly. It in no way can change the meaning of the geometry of the file. There is no hidden vector in there for malicious attacks. It makes perfect sense to accept illegal files like this and do your best to make them work, even if it might not get quite the same text strings the user intended.
I think jbert's point about being conservative in what you do in all respects is a strong one. Taking that into account suggests that maybe carefully marking the illegal character as such in the string might well be worthwhile, and is definitely more appropriate than trying to guess what 8-bit character standard was intended.
Re: Postel’s Principle is a Bad Idea
#10As a counterpoint, perhaps it is reasonable, if interpreted more strictly. Taking the perl-over-c-stdlib example (but I think it applies in other cases), if the "perl layer" was more strict in what it sent to the stdlib layer, there would have been no problem. i.e. the error is in thinking of only the network as the place to apply the maxim. In fact, you should scrupulously adhere to every interface you pass data to…
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 to establish communication would do. It was also, iirc, influenced by some of the difficulties ARPANET had experienced in getting different implementations to interoperate. But it may make less sense today.