Chrome’s position on the ESCAPE workshop
Jeffrey Yasskin, Chrome team, 2019-06-05
I have been developing the Web Packaging specifications that live in https://github.com/WICG/webpackage. As of June 2019, Chrome has shipped an initial version of “Signed Exchanges” and is working on an implementation of “Bundles”. Once the whole system is implemented, we expect it to allow publishers to sign bundles of content that can be distributed to customers in a variety of new ways, including peer-to-peer and via potentially-untrusted distributor websites, some of which will be large aggregators like Google or Facebook.
We expect this new distribution system to have several positive effects in connecting publishers with their readers:
- When publishers create content intended to be seen as a subresource of another top-level page, for example in a mashup, packages can allow the top-level page to serve that content more quickly by avoiding the need to create a connection to the origin server.
While designing Web Packaging and planning for future deployment, the Chrome team wants to make technical decisions that bias the web’s evolution away from centralization as much as possible, even if that reduces Google’s influence. In order to do that, we need to identify concrete mechanisms by which this new distribution system might cause centralization or decentralization of, or shift power between, aggregators, CDNs, publishers, advertisers, end-users, and other kinds of entities. For example:
- If the aggregators move away from their requirements to use particular formats that they then re-host, that shifts power from those aggregators to the publishers who had been opting into those formats, as described above. There is a more ambiguous effect on publishers who hadn’t opted into the formats.
- If we make packages explicitly list the origins that are allowed to distribute them, that is likely to increase aggregator centralization and limit any decentralizing effect on CDNs. Even an optional allowlist risks increasing centralization, but the risk is lower than a mandatory one.
- If somebody finds a way to privately discover and fetch geographically-nearby packages that contain particular URLs, that is likely to have a decentralizing effect on CDNs. However, this currently appears to be a very hard problem to solve.
- The question of exposing the distribution URL of a package to that package’s publisher is more complex. Doing so would allow publishers to distinguish metrics for loads from servers they control vs servers they don’t, might allow them to fix loads from misbehaving distributors, might compromise user privacy about how they arrived at a link, and might increase centralization by helping already-powerful aggregators require that publishers redirect links back to the aggregator’s server. We could use publisher input on this sort of design question, in addition to the centralization questions.
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. A new packaging system is likely to change the details of how those considerations apply: for example, if packaged content loads faster, the existing preference for fast content may lead to higher rankings for publishers that can package their content.
In this workshop, we’re hoping to learn about other centralizing or decentralizing mechanisms that the publishing community is aware of, and to make sure we build a system that serves users', authors', and publishers' needs.