| RFC 8752 | ESCAPE Workshop Report | March 2020 |
| Thomson & Nottingham | Informational | [Page] |
The Exploring Synergy between Content Aggregation and the Publisher Ecosystem(ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) inJuly 2019. This report summarizes its significant points of discussion andidentifies topics that may warrant further consideration.¶
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc8752.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF).¶
The IAB convened the ESCAPE Workshop to examine some proposed changes to the Internetand the Web, and their potential effects on the Internet publishing landscape.Of particular interest was the Web Packaging proposal from Google, underconsideration in the IETF, the W3C's Web Incubator Community Group (WICG), andthe Web Hypertext Application Technology Working Group (WHATWG).¶
In considering these proposals, we heard about both positive effects of WebPackaging and concerns that it could have significant effects on therelationship between publishers (e.g., news web sites) and content aggregators(e.g., search engines and social networks). As such, our focus was primarily onthis relationship, rather than technical discussion.¶
Online publishers do not regularly participate in standards activitiesdirectly. A workshop format was used to solicit input from them. The workshophad 27 participants from a diverse set of backgrounds, including a small numberof attendees from publishers, one aggregator (Google), plus representatives frombrowsers, the Accelerated Mobile Pages (AMP) community, Content Distribution Networks (CDNs), network operators, academia, and standardsbodies. See the workshop call for papers[CFP] for more informationand a complete listing of submissions.¶
As intended, the workshop was primarily a forum for discussion, so it did notreach definite conclusions. Instead, this report is the primary output of theworkshop, as a record of that discussion.¶
This report documents the use cases discussed inSection 2 and explains theinteractions between publishers and aggregators that might be affected by it inSection 3.Appendix A includes more details about the workshopitself. For those unfamiliar with Web Packaging,Appendix B provides a summaryas background material.¶
Participants agreed to conduct the workshop under the Chatham House Rule[CHATHAM-HOUSE], so this report does not attribute statements to individualsor organizations without express permission. Submissions to the workshop werepublic and thus attributable; they are used here to provide substance andcontext.¶
Much of the workshop concentrated on discussion of the validity and relativemerits of the use cases that might be enabled by Web Packaging. SeeAppendix B for an overview of Web Packaging.¶
The largest use of Web Packaging so far is in Google Search, where packages areintended to improve the perceived performance of navigation to pages that arelinked from search results when "clicked".¶
To enable this, when a linking (or referring) web page includes links to pageson another site, it also provides the browser with a packaged copy of the targetcontent, signed by the origin of the target content. In effect, the referringpage provides a cache for the target page's content. If navigation to one ofthose links occurs, having the Web Package gives a browser the assurance thatthe cache didn't change the content, so it can treat that content as if it wereacquired directly from the server for the target page -- even though it came froma different server. In many cases, this results in significantly lower perceiveddelay in displaying the target page.¶
A vital characteristic of this technique is that the browser does not contactthe target site before navigation. The browser does not make any requests tosites until after navigation occurs, and only then if the site requiresadditional content or makes a request directly.¶
Similar improvements could also be realized by downloading content (packaged orotherwise) directly from the target site through a technique called"prefetching". However, doing so would reveal information about the user'sactivity on the linking page to those sites -- even when the user never actuallynavigates to it.¶
Note: This technique that uses Web Packaging is also referred to as"privacy-preserving prefetch". This document avoids that term as there wassome contention at the workshop about which aspects of privacy might bepreserved by the technique.¶
Sites bundled with Web Packaging can additionally be constructed in a way thatensures that they render without needing any additional network access. Thismakes it possible to provide near-instantaneous navigation. The proposed changesto web navigation in support of loading Web Packages is designed to support thisuse case.¶
Workshop participants recognized the value of web performance for usability, aswell as for business metrics like retention and bounce rates. Such improvementswere seen as a valuable goal, but publishers raised questions about whether theyjustified the cost of supporting an additional format, while others raisedconcerns about different aspects of the Web Packaging proposal.¶
Another primary use case discussed was the ability to share web content betweendevices where neither has an active connection to the Internet. One of thestated goals of Web Packaging is to enable sharing of content offline.¶
Several participants reported that in areas where Internet access is expensive,slow, or intermittent, the use of direct peer-to-peer file exchange (e.g.,"saving a website and sharing it on a USB stick") is commonplace. Most webbrowsers already have some affordances for this, but these are recognized as inneed of improvements.¶
In the discussion, several rejected an assumed requirement of this use case -- that there be no difference between the treatment of a "normal" web page andthat of one loaded from an offline Web Package.¶
The ability for a Web Package to provide clear attribution for content was seenas valuable by some participants for a range of reasons. However, reservationswere expressed about the subtleties of the properties that signatures provideand the effect of this on web security; see also Sections4.2 and2.3.2.¶
Many participants pointed out that using "unsigned bundles" -- that is, WebPackages without signed exchanges -- could be adequate for this use case, sincemost users don't need cryptographic proof of the site's identity. However, someexpressed concerns that this might worsen the propagation of falsehood.¶
Some suggested that the value of signed exchanges was not realized insmall-scale interpersonal exchange of information but in the building ofsystems for content delivery that might include capabilities like discovery andautomated distribution. The contention here was that effective use of digitalsignatures in offline distribution of content implied considerably moreinfrastructure than was described in current proposals.¶
No definite conclusions about offline sharing were reached during the workshop.¶
A session on the second morning concentrated on two other significant potentialuse cases for Web Packages: book publishing and Web archiving. These were notseen as "primary" by the proponents of Web Packaging; the original intent wasnot to spend significant time on these subjects, but there was considerableinterest from attendees.¶
The potential application of a packaging format to book publishing wasdiscussed, with particular reference to ways that books differ from webcontent. Specialists from that industry pointed out that book delivery can varygreatly from typical web content delivery.¶
Workshop participants briefly explored existing solutions. PDF was seen asparticularly challenging for this use case, due to its limitations, and EPUBhas constraints that also make it challenging for publishers.¶
Although Web Packaging might help to address this use case, the question of howto identify book content was not resolved. The use of signed exchanges in thiscontext might offer means of tying content in books to a website, but severallimitations inherent in doing that were identified.¶
In particular, book publication specialists represented that books don't havethe same requirements for timeliness or currency as web pages. For instance,Dave Cramer's submission[CRAMER] observed that Moby Dick was publishedover 61,000 days ago, which is considerably longer than the proposed limit of 7days for signed exchanges. The limited length of time that a Web Package can beconsidered valid was discussed at some length.¶
Additionally, the risk of a publisher going out of business during the lifetimeof a book is significant, because books -- at least successful ones -- often spangenerations in their applicability. To that end, having a means of attributingcontent to a publisher was considered less practical and potentiallyundesirable (much like the discussion above regarding "unsigned bundles").¶
There were other aspects of book publication that participants saw aschallenging for packaging. For example, it is currently not understood what itmeans to refer to distinct parts of a book. Participants saw this as an area whereproviding stable references for bundles of content might offer possibilities,but nothing concrete came from that discussion.¶
The potential for active content in a bundle to use web APIs to enrich contentor enable new features was considered valuable. Models for enabling paywallswere discussed at some length (seeSection 5.4).¶
Web archiving is a complicated discipline that is made more difficult by thecomplex nature of the Web itself.¶
From an archival standpoint, the potential for web content to be provided in aself-contained form was viewed positively. Several improvements to thestructure of Web Packaging were considered, such as providing complete sets ofcontent and the use of Memento[MEMENTO].¶
Though there were potential applications of a packaging scheme, many challengeswere recognized as requiring additional work on the part of content producers tobe fully effective. For example, JavaScript is needed to render some archivedcontent faithfully, but attributing that content to an origin in all scenariosis challenging.¶
If packaging were to be widely deployed, it might improve the situation forarchival replay. In particular, the speculation is that there would be less "liveleakage" as packaged content might be less likely to refer to live resourcesthat currently tend to "leak" into views of archives. It was also noted thatsubresources might also be more likely to be packaged, especially those that areneeded for deferred representations (i.e., after JavaScript execution on thepage or some user interactions). Other potential applications and enhancementsare discussed in[ALAM].¶
Participants discussed the use of a signature for non-repudiation at somelength. In one case related to the Internet Archive, a public figure disputed theaccuracy of archived content, asserting that the original content wasmodified either at the source or in the archive.¶
Some participants initially saw digital signatures as a way to address suchissues of provenance. As similar problems exist in other areas, such as in bookpublication, medical research, and news, a solution to this problem wasconsidered to have broad applicability.¶
However, the discussion ultimately concluded that providing non-repudiation inretrospect is challenging. Signing keys are not expected to remain secure forlong periods. If keys are leaked afterwards, an attacker could retroactivelygenerate fraudulent signatures. Alternative solutions were discussed, such asproviding independent archives for the same data, using consensus protocols, orusing an append-only construct like a Haber-Stornetta log[AOLOG], all of which can be used to increase thedifficulty of altering or misrepresenting established archives.¶
A significant motivation for holding the workshop was to provide a forum wherepublishers could discuss the impact of Web Packaging on the online publishingecosystem. Of primary interest was whether Web Packages might effectively enablea transfer of power from publishers to aggregators.¶
Both publishers and aggregators at the workshop expressed the importance ofmaintaining a positive relationship. Publishers in particular expressed theneed to be able to trust that aggregators won't misrepresent their work orde-emphasize it for reasons unrelated to quality and perceived value to theuser.¶
One key question from[BERJON] was discussed:¶
Web Packaging has other uses, but it is primarily seen by a large proportion of its stakeholders as a solution to problems that AMP created. Before we agree to solve those issues, should we not ask if AMP was a useful approach in the first place -- and useful to whom?¶
In examining this issue, discussion focused on the current incentive modeloffered by aggregators. The costs that publishers incur for participation inthat system were considered. Considerable time was spent on AMP; a summary ofthat discussion can be found inSection 5.¶
We also considered the question of whether standardizing Web Packaging conferscredibility to aggregators exercising unwelcome control over publisher contentor whether the technical safeguards Web Packaging provides could allowaggregators to relax their restrictions on the kinds of content they're willingto cache and serve. No conclusions were drawn.¶
Submissions to the workshop indicated that the use of inducements involvingbetter placement and formatting of links to publisher content had a significanteffect on the uptake of related technology. For example, in[DEPUYDT-NELSON]:¶
[...] The Washington Post has always placed a great deal of trust in Google to represent its content--and their reward for doing so is more traffic, which positively impacts the business.¶
During the workshop, several online publishers indicated that if it weren't forthe privileged position in the Google Search carousel given to AMP content,they would not publish in that format.¶
Publishers that do produce AMP said they see a non-trivial increase in trafficas a result of deploying AMP content. For example, Yahoo Japan reported a 60%increase in traffic as a result of deploying AMP on Yahoo Travel[OTSU].There was no data presented as to whether this increase was due to betterplacement in Google Search results, the inherent benefits of the AMP Cache,or the use of the AMP format.¶
Anecdotal evidence was offered by another large publisher that saw a 10% dropin traffic as a result of accidentally disabling AMP content. However,increases in traffic might not result in similarly proportioned increases inrevenue, as observed in[BREWSTER].¶
Several participants pointed out that introducing a new, parallel format for Web content incurs operational costs. In particular, supporting any new format -- such as Web Packaging, Apple News, or Facebook Instant Articles -- requires not only initial development of tooling (some generic and some specific to a site's requirements) but also an ongoing investment in maintaining its operability. Some participants expressed concern about the impact upon small publishers with limited technical and financial resources, especially in the current publishing climate.¶
Increased exposure from new formats might not always justify the added expenseof providing articles in that format[BREWSTER]. However, a standardizedformat might help publishers reduce the cost of maintaining multiple formats.¶
The use of Web Packaging as a tool for avoiding censorship was not asignificant topic of discussion, except to note that publishers often haveregulatory requirements regarding removal or correction of content.¶
Reference was made to the desire to remove videos of a recent shooting[CHRISTCHURCH] and the potential difficulty in doing so if content wereavailable as Web Packages. Legal requirements to remove content come frommultiple angles: copyright violations, illegal content, editorial corrections orerrors, and right to erasure provisions in the European Union General DataProtection Regulation[GDPR] were mentioned. One participant speculated thatmaking it more difficult to remove material in this way might discourageregulators from censoring content.¶
In this context, participants observed that it would be difficult to createmechanisms to track and control content served as a Web Package without compromising the statedgoal of censorship resistance.¶
Understanding the effect that Web Packaging might have on web performance was amatter of some contention.¶
Some informal analysis from the Google Search deployment was presented (laterpublished in[AMP-PERF]) that showed significant performance improvements inmetrics related to navigation time resulting from the combination of prefetch,prerendering, and the AMP format. These results are suggestive of a possibilitythat Web Packaging could provide some of that improvement on its own, but nodata was presented that apportioned the improvement among the three components.¶
Though data was presented to demonstrate potential rather than be a definitiveresult, discussions raised a number of questions that suggest the need forfurther study. Attendees suggested that future measurements consider the effectof signed bundles distinct from the enhancements derived from the AMPformat. Future research in this area might also consider the effectiveness ofdifferent strategies on devices with varying capabilities, bandwidth, powerconsumption requirements, or network conditions.¶
Of particular interest is the additional work required to fetch and rendermultiple web pages in preparation for navigation. This might ultimately use fewerconnections but comes with an increased network and CPU cost for clients. Someparticipants pointed out that different clients or applications might requiredifferent tuning -- for example, when users have limited (or expensive) bandwidthor for sites with less clear knowledge about the use of outbound links.¶
Workshop participants also expressed interest in learning about the effect ofWeb Packages on subsequent navigations within the target site.¶
In discussion, some participants suggested that their experience supported atheory that operating a cache at the linking site was most effective and theadditional work done prior to navigation in terms of fetching and preparingcontent was what provided the most gains; others suggested that the benefitsinherent in the AMP format was a dominant factor.¶
Understanding the complete effect of Web Packaging on web performance willrequire further work.¶
It is not straightforward to estimate how a proposed technology change mightaffect all of the parts of a system -- including not only other components, butalso things like end-user rights and the balance of power between parties --ahead of time. To date, when evaluating proposals, the IETF has generallyfocused on more immediate concerns, such as interoperability and security.¶
Moreover, people often find new uses for successful standards[SUCCESS] after they are deployed. It is rarely possible toaccurately predict all applications of a protocol or format, whether they areharmful or beneficial. Refusing standardization only impedes both outcomes.¶
With the understanding that predictions are difficult to make, there wasconsiderable speculation at the workshop about the possible effect of WebPackaging on the Web. Some of that speculation is informed by experience, butthat experience is necessarily limited in scope. This section attempts tocapture that discussion.¶
Concerns about the consolidation of power on the Internet have significantlyincreased lately, as a result of several factors. While the IAB, the InternetSociety, and others are examining this phenomenon to understand it better, it isnevertheless prudent to consider whether proposals for changes to how theInternet works favors or counters consolidation. Favoring entities with existingadvantages -- like resources, size, or market share -- is not necessarily a factorthat disqualifies a new proposal, but it needs to be considered as a cost ofenabling that technology.¶
Although the outcomes of adopting Web Packaging are unclear, the workshop revealed several concerns for consolidation risks for allinvolved parties: users, publisher sites, linking sites, and services they eachrely on.¶
Several participants noted that Web Packaging's enabling of instant navigation(Section 2.1) might advantage larger linking sites -- such as social networks orsearch engines -- over smaller ones in the same industry because doing sorequires careful selections of which links to optimize, so as not to createunneeded traffic.¶
For example, a news article often has many links, but not all of them areequally likely to be followed. Deciding which ones to prefetch requiresconsiderable data collection and engineering, so this technique might not befeasible for smaller entities. Additionally, some participants noted that thistechnique favors sites that have a linear set of ranked links, like searchresults; it is more difficult to apply to a page of news (for example) becausepredicting what link a user will follow is less obvious.¶
This technique also requires access to a cache with terms of use compatiblewith the requirements of the site. It was pointed out that the Google AMP Cachehas policies that might be acceptable to many, and there are other caches.Sites operated by entities other than Google already use this cache, though itwas observed that a site that does not host its own cache suffers a minorperformance degradation.¶
Participants seemed to agree that if performance is a strong enoughdifferentiator, the effective use of Web Packaging might turn out to be acondition for success for online publishers. Google Search's choice toprivilege content that is served using HTTPS was pointed out as showing thatthis sort of influence can be effective. Equally, it is not necessarily thecase that standardization of new capabilities will affect such policiesmaterially, as noted in[YASSKIN]:¶
It seems unlikely that any decisions we make in a packaging or distribution system will affect the considerations aggregators use when deciding how to rank recommendations or the power this gives them over publishers.¶
The most common concern raised in the discussion was the effect of thistechnology on smaller publishers who might be less able to optimize the packagesthey produce, where their primary differentiation in the market has previouslybeen the quality of their content.¶
In typical operation of the Web, servers have an opportunity to tailor contentto the needs of their users. In contrast, a static Web Package has few optionsfor individualization, as the content is generated once and used by many.¶
As a result, publishers noted that AMP provides less opportunity to customizecontent for their customers. Their concerns included not only personalizingcontent based on what they know about the user but also optimizing the packagefor specific browsers. Other participants observed in relation to this that WebPackaging might also have a consolidating effect in the browser market.¶
Some participants brought up the possibility of customization by providingmultiple packages, including multiple variants of resources in a single package,or performing customization after the package was loaded. However, otherparticipants pointed out that all of these options have negative side effects,either in complexity or reduced performance arising from larger bundles ordelayed customization.¶
One session explored the impact of introducing a new security model for theWeb. Currently, sites rely on connection-oriented security (provided by TLS[TLS]), but Web Packaging adds a limited form of object security.That is, the package protects the integrity of a message, rather than providingintegrity and confidentiality for its delivery. Object security is not a newconcept in the context of the Web; designs like SHTTP[SHTTP] are asold as HTTPS. Though the intent is for Web Packaging to have a far more narrowapplicability, it provides fewer security guarantees than HTTPS, since itprovides only authentication, no confidentiality with respect to the cache, andno assurance of liveness.¶
Object-based security -- such as proposed in Web Packaging -- allows the use ofcontent regardless of how it is obtained; some participants noted that thirdparties gain greater control over the distribution of content, reducing theability of publishers to retract or alter content over the validity period ofsigned content.¶
Another topic of discussion was composition attacks. In its proposed form, WebPackaging only provides authentication of independent resources, not a web pageas a single unit, allowing an attacker to control the composition of resources.This weakness was acknowledged as a known shortcoming of the current proposalthat would be addressed.¶
The issue of managing the trade-off between control and performance in cachesarose. While participants recognized that problems with resource compositionalready occur by accident -- for example, when a cache stores different versionsof resources -- Web Packaging allows an attacker more direct control over whatresources are available to clients.¶
For example, an attacker might be able to cause content with a security flaw tobe used up to a week past the time that the defect was fixed.¶
As an example of how Web Packaging might change the risk profile for sites,participants discussed recovery from cross-site scripting attacks. It is alreadythe case that a brief exposure to this class of attack can result in an attackergaining persistent access, but mechanisms exist that can be used to avoid orcorrect issues, like cache validation and Clear Site Data[CLEAR-DATA]. Thesemeasures are not available to clients unless they connect to the site.¶
The discussion pointed out that these concerns are not new or uniquely enabledby Web Packaging. However, it was pointed out that new features are routinelysubject to higher security and privacy expectations. In an example unrelated toWeb Packaging but with similar trade-offs, shared compression of multipleresources has significant performance benefits. The risk with shared compressionis the potential for exposing encrypted information throughside channels. Though sites can use shared compression without this exposure,shared compression will likely only be enabled once it is clear that measures toprevent accidental information exposure are understood to be effective in abroad set of deployments.¶
The discussion also addressed the question of whether concerns might equallyapply to the typical use of a CDN as athird-party provider of the content. Some participants concluded that CDNs aretypically in a contractual relationship with the sites they serve and so aremore likely to have their interests aligned.¶
Discussion and submissions raised concerns regarding how serving content usingWeb Packages might adversely affect privacy of individuals. There arechallenges here, but the very narrow applicability of Web Packaging to what iseffectively static content limits the privacy risk. The conclusion was that,provided sufficient care is taken in implementation, the use of Web Packages doesnot substantially increase the information that an aggregator gains about whatcontent is consumed.¶
Concretely, an aggregator knows what content it serves in anticipation ofnavigation. This is -- at least in theory -- substantially the same as thecontent that the aggregator might receive if it performed the navigationitself. Assuming that content is stripped of personalization, the aggregatorgains no new information.¶
On multiple occasions, discussion at the workshop concentrated on problems thatarise as a result of constraints on the AMP format or details of its inclusionin Google Search. For instance, the requirement to make pages expose theirmetadata is unlikely to be affected by any standardization of apackaging format as that requirement is independent of the process ofdelivering content.¶
This section provides some detail on aspects of the discussion that touched onAMP more generally in this way. Some treatment of these points is consideredrelevant as some of the discussion at the workshop, even under the remit ofdiscussing Web Packaging, concentrated on the effect of AMP on the ecosystem.¶
Note: Of the four formats mentioned in the workshop call for papers[CFP], only AMP sent representatives to the workshop. The discussion was therefore concentrated around AMP; this section should not be read to imply anything about other formats.¶
Discussion and submissions referred to a commitment[AMP-LESSONS] to allowpublishers to use content that met specific criteria to access privilegedpositions in search results, regardless of their adoption of AMP. Participantsfelt that this approach might address some of these concerns if it were adoptedand durable. For instance, the use of Web Packaging might be sufficient toremove some constraints on active content on the basis that the active contentwould be attributed to the publisher and not the AMP Cache.¶
There was interest from workshop participants in the governance model used forAMP. In particular, the question of how independent the AMP project would be ofGoogle and Google Search arose.¶
Three of the seven members of the AMP Technical Steering Committee, the bodythat governs AMP, are Google employees, which gives Google considerableinfluence over the project. It was asserted that the governance structure wasintended to be more independent of Google over time. The understanding was thatany consumer of the format, such as Google Search, would make an independentassessment about whether to use or require different aspects of the AMP projectproducts.¶
Sites often implement AMP by creating a separate set of content in parallel totheir regular HTML content. Publishers noted this as a high cost, particularlyfor smaller sites. It was pointed out that websites can serve AMP-compliantcontent exclusively. However, several publishers referred to limitations in theformat that made it unsuitable for their needs.¶
Many cited reasons for this duplication were related to the necessity ofrunning arbitrary active content (typically, JavaScript). For example:¶
More broadly, they considered AMP's constraints on the use of active content asproblematic, since they prevent the use of capabilities that are provided onequivalent non-AMP pages. Reference was made to a proposed <amp-script>element -- which has since been made fully available -- that seeks to providelimited access to some dynamic content.¶
Publishers observed that using the AMP format does not provide any guarantee ofperformance gains and, in some cases, could contribute to performancedegradation. It was suggested that this was most problematic for sites that arealready well-tuned for performance.¶
The use of paywalls by web publishers to control access to content in returnfor payment is increasingly common. One popular approach is to offer a limitednumber of articles without payment while insisting on a paid subscription toaccess further articles.¶
On several occasions, participants expressed dissatisfaction with the difficultyof integrating paywall authorization when using AMP. In particular, they saidAMP encourages publishers to include an article's full content, hidden bydefault but easily accessible to motivated users. The discussion extended to workarounds like cookie syncing[COOKIE-SYNC],which is used as part of authorization and is a consequence of having cached content hosted on the linking site rather than the target site.¶
The same topic came up concerning book publication, where publishers indicatedthat having a means of enabling different methods of distribution without alsofacilitating unconstrained copying of book content was necessary.¶
This conflation of AMP issues with those addressed by Web Packaging wasrecurrent in the discussion. As observed in[DAS], these concerns might beaddressed by linking to a signed bundle.¶
Web Packaging work continues in multiple forums. Questions about the core format and signatures are being discussed on thewpack@ietf.org mailing list. Changes to web browsers as proposed in[LOADING] will be discussed on theFetch specification repository.¶
Proposals discussed at the workshop might have a significant security impact,and these topics were discussed in some depth; seeSection 4.2.¶
The ESCAPE Workshop was held on 2019-07-18 and the morning of 2019-07-19 atCisco's facility in Herndon, Virginia, USA.¶
Workshop attendees were asked to submit position papers. These papersare published on the IAB website[CFP].¶
The workshop was conducted under the Chatham House Rule[CHATHAM-HOUSE], meaning that statements cannot be attributed to individuals or organizations without explicit authorization.¶
This section outlines the broad areas of discussion on each day.¶
Attendees of the workshop are listed with their primary affiliation as itappeared in submissions. Attendees from the program committee (PC), theInternet Architecture Board (IAB), and the Internet Engineering Steering Group(IESG) are also marked.¶
Sawood Alam, Old Dominion University¶
Jari Arkko, Ericsson (IAB)¶
Richard Barnes, Cisco¶
Robin Berjon, New York Times (PC)¶
Zack Bloom, Cloudflare¶
Abraham Brewster, Patch.com¶
Alissa Cooper, Cisco (IESG, IAB)¶
Dave Cramer, Hachette Book Group¶
Melissa DePuydt, Washington Post¶
Levi Durfee, AMP Advisory Committee¶
Rudy Galfi, Google¶
Joseph Lorenzo Hall, Center for Democracy & Technology (PC)¶
Matthew Nelson, Washington Post¶
Michael Nelson, Old Dominion University¶
Mark Nottingham, Fastly (IAB, PC)¶
Shigeki Ohtsu, Yahoo¶
Eric Rescorla, Mozilla¶
Adam Roach, Mozilla (IESG)¶
Rich Salz, Akamai Technologies¶
Wendy Seltzer, W3C¶
David Strauss, Pantheon (PC)¶
Chi-Jiun Su, Hughes¶
Ralph Swick, W3C¶
Martin Thomson, Mozilla (IAB, PC)¶
Jeffrey Yasskin, Google¶
Dan York, Internet Society¶
Benjamin Young, John Wiley & Sons¶
Web Packaging is comprised of two separate technologies: resource bundling[BUNDLE] and signed exchanges[SXG].¶
In both the submissions and workshop discussion, the most controversial aspectof the technology is the use of signed exchanges as an alternative means ofproviding authority over a particular resource, for a few different reasons.¶
This appendix explains how authority works on the Web and how Web Packagingproposes to change that.¶
The Web currently uses HTTPS[HTTP] to establish a server'sauthority -- that is, to give an assurance that the content came from where theURL implies. The combination of URI scheme (https), domain name (or host), andport number are formed into a single identifier, the origin[ORIGIN]to which content is attributed.¶
Web browsers use the certificate offered as part of a TLS connection[TLS] to servers in determining whether a server is authoritativefor that origin; see[ORIGIN] andSection 9.1 of [HTTP].Content is attributed to a given URL only if it is received from a connectionto a server that is authoritative for the associated origin.¶
As an example, a web browser seeking to loadhttps://example.com/index.htmlmakes a TLS connection to a server. As part of the TLS connectionestablishment, the server offers a certificate for the nameexample.com. Ifthe browser accepts the certificate, it will then make requests for URLs on thehttps://example.com origin on that connection and consider any answers from theserver to be authoritative.¶
This notion of authority is a crucial property of web security: only contentthat is attributed to the same web origin can access all information in thatorigin, including the content of most resources as well as state associatedwith the origin, such as cookies. This separation ensures that sites can keepsecrets from each other, even when they are both loaded in the same browser.¶
Web Packaging, through the use of signed exchanges, aims to provide analternative means of establishing authority. A signed exchange is an expressionof an HTTP request and response (an exchange) with certain information strippedand a digital signature applied.¶
The signature is made with a similar certificate to the one a server mightoffer in HTTPS -- that certificate can also be used for HTTPS -- but it includesa special attribute that denotes its suitability for signed exchanges.¶
A web browser that has been provided with a signed exchange can verify thesignature and, if the signature is valid and the certificate is acceptable,use the content from the signed exchange. Critically, the web browser does notmake an HTTPS connection to a server to get the content or to verify thesignature.¶
In effect, Web Packaging moves from a model where authority is derived from thedelivery method (i.e., TLS) to an object security model, where authority isderived from a signature on objects. In doing so, it aims to render the meansof delivery irrelevant to determinations of security.¶
Web Packaging does not claim to supplant the authority model of the Webcompletely, but it does provide an alternative that might be used under certainnarrow conditions. In particular, Web Packaging is intended for use withcontent that is not secret from an entity that is aware of the existence ofthat content.¶
In aid of this goal, Web Packaging does not include information from exchanges that is related to the process of acquiring content nor does it include any information that is related to individual requests.For instance, use of theSet-Cookie header field is expressly forbidden, as it often containsinformation that is related to a particular user.¶
The relationship between the AMP Project<https://amp.dev/> and Web Packaging iscomplicated. The AMP Project, sponsored by Google, establishes a profile of HTMLwith a stated goal of providing support for the best practices for the format,with a strong emphasis on performance. The format tightly constrains the use ofHTML features but also offers a library of components that provide sanitizedimplementations of many commonly used capabilities.¶
The connection to Web Packaging is bound up in the way that Google Searchtreats AMP content specially. AMP content provides two properties that GoogleSearch exploits: metadata exposure and static analysis of active content.¶
AMP content provides metadata in a form that can be reliably extracted, usingthe microformats defined by the Schema.org project<https://schema.org/>. Thisaspect of AMP has no effect on the discussion, except to the extent that thisrelates to Google Search and their use of this metadata in populating thecarousel.¶
Constrained use of active content -- such as JavaScript -- in AMP makes itpossible to analyze content to verify that actions taken are narrowly limited.This static analysis assures that AMP content can be served without affectingother content on the same site. For Google Search, this is what enables theloading of AMP content alongside search content and other AMP resources.¶
To provide preloading, Google operates the Google AMP Cache<https://developers.google.com/amp/cache/>, from which AMP content is served.As a consequence, browsers attribute the content to the origin[ORIGIN] of the AMP Cache and not the publisher, creating someconfusion about how content is attributed, as discussed in the W3C finding ondistributed content[TAG-DC].¶
An important goal of Web Packaging is to attribute content loaded from a cache,such as the Google AMP Cache, to the publisher that created that content. For more onthis, seeSection 2.1.¶
Internet Architecture Board members at the time this document was approvedfor publication were:¶