Content deleted Content added
m Reverted 1 edit by 199.249.109.189 (talk) to last revision by The Anome |
Citation bot (talk | contribs) Add: doi, volume, s2cid. | Use this bot. Report bugs. | Suggested by Abductive | Category:Computer architecture statements | #UCB_Category 15/28 |
||
Line 8:
== Interpretation ==
RFC 1122 (1989) expanded on Postel's principle by recommending that programmers "assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect".<ref>{{cite IETF |title=Requirements for Internet Hosts: Communication Layers |rfc=1122 |editor1-last=Braden |editor1-first=R. |editor1-link=Bob Braden |date=October 1989 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=June 9, 2014}}</ref> Protocols should allow for the addition of new codes for existing fields in future versions of protocols by accepting messages with unknown codes (possibly logging them). Programmers should avoid sending messages with "legal but obscure protocol features" that might expose deficiencies in receivers, and design their code "not just to survive other misbehaving hosts, but also to cooperate to limit the amount of disruption such hosts can cause to the shared communication facility".<ref name="Wilde2012">{{cite book |last=Wilde |first=Erik |title=Wilde's WWW: Technical Foundations of the World Wide Web |url=https://archive.org/details/springer_10.1007-978-3-642-95855-7 |date=2012 |orig-year=1999 |publisher=Springer‑Verlag |doi=10.1007/978-3-642-95855-7 |isbn=978-3-642-95855-7| page=[https://archive.org/details/springer_10.1007-978-3-642-95855-7/page/n48 26]|s2cid=19897299 }}</ref>
== Criticism ==
Line 16:
From 2015 to 2018, in a series of [[Internet Draft]]s, Martin Thomson argues that Postel's robustness principle actually leads to a ''lack'' of robustness, including security:<ref>{{cite IETF |title=The Harmful Consequences of the Robustness Principle |last=Thomson |first=Martin |date=May 2019 |url=https://tools.ietf.org/html/draft-iab-protocol-maintenance |publisher=[[Internet Engineering Task Force|IETF]] |access-date=October 4, 2019}}</ref>{{Quote|A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. This is both a consequence of applying the robustness principle, and a product of a natural reluctance to avoid fatal error conditions. Ensuring interoperability in this environment is often referred to as aiming to be "[[Bug compatibility|bug for bug compatible]]".}}
In 2018, a paper on [[privacy-enhancing technologies]] by Florentin Rochet and Olivier Pereira showed how to exploit Postel's robustness principle inside the [[Tor (anonymity network)|Tor]] [[Onion routing|routing protocol]] to compromise the anonymity of onion services and Tor clients.<ref>{{cite journal | url = https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf | title = Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols | first1 = Florentin | last1 = Rochet | first2= Olivier | last2 = Pereira | journal = Proceedings of the Privacy Enhancing Technologies Symposium | issn = 2299-0984 | publisher = De Gruyter Open | year = 2018 | volume = 2018 | issue = 2 | pages = 27–46 | doi = 10.1515/popets-2018-0011 }}</ref>
== See also ==
| |||