RFC 8752

Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)

📅 published March 2020, from ietf

Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) 🌸

RFC number: 8752 💖 Authors: M. Thomson and M. Nottingham 🦋 Published by: the Internet Architecture Board (IAB) 👑 Category: Informational 🧚 Date: March 2020 📅 ISSN: 2070-1721 Obsoletes / Updates: nothing listed in the header, so this one isn't replacing or changing any earlier RFC 🌈

Abstract ✨

okay so the Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) Workshop was hosted by the Internet Architecture Board (IAB) in July 2019. this report sums up its biggest discussion points and flags topics that might be worth a closer look later 💅

btw, this doc is a report on what happened at the workshop. the views and positions in it belong to the workshop participants and don't necessarily match the IAB's views and positions 🫶

Status of This Memo 🎀

this is NOT an Internet Standards Track spec. it's published just for info 🌸

this doc is a product of the Internet Architecture Board (IAB). it's basically info the IAB decided was worth keeping on the permanent record, and it reflects the IAB's consensus. documents the IAB approves for publication aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 💅

if you want the current status, any errata, or a way to send feedback, check https://www.rfc-editor.org/info/rfc8752 🔥

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. read them carefully, because they explain your rights and restrictions for this doc. no skipping this one bestie 🙈

Table of Contents 🧚

1.  Introduction
  1.1.  Mention of Specific Entities
2.  Use Cases
  2.1.  Instant Navigation
  2.2.  Offline Content Sharing
  2.3.  Other Use Cases
    2.3.1.  Book Publishing
    2.3.2.  Web Archiving
3.  Interactions between Web Publishers and Aggregators
  3.1.  Incentives for Web Packages
  3.2.  Operational Costs
  3.3.  Content Regulation
  3.4.  Web Performance
4.  Systemic Effects
  4.1.  Consolidation
    4.1.1.  Consolidation of Power in Linking Sites
    4.1.2.  Consolidation of Power in Publishers
    4.1.3.  Consolidation of User Preferences
  4.2.  Effect on Web Security
  4.3.  Privacy of Content
5.  AMP Issues Unrelated to Web Packaging
  5.1.  AMP Governance
  5.2.  Constraints on the AMP Format
  5.3.  Performance
  5.4.  Implementation of Paywalls
6.  Venues for Future Discussion
7.  Security Considerations
8.  Informative References
Appendix A.  About the Workshop
  A.1.  Agenda
    A.1.1.  Thursday 2019-07-18
    A.1.2.  Friday 2019-07-19
  A.2.  Workshop Attendees
Appendix B.  Web Packaging Overview
  B.1.  Authority in HTTPS
  B.2.  Authority in Web Packaging
  B.3.  Applicability
  B.4.  The AMP Format, Google Search Results, and Web Packaging
IAB Members at the Time of Approval
Authors' Addresses

1. Introduction ✨

okay so the IAB runs occasional workshops to think about long-term Internet issues and strategy, and to suggest where the Internet architecture could head next. this big-picture planning is a companion to the day-to-day engineering the IETF working groups do 🌷

the IAB held the ESCAPE Workshop to look at some proposed changes to the Internet and the Web, and how they could shake up online publishing. the star of the show was the Web Packaging proposal from Google. it's being considered in the IETF, the W3C's Web Incubator Community Group (WICG), and the Web Hypertext Application Technology Working Group (WHATWG) 👑

people talked about the good stuff Web Packaging could do, but also worried it could seriously change the relationship between publishers (think news sites) and content aggregators (think search engines and social networks). so the focus was mostly on that relationship, not the nitty-gritty tech 💅

publishers don't usually show up to standards work directly, so the workshop was set up to collect their input. there were 27 participants from all kinds of backgrounds. only a few were publishers, there was one aggregator (Google), and the crowd also included browser folks, people from the Accelerated Mobile Pages (AMP) community, Content Distribution Networks (CDNs), network operators, academics, and standards bodies. for the call for papers and a full list of submissions, see [CFP] 🦋

the workshop was meant to be a discussion space, so it didn't land on firm conclusions. this report is the main output instead, a record of what was said 💜

this report covers the use cases from Section 2 and the publisher-aggregator interactions that might get affected, in Section 3. Appendix A has more about the workshop itself, and Appendix B is a quick Web Packaging primer for anyone new to it 🧚

1.1. Mention of Specific Entities 🙈

everyone agreed to hold the workshop under the Chatham House Rule [CHATHAM-HOUSE]. so this report doesn't pin statements on any individual or org without their express permission. submissions to the workshop were public, though, so they can be attributed, and this report uses them for substance and context 🫶

2. Use Cases 🌸

a big chunk of the workshop was spent arguing about which use cases Web Packaging could actually enable, and whether they're worth it. see Appendix B for the Web Packaging overview 💅

2.1. Instant Navigation 🚀

okay this is the biggest real-world use of Web Packaging so far. Google Search uses it to make navigating to pages linked from search results feel faster when they're "clicked" 🔥

here's how it works: when a linking (or referring) page links to pages on another site, it also gives the browser a packaged copy of the target content, signed by the origin of that target content. so the referring page basically acts as a cache for the target page's content. if you actually navigate to one of those links, having the Web Package lets the browser trust that the cache didn't change anything. so it can treat the content as if it came straight from the target page's server, even though it came from somewhere else. in lots of cases, the target page shows up way sooner 🦋

a key thing here: the browser doesn't contact the target site before navigation. it doesn't send requests to sites until after navigation happens, and only if the site needs extra content or makes a direct request 💖

there are other ways to get similar speedups, like downloading content (packaged or not) straight from the target site ahead of time, which is called "prefetching". but that would tell those sites about the user's activity on the linking page, even if the user never ends up going there 🙈

the technique that uses Web Packaging is also called "privacy-preserving prefetch". this doc avoids that term because people at the workshop disagreed about which parts of privacy the technique actually preserves 👀
   |  Note: This technique that uses Web Packaging is also referred
   |  to as "privacy-preserving prefetch".  This document avoids that
   |  term as there was some contention at the workshop about which
   |  aspects of privacy might be preserved by the technique.

sites bundled with Web Packaging can also be built so they render without needing any extra network access. that makes near-instant navigation possible, and the proposed changes to web navigation for loading Web Packages are designed to support exactly that 🌈

workshop folks agreed web performance matters for usability, and for business metrics like retention and bounce rates. it was seen as a worthwhile goal. but publishers asked whether it's worth the cost of supporting yet another format, and others had concerns about different parts of the Web Packaging proposal 💅

2.2. Offline Content Sharing 📦

another big use case was sharing web content between devices that don't have an active Internet connection. one of the stated goals of Web Packaging is to make offline sharing possible ✨

a few participants said that where Internet access is pricey, slow, or spotty, direct peer-to-peer file exchange is super common (think "saving a website and sharing it on a USB stick"). most browsers already have some tools for this, but people agree they need upgrades 🫶

during the discussion, several people pushed back on an assumed requirement for this use case, which was that a page loaded from an offline Web Package should be treated exactly the same as a "normal" web page 🙅‍♀️

some participants liked that a Web Package can clearly attribute its content, for a bunch of different reasons. but there were reservations about the subtleties of what signatures actually provide, and how that affects web security. see also Sections 4.2 and 2.3.2 🔐

lots of people pointed out that "unsigned bundles" (Web Packages without signed exchanges) could be good enough for this, since most users don't need cryptographic proof of who a site is. but some were worried this could make falsehoods spread more easily 😬

some folks suggested the real value of signed exchanges isn't in small, person-to-person sharing. it's in building content delivery systems that could include things like discovery and automated distribution. the point was that using digital signatures well for offline distribution needs way more infrastructure than the current proposals describe 🧚

the workshop didn't reach any firm conclusions about offline sharing 🌸

2.3. Other Use Cases 🦋

the second morning had a session focused on two more potential use cases for Web Packages: book publishing and Web archiving. the proponents of Web Packaging didn't consider these "primary", and the plan wasn't to spend much time on them. still, attendees were pretty interested 💖

2.3.1. Book Publishing 📚

okay so the room talked about whether a packaging format could work for books 🦋 and the book people were like, "bestie, book delivery is NOT like regular web content delivery" 💅 They had a point.

The workshop folks also looked at what already exists. PDF was seen as especially rough for this use case because of its limitations 😭, and EPUB has constraints that make life hard for publishers too.

Web Packaging might help with books, ngl 🌸 but the big question of how to identify book content never got settled. Signed exchanges could maybe tie book content back to a website 🔗, but several limitations came up with that too.

Here's the thing: books don't need to be as fresh as web pages. Dave Cramer's submission [CRAMER] pointed out that Moby Dick was published over 61,000 days ago 📖💀, which is way longer than the proposed 7-day limit for signed exchanges. The limited time a Web Package can be considered valid got talked about a lot 🕰️

There's also the risk that a publisher goes out of business while a book is still being read. Successful books often stick around for generations 🧚 So being able to attribute content to a publisher was seen as less practical and maybe even undesirable (kinda like the "unsigned bundles" discussion above 👀).

Other book stuff felt tricky for packaging too. For example, it's currently not understood what it means to refer to distinct parts of a book 🤔 People thought stable references for bundles of content might be interesting here, but nothing concrete came out of that chat.

The idea of active content in a bundle using web APIs to enrich content or unlock new features was seen as super valuable ✨ Paywalls got discussed at length too (see Section 5.4) 💸

2.3.2. Web Archiving 🗂️

Web archiving is a whole complicated discipline, and it's made harder by how complicated the Web itself is 😵‍💫

From an archival point of view, the idea of web content being provided in a self-contained form was seen as a W 🌈 Several improvements to the structure of Web Packaging were suggested, like providing complete sets of content and using Memento [MEMENTO] 🎀

Packaging could have real uses here, but a lot of challenges need extra work from content producers before it'd be fully effective 🛠️ For example, JavaScript is needed to render some archived content faithfully, but attributing that content to an origin in every scenario is hard 🙈

If packaging got widely deployed, it might make archival replay better 💜 The speculation is that there'd be less "live leakage", since packaged content would be less likely to point at live resources that tend to "leak" into archive views 🫠 People also noted that subresources might be more likely to get packaged, especially the ones needed for deferred representations (i.e., stuff that appears after JavaScript runs on the page or after some user interaction) 🧩 Other potential applications and enhancements are covered in [ALAM] 📚

Participants talked about using a signature for non-repudiation for quite a while 🔏 In one case tied to the Internet Archive, a public figure disputed the accuracy of archived content, claiming the original content had been modified either at the source or in the archive 😳

Some participants first saw digital signatures as a way to deal with these provenance issues ✍️ Similar problems show up in other areas too, like book publication, medical research, and news, so a solution here was thought to have broad applicability 🌍

The discussion ultimately concluded, though, that providing non-repudiation in retrospect is challenging 😬 Signing keys aren't expected to stay secure for long periods. If keys leak later, an attacker could retroactively generate fraudulent signatures 🚨 Alternatives were discussed, like keeping independent archives of the same data, using consensus protocols, or using an append-only construct like a Haber-Stornetta log [AOLOG]. All of these can make it harder to alter or misrepresent established archives 🔒

3. Interactions between Web Publishers and Aggregators 🤝

A big reason for holding the workshop was to give publishers a space to talk about how Web Packaging would affect the online publishing ecosystem 📣 The main question was whether Web Packages might effectively shift power from publishers to aggregators 👀

Both publishers and aggregators at the workshop said they really wanted to keep a positive relationship 🫶 Publishers especially need to be able to trust that aggregators won't misrepresent their work or de-emphasize it for reasons unrelated to quality and the value perceived by the user 💅

One key question from [BERJON] got 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?

The chat then focused on the current incentive model that aggregators offer 💰 The costs publishers take on to participate in that system were considered too. A lot of time went to AMP, and you can find a summary of that discussion in Section 5 📝

We also wondered whether standardizing Web Packaging gives credibility to aggregators who want to exercise unwelcome control over publisher content 🤔 Or could the technical safeguards Web Packaging provides let aggregators relax their restrictions on the kinds of content they're willing to cache and serve? No conclusions were drawn, bestie 🤷‍♀️

3.1. Incentives for Web Packages 🎁

Submissions to the workshop showed that inducements involving better placement and formatting of links to publisher content had a significant effect on how much the related technology got picked up 📈 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 said that if it weren't for the privileged spot in the Google Search carousel given to AMP content, they wouldn't publish in that format 🙃

Publishers who do produce AMP said they see a non-trivial increase in traffic from deploying AMP content ✨ For example, Yahoo Japan reported a 60% increase in traffic from deploying AMP on Yahoo Travel [OTSU] 🚀 No data was presented on whether that increase came from better placement in Google Search results, the inherent benefits of the AMP Cache, or the use of the AMP format itself 🤷‍♀️

Another large publisher shared anecdotal evidence that they saw a 10% drop in traffic after accidentally disabling AMP content 😱 However, more traffic doesn't always mean proportionally more revenue, as observed in [BREWSTER] 💸

3.2. Operational Costs 🧾

Several participants pointed out that introducing a new, parallel format for Web content comes with operational costs 🙄 Supporting any new format (Web Packaging, Apple News, or Facebook Instant Articles, for example) takes initial tooling development (some generic, some specific to a site's requirements) and then ongoing investment to keep it working 🛠️ Some participants were worried about small publishers with limited technical and financial resources, especially in the current publishing climate 🥺

Extra exposure from a new format might not always justify the added expense of providing articles in it [BREWSTER] 😬 Still, a standardized format might help publishers cut the cost of maintaining multiple formats 💖

3.3. Content Regulation ⚖️

Using Web Packaging as a tool for avoiding censorship wasn't a major topic of discussion 🙅‍♀️ The one thing that came up was that publishers often have regulatory requirements around removing or correcting content 📋

People brought up the desire to remove videos of a recent shooting [CHRISTCHURCH] and how hard that could be if the content were available as Web Packages 😰 Legal requirements to remove content come from a bunch of angles: copyright violations, illegal content, editorial corrections or errors, and the right to erasure provisions in the European Union General Data Protection Regulation [GDPR] 🇪🇺 One participant speculated that making material harder to remove this way might discourage regulators from censoring content 🤞

In this context, participants observed that it would be difficult to create mechanisms to track and control content served as a Web Package without compromising the stated goal of censorship resistance 🔥

3.4. Web Performance 🚀

okay so how Web Packaging affects performance was a whole thing 😭 people did NOT agree, bestie.

Some informal analysis from the Google Search deployment (later published in [AMP-PERF]) showed big improvements in navigation time metrics, from the combo of prefetch, prerendering, and the AMP format ✨. These results hint that Web Packaging could maybe get some of that boost on its own, but no data split the improvement up between those three parts, so nobody knows which piece did what 🤷‍♀️

The data was more of a "here's the potential" vibe than a definitive result, and it raised a bunch of questions that need more study 🔍. Attendees suggested future measurements look at signed bundles separately from the perks that come with the AMP format. Future research could also check how different strategies work on devices with different capabilities, bandwidth, power consumption requirements, or network conditions 📱.

Here's the tea 🍵: fetching and rendering multiple web pages ahead of navigation is extra work. It might end up using fewer connections, but it costs clients more network and CPU 🥵. Some participants pointed out that different clients or apps might need different tuning, like when users have limited (or expensive) bandwidth, or for sites without a clear picture of how their outbound links get used 🔗.

Workshop participants also wanted to learn about the effect of Web Packages on subsequent navigations within the target site 👀.

In discussion, some participants felt their experience backed up a theory: running a cache at the linking site was the most effective, and the extra prep work (fetching and preparing content before navigation) gave the biggest gains. Others said the benefits built into the AMP format were the dominant factor 🤔.

Bottom line: understanding the complete effect of Web Packaging on web performance is going to take more work 💖.

4. Systemic Effects 🌍

it is not straightforward to guess how a proposed tech change might affect all the parts of a system ahead of time 😵‍💫. That includes other components, but also stuff like end-user rights and the balance of power between parties. To date, when evaluating proposals, the IETF has generally focused on more immediate concerns, like interoperability and security 🔒.

Also, people often find new uses for successful standards [SUCCESS] after they're deployed 🙌. It's rarely possible to accurately predict every application of a protocol or format, whether harmful or beneficial. Refusing standardization only blocks both outcomes 🚫.

With the understanding that predictions are hard, there was a lot of speculation at the workshop about the possible effect of Web Packaging on the Web 🔮. Some of that speculation is informed by experience, but that experience is necessarily limited in scope. This section tries to capture that discussion 💬.

4.1. Consolidation 🏢

Concerns about the consolidation of power on the Internet have blown up lately, for several reasons 📈. The IAB, the Internet Society, and others are examining this phenomenon so they can understand it better. Still, it's prudent to consider whether proposed changes to how the Internet works favor or counter consolidation. Favoring entities that already have advantages, like resources, size, or market share, isn't automatically a dealbreaker for a new proposal, but it needs to be counted as a cost of enabling that technology 💸.

Although the outcomes of adopting Web Packaging are unclear, the workshop revealed several consolidation risks for all the parties involved: users, publisher sites, linking sites, and the services each of them relies on 😬.

4.1.1. Consolidation of Power in Linking Sites 🔗

Several participants noted that Web Packaging's enabling of instant navigation (Section 2.1) might advantage larger linking sites, like social networks or search engines, over smaller ones in the same industry. The reason: doing it requires careful choices about which links to optimize, so you don't create unneeded traffic 🎯.

For example, a news article often has many links, but not all of them are equally likely to be followed. Deciding which ones to prefetch takes a lot of data collection and engineering, so this technique might not be feasible for smaller entities 🥲. Some participants also noted that this technique favors sites with a linear set of ranked links, like search results. It's harder to apply to a page of news, for example, because predicting which link a user will follow is less obvious 📰.

This technique also requires access to a cache with terms of use compatible with the site's requirements. It was pointed out that the Google AMP Cache has policies that might be acceptable to many, and there are other caches too. Sites run by entities other than Google already use this cache, though it was observed that a site that doesn't host its own cache suffers a minor performance degradation 📉.

4.1.2. Consolidation of Power in Publishers 📚

Participants seemed to agree that if performance is a strong enough differentiator, using Web Packaging effectively might become a condition for success for online publishers 🏆. Google Search's choice to privilege content served over HTTPS was pointed out as proof that this kind of influence can work. Still, it's not necessarily the case that standardizing new capabilities will materially change those policies, 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 in the discussion was the effect of this tech on smaller publishers, who might be less able to optimize the packages they produce. Their primary differentiator in the market has previously been the quality of their content 💜.

4.1.3. Consolidation of User Preferences 🎀

In typical operation of the Web, servers get to tailor content to the needs of their users 🧑‍🤝‍🧑. A static Web Package, by contrast, has few options for individualization, since the content is generated once and used by many 📦.

As a result, publishers noted that AMP gives them less room to customize content for their customers. Their concerns included not only personalizing content based on what they know about the user, but also optimizing the package for specific browsers 🌐. Other participants observed that Web Packaging might also have a consolidating effect in the browser market 👑.

Some participants brought up the possibility of customization through multiple packages, through multiple variants of resources in a single package, or by customizing after the package was loaded. However, other participants pointed out that all of these options have negative side effects, either in complexity or in reduced performance from larger bundles or delayed customization 😩.

4.2. Effect on Web Security 🛡️

One session explored the impact of introducing a new security model for the Web 🕵️‍♀️. Right now, sites rely on connection-oriented security (provided by TLS [TLS]), but Web Packaging adds a limited form of object security. In other words, the package protects the integrity of a message, rather than providing integrity and confidentiality for its delivery 📬. Object security isn't a new concept on the Web, either. Designs like SHTTP [SHTTP] are as old as HTTPS 🕰️. Even though Web Packaging is meant to have much narrower applicability, it provides fewer security guarantees than HTTPS. It only provides authentication, no confidentiality with respect to the cache, and no assurance of liveness 🚨.

Object-based security, like what's proposed in Web Packaging, allows the use of content no matter how it was obtained. Some participants noted that third parties gain more control over how content is distributed, which reduces publishers' ability to retract or alter content over the validity period of signed content 😤.

Another topic was composition attacks 🧩. In its proposed form, Web Packaging only provides authentication of independent resources, not of a web page as a single unit. That lets an attacker control how resources are composed. This weakness was acknowledged as a known shortcoming of the current proposal, one that would be addressed 🛠️.

The trade-off between control and performance in caches also came up 🎢. Participants recognized that problems with resource composition already happen by accident, for example when a cache stores different versions of resources. But Web Packaging lets an attacker have more direct control over which resources are available to clients 😱.

For example, an attacker might be able to cause content with a security flaw to be used up to a week after the defect was fixed 📅💀.

As an example of how Web Packaging might change the risk profile for sites, participants discussed recovering from cross-site scripting attacks 🩹. It's already the case that a brief exposure to this class of attack can give an attacker persistent access. But mechanisms exist to avoid or correct the problem, like cache validation and Clear Site Data [CLEAR-DATA]. These measures aren't available to clients unless they connect to the site 🔁.

The discussion pointed out that these concerns aren't new, and Web Packaging didn't uniquely enable them. However, it was also pointed out that new features are routinely held to higher security and privacy expectations 🧐. In an example unrelated to Web Packaging but with similar trade-offs, shared compression of multiple resources has significant performance benefits. The risk with shared compression is the potential for exposing encrypted information through side channels. Sites can use shared compression without that exposure, but shared compression will likely only be enabled once it's clear that measures to prevent accidental information exposure are effective across a broad set of deployments 🔐.

The discussion also addressed whether these concerns might equally apply to the typical use of a CDN as a third-party provider of content 🌐. Some participants concluded that CDNs are typically in a contractual relationship with the sites they serve, so they're more likely to have their interests aligned 🫶.

4.3. Privacy of Content 🔒

Okay so, people in the discussions and submissions were worried that serving content with Web Packages could hurt individuals' privacy. Fair concern, and there are real challenges here 🥺 But Web Packaging only really applies to what's basically static content, and that keeps the privacy risk pretty small 🌸 The verdict was that, as long as implementers take sufficient care, using Web Packages doesn't substantially increase what an aggregator learns about which content people consume 💖

Here's the vibe. An aggregator knows what content it serves in anticipation of navigation. At least in theory, that's basically the same content the aggregator might receive if it did the navigation itself ✨ So if that content is stripped of personalization, the aggregator gets no new information 🦋 No plot twist, no extra tea ☕

5. AMP Issues Unrelated to Web Packaging 💅

A lot of the workshop talk kept circling back to problems caused by the limits of the AMP format or how it gets included in Google Search 🙃 For example, the requirement to make pages expose their metadata probably won't be affected by any standardization of a packaging format, because that requirement has nothing to do with how content gets delivered 📦

So this section gives some detail on the bits of the discussion that touched on AMP more generally like that. It's still relevant, because some of the workshop talk, even while it was supposed to be about Web Packaging, focused on how AMP was affecting 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.

People talked about a commitment [AMP-LESSONS] to let publishers who meet specific criteria get privileged positions in search results, whether or not they adopt AMP 🏆 Participants felt this approach might address some of these concerns, if it were adopted and durable 🤞 For instance, Web Packaging might be enough to remove some constraints on active content, since the active content would be attributed to the publisher and not the AMP Cache. Iconic logic, honestly 👑

5.1. AMP Governance 🏛️

Workshop participants were curious about the governance model used for AMP. The big question was how independent the AMP project would be from Google and Google Search 🤔

Three of the seven members of the AMP Technical Steering Committee, the body that governs AMP, are Google employees. That gives Google considerable influence over the project 👀 It was asserted that the governance structure was intended to become more independent of Google over time 🌱 The understanding was that any consumer of the format, such as Google Search, would make its own independent assessment about whether to use or require different aspects of the AMP project products 💭

5.2. Constraints on the AMP Format 🧩

Sites often implement AMP by creating a separate set of content in parallel to their regular HTML content. Publishers called this a high cost, especially for smaller sites 😭 It was pointed out that websites can serve AMP-compliant content exclusively. However, several publishers pointed to limitations in the format that made it unsuitable for their needs 🙅‍♀️

Lots of the reasons cited for this duplication came down to the need to run arbitrary active content, which is typically JavaScript. For example:

  • AMP provides a framework for supporting user authentication, but publishers said using this framework wasn't considered practical.
  • AMP content doesn't support rendering of certain content, which can affect publishers' ability to innovate content production.
  • The AMP model for the implementation of paywalls (Section 5.4) was claimed to be inimical to some publisher business models.

More broadly, publishers saw AMP's constraints on active content as a problem, since they block capabilities that are available on equivalent non-AMP pages 🚧 Someone brought up a proposed <amp-script> element, which has since been made fully available, that aims to provide limited access to some dynamic content ✨

5.3. Performance 🚀

Publishers observed that using the AMP format doesn't guarantee any performance gains, and in some cases it could actually contribute to performance degradation 📉 It was suggested that this was most problematic for sites that are already well-tuned for performance 😤

5.4. Implementation of Paywalls 💸

Web publishers are using paywalls more and more to control access to content in return for payment. One popular approach is to offer a limited number of articles for free while requiring a paid subscription to read more 📰

Several times, participants expressed frustration with how hard it is to fit paywall authorization into AMP 😩 Specifically, they said AMP encourages publishers to include an article's full content, hidden by default but easily accessible to motivated users. That's a whole mess 🙈 The discussion also 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 for book publication, where publishers said they needed a way to enable different distribution methods without also making it easy to copy book content without constraints 📚

This mix-up between AMP issues and the ones Web Packaging is meant to address kept coming up in the discussion 🌀 As observed in [DAS], these concerns might be addressed by linking to a signed bundle 🔏

6. Venues for Future Discussion 🗣️

Web Packaging work is happening in multiple forums 🌍 Questions about the core format and signatures are being discussed on the wpack@ietf.org mailing list (https://www.ietf.org/mailman/listinfo/wpack). Changes to web browsers as proposed in [LOADING] will be discussed on the Fetch specification repository (https://github.com/whatwg/fetch/issues/784) 💜

7. Security Considerations 🛡️

Proposals discussed at the workshop might have a significant security impact, and these topics were discussed in some depth 😳 Please, please, go read Section 4.2 🫶

8. Informative References ✨

okay bestie, this is the reference shelf 📚 every paper, spec, and talk the RFC leans on lives here, so you can go find the receipts yourself 🕵️‍♀️ I kept every citation tag, author, date, DOI, and link exactly as written, and I joined the URLs that got split across lines so you can copy-paste them 💅

Appendix A. About the Workshop 🎀

The ESCAPE Workshop was held on 2019-07-18 and the morning of 2019-07-19 at Cisco's facility in Herndon, Virginia, USA. 🏢

Workshop attendees were asked to submit position papers. These papers are 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. 🤐

A.1. Agenda 🗓️

This section outlines the broad areas of discussion on each day. ✨

A.1.1. Thursday 2019-07-18 🌸

  • Web Packaging Overview: A technical summary of Web Packaging was provided, plus a longer discussion of a range of use cases. 📦
  • Web Packaging and Aggregators: The use of Web Packaging from the perspective of a content aggregator was given. 🧺
  • Web Packaging and Publishers: After a break, presentations from web publishers talked about the benefits and costs of Web Packaging. This included some discussion of the effect of developing AMP-conformant versions of content from a publisher perspective. 📰
  • Web Packaging and Security: This session concentrated on how the Web Packaging proposal might affect the web security model. 🛡️
  • Alternatives to Web Packaging: This session looked at alternative technologies, including those that were attempted in the past and some more recent ideas for addressing the use case of making web navigations more performant. 🔄

A.1.2. Friday 2019-07-19 🦋

  • Web Archival: This session talked about the potential application of a technology like Web Packaging in addressing some of the myriad problems faced by web archival systems. 🗃️
  • Book Publishing: The effect of technologies for bundling and distribution of books was discussed. 📖
  • Conclusions: A wrap-up session attempted to capture key takeaways from the workshop. 🏁

A.2. Workshop Attendees 👯‍♀️

Attendees of the workshop are listed with their primary affiliation as it appeared in submissions. Attendees from the program committee (PC), the Internet 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

Appendix B. Web Packaging Overview 📦✨

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 aspect of the technology is the use of signed exchanges as an alternative means of providing authority over a particular resource, for a few different reasons. 👀 Honestly the drama is real 🍿

This appendix explains how authority works on the Web and how Web Packaging proposes to change that. 🧠

B.1. Authority in HTTPS 🔐

The Web currently uses HTTPS [HTTP] to establish a server's authority -- that is, to give an assurance that the content came from where the URL implies. The combination of URI scheme (https), domain name (or host), and port 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 authoritative for that origin; see [ORIGIN] and Section 9.1 of [HTTP]. Content is attributed to a given URL only if it is received from a connection to a server that is authoritative for the associated origin. 🪪

As an example, a web browser seeking to load https://example.com/index.html makes a TLS connection to a server. As part of the TLS connection establishment, the server offers a certificate for the name example.com. If the browser accepts the certificate, it will then make requests for URLs on the https://example.com origin on that connection and consider any answers from the server to be authoritative. 🔑

This notion of authority is a crucial property of web security: only content that is attributed to the same web origin can access all information in that origin, including the content of most resources as well as state associated with the origin, such as cookies. This separation ensures that sites can keep secrets from each other, even when they are both loaded in the same browser. 🫶 That's the whole vibe of web security, no cap 💖

B.2. Authority in Web Packaging 🦋

okay so bestie, this part is literally about authority, which is basically "who gets to say this content is legit?" 👑 Web Packaging has a whole new move for that. Instead of trusting the delivery method, it's like, what if we trust the signature on the object itself? 🔥

Here's the tea: a signed exchange is basically an HTTP request and response (an exchange) that's had some info stripped out and a digital signature slapped on it. 💅

The signature uses a certificate that's super similar to the one a server would show in HTTPS. Like, that same certificate can be used for HTTPS too 🎀 but it has a special attribute that says "hey, I'm good for signed exchanges" ✨

So when a web browser gets a signed exchange, it can verify the signature. If the signature checks out and the certificate is acceptable, the browser can use the content from the signed exchange. 🫶 And here's the big deal, bestie: the browser does NOT make an HTTPS connection to a server to get the content or to verify the signature. 😭 No server trip needed!

Basically, Web Packaging is switching from "authority comes from how you got it (TLS)" to an object security model, where authority comes from a signature on the objects themselves. 🌈 The goal is to make the delivery method irrelevant when deciding what's secure. Iconic, honestly. 💖

B.3. Applicability 🌸

Okay so Web Packaging doesn't claim to totally replace the Web's authority model 🙈 It's more like an alternative that might be used under certain narrow conditions. 🍓

Specifically, it's meant for content that is not secret from anyone who knows that the content exists. 🧚

To keep it that way, Web Packaging doesn't include info from exchanges that's about how the content was acquired, and it doesn't include anything tied to individual requests. 💜

Example: the Set-Cookie header field is expressly forbidden 🚫 because it often holds info about a particular user. Not it, bestie.

B.4. The AMP Format, Google Search Results, and Web Packaging ⭐

This one's kinda complicated, not gonna lie 💀 The AMP Project <https://amp.dev/>, sponsored by Google, sets up a profile of HTML focused on best practices and performance. ⚡ It tightly limits HTML features, but it also has a library of components with sanitized versions of common stuff. 💅

The connection to Web Packaging is all about how Google Search treats AMP content specially. ✨ Two properties Google Search exploits: metadata exposure and static analysis of active content. 🔥

First, AMP provides metadata in a form that can be reliably extracted, using microformats from the Schema.org project <https://schema.org/>. 🎀 This doesn't really matter for the discussion, except for how Google Search uses this metadata to fill up the carousel. 🎠

Second, constrained active content (like JavaScript) in AMP makes it possible to analyze content and verify that actions are narrowly limited. 🦋 That static analysis means AMP content can be served without messing with other content on the same site. For Google Search, this is what lets AMP content load alongside search content and other AMP resources. 💖

To provide preloading, Google runs the Google AMP Cache <https://developers.google.com/amp/cache/>, which is where AMP content gets served from. 🌈 The result? Browsers attribute the content to the origin [ORIGIN] of the AMP Cache, not the publisher. 😭 That creates some confusion about attribution, as discussed in the W3C finding on distributed content [TAG-DC]. 🙈

An important goal of Web Packaging is to attribute content loaded from a cache, like the Google AMP Cache, to the publisher that actually created it. 👑 For more on this, see Section 2.1. 🫶

IAB Members at the Time of Approval 🧚

Internet Architecture Board members at the time this document was approved for publication were: 💜

   Jari Arkko
   Alissa Cooper
   Stephen Farrell
   Wes Hardaker
   Ted Hardie
   Christian Huitema
   Zhenbin Li
   Erik Nordmark
   Mark Nottingham
   Melinda Shore
   Jeff Tantsura
   Martin Thomson
   Brian Trammell

Authors' Addresses 🎀

   Martin Thomson

   Email: mt@lowentropy.net


   Mark Nottingham

   Email: mnot@mnot.net
📦 where this page comes from