Reporting API （日本語訳）

◎要約

この文書は、報告処理の汎用~frameworkを定義する：

開発者は、名前が付与された［ `報告先$の集合］を，`生成元$に結付けれる。
様々な~platform特能（ `CSP3$r, `NETWORK-ERROR-LOGGING$r【！Network Error Reporting】, その他）が、これらの報告先を利用して，それぞれに特有な報告を一貫した方式で送達する。

◎ This document defines a generic reporting framework which allows web developers to associate a set of named reporting endpoints with an origin. Various platform features (like Content Security Policy, Network Error Reporting, and others) will use these endpoints to deliver feature-specific reports in a consistent manner.

1. 序論

この文書は、［他の仕様が利用したり拡張し得る，汎用な報告処理］用に，次に挙げる基盤を供する： ◎ This document provides three pieces of infrastructure for generic reporting, which may be used or extended by other specifications:

`報告~種別$と`報告先$を定義するための汎用な~framework ◎ A generic framework for defining report types and reporting endpoints, and＼
`報告$たちを`報告先$へ~HTTP越しに送信するための文書~形式 ◎ a document format for sending reports to endpoints over HTTP.
次のための特有な仕組み ⇒ ［文書／~worker ］内の`報告先$を環境設定して、各 `報告$のうち，その存続期間が［文書／~worker ］に縛られたものを送達する ◎ A specific mechanism for configuring reporting endpoints in a document or worker, and for delivering reports whose lifetime is tied to that document or worker.
［文書／~worker ］の中で生成された報告を観測するための~API【！~JS~interface】 ◎ A JavaScript interface for observing reports generated within a document or worker.

他の仕様は、これらを［拡張しても／用立てても］ヨイ。一例として，［具象的な報告~種別を定義する／文書に基づかない報告~用に代替な環境設定や送達の仕組みを定義する］など。 ◎ Other specifications may extend or make use of these pieces, for instance by defining concrete report types, or alternative configuration or delivery mechanisms for non-document-based reports.

1.1. 保証

この仕様は、 ~website活動の帯域外で実行されるような，最善な労の下で報告を送達する~systemを供することを目指す。 ~UAは、報告の送達に優先度をあてがったり，それらを~scheduleする~~仕事をより良く行える立場にある — ~UAは、［個々の~websiteが有さない，非同一-生成元の活動］について俯瞰でき，また，［ ~websiteの読込ngが頭から防止される~error条況］に際しても報告を送達できるので。 ◎ This specification aims to provide a best-effort report delivery system that executes out-of-band with website activity. The user agent will be able to do a better job prioritizing and scheduling delivery of reports, as it has an overview of cross-origin activity that individual websites do not, and can deliver reports based on error conditions that would prevent a website from loading in the first place.

しかしながら，送達は、いかなる仕方でも保証されない — 報告処理は、依拠-可能な通信~channelとしての利用は意図されていない。 ~network条件によっては、報告はその行先へまったく到達できなくなることもある。また，~UAには、理由があれば，報告を却下して送達しないことも許可される。 ◎ The delivery is not, however, guaranteed in any way, and reporting is not intended to be used as a reliable communications channel. Network conditions may prevent reports from reaching their destination at all, and user agents are permitted to reject and not deliver a report for any reason.

1.2. 例

【読みやすくするため、この仕様の~HTTP~header例には，行を折返して字下げする整形が施されているものもあるが、 HTTP/1.1 構文としては，そのような改行法は廃用にされたことに注意。】

MegaCorp 社は、［ ~CSP（ `Content Security Policy^en `CSP$r ）と~HPKP（ `Key Pinning^en `RFC7469$r ）］に対する違反~報告を収集したいとする。そうするには、［ `endpoint-1^l と命名される，一連の報告先］を定義する，次の~headerに加えて： ◎ MegaCorp Inc. wants to collect Content Security Policy and Key Pinning violation reports. It can do so by delivering the following header to define a set of reporting endpoints named "endpoint-1":

`Reporting-Endpoints$h: endpoint-1="https://example.com/reports"

［ ~CSP／~HPKP ］報告をその報告先へ指向ける，次の~headerを送達する： ◎ And the following headers, which direct CSP and HPKP reports to that endpoint:

`Content-Security-Policy$h: ...; `report-to$dir endpoint-1
`Public-Key-Pins$h: ...; `report-to^dir=endpoint-1

しばらくして後， MegaCorp 社は、 ~script処理を単純~化するため，これら 2 種の報告を種別ごとに別個な報告先に分けて処理するものと裁定した。そうするには、 `Reporting-Endpoints$h に定義する報告先を次のように違える： ◎ After processing reports for a little while, MegaCorp Inc. decides to split the processing of these two types of reports out into two distinct endpoints in order to make the processing scripts simpler. It can do so by delivering the following header to define two reporting endpoints:

`Reporting-Endpoints$h:
    csp-endpoint="https://example.com/csp-reports",
    hpkp-endpoint="https://example.com/hpkp-reports"

加えて、次の~headerで［ ~CSP, ~HPKP ］報告をそれら~~別々に命名された報告先へ指向ける： ◎ And the following headers, which direct CSP and HPKP reports to those named endpoints:

`Content-Security-Policy$h: ...; `report-to$dir csp-endpoint
`Public-Key-Pins$h: ...; report-to=hpkp-endpoint

2. 汎用な報告処理~framework

この節は、［報告／報告先］の汎用な概念, および報告が `application/reports+json$c 形式にどう直列化されるかを定義する。 ◎ This section defines the generic concepts of reports and endpoints, and how reports are serialized into the application/reports+json format.

2.1. 各種~概念

2.1.1. 報告先

`報告先@ （ `reporting endpoint^en ／略して `endpoint^en ）は、［特定0の`生成元$用の`報告たち$ ］の送信-先になり得る【~network端点の】所在を与える。 ◎ An endpoint is location to which reports for a particular origin may be sent.

各 `報告先$は、次のものを持つ： ◎ ↓

`名前@eP ◎ Each endpoint has a name,＼: ~ASCII文字列。 ◎ which is an ASCII string.
`~URL@eP ◎ Each endpoint has a url,＼: `~URL$ ◎ which is a URL.
`失敗数@eP （ `failures^en ） ◎ Each endpoint has a failures,＼: 負でない整数。この報告先が要請に対し応答するのに連続して失敗した回数を表現する。 ◎ which is a non-negative integer representing the number of consecutive times this endpoint has failed to respond to a request.

2.1.2. 報告~種別

`報告~種別@ は、空でない文字列であり，`報告$の`本体$rP内にどの~dataを包含させるかを指定する。 ◎ A report type is a non-empty string that specifies the set of data that is contained in the body of a report.

（この仕様も含む各種~仕様にて定義される）`報告~種別$には、 `報告用~観測器から可視@ であると指定されるものもある — それは、 `報告用~観測器$は，`報告たち$のうち［ `種別$rP ~EQ その`報告~種別$ ］なるものを観測できることを意味する。 `報告~種別$は、既定では`報告用~観測器から可視$でないとする。 ◎ When a report type is defined (in this spec or others), it can be specified to be visible to ReportingObservers, meaning that reports of that type can be observed by a reporting observer. By default, report types are not visible to ReportingObservers.

2.1.3. 報告

`報告@ （ `report^en ）は、指定された`報告先$へ送達することが~UAに期待されるような，任意な~dataからなる~collectionである。 ◎ A report is a collection of arbitrary data which the user agent is expected to deliver to a specified endpoint.

各 `報告$は、次に挙げるものを持つ： ◎ ↓

`本体@rP （ `body^en ） ◎ Each report has a body,＼: ~NULL, または`~JSON~text$に直列化できる~obj。この~objが包含する~fieldは、報告の`種別$rPにより決定される。 ◎ which is either null or an object which can be serialized into a JSON text. The fields contained in a report’s body are determined by the report’s type.
`~URL@rP ◎ Each report has a url,＼: 概して、報告を生成した［ `Document^I ／ `Worker^I ］の~address 【を表現する`~URL文字列$】になる。 ◎ which is typically the address of the Document or Worker from which the report was generated.; 注記：この直列化された~URLからは，［ `~username$url, `~password$url, `素片$url ］は剥取られる。 `§ 能力~URL＠#capability-urls$ を見よ。 ◎ Note: We strip the username, password, and fragment from this serialized URL. See § 8.1 Capability URLs.
`~UA@rP （ `user agent^en ） ◎ Each report has a user agent,＼: この報告を生成した`要請$の `User-Agent$h `~header$の値。 ◎ which is the value of the User-Agent header of the request from which the report was generated.; 注記： `報告$の`~UA$rPは、［ `報告$を生成した~page用に~browserが送信した `User-Agent^h 【すなわち、~pageを要請したときのそれ】］を表現する。これは、収集器へ報告を~uploadするときに~HTTP~header内に送信される `User-Agent^h とは，別個になり得る — 一例として、 ~browserが “~desktop~siteを要請する” 特能~用などに，既定でない `User-Agent^h 文字列を利用することにした所など。 ◎ Note: The user agent of a report represents the User-Agent sent by the browser for the page which generated the report. This is potentially distinct from the User-Agent sent in the HTTP headers when uploading the report to a collector — for instance, where the browser has chosen to use a non-default User-Agent string such as the "request desktop site" feature.
`行先@rP （ `destination^en ） ◎ Each report has a destination,＼: ［この報告の送信-先になる`報告先$ ］の`名前$ePを表現している文字列 ◎ which is a string representing the name of the endpoint that the report will be sent to.
`種別@rP （ `type^en ） ◎ Each report has a type,＼: `報告~種別$。 ◎ which is a report type.
`時刻印@rP （ `timestamp^en ） ◎ Each report has a timestamp,＼: この報告が生成された時刻を，~unix-epochからの~millisecondsで記録する。 ◎ which records the time at which the report was generated, in milliseconds since the unix epoch.
`試行数@rP （ `attempts counter^en ） ◎ Each report has an attempts counter,＼: 負でない整数。 ~UAがこの報告を送達しようと試みた回数を表現する。 ◎ which is a non-negative integer representing the number of times the user agent attempted to deliver the report.

2.2. ~MIME型

`application/reports+json@c が、指定された報告先へ報告を `POST$hm するときに利用される~MIME型（ `Internet media type^en ）を与える。 ◎ The media type used when POSTing reports to a specified endpoint is application/reports+json.

2.3. ある種別の報告を %~data から生成する【！~dataを行先~用の種別として~queueする】

`報告を生成する@ ときは、所与の ⇒＃直列化-可能な~obj %~data, 文字列 %種別, 文字列 %行先, `環境~設定群~obj$ %設定群（省略時は ε ）, `~URL$ %~URL（省略時は ε ） ◎終に対し： ◎ To generate a report given a serializable object (data), a string (type), another string (destination), an optional environment settings object (settings), and an optional URL (url):

%報告 ~LET 新たな`報告$~obj — その ⇒＃ `本体$rP ~SET %~data, `~UA$rP ~SET `navigator.userAgent$m の現在の値, `行先$rP ~SET %行先, `種別$rP ~SET %種別, `時刻印$rP ~SET 現在の時刻印, `試行数$rP ~SET 0 ◎ Let report be a new report object with its values initialized as follows: ◎ body • data user agent • The current value of navigator.userAgent destination • destination type • type timestamp • The current timestamp. attempts • 0
~IF［ %~URL ~EQ ε ］ ⇒ %~URL ~SET %設定群の`作成時の~URL$ ◎ If url was not provided by the caller, let url be settings’s creation URL.
%~URL の ⇒＃ `~username$url ~SET 空~文字列, `~password$url ~SET 空~文字列【原文は ~NULL だが、それは過去の `URL$r 仕様に基づくもの】 ◎ Set url’s username to the empty string, and its password to null.
%報告の`~URL$rP ~SET `~URLを直列化する$( %~URL, `素片は除外する^i ) ◎ Set report’s url to the result of executing the URL serializer on url with the exclude fragment flag set.
~RET %報告 ◎ Return report.

【以下に挙げられる注記のうち 2 個目以外（少なくとも最後の注記）は、 `報告を生成して~queueする$手続きに移動されるべきであろう — この手続きを成していた一部（ “~queueする” ）は、その手続きに移動されたので。】

注記： `報告用~観測器$が観測するのは、同じ`環境~設定群~obj$からの報告に限られる。 ◎ Note: reporting observers can only observe reports from the same environment settings object.

注記：報告~内の直列化された~URLからは，［ `~username$url, `~password$url, `素片$url ］は剥取られる。 `§ 能力~URL＠#capability-urls$ を見よ。 ◎ Note: We strip the username, password, and fragment from the serialized URL in the report. See § 8.1 Capability URLs.

注記： ~UAは、何か理由があれば，報告を却下してもヨイ。一例として、この~APIは，任意な量の~dataに対する送達は保証しない。 ◎ Note: The user agent MAY reject reports for any reason. This API does not guarantee delivery of arbitrary amounts of data, for instance.

注記：（~JS~engineを備えない）非~UA~clientは、 `報告用~観測器$とヤリトリするべきでないので，上の段 6 で返るべきである【`報告を生成して~queueする$の中の “報告用~観測器に通知する” 段を飛ばすべきである】。 ◎ Note: Non user agent clients (with no JavaScript engine) should not interact with reporting observers, and thus should return in step 6.

2.4. 報告を直列化する

`報告~listを~JSONに直列化する@ ときは、所与の ( `報告$の~list %報告たち ) に対し： ◎ To serialize a list of reports to JSON,

%~collection ~LET 新たな`~list$ ◎ Let collection be an empty list.
%報告たちを成す ~EACH( %報告 ) に対し： ◎ For each report in reports:
1. %~data ~LET 次に挙げる~entryからなる新たな`有順序~map$ ⇒＃ `age^l → %報告の`時刻印$rPから現在の時刻までの ~millisecondsによる時間差, `type^l → %報告の`種別$rP, `url^l → %報告の`~URL$rP, `user_agent^l → %報告の`~UA$rP, `body^l → %報告の`本体$rP ◎ Let data be a map with the following key/value pairs: ◎ age • The number of milliseconds between report’s timestamp and the current time. type • report’s type url • report’s url user_agent • report’s user agent body • report’s body
  
  注記： ~client側の時計は，時計~skewの~subjectであり依拠できないので、絶対的な時刻印ではなく，時間差を — `age^c 属性を介して — 送達する。 `§ 時計~skew＠#fingerprinting-clock-skew$ も見よ ◎ Note: Client clocks are unreliable and subject to skew. We therefore deliver an age attribute rather than an absolute timestamp. See also § 9.2 Clock Skew
2. %報告の`試行数$rP ~INCBY 1 ◎ Increment report’s attempts.
3. %~collection に %~data を付加する ◎ Append data to collection.
~RET `~Infra値を~JSON~byte列に直列化する$( %~collection ) ◎ Return the byte sequence resulting from executing serialize JSON to bytes on collection.

3. 文書~中心な報告~法

この節は、［［文書（または~worker~script）内の各~動作により生成される`報告$ ］用の`報告先$ ］を環境設定するための仕組みを定義する。そのような各`報告$の存続期間は、それを生成した［文書／~worker ］の存続期間に縛られる。 ◎ This section defines the mechanism for configuring reporting endpoints for reports generated by actions in a document (or in a worker script). Such reports have a lifetime which is tied to that of the document or worker where they were generated.

3.1. 文書~環境設定

`WindowOrWorkerGlobalScope$I を実装している各~objは、次に挙げるものを有する： ◎ ↓

`報告先~list@ （ `endpoints^en ） ◎ Each object implementing WindowOrWorkerGlobalScope has an endpoints list,＼: 0 個以上の`報告先$からなる`~list$。 ◎ which is a list of endpoints,＼; この~listを成す`報告先$たちの`名前$ePは、互いに異なるモノトスル（この一意性は、 `応答~用に報告先たちを処理する$~algoにより保証される）。 ◎ each of which MUST have a distinct name. (Uniqueness is guaranteed by the algorithm in § 3.3 Process reporting endpoints for response.)
`報告~list@ （ `reports^en ） ◎ Each object implementing WindowOrWorkerGlobalScope has an reports list,＼: 0 個以上の`報告$からなる~list。 ◎ which is a list of reports.; 【この用語は、 “報告たち” という句として参照されることもある。そのように記された所では、ある`報告~list$内の 0 個以上の`報告$を表す（原語 “`reports^en” （複数形）は，この 2 つの意味で両義的に用いられているが、そのまま訳すと不明瞭になるので，この訳では［ “報告~list”, “報告たち” ］に分けて記すことにする）。】

`大域~objの報告先~listを初期化する@ ときは、所与の ( `WindowOrWorkerGlobalScope$I %~scope, `応答$ %応答 ) に対し ⇒ %~scope の`報告先~list$ ~SET `応答~用に報告先たちを処理する$( %応答 ) ◎ To initialize a global’s endpoint list, given a WindowOrWorkerGlobalScope (scope) and a response (response), set scope’s endpoints to the result of executing § 3.3 Process reporting endpoints for response given response.

3.2. `Reporting-Endpoints^h ~HTTP応答~header

~serverは、 `Reporting-Endpoints$h ~HTTP応答~headerを介して，自身が返す［文書／~worker~script ］資源~用に一連の報告先を定義してもヨイ。その仕組みは、この節【！§ 3.2...】にて定義され，その処理は § `応答~用に報告先たちを処理する$にて定義される。 ◎ A server MAY define a set of reporting endpoints for a document or a worker script resource it returns, via the Reporting-Endpoints HTTP response header field. This mechanism is defined in § 3.2 The Reporting-Endpoints HTTP Response Header Field, and its processing in § 3.3 Process reporting endpoints for response.

`Reporting-Endpoints@h ~HTTP応答~headerの値は、所与の資源~用に報告処理の環境設定を構築するために利用される。 ◎ The value of the Reporting-Endpoints HTTP response header field is used to construct the reporting configuration for a resource.

`Reporting-Endpoints$h は、 `有構造~header$であり，その`~field値$の型は `辞書$sfである `STRUCTURED-FIELDS$r 。この辞書を成す各~entryの値 %報告先は、 `報告$たちを送達してもよい`報告先$を定義する： ◎ Reporting-Endpoints is a Dictionary Structured Field [STRUCTURED-FIELDS]. Each entry in the dictionary defines an endpoint to which reports may be delivered.＼

%報告先の値は文字列でなければナラナイ。 ◎ The entry value MUST be a string.
%報告先は、 `文字列$sfを値にとる`~item$sfとして定義され， `URI-reference$P として解釈される。 %報告先の値が妥当な `URI-reference$P でない場合、当の %報告先は無視するモノトスル。 ◎ Each endpoint is defined by a String Item, which is interpreted as a URI-reference. If its value is not a valid URI-reference, that endpoint member MUST be ignored.
%報告先の値が表現する~URL【の`生成元$url】は`信用に価し得る$ものでなければナラナイ `SECURE-CONTEXTS$r 。 ~UAは、 ~secureでない`報告先$を無視することになる。 ◎ Moreover, the URL that the member’s value represents MUST be potentially trustworthy [SECURE-CONTEXTS]. Non-secure endpoints will be ignored.
%報告先用には`~parameter$sfは定義されない — `~parameter群$sfが指定されても，黙って無視されることになる。 ◎ No parameters are defined for endpoints, and any parameters which are specified will be silently ignored.

この~headerは、次の~ABNF文法 `RFC5234$r により表現される： ◎ The header is represented by the following ABNF grammar [RFC5234]:

Reporting-Endpoints
	= `sf-dictionary$P

3.3. 応答~用に報告先たちを処理する

この~algoは、所与の ( `応答$ %応答 ) に対し，`報告先$の~listを抽出して返す： ◎ Given a response (response), this algorithm extracts and returns a list of endpoints.

~IF［ %応答の~HTTPS状態† ~NEQ `modern^l ］~AND［ %応答の`~URL$rsの`生成元$urlは`信用に価し得る$ものでない］ ⇒ ~RET

【† 用語 “~HTTPS状態” は、過去に `FETCH$r にて定義されていたが，今や廃された。この段は更新される必要がある（参考： `modern^l は、概ね， “~HTTPS越しに送達された” ことを意味する）。】
◎ Abort these steps if response’s HTTPS state is not "modern", and the origin of response’s url is not potentially trustworthy.
%構文解析した~header ~LET %応答の`~header~list$rsから`有構造~field値を取得する$( `Reporting-Endpoints$h, `辞書^i ) ◎ Let parsed header be the result of executing get a structured field value given "Reporting-Endpoints" and "dictionary" from response’s header list.
~IF［ %構文解析した~header ~EQ ~NULL ］ ⇒ ~RET ◎ If parsed header is null, abort these steps.
%報告先~list ~LET 空~list ◎ Let endpoints be an empty list.
%構文解析した~header を成す ~EACH( %名前 → %~item ) に対し： ◎ For each name → value_and_parameters of parsed header:
1. ~IF［ %~item は`~item$sfでない］ ⇒ ~CONTINUE ◎ ↓
2. %報告先~URL文字列 ~LET %~item の値 ◎ Let endpoint url string be the first element of the tuple value_and_parameters.＼
3. ~IF［ %報告先~URL文字列は文字列でない］ ⇒ ~CONTINUE ◎ If endpoint url string is not a string, then continue.
4. %報告先~URL ~LET `~URL構文解析する$( %報告先~URL文字列, %応答の`~URL$rs ) ◎ Let endpoint url be the result of executing the URL parser on endpoint url string, with base URL set to response’s url.＼
5. ~IF［ %報告先~URL ~EQ `失敗^i ］ ⇒ ~CONTINUE ◎ If endpoint url is failure, then continue.
6. ~IF［ %報告先~URL の`生成元$url【！`生成元$】は`信用に価し得る$ものでない］ ⇒ ~CONTINUE ◎ If endpoint url’s origin is not potentially trustworthy, then continue.
7. %報告先 ~LET 新たな`報告先$ — その ⇒＃ `名前$eP ~SET %名前, `~URL$eP ~SET %報告先~URL, `失敗数$eP ~SET 0 ◎ Let endpoint be a new endpoint whose properties are set as follows: ◎ name • name url • endpoint url failures • 0
8. %報告先~list に %報告先を付加する ◎ Add endpoint to endpoints.
~RET %報告先~list ◎ Return endpoints.

3.4. 報告の生成

3.4.1. ある種別の報告を %~data から生成して~queueする【！で生成する】

`報告を生成して~queueする@ ときは、所与の ⇒＃ `文書$または `WorkerGlobalScope$I %文脈, 文字列 %種別, 文字列 %行先, 直列化-可能な~obj %~data, `~URL$ %~URL（省略時は ε ） ◎終に対し，次の手続きを走らすモノトスル： ◎ When the user agent is to generate and queue a report for a Document or WorkerGlobalScope object (context), given a string (type), another string (destination), and a serializable object (data), it must run the following steps:

%設定群 ~LET %文脈に`関連な設定群~obj$ ◎ Let settings be context’s relevant settings object.
%報告 ~LET `報告を生成する$( %~data, %種別, %行先, %設定群, %~URL ) ◎ Let report be the result of running generate a report with data, type, destination and settings.
~IF［ %設定群は与えられている† ］： ◎ If settings is given, then

【† 意味不明な条件 — `報告を生成する$手続きにおける最後の注記が意図されている？】
1. %~scope ~LET %設定群の`大域~obj$enV ◎ Let scope be settings’s global object.
2. ~IF［ %~scope は `WindowOrWorkerGlobalScope$I ~objである］ ⇒ `報告用~観測器に通知する$( %~scope, %報告 ) ◎ If scope is an object implementing WindowOrWorkerGlobalScope, then execute § 4.2 Notify reporting observers on scope with report with scope and report.
%報告を %文脈の`報告~list$に付加する ◎ Append report to context’s reports.

【最後の引数 %~URL は、この訳による補完（この~algoが更新されたことに伴い，それを参照している他の仕様と合致しなくなったことへの対処）。】

3.5. 報告の送達

様々な特能が、時を経るに伴い，［文書／~worker ］内の`報告たち$を~queueすることになる。 ~UAは、定期的に，現在~queueされた報告の~listを取り出して，それらに結付けられた報告先へ送達することになる。この仕様【！文書】は、 ~UAが従うべき~scheduleは定義しない。 ~UAは、報告を適時に送達するための文脈~上の情報を — 利用者~体験への影響iとの兼ね合いも含め — 十分に有するものと見做される。 ◎ Over time, various features will queue up a list of reports in documents and workers. The user agent will periodically grab the list of currently queued reports, and deliver them to the associated endpoints. This document does not define a schedule for the user agent to follow, and assumes that the user agent will have enough contextual information to deliver reports in a timely manner, balanced against impacting a user’s experience.

それでも~UAは、 ~queueしたなら，アリな限り早く報告を送達するよう努めるベキである — 報告の~dataは、生成したての頃の方が数日先よりも有意に有用になり得るので。 ◎ That said, a user agent SHOULD make an effort to deliver reports as soon as possible after queuing, as a report’s data might be significantly more useful in the period directly after its generation than it would be a day or a week later.

3.5.1. 報告を送信する

~UAは， `WindowOrWorkerGlobalScope$I ~obj %文脈用に報告たちを送信するときは、次の手続きを実行する： ◎ A user agent sends a list of reports (reports) for WindowOrWorkerGlobalScope object (context) by executing the following steps:

【この訳では、以下に現れる “~map” に対し，`有順序~map$に定義される記法を流用するが、 ~map内を反復する際の順序については（有意になるかもしれないが），原文には言及されていない。】

%報告たち ~LET %文脈の`報告~list$ ◎ ↑
%報告先~map ~LET 空~map ◎ Let endpoint map be an empty map of endpoint objects to lists of report objects.
%文脈の`報告先~list$を成す ~EACH( %報告先 ) に対し ⇒ %報告先~map[ %報告先の`名前$eP ] ~SET 新たな`~list$ ◎ ↓
%報告たちを成す ~EACH( %報告 ) に対し： ◎ For each report in reports:
1. ~IF［ %報告先~map[ %報告の`行先$rP ] ~NEQ ε ］ ⇒ %報告先~map[ %報告の`行先$rP ] に %報告を付加する ◎ If there exists an endpoint (endpoint) in context’s endpoints list whose name is report’s destination: • Append report to endpoint map’s list of reports for endpoint.
2. ~ELSE ⇒ %報告たちから %報告を除去する ◎ Otherwise, remove report from reports.
%文脈の`報告先~list$を成す ~EACH( %報告先 ) に対し： ◎ For each (endpoint, report list) pair in endpoint map:
1. %報告~list ~LET %報告先~map[ %報告先の`名前$eP ] ◎ ↑
2. %生成元~map ~LET 空~map — これは、 `生成元$を［ `報告$~objの~list ］に対応付ける ◎ Let origin map be an empty map of origins to lists of report objects.
3. %報告~list を成す ~EACH( %報告 ) に対し： ◎ For each report in report list:
  1. %生成元 ~LET %報告の`~URL$rPの`生成元$url【！`生成元$／直列化する？】 ◎ Let origin be the origin of report’s url.
  2. %生成元~map[ %生成元 ] に %報告を付加する ◎ Append report to origin map’s list of reports for origin.
  3. この段は非同期に実行するとする。
    
    %生成元~map を成す ~EACH( %生成元 → %生成元~用の報告たち ) に対し： ◎ For each (origin, per-origin reports) pair in origin map, execute the following steps asynchronously:
    1. %結果 ~LET `報告先へ報告たちを送達するよう試みる$( %報告先, %生成元, %生成元~用の報告たち ) ◎ Let result be the result of executing § 3.5.2 Attempt to deliver reports to endpoint on endpoint, origin, and per-origin reports.
    2. ~IF［ %結果 ~EQ `失敗^i ］ ⇒ %報告先の`失敗数$eP ~INCBY 1 ◎ If result is "Failure": • Increment endpoint’s failures.
    3. ~ELIF［ %結果 ~EQ `報告先を除去する^i ］ ⇒ %文脈の`報告~list$から %報告先を除去する ◎ If result is "Remove Endpoint": • Remove endpoint from context’s endpoints list.
    4. %生成元~用の報告たちを成す ~EACH( %報告 ) に対し ⇒ %報告たちから %報告を除去する ◎ Remove each report from reports.
  ここでは、失敗した報告を試行し直す仕組みは指定されない。そのような仕組みをここに追加するか，送達は失敗したことの何らかの指示を供するかもしれない。 ◎ We don’t specify any retry mechanism here for failed reports. We may want to add one here, or provide some indication that the delivery failed.

注記： ~UAは、収集された［報告／報告先］のうち一部のみ送達するよう試みることにしてもヨイ（例えば、一度にすべての報告を送信すると帯域幅を過度に消費するとき, 等々）。報告が~cacheから除去されるのは，送達が試みらた後に限られるので、ここで飛ばされた報告は，単に後で送達されることになる。 ◎ Note: User agents MAY decide to attempt delivery for only a subset of the collected reports or endpoints (because, for example, sending all the reports at once would consume an unreasonable amount of bandwidth, etc). As reports are only removed from the cache after delivery has been attempted, skipped reports will simply be delivered later.

3.5.2. %報告先へ %報告を送達するよう試みる

この~algoは、所与の ( `報告先$ %報告先, `生成元$ %生成元, `報告~list$ %報告たち ) に対し，`要請$を構築して %報告先へ送達するよう試みた上で、次を返す ⇒＃送達に失敗したならば `失敗^i ／送達に成功したならば `成功^i ／報告先が `410$st 応答を送信することにより，報告先としての自身を明示的に除去したならば `報告先を除去する^i ◎ Given an endpoint (endpoint), an origin (origin), and a list of reports (reports), this algorithm will construct a request, and attempt to deliver it to endpoint. It returns "Success" if that delivery succeeds, "Remove Endpoint" if the endpoint explicitly removes itself as a reporting endpoint by sending a 410 response, and "Failure" otherwise.

%本体 ~LET 次のようにされた新たな`本体$ ⇒ `~source$bd ~SET `報告~listを~JSONに直列化する$( %報告たち ) ◎ Let body be the result of executing serialize a list of reports to JSON on reports. ◎ ↓
%要請 ~LET 新たな`要請$ `FETCH$r — その ⇒＃ `~method$rq ~SET `POST^bl, `~URL$rq ~SET %報告先の`~URL$eP, `生成元$rq ~SET %生成元, `~header~list$rq ~SET « ( `Content-Type^bl, `application/reports+json^bl ) », `~client$rq ~SET ~NULL, `~window$rq ~SET `no-window^l, `~sw~mode$rq ~SET `none^l, `起動元$rq ~SET 空~文字列, `行先$rq ~SET `report^l, `~mode$rq ~SET `cors^l, `安全でない要請か$rq ~SET ~T, `資格証~mode$rq ~SET `same-origin^l, `本体$rq ~SET %本体 ◎ Let request be a new request with the following properties [FETCH]: ◎ method • "POST" url • endpoint’s url origin • origin header list • A new header list containing a header named `Content-Type` whose value is "application/reports+json" client • null window • "no-window" service-workers mode • "none" initiator • "" destination • "report" mode • "cors" unsafe-request flag • set credentials • "same-origin" body • A body whose source is body.

注記：報告は、 `資格証~mode$rq を `same-origin^l に設定する下で送信される。これは、［報告している~pageと同一-生成元に属する報告先］が【`資格証$を受信することにより】［当の報告の資質について余分な文脈を取得する］ことを許容する — 例えば，［ある利用者の~accountが，一貫して~errorを誘発しているかどうか／他の~page上でとられたある種の一連の動作が，~~現在の~pageからの報告を誘発しているかどうか］を解するなど。これは、当の報告先に［他の仕方で得することはできない新たな情報］を漏洩することはない。このことは，［非同一-生成元に属する報告先］には該当しないので、それらは資格証を受信しない。 ◎ Note: Reports are sent with credentials set to same-origin. This allows reporting endpoints which are same-origin with the reporting page to get extra context about the nature of the report: for example, to understand whether a given user’s account is triggering errors consistently, or if a certain sequence of actions taken on other pages is triggering a report on this page. This does not leak any new information to the reporting endpoint that it could not obtain in other ways. That is not the case for cross-origin reporting endpoints, so they do not receive credentials.
`~taskを~queueする$( 【`~task~source$が指定されていない】, 次の手続き )

手続きは ⇒ %要請を`~fetch$する
◎ Queue a task to fetch request.
%応答を待機する【？】 ◎ Wait for a response (response).
~RET %応答の`状態s$rsに応じて ⇒＃ `~ok状態s$（ `200^st 〜 `299^st ）であるならば `成功^i ／ `410$st （ Gone ） `RFC9110$r ならば `報告先を除去する^i ／ ~ELSE_ `失敗^i ◎ If response’s status is an OK status (200-299), return "Success". ◎ If response’s status is 410 Gone [RFC9110], return "Remove Endpoint". ◎ Return "Failure".

4. 報告用~観測器

`報告用~観測器@ （ `reporting observer^en ）は、ある限られた`種別$rPの`報告たち$を，~JSから観測する — それは、 ~JSにおいては `ReportingObserver$I ~objにより表現される。 ◎ A reporting observer observes some types of reports from JavaScript, and is represented in JavaScript by the ReportingObserver object.

`WindowOrWorkerGlobalScope$I を実装している各~obj %~scope には、次に挙げるものが結付けられる： ◎ ↓

`登録-済み観測器~list@ （ `registered reporting observer list^en ） ◎ Each object implementing WindowOrWorkerGlobalScope has a registered reporting observer list,＼: `報告用~観測器$たちが成す`有順序~集合$。 ◎ which is an ordered set of reporting observers.; `報告用~観測器$が `登録-済み@ であるとは、ある`登録-済み観測器~list$内に在ることを~~意味する。 ◎ Any reporting observer that is in a registered reporting observer list is considered registered.
`報告~buffer@ （ `report buffer^en ） ◎ Each object implementing WindowOrWorkerGlobalScope has a report buffer,＼: %~scope 内で生成された`報告たち$が成す`~list$。初期~時には空とする。報告たちは、生成された順序で格納される。 ◎ which is a list of reports that have been generated in that WindowOrWorkerGlobalScope. This list is initially empty, and the reports are stored in the same order in which they are generated.; 注記： `報告~buffer$の目的は、 `報告用~観測器$が，自身が作成される前に生成された報告を（ ~option群の `buffered$m を介して）観測できるようにすることである。例えば、報告には，観測器が作成-可能になる前に生成されるものもある — ~page読込ngの早い段階や，報告を観測したいと望む~JS~libraryが読込まれる前など。 ◎ Note: The purpose of the report buffer is to allow reporting observers to observe reports that were generated earlier than that observer could be created (via the buffered option). For example, some reports might be generated during an earlier stage of page loading than when an observer could first be created, or before a JavaScript library is loaded that wishes to observe these reports.

注記：報告用~観測器が関連するのは、 ~JS~engineを備える~UA用に限られる。 ◎ Note: Reporting observers are only relevant for user agents with JavaScript engines.

4.1. ~interface `ReportingObserver^I

[`Exposed$=(Window,Worker)]
interface `ReportBody@I {
  [`Default$] `object$ `toJSON@mB();
};

[`Exposed$=(Window,Worker)]
interface `Report$I {
  [`Default$] `object$ `toJSON@m();
  readonly attribute `DOMString$ `type$m;
  readonly attribute `DOMString$ `url$m;
  readonly attribute `ReportBody$I? `body$m;
};

[`Exposed$=(Window,Worker)]
interface `ReportingObserver@I {
  `constructor$m(`ReportingObserverCallback$I %callback, optional `ReportingObserverOptions$I %options = {});
  `undefined$ `observe$m();
  `undefined$ `disconnect$m();
  `ReportList$I `takeRecords$m();
};

callback `ReportingObserverCallback@I = `undefined$ (`sequence$<`Report$I> %reports, `ReportingObserver$I %observer);

dictionary `ReportingObserverOptions@I {
  `sequence$<`DOMString$> `types@m;
  `boolean$ `buffered@m = false;
};

typedef `sequence$<`Report$I> `ReportList@I;

`Report@I は、 ~appに公開される`報告$の表現を成す。その［ `type@m ／ `url@m ／ `body@m ］取得子~手続きは、 `報告$の［ `種別$rP ／ `~URL$rP ／ `本体$rP ］を返す。 ◎ A Report is the application exposed representation of a report. type returns type, url returns url, and body returns body.

各 `ReportingObserver$I ~objには、次の概念が結付けられる： ◎ Each ReportingObserver object has these associated concepts:

`~callback@ob: 作成-時に設定される~callback関数。 ◎ A callback function set on creation.
`~option群@ob: 作成-時に設定される `ReportingObserverOptions$I 辞書。 ◎ A ReportingObserverOptions dictionary called options.
`報告~queue@ob: `Report$I ~objたちが成す~list。初期~時には空とする。 ◎ A list of Report objects called the report queue, which is initially empty.

`ReportList$I は、 `Report$I たちが成す連列を表現する — それは、 ~JS~arrayに見出されるすべての便利~methodも，開発者に供する。 ◎ A ReportList represents a sequence of Reports, providing developers with all the convenience methods found on JavaScript arrays.

`ReportingObserver(callback, options)@m 構築子~手続きは ⇒＃コレの`~callback$ob ~SET %callback, コレの`~option群$ob ~SET %options ◎ The ReportingObserver(callback, options) constructor, when invoked, must run these steps: • Create a new ReportingObserver object observer. • Set observer’s callback to callback. • Set observer’s options to options. • Return observer.

`observe()@m ~method~手続きは： ◎ The observe() method, when invoked, must run these steps:

%大域~obj ~LET コレに`関連な大域~obj$ ◎ Let global be the be the relevant global object of this.
%大域~obj の`登録-済み観測器~list$にコレを`付加する$【！＊】 ◎ Append this to the global’s registered reporting observer list.
~IF［コレの`~option群$ob[ "`buffered$m" ] ~EQ ~F ］ ⇒ ~RET ◎ If this’s buffered option is false, return.
コレの`~option群$ob[ "`buffered$m" ] ~SET ~F ◎ Set this’s buffered option to false.
%大域~obj の`報告~buffer$を成す ~EACH( %報告 ) に対し ⇒ `~taskを~queueする$( 【`~task~source$が指定されていない】, 次の手続き )

手続きは ⇒ `観測器に報告を追加する$( %報告, コレ )
◎ For each report in global’s report buffer, queue a task to execute § 4.3 Add report to observer with report and this.

`disconnect()@m ~method~手続きは ⇒ コレに`関連な大域~obj$の`登録-済み観測器~list$からコレを`除去する$ ◎ The disconnect() method, when invoked, must run these steps: • If this is not registered, return. • Let global be the relevant global object of this. • Remove this from global’s registered reporting observer list.

`takeRecords()@m ~method~手続きは： ◎ The takeRecords() method, when invoked, must run these steps:

%報告~群 ~LET コレの`報告~queue$obを`~cloneする$ ◎ Let reports be a copy of this’s report queue.
コレの`報告~queue$obを`空にする$ ◎ Empty this’s report queue.
~RET %報告~群 ◎ Return reports.

4.2. 報告用~観測器に通知する

この~algoは、報告の内容を`登録-済み$な`報告用~観測器$から可用にする。それは、所与の ( `WindowOrWorkerGlobalScope$I %~scope, `報告$ %報告 ) に対し，次を走らす： ◎ This algorithm makes report’s contents available to any registered reporting observers on the provided WindowOrWorkerGlobalScope.

%~scope に`登録-済み$な ~EACH( `報告用~観測器$ %観測器 ) に対し ⇒ `観測器に報告を追加する$( %報告, %観測器 ) ◎ For each ReportingObserver observer registered with scope, execute § 4.3 Add report to observer on report and observer.
%~buffer ~LET %~scope の`報告~buffer$ ◎ ↓
%~buffer に %報告を`付加する$ ◎ Append report to scope’s report buffer.
~IF［ %~buffer 内の~itemのうち［ ~itemの`種別$rP ~EQ %報告の`種別$rP ］を満たすものの個数 ~GT 100 ］ ⇒ %~buffer から［該当する最初の~item ］を`除去する$ ◎ Let type be report’s type. ◎ If scope’s report buffer now contains more than 100 reports with type equal to type, remove the earliest item with type equal to type in the report buffer.

4.3. 観測器に報告を追加する

この~algoは、報告を観測器の`報告~queue$obに追加する — 報告の`種別$rPが観測器から観測-可能ならば。それは、所与の ( `報告$ %報告, `報告用~観測器$ %観測器 ) に対し，次を走らす： ◎ Given a report report and a ReportingObserver observer, this algorithm adds report to observer’s report queue, so long as report’s type is observable by observer.

%種別 ~LET %報告の`種別$rP ◎ ↓
~IF［ %種別は`報告用~観測器から可視$でない］ ⇒ ~RET ◎ If report’s type is not visible to ReportingObservers, return.
%種別たち ~LET %観測器の`~option群$ob[ "`types$m" ] ◎ ↓
~IF［ %種別たち ~NEQ ε ］~AND［ %種別 ~NIN %種別たち］ ⇒ ~RET ◎ If observer’s options has a non-empty types member which does not contain report’s type, return.
%報告~obj ~LET 新たな `Report$I ~obj — その ⇒＃ `type$m ~SET %報告の`種別$rP, `url$m ~SET %報告の`~URL$rP, `body$m ~SET %報告の`本体$rP ◎ Create a new Report r with type initialized to report’s type, url initialized to report’s url, and body initialized to report’s body.

`body$m を多形態的に初期化するにはどうする？ ◎ how to polymorphically initialize body?
%観測器の`報告~queue$obに %報告~obj を`付加する$ ◎ Append r to observer’s report queue.
~IF［ %観測器の`報告~queue$obの`~size$ ~EQ 1 ］：
1. %通知-~list ~LET %観測器に`関連な大域~obj$の`登録-済み観測器~list$を`~cloneする$†
2. `~taskを~queueする$( 【`~task~source$が指定されていない】, 次の手続き )
  
  手続きは ⇒ `報告用~観測器を通知-~listで呼出す$( %通知-~list )
【† 原文の記述は，~queueされる~taskの中で~cloneするようにも解釈できるが、それだと何のために~cloneするのか意味不明になる。】
◎ If the size of observer’s report queue is 1: • Let global be observer’s relevant global object. • Queue a task to § 4.4 Invoke reporting observers with notify list with a copy of global’s registered reporting observer list.

4.4. 報告用~観測器を通知-~listで呼出す

この~algoは、それまでに観測された各［挙動の報告］用に，観測器の`~callback$obを呼出す。それは、所与の ( %通知-~list ) に対し，次を走らす： ◎ This algorithm invokes observer callback functions for reports of previously observed behavior.

%通知-~list を成す ~EACH( %観測器 ) に対し： ◎ For each ReportingObserver observer in notify list:
1. ~IF［ %観測器の`報告~queue$obは空である］ ⇒ ~CONTINUE ◎ If observer’s report queue is empty, then continue.
2. %報告~群 ~LET %観測器の`報告~queue$obを`~cloneする$ ◎ Let reports be a copy of observer’s report queue
3. %観測器の`報告~queue$obを`空にする$ ◎ Empty observer’s report queue
4. `~callback関数を呼出す$( %観測器の`~callback$ob, « %報告~群, %観測器 », `報告する^i, %観測器 ) ◎ Invoke observer’s callback with « reports, observer » and "report", and with observer as the callback this value.

5. 実装にあたっての考慮点

5.1. 送達

開発者にアリな限り素早く~feedbackを供するため、 ~UAは，アリな限り早く報告を送達するよう試みるベキである。しかしながら，これには、利用者への影響iとの兼ね合いも加味される — 利用者が~~優先される。 ~UAは，そのことを念頭に、利用者の活動や文脈について自身が有する知識に基づいて，報告の送達を延期してもヨイ。 ◎ The user agent SHOULD attempt to deliver reports as soon as possible to provide feedback to developers as quickly as possible. However, when this desire is balanced against the impact on the user, the user wins. With that in mind, the user agent MAY delay delivery of reports based on its knowledge of the user’s activities and context.

一例として、 ~UAは，報告する~data伝送の優先度を他の~network流通より低く抑えるベキである。利用者による明示的な~website活動があれば、報告よりその流通を先にくり上げるベキである。 ◎ For instance, the user agent SHOULD prioritize the transmission of reporting data lower than other network traffic. The user’s explicit activities on a website should preempt reporting traffic.

~UAは，不必要な~data~costを防止するため、報告の送達を利用者にとって~networkが高速で軽くなるまで，まるごと保留することを選んでもヨイ。 ◎ The user agent MAY choose to withhold report delivery entirely until the user is on a fast, cheap network in order to prevent unnecessary data cost.

~UAは、生成元に応じて報告の優先度を~~操作してもヨイ（たぶん，利用者が最も頻繁に訪問する生成元を優先する？） ◎ The user agent MAY choose to prioritize reports from particular origins over others (perhaps those that the user visits most often?)

5.2. ~garbage収集

~UAは、 ~cacheした［ `報告$／`報告先$ ］を定期的に巡回した上で，関連しなくなったものは破棄するベキである。これらには、次が含まれる： ◎ Periodically, the user agent SHOULD walk through the cached reports and endpoints, and discard those that are no longer relevant. These include:

`報告先$のうち，`失敗数$ePが［ ~UA定義な閾値（ 5 回くらいが適度？）］を超過したもの ◎ endpoints whose failures exceed some user-agent-defined threshold (~5 seems reasonable)
`報告$のうち，ある任意な期間（ 2 日くらい？）送達されていないもの ◎ reports which have not been delivered in some arbitrary period of time (perhaps ~2 days?)

破棄されたどの`報告たち$も、 `報告用~観測器$の`報告~buffer$から除去されるべきである。 ◎ For any reports that are discarded, these reports should also be removed from the report buffer of any reporting observer.

6. 報告の見本

◎非規範的

この例は、 ~UAが報告先へ向けて送信する報告たちを成す形式を示す。この提出~見本は、［ 1 個の~HTTP要請~内で送信されるよう一緒に束ねられた， 3 個の報告］を包含する。（各~報告の［ `種別$rP（ `type^l ）／`本体$rP（ `body^l ）］は、 ~~架空のものである — 実際の特能は、この仕様の視野から外れるので。） ◎ This example shows the format in which reports are sent by the user agent to the reporting endpoint. The sample submission contains three reports which have been bundled together and sent in a single HTTP request. (The report types and bodies themselves are not intended to be representative of any actual feature, as those are outside of the scope of this specification).

POST / HTTP/1.1
Host: example.com
...
Content-Type: application/reports+json

[{
  "type": "security-violation",
  "age": 10,
  "url": "https://example.com/vulnerable-page/",
  "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0",
  "body": {
    "blocked": "https://evil.com/evil.js",
    "policy": "bad-behavior 'none'",
    "status": 200,
    "referrer": "https://evil.com/"
  }
}, {
  "type": "certificate-issue",
  "age": 32,
  "url": "https://www.example.com/",
  "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0",
  "body": {
    "date-time": "2014-04-06T13:00:50Z",
    "hostname": "www.example.com",
    "port": 443,
    "effective-expiration-date": "2014-05-01T12:40:50Z",
    "served-certificate-chain": [
      "-----BEGIN CERTIFICATE-----\n
      MIIEBDCCAuygAwIBAgIDAjppMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT\n
      ...
      HFa9llF7b1cq26KqltyMdMKVvvBulRP/F/A8rLIQjcxz++iPAsbw+zOzlTvjwsto\n
      WHPbqCRiOwY1nQ2pM714A5AuTHhdUDqB1O6gyHA43LL5Z/qHQF1hwFGPa4NrzQU6\n
      yuGnBXj8ytqU0CwIPX4WecigUCAkVDNx\n
      -----END CERTIFICATE-----",
      ...
    ]
  }
}, {
  "type": "cpu-on-fire",
  "age": 29,
  "url": "https://example.com/thing.js",
  "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0",
  "body": {
    "temperature": 614.0
  }
}]

7. 自動化

この文書は、［ ~UAによる自動化／~appを~testする］目的で， `WebDriver$r 仕様~用にいくつかの`拡張~command$を定義する。 ◎ For the purposes of user-agent automation and application testing, this document defines a number of extension commands for the [WebDriver] specification.

7.1. ~test報告を生成する

`~test報告を生成する@i （ `Generate Test Report^en ）`拡張~command$は、 ~testする目的で`報告$の生成を模倣する。この報告は、 `登録-済み$な`報告用~観測器$があれば，それらにより観測されることになる。 ◎ The Generate Test Report extension command simulates the generation of a report for the purposes of testing. This report will be observed by any registered reporting observers.

この`拡張~command$は、以下に従って定義される： ◎ The extension command is defined as follows:

dictionary `GenerateTestReportParameters@I {
  required `DOMString$ `message@mTR;
  `DOMString$ `group@mTR = "default";
};

~HTTP~method	`~URI~template$
`POST^hm	`/session/{session id}/reporting/generate_test_report^c

◎ HTTP Method｜Prefix｜Name POST｜/session/{session id}/reporting｜generate_test_report

以下における `~WebDriver~error$( %~error~code ) という表記は、次の略記である ⇒ `~WebDriver~error~code$として %~error~code を伴う，新たな`~WebDriver~error$ ◎ ↓

`~remote端~手続き$は、所与の ( %parameters ) に対し，次を走らす： ◎ The remote end steps are:

~IF［ %parameters は~JSON `Object＠~FILEAPI#blob-url-entry-object$【 `Object^jT ？】でない］ ⇒ ~RET `~WebDriver~error$( `無効な引数$i ) ◎ If parameters is not a JSON Object, return a WebDriver error with WebDriver error code invalid argument.
%~message ~LET %parameters の `message$mTR ~propを`取得しようと試行する$ ◎ Let message be the result of trying to get parameters’s message property.
~IF［ %~message `is not present^en 【%~message は~errorである？】］ ⇒ ~RET `~WebDriver~error$( `無効な引数$i ) ◎ If message is not present, return a WebDriver error with WebDriver error code invalid argument.
~IF［ `現在の閲覧~文脈$は、もはや開いていない］ ⇒ ~RET `~WebDriver~error$( `そのような~windowは無い$i ) ◎ If the current browsing context is no longer open, return a WebDriver error with WebDriver error code no such window.
%値 ~LET `利用者~promptを取扱う$ ◎ Handle any user prompts and＼
~IF［ %値は`~WebDriver~error$である］ ⇒ ~RET %値 ◎ return its value if it is a WebDriver error.
%~group ~LET %parameters の `group$mTR ~prop ◎ Let group be parameters’s group property.
%本体 ~LET 次のようにされた~propを有する新たな `Object^jT ⇒ `body_message^c ~SET %~message ◎ Let body be a new object that can be serialized into a JSON text, containing a single string field, body_message. ◎ Set body_message to message.
【！原文更新漏れ：引数, その順序】【！%設定群 ~LET `現在の閲覧~文脈$にて`作動中な文書$bcの`環境~設定群~obj$】 `報告を生成して~queueする$( `現在の閲覧~文脈$にて`作動中な文書$bc, `test^l, %~group, %本体 ) 【！( %本体, `test^l, %~group, %設定群 )】 ◎ Let settings be the environment settings object of the current browsing context’s active document. ◎ Execute generate and queue a report with body, "test", group, and settings.
~RET ~dataとして ~NULL を伴う`成功$wd ◎ Return success with data null.

8. ~securityの考慮点

8.1. 能力~URL

~URLには，それ自体が有価値なものもある。そのような~URLは、［その［ `~username$url, `~password$url ］部位~内に明示的な資格証を包含する］こともあれば，［当の~URL~pathの知識を有する誰にでも，何らかの資源への~accessを是認する］こともある。加えて，~URLの`素片$urlが［利用者の~browser内【~address~barや履歴など】には決して残さないものと意図される情報］を包含することもある。さらなる情報は、 `CAPABILITY-URLS$r を見よ。 ◎ Some URLs are valuable in and of themselves. They may contain explicit credentials in the username and password portion of the URL, or may grant access to some resource to anyone with knowledge of the URL path. Additionally, they may contain information which was never intended leave the user’s browser in the URL fragment. See [CAPABILITY-URLS] for more information.

そのような~URLが，この仕様の報告処理の仕組みを介して漏洩される可能性を軽減するため、この仕様の~algoは，`報告$の出自者として送信される~URLから［資格証, `素片$url ］の~dataを剥取る。しかしながら，それでも、 ~URLの~path内の敏感な情報は，この仕方で漏洩される可能性はある。そのような~URLを利用する~siteは、自前の報告先を運用する必要があろう。 ◎ To mitigate the possibility that such URLs will be leaked via this reporting mechanism, the algorithms here strip out credential information and fragment data from the URL sent as a report’s originator. It is still possible, however, for sensitive information in the URL’s path to be leaked this way. Sites which use such URLs may need to operate their own reporting endpoints.

加えて，そのような~URLは、報告の`本体$rP内に在ることもある。この~APIを拡張して，報告の`本体$rP内に~URLを含める仕様は、それらも類似に剥取るよう要求するベキである。 ◎ Additionally, such URLs may be present in a report’s body. Specifications which extend this API and which include any URLs in a report’s body SHOULD require that they be similarly stripped.

9. ~privacyの考慮点

9.1. ~network漏洩e

~pageが読込まれてから報告が生成され, 送信されるまでには遅延があるので、利用者が［ある~network上にいる間に生成された報告が，別の~network上にいる間に送信される］ことも，まったくアリになる。 ◎ Because there is a delay between a page being loaded and a report being generated and sent, it’s entirely possible for a report generated while a user is on one network to be sent while the user is on another network.

この挙動は、当の報告を生成した文書の存続期間に制限される。そのような文書は — どの事例でも，文書が閉じられた後でも — 他の手段（例： `navigator.sendBeacon()$m の仕組み）を通して，新たな~network上で流通を生成することもできるが。 ◎ This behaviour is limited to the lifetime of the document which generated the reports, though, and such a document could be generating traffic on the new network through other means in any case, even after the document is closed, through mechanisms such as navigator.sendBeacon.

軽減策を考慮する。例えば、別の~networkへ変更されたときは，報告を落とすこともできるような。 `w3c/BackgroundSync 課題 #107＠https://github.com/WICG/background-sync/issues/107$ ◎ Consider mitigations. For example, we could drop reports if we change from one network to another. [Issue #w3c/BackgroundSync#107]

9.2. 時計~skew

利用者~側の局所~時計は，~server上の時計から任意な量だけ~skewされるので、各~報告には — それが生成された時点の時刻印でなく — `age^c ~propが伴われて送達される。これにより、報告の［生成-時刻と送信-時刻］の差異は，時計~skewに関わらず~~一定になり、この~APIを介する時計~skewが公開されることによる指紋収集の~riskも避けれる。 ◎ Each report is delivered along with an age property, rather than the timestamp at which it was generated. We do this because each user’s local clock will be skewed from the clock on the server by an arbitrary amount. The difference between the time the report was generated and the time it was sent will be stable, regardless of clock skew, and we can avoid the fingerprinting risk of exposing the clock skew via this API.

9.3. 非同一-生成元の相関

複数の生成元がすべて同じ報告先を利用する場合、その報告先は，［それぞれから生成元~付きの報告を受信する］ことになるので、特定0の利用者がある~websiteの集合とやりとりしたことを学習できることになる。これは、［複数の生成元が，同じ情報を協力的に追跡する能］がある現状を，より悪化させるものには見えない。それは、［今日における~HTML `img^e 要素でアリなもの］以上の新たな追跡~能を是認するものではない。 ◎ If multiple origins all use the same reporting endpoint, that endpoint may learn that a particular user has interacted with a certain set of websites, as it will receive origin-tagged reports from each. This doesn’t seem worse than the status quo ability to track the same information from cooperative origins, and doesn’t grant any new tracking ability above and beyond what’s possible with <img> today.

9.4. 報告処理の不能化-法

報告処理は、ある~~範囲までは，公共性に関わる。報告が送達されることは、総じて，誰にとっても有用であろう。 ~bugを修正できる開発者には，直接的な便益があり、それにより利用者たちが楽しむ~siteも，より安定的かつ楽しめるものになるので、利用者も間接的な便益を得ることになる。具体例として，~CSPは、 ~siteの防壁~内にありうる穴について開発者に警戒を促すことにより， ~XSS攻撃に対する集団免疫【`herd immunity＠https://en.wikipedia.org/wiki/Herd_immunity$en】の様なものを促進する。それらの~bugの修正は、 ~CSPを~supportしない~UAを利用している利用者までも助ける。 ◎ Reporting is, to some extent, a question of commons. In the aggregate, it seems useful for everyone for reports to be delivered. There is direct benefit to developers, as they can fix bugs, which means there’s indirect benefit to users, as the sites they enjoy will be more stable and enjoyable. As a concrete example, Content Security Policy grants something like herd immunity to cross-site scripting attacks by alerting developers about potential holes in their sites' defenses. Fixing those bugs helps every user, even those whose user agents don’t support Content Security Policy.

計算法は、もちろん，送達されている~dataの資質と報告先の相対的な悪意度に依存するが、それは，大雑把に言えば価値提案である。 ◎ The calculus, of course, depends on the nature of data that’s being delivered, and the relative maliciousness of the reporting endpoints, but that’s the value proposition in broad strokes.

それでも、この一般~便益が［そのような~systemを個別に~opt-outする利用者の能］を超えて優先されることは，許容されない。報告の送信には帯域幅~costがかかることに加え、［ ~websiteが帯域内で得せる以上の，少量の情報］も露呈し得る（一例として， `NETWORK-ERROR-LOGGING$r ）。 `HTML-DESIGN$r にて信奉されている有権者の優先度を保守するため、 ~UAは，利用者が報告処理を適度な粒度で不能化できるようにするモノトスル。 ◎ That said, it can’t be the case that this general benefit be allowed to take priority over the ability of a user to individually opt-out of such a system. Sending reports costs bandwidth, and potentially could reveal some small amount of additional information above and beyond what a website can obtain in-band ([NETWORK-ERROR-LOGGING], for instance). User agents MUST allow users to disable reporting with some reasonable amount of granularity in order to maintain the priority of constituencies espoused in [HTML-DESIGN-PRINCIPLES].

10. IANA 考慮点

10.1. `Reporting-Endpoints^h ~header

恒久的~message~header~registry `RFC3864$r は、次の登録で更新されるべきである： ◎ The permanent message header field registry should be updated with the following registration: [RFC3864]

~header名前	`Reporting-Endpoints^h
適用-可能な~protocol	http
位置付け	標準
著作者／変更~制御者	W3C
仕様~文書	この仕様（§ `Reporting-Endpoints$h ~HTTP応答~headerを見よ）

◎ Header field name • Reporting-Endpoints Applicable protocol • http Status • standard Author/Change controller • W3C Specification document • This specification (see § 3.2 The Reporting-Endpoints HTTP Response Header Field)

10.2. ~MIME型 `application/reports+json^c

型~名 ◎ Type name: `application^c
下位型~名 ◎ Subtype name: `reports+json^c
要求される~parameter ◎ Required parameters: N/A
省略可能な~parameter ◎ Optional parameters: N/A
符号化法の考慮点 ◎ Encoding considerations: ~MIME型 `application/json^l 用に指定されものに一致する。 `RFC8259$r を見よ。 ◎ Encoding considerations are identical to those specified for the "application/json" media type. See [RFC8259].
~securityの考慮点 ◎ Security considerations: `§ ~securityの考慮点＠#security$ を見よ。 ◎ See § 8 Security Considerations.
相互運用能の考慮点 ◎ Interoperability considerations: この文書は、適合する~messageの形式とその解釈を指定する。 ◎ This document specifies the format of conforming messages and the interpretation thereof.
公表した仕様 ◎ Published specification: `§ ~MIME型＠#media-type$ ◎ § 2.2 Media Type
この~MIME型を利用する応用 ◎ Applications that use this media type
素片~識別子の考慮点 ◎ Fragment identifier considerations
追加的な情報 ◎ Additional information: N/A
更なる情報~用の個人の ~email~address／連絡先 ◎ Person and email address to contact for further information: この文書の編集者たち。 ◎ This document’s editors.
意図される用法 ◎ Intended usage:: COMMON
用法~上の制約 ◎ Restrictions on usage:: N/A
著作者 ◎ Author: この文書の編集者たち。 ◎ This document’s editors.
変更~制御者 ◎ Change controller: W3C
暫定的な登録？ ◎ Provisional registration?: Yes.