A place to cache linked articles (think custom and personal wayback machine)
您最多选择25个主题 主题必须以字母或数字开头,可以包含连字符 (-),并且长度不得超过35个字符

4 年前
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285
  1. <!doctype html><!-- This is a valid HTML5 document. -->
  2. <!-- Screen readers, SEO, extensions and so on. -->
  3. <html lang="fr">
  4. <!-- Has to be within the first 1024 bytes, hence before the <title>
  5. See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
  6. <meta charset="utf-8">
  7. <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
  8. <!-- The viewport meta is quite crowded and we are responsible for that.
  9. See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
  10. <meta name="viewport" content="width=device-width,initial-scale=1">
  11. <!-- Required to make a valid HTML5 document. -->
  12. <title>RFC8890: The Internet is for End Users (archive) — David Larlet</title>
  13. <meta name="description" content="Publication mise en cache pour en conserver une trace.">
  14. <!-- That good ol' feed, subscribe :). -->
  15. <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
  16. <!-- Generated from https://realfavicongenerator.net/ such a mess. -->
  17. <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
  18. <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
  19. <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
  20. <link rel="manifest" href="/static/david/icons2/site.webmanifest">
  21. <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
  22. <link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
  23. <meta name="msapplication-TileColor" content="#f0f0ea">
  24. <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
  25. <meta name="theme-color" content="#f0f0ea">
  26. <!-- Documented, feel free to shoot an email. -->
  27. <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css">
  28. <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
  29. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
  30. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
  31. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
  32. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  33. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  34. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  35. <script type="text/javascript">
  36. function toggleTheme(themeName) {
  37. document.documentElement.classList.toggle(
  38. 'forced-dark',
  39. themeName === 'dark'
  40. )
  41. document.documentElement.classList.toggle(
  42. 'forced-light',
  43. themeName === 'light'
  44. )
  45. }
  46. const selectedTheme = localStorage.getItem('theme')
  47. if (selectedTheme !== 'undefined') {
  48. toggleTheme(selectedTheme)
  49. }
  50. </script>
  51. <meta name="robots" content="noindex, nofollow">
  52. <meta content="origin-when-cross-origin" name="referrer">
  53. <!-- Canonical URL for SEO purposes -->
  54. <link rel="canonical" href="https://www.mnot.net/blog/2020/08/28/for_the_users">
  55. <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">
  56. <article>
  57. <header>
  58. <h1>RFC8890: The Internet is for End Users</h1>
  59. </header>
  60. <nav>
  61. <p class="center">
  62. <a href="/david/" title="Aller à l’accueil">🏠</a> •
  63. <a href="https://www.mnot.net/blog/2020/08/28/for_the_users" title="Lien vers le contenu original">Source originale</a>
  64. </p>
  65. </nav>
  66. <hr>
  67. <main>
  68. <p class="intro">The <a href="https://iab.org/">Internet Architecture Board</a> (IAB) has published <a href="https://www.rfc-editor.org/rfc/rfc8890.html">RFC8890, <em>The Internet is for End Users</em></a>, arguing that the <a href="https://ietf.org/">Internet Engineering Task Force</a> (IETF) should ground its decisions in what’s good for people who use the Internet, and that it should take positive steps to achieve that.</p>
  69. <p class="intro">Why does this need to be said? Is it going too far? Who else could they favour, and why should you care? As author of the RFC and a member of the IAB that passed it, here are my thoughts.</p>
  70. <h3 id="how-the-internet-is-made">How the Internet is made</h3>
  71. <p>The IETF plays a central role in the design and operation of the Internet. Formed in the 1980s by the engineers who created several of the Internet’s core technologies, it is the primary venue for documenting the technical design of the Internet, and has overseen development of protocols like TCP, IP, DNS and HTTP.</p>
  72. <p>Companies, governments and other organisations don’t officially participate in the IETF; people only represent themselves. There isn’t even a concept of membership. Instead, decisions about specifications are made by ‘rough consensus’ — instead of formal voting, the IETF tries to find the best solution for each issue, based upon the ideas, comments and concerns brought to it.</p>
  73. <p>‘Best' doesn't mean the choice that has the most companies supporting it; it’s the one that has the best technical arguments behind it. Working Group chairs measure that consensus; if someone thinks they got it wrong, they can appeal it through a chain of authorities selected for their experience.</p>
  74. <p>Or, in the words of the unofficial IETF credo: ‘We reject kings, presidents and voting. We believe in rough consensus and running code.’</p>
  75. <h3 id="technical-or-political-both">Technical or political? Both</h3>
  76. <p>Naturally, most IETF decisions are about technical details; what bytes should go where, how a server reacts to a client, and so on. Because of this, participants often tell themselves that their decisions aren't ever political; that any such concerns are on ‘layer 8’ — referring to the stack of seven abstractions commonly used for network protocols — and therefore nothing to be concerned about.</p>
  77. <p class="callout">“[T]he running code that results from our process (when things work well) inevitably has an impact beyond technical considerations, because the underlying decisions afford some uses while discouraging others.”<br/>
  78. — <em><a href="https://www.rfc-editor.org/rfc/rfc8890.html">The Internet is for End Users</a></em></p>
  79. <p>However, the barrier between the bits on the wire and political matters has turned out to be leaky, like <a href="https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/">most abstractions are</a>. Sometimes the ability to send information (or the prevention of it) has real-world consequences that take power from some people and give it to others. Likewise with the ability to see what other people are saying, and to control the format in which they speak.</p>
  80. <p>So, in a world that is increasingly intertwined with the Internet, it’s becoming more difficult to maintain the position that the design of Internet protocols doesn't have a political dimension. All decisions have the possibility of bias; of advantaging or disadvantaging different parties.</p>
  81. <p>For example, the recent standardisation of <a href="https://tools.ietf.org/html/rfc8484">DNS-over-HTTPS</a> (DoH) pitted advocates for dissidents and protestors against network operators who use DNS for centralised network management, and child safety advocates who promote DNS-based filtering solutions. If the IETF were to only decide upon technical merit, how would it balance these interests?</p>
  82. <p>Another example is the <a href="https://tools.ietf.org/html/draft-ietf-tls-esni">Encrypted Client Hello proposal</a>, which closes a loophole that shares the identity of HTTPS sites you visit with anyone listening. China has <a href="https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/">reportedly started blocking connections that use it</a>, so in a purely technical sense, it will not work well because some networks block it. Should the IETF stop working on it?</p>
  83. <p>Yet another example: how should the IETF handle a proposal to allow networks to decrypt or intermediate HTTPS connections? Is that OK if it’s merely technically sound? What if the user agrees to it, and what does ‘consent’ mean? Many such proposals have been made, but not approved. Why?</p>
  84. <p>If the IETF’s decisions affect the design of the Internet, and the Internet is political, the IETF’s decisions are sometimes political too. However, its decision-making processes presume that there is a technically correct answer to each problem. When that decision affects people and power in the actual world, rough consensus and running code are insufficient.</p>
  85. <p>Over the years, these questions have become increasingly urgent, because it isn’t viable to make decisions that have political outcomes but explain them using only technical arguments. That endangers the legitimacy of the IETF’s decisions, because they can be viewed as arbitrary, especially by those on the losing side.</p>
  86. <p>Many rule-making systems — whether they be courts, legislatures or standards bodies — establish legitimacy by taking a principled approach. A community that agrees to principles that are informed by shared values can use them to navigate hard decisions. It's reasonable, then, to consider the principles that the IETF uses to guide development of the Internet.</p>
  87. <h3 id="the-internets-principles">The Internet’s principles</h3>
  88. <p>The Internet as we know it is a product of the times in which it grew up. The rule of law and liberal values of equality, reason, liberty, rights, and property were all dominant in the political landscape of post-war America and Europe, where most early Internet development took place.</p>
  89. <p class="callout">“The IETF community wants the Internet to succeed because we believe that the existence of the Internet, and its influence on economics, communication, and education, will help us to build a better human society.”<br/>
  90. — <em><a href="https://tools.ietf.org/html/rfc3935">A Mission Statement<br/>
  91. for the IETF</a></em></p>
  92. <p>The Internet has implicitly embedded those values. You don’t need a license (or even to disclose your identity) to use it, and its technical underpinnings make it difficult to impose that requirement. Anyone can publish, and as a result it takes significant effort for a government to restrict the rights to speech and free assembly on it — again due in part to the way it is designed. There isn’t any central authority that decides what networks can or can’t attach to the Internet. You can create a new Internet application without getting permission first (just like Tim Berners-Lee did so long ago when he created the Web). Such openness is often cited as critical to the Internet’s success.</p>
  93. <p>However, implicit values can drift, as new people get involved in the work, and as new challenges are faced. This is especially true when the resulting decisions can have profound effects on both profits and societies. So, over the years, the IETF community has made progress in documenting explicit principles that can guide decision-making.</p>
  94. <p>For example, <a href="https://tools.ietf.org/html/rfc7258">RFC7258</a> <em>Pervasive Monitoring Is an Attack</em> established IETF consensus that it’s bad for the Internet to allow widespread, covert monitoring, and that therefore the IETF would design its protocols to mitigate this risk —a technical argument with both political motivation and ramifications.</p>
  95. <p>Likewise, <a href="https://tools.ietf.org/html/rfc6973">RFC6973</a> documents <em>Privacy Considerations for Internet Protocols</em>, and <a href="https://tools.ietf.org/html/rfc8752">RFC8752</a> reports on an IAB workshop that explored the power dynamics between news publishers and large online platforms.</p>
  96. <p>Or, consider the <a href="http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf">end-to-end principle</a>, which states that features for applications should reside in the end nodes (for example, your computer or phone) rather than in the network.</p>
  97. <p>The IETF community will (I hope) continue to document and explore such principles, informed by shared values. RFC8890 makes a small contribution to this, by asking the IETF community to favour end users of the Internet — in other words, actual people — over other stakeholders that ask for their needs to be met, when there’s a conflict.</p>
  98. <h3 id="we-cant-just-stick-to-the-technology">We can’t just stick to the technology</h3>
  99. <p>If the IETF didn’t have any underlying principles, it would just focus on technology. A few detractors of <em>The Internet is for End Users</em> have said that’s exactly what it should do. That means that it would publish any proposal, no matter what its effects, provided that it was technically sufficient.</p>
  100. <p>Some standards bodies already operate in that fashion; as long as you can get a few people (or more often, companies) together and agree on something, you can get it published. The IETF does not; it often declines to adopt proposals.</p>
  101. <p class="callout">“When the IETF takes ownership of a protocol or function, it accepts the responsibility for all aspects of the protocol, even though some aspects may rarely or never be seen on the Internet.”<br/>
  102. — <em><a href="https://tools.ietf.org/html/rfc3935">A Mission Statement<br/>
  103. for the IETF</a></em></p>
  104. <p>That ability to refuse is meaningful to many people inside and outside the organisation; the IETF standardising something implies that it is good for the Internet, and has been reviewed not only for technical suitability but also adherence to the principles that inform the Internet’s design. In other words, the IETF is a quality filter; if a specification achieves consensus there, it gets deployed more broadly and easily (although it’s not a guarantee of success by any means) because people know it’s had that scrutiny.</p>
  105. <p>Abdicating that role just to avoid thinking about and applying principles would not be good for the Internet. While it might gain a few participants eager to take advantage, it would lose many — including many of those who are still invested in the Internet as a force for good in the world.</p>
  106. <p>Doing so would also affect the legitimacy of the IETF’s role in Internet governance in many eyes. There is a long history of <a href="https://thebulletin.org">scientists</a> and <a href="http://www.apple.com/au/">engineers</a> being concerned with how their work affects the world, and its potential for misuse. The IETF has continued this tradition, and should do so openly.</p>
  107. <h3 id="getting-comfortable-with-the-ietfs-power">Getting comfortable with the IETF’s power</h3>
  108. <p>If the IETF is making decisions based upon what it thinks is good for users, is it setting itself up as being some sort of governing body, taking power away from governments and other institutions? Isn’t it dangerous to leave such important matters in the hands of the geeks who show up, and who don’t have any democratic legitimacy?</p>
  109. <p>First of all, a reality check. IETF decisions are only about documents; they don’t control the Internet. Other parties like equipment and software vendors, end users, platform and network operators and ultimately governments have a lot more say in what actually happens on the Internet from day to day.</p>
  110. <p>What the IETF has is a proven ability to design protocols that work at scale, the ability to steer a proposal to align with its principles, and a reputation that gives its documents a certain amount of gravitas. These draw those parties to the IETF as a venue for standardisation, and their power flows into the specifications it endorses — especially when a protocol has momentum, like HTTP or IP. It doesn’t work the other way around; if an IETF standard doesn’t catch on with implementers and users, it gets ignored (and many have).</p>
  111. <p><em>The Internet is for End Users</em> argues that this soft power should be explicitly acknowledged, so that participants are more conscious of the real-world ramifications of their decisions.</p>
  112. <p>DNS over HTTPS is an interesting case study. It got the IETF <a href="https://hansard.parliament.uk/Lords/2019-05-14/debates/E84CBBAE-E005-46E0-B7E5-845882DB1ED8/InternetEncryption">mentioned in the UK Parliament</a> by Baroness Thornton, a child safety advocate concerned about DoH’s use to bypass DNS-based controls mandated by UK law:</p>
  113. <blockquote>
  114. <p>’[T]here is a fundamental and very concerning lack of accountability when obscure technical groups, peopled largely by the employees of the big internet companies, take decisions that have major public policy implications with enormous consequences for all of us…’</p>
  115. </blockquote>
  116. <p>However, DoH was designed, contributed and ultimately deployed by participants from Web browsers, not the IETF, who cannot stop vendors from deploying a protocol it doesn’t approve of (as is often said, ‘there are no standards police.’). The IETF’s contribution was putting the specification through its process to assess its technical suitability and adherence to established principles.</p>
  117. <p>Did the IETF create a better internet when it approved DoH? There’s a lot of disagreement about that, but what has upset many is that DoH was a surprise — the IETF standardised it without consulting some who it was likely to affect. Here, the IETF could have done better. <em>The Internet is for End Users</em> argues that such consultation is important, to assure that the people writing and reviewing the protocols understand how they will be used, and how they will impact users.</p>
  118. <p>In the case of DoH, better communication between the technical community (not just big tech companies) and policymakers would clarified that relying on DNS to impose filtering was a bad assumption, in light of the principles underlying the design of the Internet.</p>
  119. <p class="callout">“From its inception, the Internet has been, and is expected to remain, an evolving system whose participants regularly factor new requirements and technology into its design and implementation. Users of the Internet and providers of the equipment, software, and services that support it should anticipate and embrace this evolution as a major tenet of Internet philosophy.”<br/>
  120. — <em><a href="https://tools.ietf.org/html/rfc2026">The Internet Standards Process</a></em></p>
  121. <p>However, that consultation does not translate to giving other parties a veto over Internet protocols. The UK Government or any other external authority should not be able to stop the IETF from creating a particular standard, or to hold it directly accountable; that would be a radical break from how the Internet has been developed for over thirty years. Because of the global nature of the Internet, it wouldn’t be possible to pursue a bilateral or regional style of governance; decisions would have to be sanctioned by every government where the Internet operates. That’s difficult to achieve even for vague statements of shared goals; doing it for the details of network protocols is impractical.</p>
  122. <p>Who, then, is the IETF accountable to? Besides the internal rules which assure that the standards process runs in a way that’s accountable to the technical community, ultimately the IETF is accountable to the Internet; if it strays too far from what vendors, networks, users, and governments want to do, it will lose relevance. As with any platform, the Internet is a beneficiary of the network effect, and if the IETF leads it in a direction that’s unacceptable in too many places, the Internet might fragment into several networks — a risk currently on many people’s minds.</p>
  123. <h3 id="finding-whats-best-for-end-users">Finding what’s best for end users</h3>
  124. <p>There are also bound to be situations where what is best for end users is not obvious. Some will claim that giving other parties power — to filter, to monitor, to block — is in the interest of end users. How will the IETF make those decisions?</p>
  125. <p>Unsurprisingly, this has already happened; it <a href="https://tools.ietf.org/html/rfc2804">refused to standardise wiretapping technology</a>, for example. In doing so, it applied technical reasoning informed by principles and the global nature of the Internet; designing Internet standards to suit the laws of one or a few countries isn’t appropriate.</p>
  126. <p>That is echoed by <em>The Internet is for End Users</em>, which says:</p>
  127. <blockquote>
  128. <p>[W]hen a decision improves the Internet for end users in one jurisdiction, but at the cost of potential harm to others elsewhere, that is not a good tradeoff. As such, we effectively design the Internet for the pessimal environment.</p>
  129. </blockquote>
  130. <p>Even with careful thought, technical acumen and broad consultation, the IETF is bound to get some decisions wrong. That’s OK. RFC stands for Request for Comments, and in that spirit, sometimes the comments — evidenced by adoption and deployment as well — tell us to revise our specifications. That spirit of humility is still very much alive in the IETF community.</p>
  131. <h3 id="next-steps">Next steps</h3>
  132. <p>The Internet has been with us for almost 40 years and has contributed to profound changes in society. It currently faces serious challenges — issues that require input from policymakers, civil society, ordinary citizens, businesses and technologists.</p>
  133. <p>It’s past time for technologists to both become more involved in discussions about how to meet those challenges, and to consider broader views of how the technology they create fits into society. Without good communication, policymakers are prone to making rules that doesn’t work with the technology, and technologists are prone to creating technology naïve to its policy implications.</p>
  134. <p>So at its heart, <em>The Internet is for End Users</em> is a call for IETF participants to stop pretending that they can ignore the non-technical consequences of their decisions, a call for broader consultation when making them, and one for continued focus on the end user. Ultimately, end user impact is as least as important as the technical considerations of a proposal, and judging that impact requires a more serious effort to understand and incorporate other non-technical views.</p>
  135. <p><em>The Internet is for End Users</em> is an IAB document; it doesn't have IETF consensus. As such, it doesn’t bind IETF decisions, but it is considered persuasive because the IAB has a mandate to consider issues affecting the Internet architecture.</p>
  136. <p>On its own, then, it has limited effect. I view it as a small contribution to a larger body of principled thought that can help inform decisions about the evolution of the Internet. It’s up to all of us to apply those principles and develop them further.</p>
  137. <p><em>Thanks to Martin Thomson and Eric Rescorla for reviewing this article.</em></p>
  138. </main>
  139. </article>
  140. <hr>
  141. <footer>
  142. <p>
  143. <a href="/david/" title="Aller à l’accueil">🏠</a> •
  144. <a href="/david/log/" title="Accès au flux RSS">🤖</a> •
  145. <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> •
  146. <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
  147. <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
  148. </p>
  149. <template id="theme-selector">
  150. <form>
  151. <fieldset>
  152. <legend>Thème</legend>
  153. <label>
  154. <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
  155. </label>
  156. <label>
  157. <input type="radio" value="dark" name="chosen-color-scheme"> Foncé
  158. </label>
  159. <label>
  160. <input type="radio" value="light" name="chosen-color-scheme"> Clair
  161. </label>
  162. </fieldset>
  163. </form>
  164. </template>
  165. </footer>
  166. <script type="text/javascript">
  167. function loadThemeForm(templateName) {
  168. const themeSelectorTemplate = document.querySelector(templateName)
  169. const form = themeSelectorTemplate.content.firstElementChild
  170. themeSelectorTemplate.replaceWith(form)
  171. form.addEventListener('change', (e) => {
  172. const chosenColorScheme = e.target.value
  173. localStorage.setItem('theme', chosenColorScheme)
  174. toggleTheme(chosenColorScheme)
  175. })
  176. const selectedTheme = localStorage.getItem('theme')
  177. if (selectedTheme && selectedTheme !== 'undefined') {
  178. form.querySelector(`[value="${selectedTheme}"]`).checked = true
  179. }
  180. }
  181. const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
  182. window.addEventListener('load', () => {
  183. let hasDarkRules = false
  184. for (const styleSheet of Array.from(document.styleSheets)) {
  185. let mediaRules = []
  186. for (const cssRule of styleSheet.cssRules) {
  187. if (cssRule.type !== CSSRule.MEDIA_RULE) {
  188. continue
  189. }
  190. // WARNING: Safari does not have/supports `conditionText`.
  191. if (cssRule.conditionText) {
  192. if (cssRule.conditionText !== prefersColorSchemeDark) {
  193. continue
  194. }
  195. } else {
  196. if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
  197. continue
  198. }
  199. }
  200. mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
  201. }
  202. // WARNING: do not try to insert a Rule to a styleSheet you are
  203. // currently iterating on, otherwise the browser will be stuck
  204. // in a infinite loop…
  205. for (const mediaRule of mediaRules) {
  206. styleSheet.insertRule(mediaRule.cssText)
  207. hasDarkRules = true
  208. }
  209. }
  210. if (hasDarkRules) {
  211. loadThemeForm('#theme-selector')
  212. }
  213. })
  214. </script>
  215. </body>
  216. </html>