Signed Exchanges and the Importance of Trust in Aggregator/Publisher Relationships

Introduction

The Internet always promised openness — but it never promised truth. As its inventor, Sir Tim Berners-Lee, described in a 2017 interview with CNN, "There was an assumption if we kept the web open and neutral… then surely it would become a wonderful place because it was free of national borders," allowing anyone across the world to "communicate in peace."¹

However, in the same interview and via a letter he wrote on the web's 28th birthday,² Berners-Lee acknowledged that those ideals haven't been enough to combat the rampant spread of misinformation that grew alongside the Internet. The flexibility of the medium allows lies to pose as credible truths, and a user may make a decision they believe to be informed when, in reality, it could be worse than if they had made it in ignorance.

Truth, then, must become a critical part of the Internet. Journalists and their editors are taught to produce "quality journalism — that is, independently reported, verified, branded information published or broadcast by institutions prepared to 'stand by their stories' despite pressures from commercial or government interests."³

The question then becomes clear — how does one know that the content they consume is truth?

Signed HTTP Exchanges, a subset of Web Packaging, can help promote truth on the Internet by preserving brand, but publishers should carefully consider the caveats before enabling them and subsequently advocate for aggregator accountability as well.

Regrettably, this was not the case; fake news abounded even in pre-Internet eras. Our time traveler would find themselves beset by publications selling absurdist claims or blaring headlines that featured truth stretched to the point of gossip, or over-the-top lies that were mildly entertaining at their best.

Yet, based on the publication they were considering, a reader of the era could still determine what content was true; the differentiating factor was brand. Stories published under the masthead of a local or national newspaper bore the names, faces and contact information of those who reported and delivered the content. As a result, readers associated certain brands with quality—and thus brand became a distinguishing factor for publications that remains critical to this day. In both its print and online products, The Washington Post aims to guarantee that, when a reader lands on a piece of content from The Washington Post, the reader can be certain that the content itself is supplied by The Post.

But just as the Internet is full of promise for content distribution and engaging audiences in new ways, it also is full of compromise. Partnerships with aggregators, such as Google's AMP, Facebook Instant Articles, and Apple News, have always required some amount of compromise on this front.

AMP aims to offer customer benefits—near-instant loading speeds and elevation into the Google News carousel for mobile search results—but the AMP user interface itself leads to some loss of brand. In the screenshot shown above, The Washington Post logo is not the top item on the page; instead, it is placed beneath a dotted bar that allows users to swipe to other content associated with a particular query.⁴

This discrepancy arises because of the nature of content hosted by an aggregator. This particular piece of content is created by The Washington Post under strict technical guidelines from Google. If this article uses valid AMP markup, Google stores it within its own caches. As a result, users receive the article from Google rather than The Washington Post. A user may notice—and be pleased with—the front-end page speed of content served via the AMP cache, but they may not otherwise notice that the content is not served from The Washington Post until they intend to share it. The tell-tale sign of a Google-served AMP article (besides the aforementioned dotted navigation component) is the URL associated with it in the browser: a link to the Google CDN,⁵ not to the original publication.

Signed Exchanges will alleviate the problem of mismatched URLs when it comes to publications' brand identity. For example, when a user attempts to access content from a publication that implements Signed Exchanges, that user would first access the publication's content from Google—and Google would serve that content with a URL bearing the original publisher's domain.

The Role of Trust in Signed Exchanges

Signed Exchanges appeal to publishers for multiple reasons: a beefing up of brand identity via the URLs, as described in the preceding sections, and for certain technical considerations, such as analytics and user tracking. Since the pages appear to users as those served out of the publisher's domain, developers could use first-party cookies and other methods for detecting user behavior patterns,⁶ vastly simplifying integrations and empowering engineering teams. Signed Exchanges allow for the "instant" feel of AMP pages being served from the Google caches, while doing a better job of ensuring users that they are receiving verified content from a trusted source. This trust comes in two portions:

Users must be able to trust that the content they are receiving is true and accurate. While many readers are actively concerned about the long-term proliferation of fake news, few consciously consider the role that content aggregators play in the industry on a day-to-day basis. Signed exchanges will help bring that discussion to consumers' attention, elevating participating publications' brands even further.

Publishers must be able to trust the aggregators who host and deliver their content. Publishers must be confident that aggregators are presenting it to their readers accurately, and that it hews closely to their brand identity. By handing their content to an aggregator, publishers are ceding control over their content to the aggregator. In doing so, they are placing an enormous amount of trust in that aggregator to represent their brand. One major concern regards the possibility of any aggregator becoming a bad actor—either intentionally or unintentionally.

Dave Merrell, Product Partnerships Director at the Washington Post, and serving on the AMP Advisory Committee, has been working closely with The Washington Post AMP adoption since AMP's earliest days. According to Merrell, if a publisher does a signed exchange, "we are letting [an aggregator] represent content that they are serving directly from us. The browser recognizes a washingtonpost.com URL even though [the aggregator] has some say in what is displayed to the end user."⁷

This ceding of control currently happens even without Signed Exchanges, and—to the best knowledge of this paper's authors—has never posed serious problems. Publishers are bound by an aggregator's restrictions and the visions of its product, which may not align with the publisher's priorities. As a result, a close relationship between an aggregator and a publisher is essential to maintaining a high level of trust. Merrell described the relationship as a positive one in which the AMP team takes Washington Post feedback and responds to it.

Early on in The Washington Post's adoption of AMP, Merrell said, there was a learning curve around revenue-boosting projects such as paywall, content metering and advertising. But, he noted, the AMP team listened to The Post and responded to feedback, ultimately delivering on their promises. For particularly large projects that might affect The Washington Post's implementation of AMP, The Post's internal engineering teams and product owners have been able to connect with the Google AMP team directly.

Thus, just as readers place their trust in a publisher, 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. More importantly, their users are rewarded with improved user experiences.

As Signed Exchanges become widespread, this kind of trust between publisher and aggregator will only become more important. Publishers must trust that an aggregator will represent their content accurately, as—from the reader's perspective—content served from the aggregator will be increasingly indistinguishable from content served from the publisher. This trust is priceless. It must be prioritized appropriately; once lost, it cannot be regained.

Establishing a promise. Aggregators should publish a pledge to readers promising they will never misrepresent content entrusted to them by publishers. Aggregators already purport to abide by these standards, but putting it in a place for all to see would be valuable to publishers, even if it has no legally binding implications. Even if, technically, an aggregator might be able to misrepresent or change content because it is in their caches, a stated, published pledge to never do that would help establish trust.

Pursuing open-sourced technologies. While AMP is maintained by Google, it also accepts open-source contributions.⁸ Open-source projects allow anyone to peruse and contribute to the underlying code, and it allows anyone the ability to follow along with the technical and philosophical decisions of the developers maintaining the project. In a world where the medium is the message,⁹ it is immensely useful to preserve trust by allowing anybody to pick apart and contribute to the architecture of the medium.

Creating authentic relationships between publishers and aggregators. This may be the most difficult recommendation to maintain or keep in mind as more and more publishers take advantage of web packaging to deliver their content through aggregators, but it may also be the most important. Aggregators can ensure these lines of communication stay open by utilizing services such as:

• Slack channels, or some other equivalent channel, within which developers or stakeholders can learn more about the aggregator or ask questions about the product and participate in real-time discussions with other users of the product.
• Open and public technical discussions for both broad and specific issues. Github, a widely used code management platform, is an ideal place for developers to comment on code and understand how technologies function under the hood. These discussions are another advantage to the aggregators if they open source their technologies; developers can provide ideas for the product roadmap, identify bugs or other discrepancies, and even resolve production issues on the aggregator's behalf.
• Frequent, regular conferences encouraging discussion. These venues would provide a way for publishers to learn about and buy-in to the roadmaps of the aggregator, and give publishers the ability to voice their concerns—or excitement—face-to-face. In a world where so many interactions take place through keyboards, events help foster an appreciation for the humans behind the code.

Additionally, publishers who participate in aggregated content platforms also can take steps to promote trust amongst readers:

Maintaining a public list of all platforms where a publication's content may be found or syndicated. Many readers may not be aware of the differences between content served from an aggregator and that served from a publisher's origin. As a result, a publisher should be proactive in communicating with readers about platforms where they may discover its content. The simplest way to do this would be to publish a reader-facing page that contains details about authorized domains or platforms on which a publication's content may be viewed, including example URL formats that a reader may encounter.

Advocating for more browser and platform support for signed exchanges. One current drawback to signed exchanges is the limited availability for publishers who implement them. Currently, only Google's Chrome browser supports signed exchanges, and only Google's mobile search AMP results supports their use in production. In order for publishers to realize the full benefits of signed exchanges, publishers should advocate for browsers to implement signed exchange support in new versions as soon as possible and to provide a graceful fallback solution for readers who are running out-of-date versions. Similarly, publishers should push aggregators such as Facebook, Apple, and Baidu to offer support for signed exchanges in a standardized way, rather than allowing each to pursue platform-specific methods of domain verification.

Monitoring aggregators' roadmaps and releases. Just as aggregators should encourage frequent, open discussion about their products, publishers should be active participants in those conversations and stay up-to-date on platform changes or deprecations. Further, publishers should also implement automated pipelines that programmatically test and validate the publisher's code against each aggregator's format; this proactive approach would diminish the likelihood of publishers scrambling to hotfix production APIs or websites in response to changes in an aggregator's format or requirements.

Footnotes

¹ Larson, Selena. "Web inventor: Internet should 'promote truth'." CNN 4 Apr. 2017. Web. 31 May 2019, https://money.cnn.com/2017/04/04/technology/tim-berners-lee-open-web-democracy-truth/ (via Wayback Machine)

² "Three challenges for the web, according to its inventor." Web Foundation. 12 Mar. 2017. Web. 31 May 2019, https://webfoundation.org/2017/03/web-turns-28-letter/ (via Wayback Machine)

³ "What really happened to the news business". Digital Riptide. Web. 31 May 2019, https://www.digitalriptide.org/introduction/

⁴ Sheinin, Dave. "Dallas Keuchel and Craig Kimbrel will soon sign free agent deals. Where will they land?." The Washington Post. 31 May 2019. Web. 31 May 2019, washingtonpost.com

⁵ CDN: Content Delivery Network. This is a system of servers, distributed around the world, that get content to users faster because it is geographically closer to them.

⁶ "Instant-loading AMP pages from your domain." Official Google Webmaster Central Blog. 16 Apr. 2019. Web. 31 May 2019, https://webmasters.googleblog.com/2019/04/instant-loading-amp-pages-from-your-own.html

⁷ Dave Merrell, interview. Matt Nelson. 29 May 2019.

⁸ "Github AMP Repository Read Me". Github. Last modified 31 May 2019. Accessed 31 May 2019, https://github.com/ampproject/amphtml

⁹ McCluhan, Marshall. "The Medium is the Message". 1964. Web MIT Edu. 31 May 2019, https://web.mit.edu/allanmc/www/mcluhan.mediummessage.pdf