idnits 2.17.1 draft-yasskin-wpack-ecosystem-effects-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 07, 2019) is 1660 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 196 -- Looks like a reference, but probably isn't: '2' on line 198 -- Looks like a reference, but probably isn't: '3' on line 200 -- Looks like a reference, but probably isn't: '4' on line 202 == Outdated reference: A later version (-09) exists of draft-yasskin-http-origin-signed-responses-07 == Outdated reference: A later version (-04) exists of draft-yasskin-wpack-bundled-exchanges-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yasskin 3 Internet-Draft Google 4 Intended status: Informational October 07, 2019 5 Expires: April 9, 2020 7 Ecosystem Effects of Web Packaging 8 draft-yasskin-wpack-ecosystem-effects-00 10 Abstract 12 This document analyzes how Web Packaging may affect the web 13 ecosystem. 15 Note to Readers 17 This document has NOT been reviewed widely and probably contains lots 18 of mistakes. 20 Discussion of this draft takes place on the wpack mailing list 21 (wpack@ietf.org), which is archived at 22 https://www.ietf.org/mailman/listinfo/wpack [1]. 24 The source code and issues list for this draft can be found in 25 https://github.com/jyasskin/wpack-ecosystem-effects [2]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. General . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. Aggregators . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 5. CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 6. Content Producers . . . . . . . . . . . . . . . . . . . . . . 4 67 7. Other effects not necessarily related to centralization . . . 4 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 10.1. Informative References . . . . . . . . . . . . . . . . . 4 72 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 5 74 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 5 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1. Introduction 79 Web Packaging, as currently defined in 80 [I-D.yasskin-wpack-bundled-exchanges] and 81 [I-D.yasskin-http-origin-signed-responses], is a system to allow 82 content authored by one web origin to be retrieved in an optionally- 83 trustworthy way from a peer or other intermediate server. The ESCAPE 84 conference [3] was chartered to (among other things) look for any 85 increase in consolidation that might result from standardizing Web 86 Packaging. The known possible effects on centralization and power 87 imbalances, arranged by the type of service provider, and not 88 filtered by benefit, harm, or likelihood, follow. 90 2. General 92 o The implementation of any new technology is a smaller fraction of 93 a large organization's budget, which pushes toward centralization. 95 3. Aggregators 97 o Aggregators' primary power comes from ranking: telling people that 98 they probably want to visit particular URLs. That's not affected 99 by packaging. 101 o Aggregators already rank based on sites' content and technology 102 choices. e.g. Google's promotion of HTTPS sites. Packaging can 103 give the aggregator more certainty about the user's experience, 104 which might lead to more intrusive requirements. 106 For example, the Google Search Carousel might be able to insist on 107 particular Javascript that could handle swipe gestures where they 108 might not be willing to rely on just having seen such JS on the 109 last crawl. However, packaged Javascript must also be able to 110 reload the page from the origin to deal with retracted content, 111 and that could break reliance on knowing the exact content in the 112 same way. 114 o Prefetch improves navigation speeds from aggregators that can 115 predict which links users will click. The ability to make that 116 prediction is an economy of scale which encourages centralization. 117 This is likely to have more effect for some kinds of aggregators 118 (search engines?) than others (news streams?). 120 4. Browsers 122 o Packages add pressure to have just one or a few versions of a 123 site's content, which might reduce publishers' willingness to 124 support lots of different browser engines with different features. 125 They'll either settle on the lowest common denominator with some 126 progressive enhancement or target the most popular couple engines, 127 which is likely to be Chromium (Google Chrome, Edge, Brave, 128 Samsung Internet, Opera, UC Browser, etc.) and WebKit (Safari), 129 disadvantaging Gecko (Firefox). 131 However, "we only tested in Chrome" is enough of a problem on the 132 online web that it's not clear how big an additional impact 133 packaging can have. 135 5. CDNs 137 o Adding a new kind of distribution might transfer traffic from CDNs 138 to large aggregators, which would reduce CDNs' revenue. 140 o However, CDNs will still be needed to serve URLs that users type 141 in, bookmark, or navigate to via same-site links, so there's 142 disagreement, even among employees of CDNs, about the likely size 143 of this effect. 145 o CDNs might be able to acquire even more traffic by offering 146 package caches to let smaller sites take advantage of prefetching. 148 6. Content Producers 150 o If Web Packages become an additional format publishers need to 151 produce (https://xkcd.com/927/ [4]), that will advantage the 152 larger publishers who can afford the engineering to maintain lots 153 of formats. If instead they replace at least 2 of the existing 154 formats (e.g. AMP, Apple News, Facebook Instant Articles), 155 that'll reduce that advantage of larger publishers and contribute 156 to decentralization. 158 o If aggregators use packaging to serve a significant fraction of 159 content producers' bytes for free, this reduces the amount the 160 producers need to pay CDNs, which would allow more marginal 161 content producers to stay profitable, increasing diversity. 163 7. Other effects not necessarily related to centralization 165 o When an aggregator prefetches a web package, the static content 166 will load instantly, but ads and other dynamic content will have a 167 visible delay. Personalization might have a delay or might be 168 loaded from local storage effectively instantly. It's not clear 169 what ecosystem effects the changes in loading speed are likely to 170 have. 172 8. Security Considerations 174 This document has no security implications. 176 9. IANA Considerations 178 This document has no actions for IANA. 180 10. References 182 10.1. Informative References 184 [I-D.yasskin-http-origin-signed-responses] 185 Yasskin, J., "Signed HTTP Exchanges", draft-yasskin-http- 186 origin-signed-responses-07 (work in progress), September 187 2019. 189 [I-D.yasskin-wpack-bundled-exchanges] 190 Yasskin, J., "Bundled HTTP Exchanges", draft-yasskin- 191 wpack-bundled-exchanges-02 (work in progress), September 192 2019. 194 10.2. URIs 196 [1] https://www.ietf.org/mailman/listinfo/wpack 198 [2] https://github.com/jyasskin/wpack-ecosystem-effects 200 [3] https://www.iab.org/activities/workshops/escape-workshop/ 202 [4] https://xkcd.com/927/ 204 Appendix A. Change Log 206 RFC EDITOR PLEASE DELETE THIS SECTION. 208 Appendix B. Acknowledgements 210 Thanks to the ESCAPE workshop attendees for coming up with many of 211 the effects in this document. 213 Author's Address 215 Jeffrey Yasskin 216 Google 218 Email: jyasskin@chromium.org