[要約] RFC 8752は、コンテンツの集約とパブリッシャーエコシステムの相乗効果を探るIABワークショップ(ESCAPE)の報告書です。このRFCの目的は、コンテンツの集約とパブリッシャーエコシステムの関係を理解し、相互作用を促進するためのガイドラインを提供することです。

Internet Architecture Board (IAB)                             M. Thomson
Request for Comments: 8752
Category: Informational                                    M. Nottingham
ISSN: 2070-1721                                               March 2020
        

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

コンテンツ集約とパブリッシャーエコシステム(ESCAPE)の間の相乗効果の探索に関するIABワークショップからのレポート

Abstract

概要

The Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration.

コンテンツ集約とパブリッシャーエコシステム(ESCAPE)ワークショップの間の相乗効果の調査ワークショップは、2019年7月にインターネットアーキテクチャボード(IAB)によって召集されました。このレポートは、その重要な議論のポイントを要約し、さらに検討する必要があるトピックを特定します。

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.

なお、本資料はワークショップの議事録です。このレポートに記載されている見解と見解はワークショップ参加者のものであり、必ずしもIABの見解と見解を反映しているわけではありません。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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.

このドキュメントは、インターネットアーキテクチャボード(IAB)の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード(IAB)のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8752.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8752で入手できます。

Copyright Notice

著作権表示

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

著作権(c)2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

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
1. はじめに

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).

インターネットアーキテクチャボード(IAB)は、インターネットの長期的な問題と戦略を検討し、インターネットアーキテクチャの将来の方向性を提案するように設計されたワークショップを時折開催します。 IABのこの長期計画機能は、インターネットエンジニアリングタスクフォース(IETF)のワーキンググループによって実行されている継続的なエンジニアリングの取り組みを補完します。

The IAB convened the ESCAPE Workshop to examine some proposed changes to the Internet and the Web, and their potential effects on the Internet publishing landscape. Of particular interest was the Web Packaging proposal from Google, under consideration in the IETF, the W3C's Web Incubator Community Group (WICG), and the Web Hypertext Application Technology Working Group (WHATWG).

IABはESCAPEワークショップを招集して、インターネットとWebに対するいくつかの提案された変更と、それらがインターネットの発行状況に及ぼす可能性のある影響を調査しました。特に興味深いのは、IETF、W3CのWebインキュベーターコミュニティグループ(WICG)、およびWebハイパーテキストアプリケーションテクノロジーワーキンググループ(WHATWG)で検討中の、GoogleによるWebパッケージングの提案でした。

In considering these proposals, we heard about both positive effects of Web Packaging and concerns that it could have significant effects on the relationship between publishers (e.g., news web sites) and content aggregators (e.g., search engines and social networks). As such, our focus was primarily on this relationship, rather than technical discussion.

これらの提案を検討する際に、Webパッケージングのプラスの影響と、パブリッシャー(ニュースWebサイトなど)とコンテンツアグリゲーター(検索エンジンやソーシャルネットワークなど)との関係に大きな影響を与える可能性があるという懸念について聞いた。したがって、私たちの焦点は、技術的な議論ではなく、主にこの関係にありました。

Online publishers do not regularly participate in standards activities directly. A workshop format was used to solicit input from them. The workshop had 27 participants from a diverse set of backgrounds, including a small number of attendees from publishers, one aggregator (Google), plus representatives from browsers, the Accelerated Mobile Pages (AMP) community, Content Distribution Networks (CDNs), network operators, academia, and standards bodies. See the workshop call for papers [CFP] for more information and a complete listing of submissions.

オンライン発行者は、標準活動に直接直接参加することはありません。ワークショップ形式は、彼らからの意見を求めるために使用されました。ワークショップには、パブリッシャーからの少数の参加者、1つのアグリゲーター(Google)、ブラウザーからの代表者、Accelerated Mobile Pages(AMP)コミュニティ、コンテンツ配信ネットワーク(CDN)、ネットワークオペレーターなど、さまざまなバックグラウンドの27人の参加者がいました、学界、標準化団体。詳細と提出物の完全なリストについては、ワークショップの論文募集[CFP]を参照してください。

As intended, the workshop was primarily a forum for discussion, so it did not reach definite conclusions. Instead, this report is the primary output of the workshop, as a record of that discussion.

意図したとおり、ワークショップは主に議論の場でしたので、明確な結論には至りませんでした。代わりに、このレポートは、その議論の記録として、ワークショップの主要な成果物です。

This report documents the use cases discussed in Section 2 and explains the interactions between publishers and aggregators that might be affected by it in Section 3. Appendix A includes more details about the workshop itself. For those unfamiliar with Web Packaging, Appendix B provides a summary as background material.

このレポートは、セクション2で説明した使用例を文書化し、セクション3で影響を受ける可能性のあるパブリッシャーとアグリゲーター間の相互作用について説明します。付録Aには、ワークショップ自体の詳細が含まれています。 Webパッケージングに不慣れな方のために、付録Bは背景資料として要約を提供します。

1.1. Mention of Specific Entities
1.1. 特定のエンティティの言及

Participants agreed to conduct the workshop under the Chatham House Rule [CHATHAM-HOUSE], so this report does not attribute statements to individuals or organizations without express permission. Submissions to the workshop were public and thus attributable; they are used here to provide substance and context.

参加者はチャタムハウスルール[CHATHAM-HOUSE]に基づいてワークショップを実施することに同意したため、このレポートでは、明示的な許可なしに個人または組織に声明を記載していません。ワークショップへの提出は公開されたものであり、それが原因でした。ここでは、内容とコンテキストを提供するために使用されます。

2. Use Cases
2. ユースケース

Much of the workshop concentrated on discussion of the validity and relative merits of the use cases that might be enabled by Web Packaging. See Appendix B for an overview of Web Packaging.

ワークショップの多くは、Webパッケージングによって可能になる可能性のあるユースケースの有効性と相対的なメリットについての議論に集中しました。 Webパッケージングの概要については、付録Bを参照してください。

2.1. Instant Navigation
2.1. インスタントナビゲーション

The largest use of Web Packaging so far is in Google Search, where packages are intended to improve the perceived performance of navigation to pages that are linked from search results when "clicked".

これまでのWebパッケージの最大の用途はGoogle検索であり、パッケージは、「クリックされた」ときに検索結果からリンクされたページへのナビゲーションの知覚パフォーマンスを向上させることを目的としています。

To enable this, when a linking (or referring) web page includes links to pages on another site, it also provides the browser with a packaged copy of the target content, signed by the origin of the target content. In effect, the referring page provides a cache for the target page's content. If navigation to one of those links occurs, having the Web Package gives a browser the assurance that the cache didn't change the content, so it can treat that content as if it were acquired directly from the server for the target page -- even though it came from a different server. In many cases, this results in significantly lower perceived delay in displaying the target page.

これを可能にするために、リンク(または参照)Webページに別のサイトのページへのリンクが含まれている場合、ターゲットコンテンツのオリジンによって署名された、ターゲットコンテンツのパッケージコピーもブラウザーに提供します。実際、参照ページは、ターゲットページのコンテンツのキャッシュを提供します。これらのリンクの1つへのナビゲーションが発生した場合、Webパッケージを使用すると、キャッシュによってコンテンツが変更されなかったことがブラウザーに保証され、ターゲットページのサーバーから直接取得されたかのようにコンテンツを処理できます。別のサーバーからのものですが。多くの場合、これにより、ターゲットページの表示で認識される遅延が大幅に減少します。

A vital characteristic of this technique is that the browser does not contact the target site before navigation. The browser does not make any requests to sites until after navigation occurs, and only then if the site requires additional content or makes a request directly.

この手法の重要な特徴は、ブラウザがナビゲーションの前にターゲットサイトにアクセスしないことです。ブラウザは、ナビゲーションが発生するまで、サイトが追加のコンテンツを必要とするか、直接リクエストする場合にのみ、サイトへのリクエストを行いません。

Similar improvements could also be realized by downloading content (packaged or otherwise) directly from the target site through a technique called "prefetching". However, doing so would reveal information about the user's activity on the linking page to those sites -- even when the user never actually navigates to it.

「プリフェッチ」と呼ばれる手法を使用して、ターゲットサイトから直接コンテンツ(パッケージ化またはその他)をダウンロードすることで、同様の改善を実現することもできます。ただし、そうすることで、リンクページでのユーザーのアクティビティに関する情報が明らかになります。

      |  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 additionally be constructed in a way that ensures that they render without needing any additional network access. This makes it possible to provide near-instantaneous navigation. The proposed changes to web navigation in support of loading Web Packages is designed to support this use case.

Webパッケージングにバンドルされたサイトは、追加のネットワークアクセスを必要とせずにレンダリングできるようにさらに構築できます。これにより、ほぼ瞬時にナビゲーションを提供できます。 Webパッケージの読み込みをサポートするWebナビゲーションへの提案された変更は、この使用例をサポートするように設計されています。

Workshop participants recognized the value of web performance for usability, as well as for business metrics like retention and bounce rates. Such improvements were seen as a valuable goal, but publishers raised questions about whether they justified the cost of supporting an additional format, while others raised concerns about different aspects of the Web Packaging proposal.

ワークショップの参加者は、使いやすさだけでなく、保持率や直帰率などのビジネス指標にとってのWebパフォーマンスの価値を認識しました。このような改善は価値のある目標と見なされていましたが、出版社は追加のフォーマットをサポートするコストを正当化するかどうかについて疑問を投げかけました。

2.2. Offline Content Sharing
2.2. オフラインコンテンツ共有

Another primary use case discussed was the ability to share web content between devices where neither has an active connection to the Internet. One of the stated goals of Web Packaging is to enable sharing of content offline.

議論されたもう1つの主な使用例は、どちらもインターネットにアクティブに接続していないデバイス間でWebコンテンツを共有する機能でした。 Webパッケージングの目標の1つは、コンテンツをオフラインで共有できるようにすることです。

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 web browsers already have some affordances for this, but these are recognized as in need of improvements.

一部の参加者は、インターネットアクセスが高価、低速、または断続的な領域では、直接のピアツーピアファイル交換(たとえば、「Webサイトを保存してUSBスティックで共有する」)の使用が一般的であると報告しました。ほとんどのWebブラウザーにはすでにこれに対するいくつかのアフォーダンスがありますが、これらは改善が必要であると認識されています。

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 and that of one loaded from an offline Web Package.

ディスカッションでは、「通常の」Webページの扱いとオフラインのWebパッケージからロードされたWebページの扱いに違いがないという、このユースケースの想定要件を拒否する人がいくつかいました。

The ability for a Web Package to provide clear attribution for content was seen as valuable by some participants for a range of reasons. However, reservations were expressed about the subtleties of the properties that signatures provide and the effect of this on web security; see also Sections 4.2 and 2.3.2.

一部の参加者は、さまざまな理由から、Webパッケージがコンテンツに明確な属性を提供できることを評価しました。ただし、署名によって提供されるプロパティの微妙な点と、これがWebセキュリティに与える影響について、留保が表明されました。セクション4.2および2.3.2も参照してください。

Many participants pointed out that using "unsigned bundles" -- that is, Web Packages without signed exchanges -- could be adequate for this use case, since most users don't need cryptographic proof of the site's identity. However, some expressed concerns that this might worsen the propagation of falsehood.

ほとんどのユーザーはサイトのIDの暗号化された証明を必要としないため、多くの参加者は、「署名されていないバンドル」、つまり署名された交換のないWebパッケージの使用がこの使用例に適していると指摘しました。しかし、これが虚偽の伝播を悪化させるかもしれないという懸念を表明する人もいた。

Some suggested that the value of signed exchanges was not realized in small-scale interpersonal exchange of information but in the building of systems for content delivery that might include capabilities like discovery and automated distribution. The contention here was that effective use of digital signatures in offline distribution of content implied considerably more infrastructure than was described in current proposals.

署名された交換の価値は、小規模な個人間の情報交換では実現されなかったが、発見や自動配信などの機能を含む可能性のあるコンテンツ配信のためのシステムの構築で実現されたとする提案もあった。ここでの論争は、コンテンツのオフライン配信におけるデジタル署名の効果的な使用は、現在の提案で説明されているよりもはるかに多くのインフラストラクチャを意味するというものでした。

No definite conclusions about offline sharing were reached during the workshop.

ワークショップでは、オフライン共有について明確な結論に達しませんでした。

2.3. Other Use Cases
2.3. その他の使用例

A session on the second morning concentrated on two other significant potential use cases for Web Packages: book publishing and Web archiving. These were not seen as "primary" by the proponents of Web Packaging; the original intent was not to spend significant time on these subjects, but there was considerable interest from attendees.

2日目の午前のセッションでは、Webパッケージのその他の2つの重要な潜在的な使用例である本の公開とWebアーカイブに集中しました。これらは、Webパッケージングの支持者には「主要」とは見なされていませんでした。当初の目的は、これらのテーマにかなりの時間を費やすことではありませんでしたが、参加者からかなりの関心がありました。

2.3.1. Book Publishing
2.3.1. 本の出版

The potential application of a packaging format to book publishing was discussed, with particular reference to ways that books differ from web content. Specialists from that industry pointed out that book delivery can vary greatly from typical web content delivery.

書籍がWebコンテンツと異なる点に特に言及しながら、パッケージング形式を書籍出版に適用できる可能性について説明しました。その業界の専門家は、書籍の配信は通常のWebコンテンツ配信とは大きく異なる可能性があると指摘しました。

Workshop participants briefly explored existing solutions. PDF was seen as particularly challenging for this use case, due to its limitations, and EPUB has constraints that also make it challenging for publishers.

ワークショップの参加者は、既存のソリューションを簡単に調査しました。 PDFは、その制限のため、このユースケースでは特に困難であると見なされていました。また、EPUBには、発行者にとっても困難な制約があります。

Although Web Packaging might help to address this use case, the question of how to identify book content was not resolved. The use of signed exchanges in this context might offer means of tying content in books to a website, but several limitations inherent in doing that were identified.

Webパッケージングは​​この使用例に対処するのに役立つかもしれませんが、本のコンテンツを識別する方法の問題は解決されませんでした。このコンテキストで署名された交換を使用すると、書籍のコンテンツをWebサイトに結び付ける手段が提供される可能性がありますが、これを行うことには固有の制限がいくつか確認されました。

In particular, book publication specialists represented that books don't have the same requirements for timeliness or currency as web pages. For instance, Dave Cramer's submission [CRAMER] observed that Moby Dick was published over 61,000 days ago, which is considerably longer than the proposed limit of 7 days for signed exchanges. The limited length of time that a Web Package can be considered valid was discussed at some length.

特に、書籍出版の専門家は、書籍には適時性や通貨に関する要件がWebページと同じではないことを表明しました。たとえば、Dave Cramerの提出[CRAMER]は、Moby Dickが61,000日以上前に公開されたことを認めており、これは、署名された交換について提案されている7日間の制限よりかなり長いです。 Webパッケージが有効であると見なすことができる限られた時間は、ある程度議論されました。

Additionally, the risk of a publisher going out of business during the lifetime of a book is significant, because books -- at least successful ones -- often span generations in their applicability. To that end, having a means of attributing content to a publisher was considered less practical and potentially undesirable (much like the discussion above regarding "unsigned bundles").

さらに、本-少なくとも成功した本-は、何世代にもわたって適用できるため、本の存続期間中に出版社が廃業するリスクは重大です。そのために、コンテンツを発行者に帰属させる手段を持つことは、実用性が低く、望ましくない可能性があると考えられていました(「署名されていないバンドル」に関する上記の説明と同様)。

There were other aspects of book publication that participants saw as challenging for packaging. For example, it is currently not understood what it means to refer to distinct parts of a book. Participants saw this as an area where providing 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 content or enable new features was considered valuable. Models for enabling paywalls were discussed at some length (see Section 5.4).

バンドル内のアクティブコンテンツがWeb APIを使用してコンテンツを充実させたり、新機能を有効にしたりする可能性は、貴重であると考えられていました。ペイウォールを有効にするためのモデルについてはある程度議論されました(セクション5.4を参照)。

2.3.2. Web Archiving
2.3.2. Webアーカイブ

Web archiving is a complicated discipline that is made more difficult by the complex nature of the Web itself.

Webアーカイブは複雑な分野であり、Web自体の複雑な性質によってさらに困難になっています。

From an archival standpoint, the potential for web content to be provided in a self-contained form was viewed positively. Several improvements to the structure of Web Packaging were considered, such as providing complete sets of content and the use of Memento [MEMENTO].

アーカイブの観点からは、Webコンテンツが自己完結型で提供される可能性が積極的に見られました。コンテンツの完全なセットの提供やMemento [MEMENTO]の使用など、Webパッケージングの構造に対するいくつかの改善が検討されました。

Though there were potential applications of a packaging scheme, many challenges were recognized as requiring additional work on the part of content producers to be fully effective. For example, JavaScript is needed to render some archived content faithfully, but attributing that content to an origin in all scenarios is challenging.

パッケージスキームの潜在的なアプリケーションがありましたが、コンテンツプロデューサーの側で追加の作業が完全に効果的であることを要求するものとして多くの課題が認識されました。たとえば、JavaScriptはアーカイブされたコンテンツを忠実にレンダリングするために必要ですが、すべてのシナリオでそのコンテンツをオリジンに帰することは困難です。

If packaging were to be widely deployed, it might improve the situation for archival replay. In particular, the speculation is that there would be less "live leakage" as packaged content might be less likely to refer to live resources that currently tend to "leak" into views of archives. It was also noted that subresources might also be more likely to be packaged, especially those that are needed for deferred representations (i.e., after JavaScript execution on the page or some user interactions). Other potential applications and enhancements are discussed in [ALAM].

パッケージが広く展開されると、アーカイブの再生状況が改善される可能性があります。特に、パッケージ化されたコンテンツは、現在アーカイブのビューに「リーク」する傾向があるライブリソースを参照する可能性が低いため、「ライブリーク」は少ないと推測されています。また、サブリソース、特に据え置き表現に必要なサブリソース(つまり、ページ上でのJavaScriptの実行後または一部のユーザー操作後)がパッケージ化される可能性が高いことも指摘されました。他の潜在的なアプリケーションと機能強化については、[ALAM]で説明されています。

Participants discussed the use of a signature for non-repudiation at some length. In one case related to the Internet Archive, a public figure disputed the accuracy of archived content, asserting that the original content was modified either at the source or in the archive.

参加者は、否認防止のための署名の使用についてある程度議論しました。インターネットアーカイブに関連する1つのケースでは、公の人物がアーカイブされたコンテンツの正確さに異議を唱え、元のコンテンツがソースまたはアーカイブで変更されたと主張しました。

Some participants initially saw digital signatures as a way to address such issues of provenance. As similar problems exist in other areas, such as in book publication, medical research, and news, a solution to this problem was considered to have broad applicability.

一部の参加者は、当初、このような出所の問題に対処する方法としてデジタル署名を考えていました。本の出版、医学研究、ニュースなどの他の分野にも同様の問題が存在するため、この問題の解決策は幅広い適用性があると考えられました。

However, the discussion ultimately concluded that providing non-repudiation in retrospect is challenging. Signing keys are not expected to remain secure for long periods. If keys are leaked afterwards, an attacker could retroactively generate fraudulent signatures. Alternative solutions were discussed, such as providing independent archives for the same data, using consensus protocols, or using an append-only construct like a Haber-Stornetta log [AOLOG], all of which can be used to increase the difficulty of altering or misrepresenting established archives.

ただし、最終的には、否認防止を振り返って提供することは難しいと結論付けました。署名鍵は長期間安全であるとは考えられていません。その後キーが漏洩した場合、攻撃者は遡及して不正な署名を生成する可能性があります。同じデータに独立したアーカイブを提供する、コンセンサスプロトコルを使用する、Haber-Stornettaログ[AOLOG]などの追加のみの構造を使用するなど、代替ソリューションについて説明しました。これらはすべて、変更や不実表示の難易度を高めるために使用できます。確立されたアーカイブ。

3. Interactions between Web Publishers and Aggregators
3. Webパブリッシャーとアグリゲーター間の相互作用

A significant motivation for holding the workshop was to provide a forum where publishers could discuss the impact of Web Packaging on the online publishing ecosystem. Of primary interest was whether Web Packages might effectively enable a transfer of power from publishers to aggregators.

ワークショップを開催する重要な動機は、出版社がオンラインパブリッシングエコシステムへのWebパッケージングの影響について議論できるフォーラムを提供することでした。主な関心事は、Webパッケージがパブリッシャーからアグリゲーターへの力の伝達を効果的に可能にするかどうかでした。

Both publishers and aggregators at the workshop expressed the importance of maintaining a positive relationship. Publishers in particular expressed the need to be able to trust that aggregators won't misrepresent their work or de-emphasize it for reasons unrelated to quality and perceived value to the user.

ワークショップのパブリッシャーとアグリゲーターの両方が、前向きな関係を維持することの重要性を表明しました。特にパブリッシャーは、アグリゲーターがユーザーの品質や知覚される価値とは無関係の理由で、アグリゲーターが自分の仕事を誤って伝えたり、強調したりしないことを信頼できる必要性を表明しました。

One key question from [BERJON] was discussed:

[BERJON]からの1つの重要な質問が議論されました:

   |  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 model offered by aggregators. The costs that publishers incur for participation in that system were considered. Considerable time was spent on AMP; a summary of that discussion can be found in Section 5.

この問題を検討するにあたり、アグリゲーターが提供する現在のインセンティブモデルに焦点を当てた議論が行われました。そのシステムへの参加のために出版社が負担する費用が考慮された。 AMPにはかなりの時間が費やされました。その議論の要約はセクション5にあります。

We also considered the question of whether standardizing Web Packaging confers credibility to aggregators exercising unwelcome control over publisher content or whether the technical safeguards Web Packaging provides could allow aggregators to relax their restrictions on the kinds of content they're willing to cache and serve. No conclusions were drawn.

また、Webパッケージの標準化により、パブリッシャーのコンテンツに対して歓迎されない制御を行うアグリゲーターに信頼性を与えるかどうか、またはWebパッケージが提供する技術的な保護手段によって、アグリゲーターがキャッシュして提供するコンテンツの種類に対する制限を緩和できるかどうかについても検討しました。結論は出されませんでした。

3.1. Incentives for Web Packages
3.1. Webパッケージのインセンティブ

Submissions to the workshop indicated that the use of inducements involving better placement and formatting of links to publisher content had a significant effect on the uptake of related technology. For example, in [DEPUYDT-NELSON]:

ワークショップへの提出は、出版社のコンテンツへのリンクのより良い配置とフォーマットを含む誘導の使用が関連するテクノロジーの取り込みに大きな影響を与えたことを示しました。たとえば、[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 for the privileged position in the Google Search carousel given to AMP content, they would not publish in that format.

ワークショップ中に、いくつかのオンラインパブリッシャーは、AMPコンテンツに付与されたGoogle検索カルーセルでの特権的な立場がなければ、その形式でパブリッシュしないことを示しました。

Publishers that do produce AMP said they see a non-trivial increase in traffic as 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 better placement in Google Search results, the inherent benefits of the AMP Cache, or the use of the AMP format.

AMPを作成しているパブリッシャーは、AMPコンテンツを導入した結果として、トラフィックの増加は自明ではないと述べています。たとえば、Yahoo Japanは、Yahoo Travel [OTSU]にAMPを導入した結果、トラフィックが60%増加したと報告しています。この増加がGoogle検索結果での配置の改善によるものか、AMPキャッシュの固有の利点によるものか、AMP形式の使用によるものかについては、データは示されていません。

Anecdotal evidence was offered by another large publisher that saw a 10% drop in traffic as a result of accidentally disabling AMP content. However, increases in traffic might not result in similarly proportioned increases in revenue, as observed in [BREWSTER].

AMPコンテンツを誤って無効にした結果、トラフィックが10%減少した別の大手パブリッシャーが事例証拠を提供しました。ただし、トラフィックの増加は、[BREWSTER]で観察されたように、収益に同様に比例した増加をもたらさない場合があります。

3.2. Operational Costs
3.2. 運用コスト

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.

数人の参加者は、Webコンテンツに新しい並列形式を導入すると運用コストが発生すると指摘しました。特に、Webパッケージング、Apple News、Facebookインスタント記事などの新しい形式をサポートするには、ツールの初期開発(一般的なものやサイトの要件に固有のもの)だけでなく、その操作性を維持するための継続的な投資も必要です。 。一部の参加者は、特に現在の出版環境において、技術的および財政的リソースが限られている小規模な出版社への影響について懸念を表明しました。

Increased exposure from new formats might not always justify the added expense of providing articles in that format [BREWSTER]. However, a standardized format might help publishers reduce the cost of maintaining multiple formats.

新しいフォーマットからの露出の増加は、常にそのフォーマットで記事を提供する追加の費用を正当化するとは限りません[BREWSTER]。ただし、標準化された形式は、発行者が複数の形式を維持するコストを削減するのに役立つ場合があります。

3.3. Content Regulation
3.3. コンテンツ規制

The use of Web Packaging as a tool for avoiding censorship was not a significant topic of discussion, except to note that publishers often have regulatory requirements regarding removal or correction of content.

検閲を回避するためのツールとしてWebパッケージングを使用することは、コンテンツの削除または修正に関する規制要件が発行者にあることが多いことを除いて、重要な議論のトピックではありませんでした。

Reference was made to the desire to remove videos of a recent shooting [CHRISTCHURCH] and the potential difficulty in doing so if content were available as Web Packages. Legal requirements to remove content come from multiple angles: copyright violations, illegal content, editorial corrections or errors, and right to erasure provisions in the European Union General Data Protection Regulation [GDPR] were mentioned. One participant speculated that making it more difficult to remove material in this way might discourage regulators from censoring content.

最近の撮影のビデオ[CHRISTCHURCH]を削除したいという要望と、コンテンツがWebパッケージとして提供されている場合は削除が難しい可能性について言及しました。コンテンツを削除するための法的要件は、著作権違反、違法なコンテンツ、編集上の修正またはエラー、EUの一般データ保護規則[GDPR]の条項を消去する権利など、さまざまな角度から生じています。ある参加者は、この方法で素材を削除することをより困難にすると、規制当局がコンテンツを検閲するのを妨げるかもしれないと推測しました。

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.

この文脈において、参加者は、検閲抵抗の規定された目標を損なうことなく、Webパッケージとして提供されるコンテンツを追跡および制御するメカニズムを作成することは困難であることを認めました。

3.4. Web Performance
3.4. ウェブパフォーマンス

Understanding the effect that Web Packaging might have on web performance was a matter of some contention.

WebパッケージングがWebパフォーマンスに与える影響を理解することは、いくつかの争点の問題でした。

Some informal analysis from the Google Search deployment was presented (later published in [AMP-PERF]) that showed significant performance improvements in metrics related to navigation time resulting from the combination of prefetch, prerendering, and the AMP format. These results are suggestive of a possibility that Web Packaging could provide some of that improvement on its own, but no data was presented that apportioned the improvement among the three components.

Google検索の展開からのいくつかの非公式な分析が提示され([AMP-PERF]で後で公開)、プリフェッチ、プリレンダリング、およびAMP形式の組み合わせに起因するナビゲーション時間に関連するメトリックの大幅なパフォーマンスの向上が示されました。これらの結果は、Webパッケージングがそれ自体でその改善の一部を提供できる可能性を示唆していますが、3つのコンポーネント間で改善を配分したデータは提示されていません。

Though data was presented to demonstrate potential rather than be a definitive result, discussions raised a number of questions that suggest the need for further study. Attendees suggested that future measurements consider the effect of signed bundles distinct from the enhancements derived from the AMP format. Future research in this area might also consider the effectiveness of different strategies on devices with varying capabilities, bandwidth, power consumption requirements, or network conditions.

データは決定的な結果というよりは可能性を実証するために提示されましたが、議論はさらなる研究の必要性を示唆する多くの質問を提起しました。参加者は、今後の測定では、AMP形式から派生した拡張機能とは異なる署名付きバンドルの影響を考慮することを提案しました。この領域の将来の調査では、機能、帯域幅、消費電力要件、またはネットワーク条件が異なるデバイスでのさまざまな戦略の有効性も検討する可能性があります。

Of particular interest is the additional work required to fetch and render multiple web pages in preparation for navigation. This might ultimately use fewer connections but comes with an increased network and CPU cost for clients. Some participants pointed out that different clients or applications might require different tuning -- for example, when users have limited (or expensive) bandwidth or for sites with less clear knowledge about the use of outbound links.

特に興味深いのは、ナビゲーションの準備として複数のWebページをフェッチしてレンダリングするために必要な追加の作業です。これにより、最終的に使用される接続が少なくなる可能性がありますが、クライアントのネットワークおよびCPUコストが増加します。一部の参加者は、たとえばクライアントの帯域幅が制限されている(または高価である)場合や、送信リンクの使用に関する明確な知識が少ないサイトの場合など、異なるクライアントまたはアプリケーションには異なる調整が必要になる可能性があると指摘しました。

Workshop participants also expressed interest in learning about the effect of Web Packages on subsequent navigations within the target site.

ワークショップの参加者は、ターゲットサイト内の後続のナビゲーションに対するWebパッケージの影響について学ぶことに関心を示しました。

In discussion, some participants suggested that their experience supported a theory that operating a cache at the linking site was most effective and the additional work done prior to navigation in terms of fetching and preparing content was what provided the most gains; others suggested that the benefits inherent in the AMP format was a dominant factor.

ディスカッションでは、一部の参加者は、自分の経験がリンクサイトでのキャッシュの操作が最も効果的であり、ナビゲーションの前にコンテンツのフェッチと準備に関して追加の作業が最も効果的であるという理論をサポートすることを示唆しました。他の人は、AMPフォーマットに固有の利点が支配的な要因であると提案しました。

Understanding the complete effect of Web Packaging on web performance will require further work.

WebパッケージングがWebパフォーマンスに与える影響を完全に理解するには、さらに作業が必要になります。

4. Systemic Effects
4. 全身への影響

It is not straightforward to estimate how a proposed technology change might affect all of the parts of a system -- including not only other components, but also things like end-user rights and the balance of power between parties -- ahead of time. To date, when evaluating proposals, the IETF has generally focused on more immediate concerns, such as interoperability and security.

他のコンポーネントだけでなく、エンドユーザーの権利や当事者間の電力のバランスなど、システムのすべての部分にどのように影響する可能性があるかを前もって見積もることは簡単ではありません。これまで、提案を評価する際、IETFは一般に、相互運用性やセキュリティなど、より差し迫った問題に焦点を当ててきました。

Moreover, people often find new uses for successful standards [SUCCESS] after they are deployed. It is rarely possible to accurately predict all applications of a protocol or format, whether they are harmful or beneficial. Refusing standardization only impedes both outcomes.

さらに、人々はしばしば彼らが配備された後に成功した標準[SUCCESS]の新しい用途を見つける。プロトコルやフォーマットのすべてのアプリケーションが、有害か有益かを正確に予測することはほとんど不可能です。標準化を拒否しても、両方の結果が妨げられるだけです。

With the understanding that predictions are difficult to make, there was considerable 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 attempts to capture that discussion.

予測が難しいことを理解した上で、ワークショップでは、WebへのWebパッケージングの影響の可能性についてかなりの憶測がありました。その推測の一部は経験に基づいていますが、その経験は必然的に範囲が限定されます。このセクションでは、その議論を捉えようとします。

4.1. Consolidation
4.1. 統合

Concerns about the consolidation of power on the Internet have significantly increased lately, as a result of several factors. While the IAB, the Internet Society, and others are examining this phenomenon to understand it better, it is nevertheless prudent to consider whether proposals for changes to how the Internet works favors or counters consolidation. Favoring entities with existing advantages -- like resources, size, or market share -- is not necessarily a factor that disqualifies a new proposal, but it needs to be considered as a cost of enabling that technology.

いくつかの要因の結果として、インターネット上の電力統合に関する懸念は最近大幅に高まっています。 IAB、インターネットソサエティなどがこの現象を調査して理解を深めていますが、それでも、インターネットの動作方法の変更に関する提案が、統合に有利か反対かを検討することは賢明です。リソース、サイズ、市場シェアなど、既存の利点を持つエンティティを優先することは、必ずしも新しい提案を不合格にする要因ではありませんが、そのテクノロジを実現するためのコストと見なす必要があります。

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

Webパッケージングを採用した結果は不明確ですが、ワークショップでは、関係するすべての関係者(ユーザー、発行者サイト、リンクサイト、それぞれが依存するサービス)の統合リスクに関するいくつかの懸念が明らかになりました。

4.1.1. Consolidation of Power in Linking Sites
4.1.1. サイトのリンクにおけるパワーの統合

Several participants noted that Web Packaging's enabling of instant navigation (Section 2.1) might advantage larger linking sites -- such as social networks or search engines -- over smaller ones in the same industry because doing so requires careful selections of which links to optimize, so as not to create unneeded traffic.

数人の参加者は、Webパッケージングでインスタントナビゲーションを有効にすると(セクション2.1)、ソーシャルネットワークや検索エンジンなどの大規模なリンクサイトが、同じ業界の小さなサイトよりも有利になる可能性があると指摘しました。不要なトラフィックを作成しないように。

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 requires considerable data collection and engineering, so this technique might not be feasible for smaller entities. Additionally, some participants noted that this technique favors sites that have a linear set of ranked links, like search results; it is more difficult to apply to a page of news (for example) because predicting what link a user will follow is less obvious.

たとえば、ニュース記事には多くのリンクが含まれていることがよくありますが、そのすべてが同じようにフォローされるわけではありません。どちらをプリフェッチするかを決定するには、かなりのデータ収集とエンジニアリングが必要になるため、この手法は小規模なエンティティでは実行できない場合があります。さらに、一部の参加者は、この手法は検索結果のように、ランク付けされたリンクの線形セットを持つサイトを優先することに言及しました。 (たとえば)ニュースのページに適用するのはより困難です。これは、ユーザーがたどるリンクを予測することはそれほど明白ではないためです。

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

この手法では、サイトの要件と互換性のある使用条件でキャッシュにアクセスする必要もあります。 Google AMPキャッシュには多くの人が受け入れられるポリシーがあり、他にもキャッシュがあることが指摘されました。 Google以外のエンティティによって運営されているサイトはすでにこのキャッシュを使用していますが、独自のキャッシュをホストしていないサイトでは、パフォーマンスが若干低下することが確認されています。

4.1.2. Consolidation of Power in Publishers
4.1.2. パブリッシャーにおけるパワーの統合

Participants seemed to agree that if performance is a strong enough differentiator, the effective use of Web Packaging might turn out to be a condition for success for online publishers. Google Search's choice to privilege content that is served using HTTPS was pointed out as showing that this sort of influence can be effective. Equally, it is not necessarily the case that standardization of new capabilities will affect such policies materially, as noted in [YASSKIN]:

参加者は、パフォーマンスが十分に優れた差別化要因である場合、Webパッケージングの効果的な使用がオンラインパブリッシャーの成功の条件となる可能性があることに同意するようです。 HTTPSを使用して提供されるコンテンツを特権にするGoogle検索の選択は、この種の影響が効果的である可能性があることを示していると指摘されました。同様に、[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 this technology on smaller publishers who might be less able to optimize the packages they produce, where their primary differentiation in the market has previously been the quality of their content.

議論で提起された最も一般的な懸念は、これまで市場での主な差別化がコンテンツの品質であった、パッケージを最適化できない可能性のある小規模なパブリッシャーに対するこのテクノロジーの影響でした。

4.1.3. Consolidation of User Preferences
4.1.3. ユーザー設定の統合

In typical operation of the Web, servers have an opportunity to tailor content to the needs of their users. In contrast, a static Web Package has few options for individualization, as the content is generated once and used by many.

Webの通常の運用では、サーバーはユーザーのニーズに合わせてコンテンツを調整する機会があります。対照的に、コンテンツが一度生成されて多くの人が使用するため、静的Webパッケージには個別化のオプションがほとんどありません。

As a result, publishers noted that AMP provides less opportunity 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 in relation to this that Web Packaging might also have a consolidating effect in the browser market.

その結果、出版社は、AMPは顧客向けにコンテンツをカスタマイズする機会が少ないと指摘しました。彼らの懸念には、ユーザーに関する知識に基づいてコンテンツをパーソナライズするだけでなく、特定のブラウザー向けにパッケージを最適化することも含まれていました。他の参加者は、これに関連して、Webパッケージングもブラウザ市場に統合効果をもたらす可能性があることを観察しました。

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

一部の参加者は、単一のパッケージにリソースの複数のバリアントを含む複数のパッケージを提供したり、パッケージがロードされた後にカスタマイズを実行したりして、カスタマイズの可能性を持ち出しました。ただし、他の参加者は、これらのオプションのすべてが、複雑さや、大きなバンドルや遅延したカスタマイズに起因するパフォーマンスの低下のいずれかでマイナスの副作用があると指摘しました。

4.2. Effect on Web Security
4.2. Webセキュリティへの影響

One session explored the impact of introducing a new security model for the Web. 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 providing integrity and confidentiality for its delivery. Object security is not a new concept in the context of the Web; designs like SHTTP [SHTTP] are as old as HTTPS. Though the intent is for Web Packaging to have a far more narrow applicability, it provides fewer security guarantees than HTTPS, since it provides only authentication, no confidentiality with respect to the cache, and no assurance of liveness.

あるセッションでは、Webに新しいセキュリティモデルを導入することの影響を調査しました。現在、サイトは接続指向のセキュリティ(TLS [TLS]によって提供される)に依存していますが、Webパッケージングは​​限定的な形式のオブジェクトセキュリティを追加します。つまり、パッケージはメッセージの整合性と機密性を提供するのではなく、メッセージの整合性を保護します。オブジェクトセキュリティは、Webのコンテキストでは新しい概念ではありません。 SHTTP [SHTTP]のような設計はHTTPSと同じくらい古いものです。 Webパッケージングの適用範囲をはるかに狭くすることを目的としていますが、認証のみを提供し、キャッシュに関する機密性を保持せず、生存性を保証しないため、HTTPSよりもセキュリティの保証が少なくなります。

Object-based security -- such as proposed in Web Packaging -- allows the use of content regardless of how it is obtained; some participants noted that third parties gain greater control over the distribution of content, reducing the ability of publishers to retract or alter content over the validity period of signed content.

オブジェクトベースのセキュリティ-Webパッケージングで提案されているような-は、取得方法に関係なくコンテンツを使用できます。一部の参加者は、サードパーティがコンテンツの配信をより詳細に制御し、発行者が署名済みコンテンツの有効期間にわたってコンテンツを撤回または変更する能力を低下させると指摘しました。

Another topic of discussion was composition attacks. In its proposed form, Web Packaging only provides authentication of independent resources, not a web page as a single unit, allowing an attacker to control the composition of resources. This weakness was acknowledged as a known shortcoming of the current proposal that would be addressed.

もう1つの話題は、コンポジション攻撃です。提案された形式では、Webパッケージングは​​独立したリソースの認証のみを提供し、単一のユニットとしてのWebページは提供しないため、攻撃者はリソースの構成を制御できます。この弱点は、対処される現在の提案の既知の欠点として認められました。

The issue of managing the trade-off between control and performance in caches arose. While participants recognized that problems with resource composition already occur by accident -- for example, when a cache stores different versions of resources -- Web Packaging allows an attacker more direct control over what resources are available to clients.

キャッシュ内の制御とパフォーマンスのトレードオフを管理する問題が発生しました。参加者は、リソース構成の問題がすでに偶然に発生していることを認識しましたが(たとえば、キャッシュにさまざまなバージョンのリソースが格納されている場合)、Webパッケージングにより、攻撃者はクライアントが利用できるリソースをより直接制御できます。

For example, an attacker might be able to cause content with a security flaw to be used up to a week past the time that the defect was fixed.

たとえば、攻撃者は、セキュリティ上の欠陥があるコンテンツを、欠陥が修正された時刻から1週間後まで使用させることができる可能性があります。

As an example of how Web Packaging might change the risk profile for sites, participants discussed recovery from cross-site scripting attacks. It is already the case that a brief exposure to this class of attack can result in an attacker gaining persistent access, but mechanisms exist that can be used to avoid or correct issues, like cache validation and Clear Site Data [CLEAR-DATA]. These measures are not available to clients unless they connect to the site.

Webパッケージングがサイトのリスクプロファイルをどのように変更するかの例として、参加者は、クロスサイトスクリプティング攻撃からの回復について話し合いました。このクラスの攻撃に短時間さらされると攻撃者が永続的なアクセスを取得する可能性がありますが、キャッシュの検証やサイトデータのクリア[CLEAR-DATA]などの問題を回避または修正するために使用できるメカニズムが存在します。これらの対策は、クライアントがサイトに接続しない限り利用できません。

The discussion pointed out that these concerns are not new or uniquely enabled by Web Packaging. However, it was pointed out that new features are routinely subject 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. Though sites can use shared compression without this exposure, shared compression will likely only be enabled once it is clear that measures to prevent accidental information exposure are understood to be effective in a broad set of deployments.

ディスカッションでは、これらの懸念は新しいものではなく、Webパッケージングによって独自に実現されるものでもないことが指摘されました。ただし、新しい機能には、通常、セキュリティとプライバシーに対する期待が高まっていることが指摘されています。 Webパッケージングとは無関係ですが、同様のトレードオフがある例では、複数のリソースの共有圧縮には、パフォーマンス上の大きな利点があります。共有圧縮のリスクは、暗号化された情報をサイドチャネルを介して公開する可能性です。サイトはこのエクスポージャーなしで共有圧縮を使用できますが、偶発的な情報エクスポージャーを防ぐための対策が幅広い展開のセットで効果的であると理解されていることが明らかな場合にのみ、共有圧縮が有効になる可能性があります。

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

ディスカッションでは、コンテンツのサードパーティプロバイダーとしてのCDNの一般的な使用にも同様に懸念が当てはまるかどうかという問題も取り上げられました。一部の参加者は、CDNは通常、サービスを提供するサイトと契約関係にあり、利害関係を調整する可能性が高いと結論付けました。

4.3. Privacy of Content
4.3. コンテンツのプライバシー

Discussion and submissions raised concerns regarding how serving content using Web Packages might adversely affect privacy of individuals. There are challenges here, but the very narrow applicability of Web Packaging to what is effectively static content limits the privacy risk. The conclusion was that, provided sufficient care is taken in implementation, the use of Web Packages does not substantially increase the information that an aggregator gains about what content is consumed.

議論と提出は、Webパッケージを使用してコンテンツを提供することが個人のプライバシーにどのように悪影響を及ぼすかについて懸念を引き起こしました。ここには課題がありますが、Webパッケージングの静的コンテンツであるものへの非常に狭い適用性により、プライバシーリスクが制限されます。結論として、実装に十分な注意が払われていれば、Webパッケージを使用しても、どのコンテンツが消費されるかについてアグリゲーターが取得する情報が実質的に増えることはありません。

Concretely, an aggregator knows what content it serves in anticipation of navigation. This is -- at least in theory -- substantially the same as the content that the aggregator might receive if it performed the navigation itself. Assuming that content is stripped of personalization, the aggregator gains no new information.

具体的には、アグリゲーターは、ナビゲーションを見越してどのコンテンツを提供するかを知っています。これは、少なくとも理論的には、アグリゲーターがナビゲーション自体を実行した場合に受け取る可能性のあるコンテンツと実質的に同じです。コンテンツからパーソナライゼーションが取り除かれていると仮定すると、アグリゲーターは新しい情報を取得しません。

5. AMP Issues Unrelated to Web Packaging
5. Webパッケージに関連しないAMPの問題

On multiple occasions, discussion at the workshop concentrated on problems that arise as a result of constraints on the AMP format or details of its inclusion in Google Search. For instance, the requirement to make pages expose their metadata is unlikely to be affected by any standardization of a packaging format as that requirement is independent of the process of delivering content.

複数の機会で、ワークショップでの議論は、AMP形式またはGoogle検索への組み込みの詳細に対する制約の結果として発生する問題に集中しました。たとえば、ページにメタデータを公開させるという要件は、コンテンツを配信するプロセスとは独立しているため、パッケージ形式の標準化によって影響を受ける可能性はほとんどありません。

This section provides some detail on aspects of the discussion that touched on AMP more generally in this way. Some treatment of these points is considered relevant as some of the discussion at the workshop, even under the remit of discussing Web Packaging, concentrated on the effect of AMP on the ecosystem.

このセクションでは、この方法でAMPについてより一般的に触れたディスカッションの側面について詳しく説明します。これらのポイントのいくつかの扱いは、ワークショップでの議論の一部として、AMPのエコシステムへの影響に焦点を当てたWebパッケージングの議論の権限下でも、関連性があると見なされています。

      |  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 allow publishers to use content that met specific criteria to access privileged positions in search results, regardless of their adoption of AMP. Participants felt that this approach might address some of these concerns if it were adopted and durable. For instance, the use of Web Packaging might be sufficient to remove some constraints on active content on the basis that the active content would be attributed to the publisher and not the AMP Cache.

ディスカッションと提出では、AMPの採用に関係なく、特定の条件を満たすコンテンツを使用して検索結果の特権的な位置にアクセスできるようにするというコミットメント[AMP-LESSONS]に言及しました。参加者は、このアプローチが採用され、耐久性があれば、これらの懸念のいくつかに対処できる可能性があると感じました。たとえば、アクティブなコンテンツがAMPキャッシュではなくパブリッシャーに帰属することに基づいて、アクティブなコンテンツに対するいくつかの制約を取り除くには、Webパッケージングの使用で十分かもしれません。

5.1. AMP Governance
5.1. AMPガバナンス

There was interest from workshop participants in the governance model used for AMP. In particular, the question of how independent the AMP project would be of Google and Google Search arose.

ワークショップの参加者から、AMPに使用されるガバナンスモデルに関心がありました。特に、AMPプロジェクトがGoogleおよびGoogle検索からどの程度独立しているかという疑問が生じました。

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

AMPを管理する組織であるAMP技術運営委員会の7人のメンバーのうち3人はGoogleの従業員であり、Googleがプロジェクトに大きな影響を与えています。ガバナンス構造は、時間の経過とともにGoogleからより独立することを意図したものであると主張されました。 Google検索などのフォーマットの利用者は、AMPプロジェクト製品のさまざまな側面を使用するか、または必要とするかについて、独立した評価を行うことが理解されました。

5.2. Constraints on the AMP Format
5.2. AMP形式の制約

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

多くのサイトでは、通常のHTMLコンテンツと並行して個別のコンテンツセットを作成することにより、AMPを実装しています。出版社はこれを、特に小規模なサイトでは高コストであると指摘しました。 WebサイトはAMP準拠のコンテンツのみを提供できることが指摘されました。ただし、いくつかの出版社は、自分たちのニーズに適さない形式の制限について言及しました。

Many cited reasons for this duplication were related to the necessity of running arbitrary active content (typically, JavaScript). For example:

この重複の理由の多くは、任意のアクティブコンテンツ(通常はJavaScript)を実行する必要性に関連しています。例えば:

* AMP provides a framework for supporting user authentication, but publishers asserted that using this framework was not considered practical.

* AMPはユーザー認証をサポートするためのフレームワークを提供しますが、出版社はこのフレームワークを使用することは実用的とは見なされていないと主張しました。

* AMP content does not support rendering of certain content, which can affect the ability of publishers to innovate content production.

* AMPコンテンツは特定のコンテンツのレンダリングをサポートしていないため、コンテンツ制作を革新するパブリッシャーの能力に影響を与える可能性があります。

* The AMP model for the implementation of paywalls (Section 5.4) was claimed to be inimical to some publisher business models.

* ペイウォールを実装するためのAMPモデル(セクション5.4)は、一部のパブリッシャービジネスモデルに似ていると主張されています。

More broadly, they considered AMP's constraints on the use of active content as problematic, since they prevent the use of capabilities that are provided on equivalent non-AMP pages. Reference was made to a proposed <amp-script> element -- which has since been made fully available -- that seeks to provide limited access to some dynamic content.

より広義には、同等の非AMPページで提供される機能の使用を妨げているため、アクティブコンテンツの使用に対するAMPの制約を問題があると見なしていました。提案された<amp-script>要素が参照されました。これは、一部の動的コンテンツへの制限されたアクセスを提供することを目的としています。

5.3. Performance
5.3. パフォーマンス

Publishers observed that using the AMP format does not provide any guarantee of performance gains and, in some cases, could contribute to performance degradation. It was suggested that this was most problematic for sites that are already well-tuned for performance.

パブリッシャーは、AMP形式を使用してもパフォーマンスの向上は保証されず、場合によってはパフォーマンスの低下につながる可能性があることを確認しました。これは、パフォーマンスが既に十分に調整されているサイトで最も問題があることが示唆されました。

5.4. Implementation of Paywalls
5.4. ペイウォールの実装

The use of paywalls by web publishers to control access to content in return for payment is increasingly common. One popular approach is to offer a limited number of articles without payment while insisting on a paid subscription to access further articles.

支払いと引き換えにコンテンツへのアクセスを制御するためにWebパブリッシャーがペイウォールを使用することがますます一般的になっています。人気のあるアプローチの1つは、追加の記事にアクセスするための有料サブスクリプションを主張しながら、支払いなしで限られた数の記事を提供することです。

On several occasions, participants expressed dissatisfaction with the difficulty of integrating paywall authorization when using AMP. In particular, they said AMP encourages publishers to include an article's full content, hidden by default 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.

参加者は、AMPを使用する際にペイウォール認証を統合することの難しさに不満を感じることも何度かありました。特に、AMPは、デフォルトで非表示になっているが、やる気のあるユーザーが簡単にアクセスできる記事の全コンテンツを含めることをパブリッシャーに推奨していると彼らは語った。許可の一部として使用され、キャッシュされたコンテンツがターゲットサイトではなくリンクサイトでホストされている結果であるCookie同期[COOKIE-SYNC]などの回避策にまで議論が広がりました。

The same topic came up concerning book publication, where publishers indicated that having a means of enabling different methods of distribution without also facilitating unconstrained copying of book content was necessary.

本の出版に関しても同じトピックが浮上し、出版社は本の内容を無制限に複製することなく、さまざまな配布方法を可能にする手段が必要であると指摘しました。

This conflation of AMP issues with those addressed by Web Packaging was recurrent in the discussion. As observed in [DAS], these concerns might be addressed by linking to a signed bundle.

AMPの問題とWebパッケージングによって対処された問題とのこの融合は、議論の中で繰り返されました。 [DAS]で観察されたように、これらの懸念は署名されたバンドルにリンクすることで対処されるかもしれません。

6. Venues for Future Discussion
6. 今後の議論の場

Web Packaging work continues 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).

Webパッケージング作業は、複数のフォーラムで継続されています。コアフォーマットと署名に関する質問は、wpack @ ietf.orgメーリングリスト(https://www.ietf.org/mailman/listinfo/wpack)で議論されています。 [LOADING]で提案されているWebブラウザーの変更については、Fetch仕様リポジトリ(https://github.com/whatwg/fetch/issues/784)で議論されます。

7. Security Considerations
7. セキュリティに関する考慮事項

Proposals discussed at the workshop might have a significant security impact, and these topics were discussed in some depth; see Section 4.2.

ワークショップで議論された提案はセキュリティに大きな影響を与える可能性があり、これらのトピックはある程度深く議論されました。セクション4.2を参照してください。

8. Informative References
8. 参考引用

[ALAM] Alam, S., Weigle, M., Nelson, M., Klein, M., and H. Van de Sompel, "Supporting Web Archiving via Web Packaging", 6 June 2019, <https://www.iab.org/wp-content/IAB-uploads/2019/06/sawood-alam-2.pdf>.

[ALAM]アラム、S。、ウェイグル、M。、ネルソン、M。、クライン、M。、およびH.ヴァンデソンペル、「WebパッケージングによるWebアーカイブのサポート」、2019年6月6日、<https:// www。 iab.org/wp-content/IAB-uploads/2019/06/sawood-alam-2.pdf>。

[AMP-LESSONS] Ubl, M., "Standardizing lessons learned from AMP", 8 March 2018, <https://blog.amp.dev/2018/03/08/standardizing-lessons-learned-from-amp/>.

[AMP-LESSONS] Ubl、M。、「AMPから学んだ教訓の標準化」、2018年3月8日、<https://blog.amp.dev/2018/03/08/standardizing-lessons-learned-from-amp/> 。

[AMP-PERF] Steinlauf, E., "The Speed Benefit of AMP Prerendering", 14 August 2019, <https://developers.googleblog.com/2019/08/ the-speed-benefit-of-amp-prerendering.html>.

[AMP-PERF] Steinlauf、E。、「AMP Prerenderingのスピードメリット」、2019年8月14日、<https://developers.googleblog.com/2019/08/ the-speed-benefit-of-amp-prerendering。 html>。

[AOLOG] Haber, S. and W. Stornetta, "How to time-stamp a digital document", Journal of Cryptology, Vol. 3, Issue 2, pp. 99-111, DOI 10.1007/bf00196791, 1991, <https://doi.org/10.1007/bf00196791>.

[AOLOG] Haber、S。およびW. Stornetta、「デジタルドキュメントにタイムスタンプを付ける方法」、Journal of Cryptology、Vol。 3、問題2、99-111ページ、DOI 10.1007 / bf00196791、1991、<https://doi.org/10.1007/bf00196791>。

[BERJON] Berjon, R., "ESCAPE: The New York Times Position", 9 July 2019, <https://www.iab.org/wp-content/IAB-uploads/2019/07/ NYT-ESCAPE.pdf>.

[BERJON] Berjon、R。、「ESCAPE:The New York Times Position」、2019年7月9日、<https://www.iab.org/wp-content/IAB-uploads/2019/07/ NYT-ESCAPE.pdf >。

[BREWSTER] Brewster, A., "ESCAPE Position / Patch.com", 6 June 2019, <https://www.iab.org/wp-content/IAB-uploads/2019/06/ patch.pdf>.

[BREWSTER]ブリュースター、A。、「ESCAPE Position / Patch.com」、2019年6月6日、<https://www.iab.org/wp-content/IAB-uploads/2019/06/ patch.pdf>。

[BUNDLE] Yasskin, J., "Bundled HTTP Exchanges", Work in Progress, Internet-Draft, draft-yasskin-wpack-bundled-exchanges-02, 26 September 2019, <https://tools.ietf.org/html/draft-yasskin-wpack-bundled-exchanges-02>.

[バンドル] Yasskin、J。、「Bundled HTTP Exchanges」、Work in Progress、Internet-Draft、draft-yasskin-wpack-bundled-exchanges-02、2019年9月26日、<https://tools.ietf.org/html / draft-yasskin-wpack-bundled-exchanges-02>。

[CFP] Internet Architecture Board, "Exploring Synergy between Content Aggregation and the Publisher Ecosystem Workshop 2019", 3 May 2019, <https://www.iab.org/activities/workshops/escape-workshop/>.

[CFP] Internet Architecture Board、「Exploring Synergy between Content Aggregation and the Publisher Ecosystem Workshop 2019」、2019年5月3日、<https://www.iab.org/activities/workshops/escape-workshop/>。

[CHATHAM-HOUSE] Chatham House, "Chatham House Rule", <https://www.chathamhouse.org/chatham-house-rule>.

[CHATHAM-HOUSE]チャタムハウス、「チャタムハウスルール」、<https://www.chathamhouse.org/chatham-house-rule>。

[CHRISTCHURCH] Stevenson, R. and J. Anthony, "'Thousands' of Christchurch shootings videos removed from YouTube, Google says", 16 March 2019, <https://www.stuff.co.nz/business/111330323/ facebook-working-around-the-clock-to-block-christchurch-shootings-video>.

[CHRISTCHURCH] Stevenson、R.、J。Anthony、「YouTubeから削除されたクライストチャーチの数千のビデオを撮影、Googleは言う」、2019年3月16日、<https://www.stuff.co.nz/business/111330323/ facebook -working-around-the-clock-to-block-christchurch-shootings-video>。

[CLEAR-DATA] West, M., "Clear Site Data", W3C Working Draft, 30 November 2017, <https://www.w3.org/TR/clear-site-data/>.

[CLEAR-DATA] West、M。、「Clear Site Data」、W3C草案、2017年11月30日、<https://www.w3.org/TR/clear-site-data/>。

[COOKIE-SYNC] Acar, G., Eubank, C., Englehardt, S., Juarez, M., Narayanan, A., and C. Diaz, "The Web Never Forgets", CSS '14: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, pp. 674-689, DOI 10.1145/2660267.2660347, 2014, <https://doi.org/10.1145/2660267.2660347>.

[COOKIE-SYNC] Acar、G.、Eubank、C.、Englehardt、S.、Juarez、M.、Narayanan、A.、and C. Diaz、 "The Web Never Forgets"、CSS '14:Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security、pp。674-689、DOI 10.1145 / 2660267.2660347、2014、<https://doi.org/10.1145/2660267.2660347>。

[CRAMER] Cramer, D., "Packaging Books", 2 June 2019, <https://www.iab.org/wp-content/IAB-uploads/2019/06/ cramer-position-paper.pdf>.

[CRAMER] Cramer、D。、「Packaging Books」、2019年6月2日、<https://www.iab.org/wp-content/IAB-uploads/2019/06/ cramer-position-paper.pdf>。

[DAS] Das, S., "The Implication of Signed Exchanges on E-Commerce", 7 June 2019, <https://www.iab.org/wp-content/ IAB-uploads/2019/06/IAB-Position-Paper_-Signed-Exchanges.pdf>.

[DAS] Das、S。、「Eコマースにおける署名済み交換の影響」、2019年6月7日、<https://www.iab.org/wp-content/ IAB-uploads / 2019/06 / IAB-Position -Paper_-Signed-Exchanges.pdf>。

[DEPUYDT-NELSON] DePuydt, M. and M. Nelson, "Signed Exchanges and The Importance of Trust in Aggregator/Publisher relationships", 4 June 2019, <https://www.iab.org/wp-content/IAB-uploads/2019/06/washpost.pdf>.

[DEPUYDT-NELSON] DePuydt、M。およびM. Nelson、「Signed Exchanges and the Importance of Trust in Aggregator / Publisher relationship」、2019年6月4日、<https://www.iab.org/wp-content/IAB- uploads / 2019/06 / washpost.pdf>。

[GDPR] European Union, "General Data Protection Regulation", EU Regulation 2016/679, 27 April 2016, <https://eur-lex.europa.eu/legal-content/EN/TXT/ HTML/?uri=CELEX:32016R0679&from=EN#d1e2606-1-1>.

[GDPR]欧州連合、「一般データ保護規則」、EU規則2016 / 679、2016年4月27日、<https://eur-lex.europa.eu/legal-content/EN/TXT/ HTML /?uri = CELEX :32016R0679&from = EN#d1e2606-1-1>。

[HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

[HTTP]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol(HTTP / 1.1):Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。

[LOADING] Yasskin, J., "Loading Signed Exchanges", 4 September 2019, <https://wicg.github.io/webpackage/loading.html>.

[読み込み中] Yasskin、J。、「Loaded Signed Exchanges」、2019年9月4日、<https://wicg.github.io/webpackage/loading.html>。

[MEMENTO] Van de Sompel, H., Nelson, M., and R. Sanderson, "HTTP Framework for Time-Based Access to Resource States -- Memento", RFC 7089, DOI 10.17487/RFC7089, December 2013, <https://www.rfc-editor.org/info/rfc7089>.

[MEMENTO] Van de Sompel、H.、Nelson、M。、およびR. Sanderson、「リソース状態への時間ベースのアクセスのためのHTTPフレームワーク-Memento」、RFC 7089、DOI 10.17487 / RFC7089、2013年12月、<https: //www.rfc-editor.org/info/rfc7089>。

[ORIGIN] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.

[ORIGIN] Barth、A。、「The Web Origin Concept」、RFC 6454、DOI 10.17487 / RFC6454、2011年12月、<https://www.rfc-editor.org/info/rfc6454>。

[OTSU] Ohtsu, S., "Deployment Experience of Signed HTTP Exchanges with AMP as a Publisher", 4 June 2019, <https://www.iab.org/wp-content/IAB-uploads/2019/06/ shigeki-ohtsu.pdf>.

[OTSU]大津誠、「AMPをパブリッシャーとして使用した署名付きHTTP交換の導入経験」、2019年6月4日、<https://www.iab.org/wp-content/IAB-uploads/2019/06/ shigeki -ohtsu.pdf>。

[SHTTP] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, DOI 10.17487/RFC2660, August 1999, <https://www.rfc-editor.org/info/rfc2660>.

[SHTTP] Rescorla、E。およびA. Schiffman、「The Secure HyperText Transfer Protocol」、RFC 2660、DOI 10.17487 / RFC2660、1999年8月、<https://www.rfc-editor.org/info/rfc2660>。

[SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, <https://www.rfc-editor.org/info/rfc5218>.

[成功]ターラー、D.、B。アボバ、「成功するプロトコルを作るもの」、RFC 5218、DOI 10.17487 / RFC5218、2008年7月、<https://www.rfc-editor.org/info/rfc5218> 。

[SXG] Yasskin, J., "Signed HTTP Exchanges", Work in Progress, Internet-Draft, draft-yasskin-http-origin-signed-responses-08, 4 November 2019, <https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-08>.

[SXG] Yasskin、J。、「Signed HTTP Exchanges」、Work in Progress、Internet-Draft、draft-yasskin-http-origin-signed-responses-08、2019年11月4日、<https://tools.ietf.org / html / draft-yasskin-http-origin-signed-responses-08>。

[TAG-DC] Betts, A., Ed., "Distributed and syndicated content", W3C TAG Finding, 27 July 2017, <https://www.w3.org/2001/tag/doc/distributed-content/>.

[TAG-DC] Betts、A.、Ed。、「Distributed and syndicated content」、W3C TAG Finding、2017年7月27日、<https://www.w3.org/2001/tag/doc/distributed-content/> 。

[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[TLS] Rescorla、E。、「トランスポート層セキュリティ(TLS)プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。

[YASSKIN] Yasskin, J., "Chrome's position on the ESCAPE workshop", 6 June 2019, <https://www.iab.org/wp-content/IAB-uploads/2019/06/chrome.html>.

[YASSKIN] Yasskin、J。、「ESCAPEワークショップにおけるChromeの位置付け」、2019年6月6日、<https://www.iab.org/wp-content/IAB-uploads/2019/06/chrome.html>。

Appendix A. About the Workshop
付録A.ワークショップについて

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

ESCAPEワークショップは、米国バージニア州ハーンドンにあるシスコの施設で2019-07-18および2019-07-19の朝に開催されました。

Workshop attendees were asked to submit position papers. These papers are published on the IAB website [CFP].

ワークショップの参加者は、ポジションペーパーの提出を求められました。これらの論文は、IAB Webサイト[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.

ワークショップはチャタムハウス規則[CHATHAM-HOUSE]に基づいて実施されました。つまり、ステートメントは、明示的な許可なしに個人または組織に帰属させることはできません。

A.1. Agenda
A.1. 議題

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

このセクションでは、毎日の幅広い議論について概説します。

A.1.1. Thursday 2019-07-18
A.1.1. 木曜日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パッケージングの概要:Webパッケージングの技術的な概要と、さまざまな使用例についてのより長い議論が提供されました。

Web Packaging and Aggregators: The use of Web Packaging from the perspective of a content aggregator was given.

Webパッケージングとアグリゲーター:コンテンツアグリゲーターの観点からのWebパッケージングの使用方法が示されました。

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パッケージングとパブリッシャー:休憩の後、Webパブリッシャーからのプレゼンテーションで、Webパッケージングの利点とコストについて話しました。これには、パブリッシャーの観点から、コンテンツのAMP準拠バージョンを開発する効果についての議論が含まれています。

Web Packaging and Security: This session concentrated on how the Web Packaging proposal might affect the web security model.

Webパッケージングとセキュリティ:このセッションでは、Webパッケージングの提案がWebセキュリティモデルにどのように影響するかについて説明しました。

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.

Webパッケージの代替手段:このセッションでは、過去に試行されたものや、Webナビゲーションのパフォーマンスを向上させるユースケースに取り組むためのいくつかの最近のアイデアなど、代替テクノロジについて検討しました。

A.1.2. Friday 2019-07-19
A.1.2. 金曜日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.

Webアーカイブ:このセッションでは、Webアーカイブシステムが直面する無数の問題のいくつかに対処するための、Webパッケージングなどのテクノロジの潜在的なアプリケーションについて話しました。

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
A.2. ワークショップの参加者

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.

ワークショップの参加者は、提出物に記載されていた主要な所属と一緒にリストされています。プログラム委員会(PC)、インターネットアーキテクチャボード(IAB)、およびインターネットエンジニアリングステアリンググループ(IESG)の出席者にもマークが付けられます。

* 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

* Sawood Alam、オールドドミニオン大学* Jari Arkko、Ericsson(IAB)* Richard Barnes、シスコ* Robin Berjon、ニューヨークタイムズ(PC)* Zack Bloom、Cloudflare * Abraham Brewster、Patch.com * Alissa Cooper、Cisco(IESG、IAB )* Dach Cramer、アシェットブックグループ* Melissa DePuydt、ワシントンポスト* Levi Durfee、AMP諮問委員会* Rudy Galfi、Google * Joseph Lorenzo Hall、Center for Democracy&Technology(PC)* Matthew Nelson、ワシントンポスト* Michael Nelson、Oldドミニオン大学*マークノッティンガム、Fastly(IAB、PC)*大津茂樹、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
付録B. Webパッケージの概要

Web Packaging is comprised of two separate technologies: resource bundling [BUNDLE] and signed exchanges [SXG].

Webパッケージングは​​、リソースバンドル[BUNDLE]と署名済み交換[SXG]の2つの別々のテクノロジーで構成されています。

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.

提出とワークショップのディスカッションの両方で、テクノロジーの最も物議を醸す側面は、いくつかの異なる理由で、特定のリソースに対する権限を提供する代替手段としての署名付き交換の使用です。

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

この付録では、権限がWebでどのように機能するか、およびWebパッケージングがそれを変更することを提案する方法について説明します。

B.1. Authority in HTTPS
B.1. 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は現在、HTTPS [HTTP]を使用してサーバーの権限を確立します。つまり、コンテンツがURLの意味するところからのものであることを保証します。 URIスキーム(https)、ドメイン名(またはホスト)、およびポート番号の組み合わせは、単一の識別子(コンテンツの属性の起点[ORIGIN])に形成されます。

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.

Webブラウザーは、サーバーがその送信元に対して信頼できるかどうかを判断する際に、サーバーへのTLS接続[TLS]の一部として提供される証明書を使用します。 [ORIGIN]および[HTTP]のセクション9.1を参照してください。コンテンツは、関連付けられたオリジンに対して権限のあるサーバーへの接続から受信された場合にのみ、特定のURLに帰属します。

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.

例として、「https://example.com/ index.html」をロードしようとするWebブラウザは、サーバーへのTLS接続を確立します。 TLS接続確立の一部として、サーバーは "example.com"という名前の証明書を提供します。ブラウザーが証明書を受け入れると、ブラウザーはその接続の "https://example.com"オリジンでURLを要求し、サーバーからのすべての回答が信頼できると見なします。

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.

この権限の概念はWebセキュリティの重要な特性です。同じWebオリジンに起因するコンテンツだけが、ほとんどのリソースのコンテンツやCookieなど、オリジンに関連付けられた状態を含む、そのオリジンのすべての情報にアクセスできます。この分離により、サイトが両方とも同じブラウザーに読み込まれている場合でも、サイトが互いに秘密を保持できることが保証されます。

B.2. Authority in Web Packaging
B.2. Webパッケージングにおける権限

Web Packaging, through the use of signed exchanges, aims to provide an alternative means of establishing authority. A signed exchange is an expression of an HTTP request and response (an exchange) with certain information stripped and a digital signature applied.

Webパッケージングは​​、署名された交換を使用して、権限を確立する代替手段を提供することを目的としています。署名付き交換は、特定の情報が取り除かれ、デジタル署名が適用されたHTTP要求および応答(交換)の表現です。

The signature is made with a similar certificate to the one a server might offer in HTTPS -- that certificate can also be used for HTTPS -- but it includes a special attribute that denotes its suitability for signed exchanges.

署名は、サーバーがHTTPSで提供するものと同様の証明書で作成されます-その証明書はHTTPSにも使用できます-署名付き交換への適合性を示す特別な属性が含まれています。

A web browser that has been provided with a signed exchange can verify the signature and, if the signature is valid and the certificate is acceptable, use the content from the signed exchange. Critically, the web browser does not make an HTTPS connection to a server to get the content or to verify the signature.

署名付き交換が提供されているWebブラウザーは、署名を検証できます。署名が有効で証明書が受け入れ可能である場合は、署名付き交換のコンテンツを使用します。重要なのは、Webブラウザーがコンテンツを取得したり、署名を検証したりするためにサーバーにHTTPS接続を行わないことです。

In effect, Web Packaging moves from a model where authority is derived from the delivery method (i.e., TLS) to an object security model, where authority is derived from a signature on objects. In doing so, it aims to render the means of delivery irrelevant to determinations of security.

実際には、Webパッケージングは​​、配信方法(TLSなど)から権限が派生するモデルから、オブジェクトの署名から権限が派生するオブジェクトセキュリティモデルに移行します。そうすることで、配信の手段をセキュリティの決定と無関係にすることを目的としています。

B.3. Applicability
B.3. 適用性

Web Packaging does not claim to supplant the authority model of the Web completely, but it does provide an alternative that might be used under certain narrow conditions. In particular, Web Packaging is intended for use with content that is not secret from an entity that is aware of the existence of that content.

Webパッケージングは​​、Webのオーソリティモデルに完全に取って代わるとは主張していませんが、特定の狭い条件下で使用できる代替手段を提供しています。特に、Webパッケージは、コンテンツの存在を認識しているエンティティから秘密にされていないコンテンツでの使用を目的としています。

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 the Set-Cookie header field is expressly forbidden, as it often contains information that is related to a particular user.

この目標を支援するために、Webパッケージングには、コンテンツの取得プロセスに関連する取引所からの情報も含まれず、個々の要求に関連する情報も含まれていません。たとえば、Set-Cookieヘッダーフィールドには特定のユーザーに関連する情報が含まれていることが多いため、Set-Cookieヘッダーフィールドの使用は明示的に禁止されています。

B.4. The AMP Format, Google Search Results, and Web Packaging
B.4. AMPフォーマット、Google検索結果、およびWebパッケージ

The relationship between the AMP Project <https://amp.dev/> and Web Packaging is complicated. The AMP Project, sponsored by Google, establishes a profile of HTML with 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 of HTML features but also offers a library of components that provide sanitized implementations of many commonly used capabilities.

AMPプロジェクト<https://amp.dev/>とWebパッケージングの関係は複雑です。 GoogleがスポンサーとなっているAMPプロジェクトは、パフォーマンスに重点を置いて、フォーマットのベストプラクティスをサポートすることを目的とするHTMLのプロファイルを確立します。このフォーマットは、HTML機能の使用を厳しく制限しますが、一般的に使用される多くの機能のサニタイズされた実装を提供するコンポーネントのライブラリも提供します。

The connection to Web Packaging is bound up in the way that Google Search treats AMP content specially. AMP content provides two properties that Google Search exploits: metadata exposure and static analysis of active content.

Webパッケージングへの接続は、Google検索がAMPコンテンツを特別に処理する方法に拘束されます。 AMPコンテンツには、Google検索が利用する2つのプロパティがあります。メタデータの公開とアクティブコンテンツの静的分析です。

AMP content provides metadata in a form that can be reliably extracted, using the microformats defined by the Schema.org project <https://schema.org/>. This aspect of AMP has no effect on the discussion, except to the extent that this relates to Google Search and their use of this metadata in populating the carousel.

AMPコンテンツは、Schema.orgプロジェクト<https://schema.org/>によって定義されたマイクロフォーマットを使用して、確実に抽出できる形式でメタデータを提供します。 AMPのこの側面は、Google検索に関連する範囲と、カルーセルの入力におけるこのメタデータの使用を除いて、ディスカッションに影響を与えません。

Constrained use of active content -- such as JavaScript -- in AMP makes it possible to analyze content to verify that actions taken are narrowly limited. This static analysis assures that AMP content can be served without affecting other content on the same site. For Google Search, this is what enables the loading of AMP content alongside search content and other AMP resources.

AMPでのJavaScriptなどのアクティブコンテンツの制限された使用により、コンテンツを分析して、実行されるアクションが限定されていることを確認できます。この静的分析により、同じサイトの他のコンテンツに影響を与えることなくAMPコンテンツを配信できることが保証されます。 Google検索の場合、これにより、検索コンテンツやその他のAMPリソースとともにAMPコンテンツを読み込むことができます。

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 some confusion about how content is attributed, as discussed in the W3C finding on distributed content [TAG-DC].

プリロードを提供するために、Googleは、AMPコンテンツが提供されるGoogle AMPキャッシュ<https://developers.google.com/amp/cache/>を操作します。結果として、ブラウザはコンテンツをパブリッシャーではなくAMPキャッシュのオリジン[ORIGIN]に帰属させ、W3Cによる分散コンテンツの発見[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 on this, see Section 2.1.

Webパッケージングの重要な目標は、Google AMPキャッシュなどのキャッシュからロードされたコンテンツを、そのコンテンツを作成したパブリッシャーに関連付けることです。詳細については、セクション2.1を参照してください。

IAB Members at the Time of Approval

承認時のIABメンバー

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

このドキュメントの公開が承認された時点のInternet Architecture Boardのメンバーは次のとおりです。

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