1. 序論
[INTRODUCTION GOES HERE]
1.1. 保証-
この仕様は、~website活動の帯域外で実行されるような ~best-effortによる 報告~送達~systemを供することを目指す。 ~UAは、報告の送達に優先度をあてがったり,それらを~scheduleする~~仕事をより良く行える立場にある — ~UAは、[ 個々の~websiteが有さない,非同一生成元の活動 ]について俯瞰でき,また,[ ~websiteの読込みが頭から防止される~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.
しかしながら、送達は,厳密的には保証されない。 この仕様の~algoは,適度な再試行~規則の集合を~~述べるが、何か不具合が生じたときは,報告が取りこぼされることも~~十分にあり得る。 ◎ The delivery is not, however, guaranteed in a strict sense. We spell out a reasonable set of retry rules in the algorithms below, but it’s quite possible for a report to be dropped on the floor if things go badly.
報告処理は 多量の流通を生成し得るので、開発者は[ ~DNS `SRV record$ から着想を得られた,~failoverと負荷~分散-法の仕組み ]を利用して,各[ `報告先$たちの~group ]を設定しておけるようになっている。 ~UAは、特定0の報告を~group内の高々一個の報告先に送達するよう,最善を尽くすことになる。 各~報告先には、負荷を配分するための重みをアテガえる — 各~報告先がそれぞれに指定された割合分の報告用~流通を受信するように。 各~報告先には、優先度をアテガえる — 開発者は[ 首~収集器への~uploadが失敗したときに限り,試行される~fallback収集器 ]を設定しておけるようになる。 ◎ Reporting can generate a good deal of traffic, so we allow developers to set up groups of endpoints, using a failover and load-balancing mechanism inspired by the DNS SRV record. The user agent will do its best to deliver a particular report to at most one endpoint in a group. Endpoints can be assigned weights to distribute load, with each endpoint receiving a specified fraction of reporting traffic. Endpoints can be assigned priorities, allowing developers to set up fallback collectors that are only tried when uploads to primary collectors fail.
1.2. 例
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":
`Report-To$h: { "`group$jR": "endpoint-1", "`max_age$jR": 10886400, "`endpoints$jR": [ { "`url$jR": "https://example.com/reports", "`priority$jR": 1 }, { "`url$jR": "https://backup.com/reports", "`priority$jR": 2 } ] }
に加えて、[ ~CSP/~HPKP ]報告をその `group$jR に指向ける,次の~headerを送達する: ◎ And the following headers, which direct CSP and HPKP reports to that group:
`Content-Security-Policy$h: ...; `report-to$dir=endpoint-1 `Public-Key-Pins$h: ...; `report-to^dir=endpoint-1
【 読みやすくするため、この仕様の `Report-To^h ~header例は,行の折り返しや字下げなどの整形が施されているが、 HTTP/1.1 の構文としては,改行は許容されないことに注意。 】
しばらくして後, MegaCorp 社は、~script処理を単純~化するため,これら 2 種の報告を,種別ごとに別々の報告先に分けて処理することに決めた。 そうするには、 `Report-To$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:
`Report-To$h: { "`url$jR": "https://example.com/csp-reports", "`group$jR": "csp-endpoint", "`max_age$jR": 10886400 }, { "`url$jR": "https://example.com/hpkp-reports", "`group$jR": "hpkp-endpoint", "`max_age$jR": 10886400 } `Report-To$h: { "`group$jR": "csp-endpoint", "`max_age$jR": 10886400, "`endpoints$jR": [ { "`url$jR": "https://example.com/csp-reports" } ] }, { "`group$jR": "hpkp-endpoint", "`max_age$jR": 10886400, "`endpoints$jR": [ { "`url$jR": "https://example.com/hpkp-reports" } ] }
ことに加え、次の~headerで,[ ~CSP, ~HPKP ]報告を別々に命名された報告先へ指向ける: ◎ And the following headers, which direct CSP and HPKP reports to those named endpoint:
`Content-Security-Policy$h: ...; `report-to$dir=csp-endpoint `Public-Key-Pins$h: ...; report-to=hpkp-endpoint
2. 各種~概念
2.1. ~client
`~client@ ( `client^en )は、[ 特定0の生成元 ]と[ `報告先$の集合 ]との関係性を表現する。 ◎ A client represents a particular origin’s relationship to a set of endpoints.
各 `~client$は、次のものを持つ: ◎ ↓
- `生成元@cL ( `origin^en ) ◎ Each client has an origin,\
- `生成元$を与える。 ◎ which is an origin.
- `報告先~group~list@cL ( `endpoint-groups list^en ) ◎ Each client has an endpoint-groups list,\
- いくつかの`報告先~group$からなる~list — それらの`名前$eGは互いに異なってい~MUST(これは、`要請に対する応答~用に報告先たちを処理する$~algoにより,保証される — `Report-To$h ~header内に,同じ名前の~entryが複数~在る場合、最初のものだけ保たれる。) ◎ which is a list of endpoint groups, each of which MUST have a distinct name. (The algorithm in §3.2 Process reporting endpoints for response to request guarantees this by keeping the first entry in a Report-To header with a particular name.)
2.2. 報告先~group
`報告先~group@ ( `endpoint group^en )は、失敗時の予備( `backup and failover^en )の目的で,一緒に利用される`報告先$の集合である。 ◎ An endpoint group is a set of endpoints that will be used together for backup and failover purposes.
各 `報告先~group$は、次のものを持つ: ◎ ↓
- `名前@eG ( `name^en ) ◎ Each endpoint group has a name,\
- ~ASCII文字列。 ◎ which is an ASCII string.
- `報告先~list@eG ( `endpoints list^en ) ◎ Each endpoint group has an endpoints list,\
- いくつかの`報告先$からなる~list。 ◎ which is a list of endpoints.
- `下位domain~flag@eG ( `subdomains flag^en ) ◎ Each endpoint group has a subdomains flag,\
- 次のいずれか ⇒ `include^l, `exclude^l ◎ which is either "include" or "exclude".
- `有効秒数@eG ( `ttl^en) ◎ Each endpoint group has a ttl\
- この~groupが当の`生成元$用に有効であり続ける秒数を表現する。 【 `ttl^en は `time to live^en の略語】 ◎ representing the number of seconds the group remains valid for an origin.
- `作成時刻@eG ( `creation^en ) ◎ Each endpoint group has a creation\
- 当の`生成元$用に この~groupが追加された時点を表す時刻印。 ◎ which is the timestamp at which the group was added to an origin.
`報告先~group$は、所与の時点で次を満たすならば `失効した@ とされる ⇒ `作成時刻$eGから`有効秒数$eGだけ~~経過した時点は、所与の時点より過去を表現する ◎ An endpoint group is expired if its creation plus its ttl represents a time in the past.
2.3. 報告先
`報告先@ ( `endpoint^en )は、[ 特定0の`生成元$用の`報告$ ]の送信-先になり得る【~network端点の】所在を与える。 ◎ An endpoint is location to which reports for a particular origin may be sent.
各 `報告先$は、次のものを持つ: ◎ ↓
- `~url@eP ◎ Each endpoint has a url,\
- `~URL$ ◎ which is a URL.
- `優先度@eP ◎ Each endpoint has a priority,\
- 非負~整数 【低いほど優先される。】 ◎ which is a non-negative integer.
- `重み@eP ◎ Each endpoint has a weight,\
- 非負~整数 ◎ which is a non-negative integer.
- `失敗数@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.
- `再試行時刻@eP ( `retry_after^en ) ◎ Each endpoint has a retry_after,\
- ~NULL, または 次にいつ送達を再試行するかを表す時刻†。 ◎ which is either null, or a timestamp after which delivery should be retried.
- 【 原文では “時刻印(具体的な時刻)” と記されているが、この仕様の中では,抽象的な時刻(ある時点からの相対的な時間~差)に解釈しても不都合はない。 】
`報告先$は、所与の時点で[ その`再試行時刻$ePが ~NULL でない, かつ未来の時刻を表現する ]ならば, `処理待ち@eP にあるとされる。 ◎ An endpoint is pending if its retry_after is not null, and represents a time in the future.
2.4. 報告~種別
`報告~種別@ は、空でない文字列であり,`報告$の`本体$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.
注記: § 種別:廃止予定に,`報告~種別$の定義~例がある。 ◎ Note: See §6.1 Deprecation as an example report type definition.
2.5. 報告
`報告@ ( `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 節を見よ。 ◎ Note: We strip the username, password, and fragment from this serialized URL. See §10.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.
- `~group名@rP ( `group^en ) ◎ Each report has a group,\
- この報告の送信-先となる[ 当の`生成元$【この報告の`~url$rPの生成元?】の`報告先~group$の`名前$eG ]を表現している文字列。 ◎ which is a string representing the name of the origin’s endpoint group 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.6. 蓄積
適合~UAは `報告用~cache@ を供さ~MUST。 それは、 ~websiteが[ 自身の`生成元$に結付けるよう,~UAに指図した`報告先~group$の集合 ],および[ 送達~用に~queueされる`報告$の集合 ]を保守する蓄積の仕組みである。 ◎ A conformant user agent MUST provide a reporting cache, which is a storage mechanism that maintains a set of endpoint groups that websites have instructed the user agent to associate with their origins, and a set of reports which are queued for delivery.
この蓄積の仕組みは、[ 不透明, かつ ~vendor特有の, かつ ~webには公開されない ]が,[ この文書が定義する各種~algoにて利用されることになる,次の各種~method ]を供さ~MUST: ◎ This storage mechanism is opaque, vendor-specific, and not exposed to the web, but it MUST provide the following methods which will be used in the algorithms this document defines:
- `~client$を[ 挿入-/更新-/除去- ]する。 ◎ Insert, update, and remove clients.
- 送達~用に`報告$を[ ~enqueue/~dequeue ]する。 ◎ Enqueue and dequeue reports for delivery.
- ある`生成元$用の`~client$~objの~listを検索取得する。 ◎ Retrieve a list of client objects for an origin.
- ~queueされている`報告$~objの~listを検索取得する。 ◎ Retrieve a list of queued report objects.
- ~cacheを消去する。 ◎ Clear the cache.
2.7. ~failoverと負荷~分散-法
`報告先~group$を成す`報告先$のうち,`優先度$ePが互いに同じものたちは、1 つの `~failover-class@ を形成する。 ~failover-classにより、開発者は,報告先として予備の収集器を供せるようになる — それは、[ すべての首~収集器(`優先度$eP値が予備のそれより低い`報告先$)が失敗した場合に限り,報告を受信することになる。 ◎ The endpoints in an endpoint group that all have the same priority form a failover class. Failover classes allow the developer to provide backup collectors (those with higher priority values) that will only receive reports if all of the primary collectors (those with lower priority values) fail.
開発者は、`~failover-class$内の各`報告先$に`重み$ePをアテガえる — それは、報告の流通が それらの報告先にどう分散されるかを決定する。 ◎ Developers can assign each endpoint in a failover class a weight, which determines how report traffic is balanced across the failover class.
これらの規則を実装する~algoは、`~groupから報告先を選ぶ$,にて述べる。 ◎ The algorithm that implements these rules is described in §4.3 Choose an endpoint from a group.
注記: `優先度$eP, `重み$eP の意味論は、それぞれ~DNS `SRV record$ における対応する~field 【 `Priority^en, `Weight^en 】 と同じである。 ◎ Note: The priority and weight fields have the same semantics as the corresponding fields in a DNS SRV record.
注記: ~failoverと負荷~分散-法は、一般に,この仕様の報告処理の外側で有用になる特色機能である。 報告処理は、報告先が選定されたなら報告を実際に~uploadするのを `FETCH$r ~APIに移譲する。 将来において, `FETCH^r ~APIが要請の[ ~failoverと負荷~分散-法 ]用に~native~supportを追加したなら、報告処理~APIの将来~versionは,この “あつらえの” 仕組みに代えて それを利用するよう更新されることになる。 ◎ Note: Failover and load balancing is a feature that would be generally useful outside of Reporting. Reporting delegates to the [FETCH] API to actually upload reports once an endpoint has been selected. If, in the future, the Fetch API adds native support for failover and load balancing of requests, a future version of the Reporting API will be updated to use it instead of this bespoke mechanism.
3. 報告先への送達
~serverは、 `Report-To$h ~HTTP応答~headerを介して,自身が制御する生成元~用に報告先の集合を定義して~MAY。 この仕組みは `Report-To^h ~HTTP 応答~header 節に定義され、その処理は`要請に対する応答~用に報告先たちを処理する$節にて定義される。 ◎ A server MAY define a set of reporting endpoints for an origin it controls via the Report-To HTTP response header field. This mechanism is defined in §3.1 The Report-To HTTP Response Header Field, and its processing in §3.2 Process reporting endpoints for response to request.
3.1. `Report-To^h ~HTTP 応答~header
`Report-To@h ~HTTP応答~headerは、ある生成元~用に報告先を格納するよう,~UAに指図する。 この~headerの文法は、次の~ABNFで表現される `RFC5234$r : ◎ The Report-To HTTP response header field instructs the user agent to store reporting endpoints for an origin. The header is represented by the following ABNF grammar [RFC5234]:
Report-To = json-field-value ; †
† `HTTP-JFV$r の 2 節, `RFC8259$r の 2 節を見よ。 ◎ ; See Section 2 of [[HTTP-JFV]], and Section 2 of [[RFC8259]]
~headerの値は、 `HTTP-JFV$r の 4 節にしたがって,~JSON~objの~arrayとして解釈される。 ◎ The header’s value is interpreted as an array of JSON objects, as described in Section 4 of [HTTP-JFV].
結果の~array内の各~objは、報告を送達してよいとされる`報告先~group$を定義し,`要請に対する応答~用に報告先たちを処理する$~algo内で構文解析されることになる。 ◎ Each object in the array defines an endpoint group to which reports may be delivered, and will be parsed as defined in §3.2 Process reporting endpoints for response to request.
以下の各 下位節では、~header値により定義される,各~JSON~obj内の既知の~memberの初期~集合を定義する。 この文書の将来~versionは、その種の~memberを追加で定義し得る。 よって~UAは、~headerの構文解析-時には,未知の~memberを無視し~MUST。 ◎ The following subsections define the initial set of known members in each JSON object the header’s value defines. Future versions of this document may define additional such members, and user agents MUST ignore unknown members when parsing the header.
3.1.1. `group^mb ~member
`group@jR ~member(省略可)は、その値で与えられる`名前$eGを,所与の`報告先~group$に結付ける。 値は、~string型で~MUST — 他の場合,構文解析-~errorになる。 ~obj内に名前 `group^l の~memberが無い場合、当の`報告先~group$の`名前$eGは `default^l にされる。 ◎ The OPTIONAL group member is a string that associates a name with the endpoint group. The member’s value MUST be a string; any other type will result in a parse error. If no member named "group" is present in the object, the endpoint group will be given the name "default".
3.1.2. `include_subdomains^mb ~member
`include_subdomains@jR ~member(省略可)は,~boolean値を与える — [ ~obj内にこの~memberは在する, かつ その値 ~EQ ~T ]ならば、当の`報告先~group$を,[[ 現在の`生成元$ ]の `host$m【`~host$?】 ]の[ すべての下位domain ]用の報告-先として可能化する。 他の場合、当の`報告先~group$は,下位domain用には可能化されないことになる。 ◎ The OPTIONAL include_subdomains member is a boolean that enables this endpoint group for all subdomains of the current origin’s host. If no member named "include_subdomains" is present in the object, or its value is not "true", the endpoint group will not be enabled for subdomains.
3.1.3. `max_age^mb ~member
`max_age@jR ~member(必須)は、`報告先~group$の存続期間を,非負~整数による秒数として定義する。 値は、~number型, かつ非負で~MUST — 他の場合、構文解析-~errorになる。 ◎ The REQUIRED max_age member defines the endpoint group’s lifetime, as a non-negative integer number of seconds. The member’s value MUST be a non-negative number; any other type will result in a parse error.
値に 0 を与えた場合、当の`報告先~group$は,~UAの`報告用~cache$から除去されることになる。 ◎ A value of "0" will cause the endpoint group to be removed from the user agent’s reporting cache.
3.1.4. `endpoints^mb ~member
`endpoints@jR ~member(必須)は、当の`報告先~group$に属するとされる`報告先$の~listを定義する。 値は、いくつかの~JSON~objからなる~arrayで~MUST。 ◎ The REQUIRED endpoints member defines the list of endpoints that belong to this endpoint group. The member’s value MUST be an array of JSON objects.
以下の各 下位節では、この~array内の各~obj用の既知の~memberの初期~集合を定義する。 この文書の将来~versionは、その種の~memberを追加で定義し得る。 よって~UAは、この~array内の各~要素の構文解析-時には,未知の~memberは無視し~MUST。 ◎ The following subsections define the initial set of known members in each JSON object in the array. Future versions of this document may define additional such members, and user agents MUST ignore unknown members when parsing the elements of the array.
3.1.4.1. `endpoints.url^mb ~member
`url@jR ~member(必須)は、`報告先$の所在を定義する。 値は、~string型で~MUST — 他の場合,構文解析-~errorになる。 ◎ The REQUIRED url member is a string that defines the location of the endpoint. The member’s value MUST be a string; any other type will result in a parse error.
加えて,その~memberの値が表現する~URLは、`信用に価し得る$もので~MUST。 保安的でない報告先は、無視されることになる。 `SECURE-CONTEXTS$r ◎ Moreover, the URL that the member’s value represents MUST be potentially trustworthy [SECURE-CONTEXTS]. Non-secure endpoints will be ignored.
3.1.4.2. `endpoints.priority^mb ~member
`priority@jR ~member(省略可)は、`報告先$はどの`~failover-class$に所属するかを定義する。 在するならば、その値は非負~整数で~MUST — 他の値を指定した場合、構文解析-~errorになる。 ◎ The OPTIONAL priority member is a number that defines which failover class the endpoint belongs to. The member’s value, if present, MUST be a non-negative integer; any other type will result in a parse error.
3.1.4.3. `endpoints.weight^mb ~member
`weight@jR ~member(省略可)は、`報告先$が所属する`~failover-class$用の負荷~分散-法を定義する。 在するならば、その値は非負~整数で~MUST — 他の値を指定した場合、構文解析-~errorになる。 ◎ The OPTIONAL weight member is a number that defines load balancing for the failover class that the endpoint belongs to. The member’s value, if present, MUST be a non-negative integer; any other type will result in a parse error.
3.2. 要請に対する応答~用に報告先たちを処理する
この~algoは、所与の ( `応答$ %応答, `要請$ %要請 ) に対し, %要請 の`生成元$用の[ `報告先$の~list, `報告先~group$の~list ]を抽出した上で、それに則って`報告用~cache$を更新する。 ◎ Given a response (response) and a request (request), this algorithm extracts a list of endpoints and endpoint groups for the request’s origin, and updates the reporting cache accordingly.
【 %要請 が~algoのどこからも利用されていない。 この~algoの最後の段の “`生成元$” は、要請の`生成元$rqなのか? 】
注記: この~algoは、`~main~fetch$ `FETCH$r の段 13 あたりで~callされ、 %応答 が保安的に送達された場合に限り,`報告用~cache$を更新する。 ◎ Note: This algorithm is called from around step 13 of main fetch [FETCH], and only updates the reporting cache if the response has been delivered securely.
`Fetch monkey patching. Talk to Anne.^en 【実際にはまだ `FETCH$r に統合されていない( “段 13 あたり” には該当する記述はまだない)。】
- %生成元 ~LET %応答 の`~url$rsの`生成元$url ◎ ↓
- ~IF[ %応答 の`~HTTPS状態$rs ~NEQ `modern^l ]~AND[ %生成元 は`信用に価し得る$でない ] ⇒ ~RET ◎ Abort these steps if any of the following conditions are true: • response’s HTTPS state is not "modern", and the origin of response’s url is not potentially trustworthy. • response’s header list does not contain a header whose name is "Report-To". ◎ Let origin be the origin of response’s url.
- %~header値 ~LET %応答 の`~header~list$rs内に `Report-To$h を`名前に持つ~header$が[ あれば その`値$hd / なければ ε ] ◎ Let header be the value of the header in response’s header list whose name is "Report-To".
- ~IF[ %~header値 ~EQ ε ] ⇒ ~RET ◎ ↑↑
- %~list ~LET[ `HTTP-JFV$r の 4 節に定義される~algo ]にしたがって, %~header値 を構文解析した結果 ◎ Let list be the result of executing the algorithm defined in Section 4 of [HTTP-JFV] on header.\
- ~IF[ %~list ~EQ `~error^i ] ⇒ ~RET ◎ If that algorithm results in an error, abort these steps.
- %~group~list ~LET 空~list ◎ Let groups be an empty list.
-
%~list 内の ~EACH( %~item ) に対し: ◎ For each item in list:
- %有効秒数 ~LET [[ %~item に `max_age$jR ~memberは在する, かつ その値は~numberである ]ならば その値 / ~ELSE_ ε ] ◎ ↓
- ~IF[ %有効秒数 ~EQ ε ] ⇒ ~CONTINUE ◎ If item has no member named "max_age", or that member’s value is not a number, skip to the next item.
- %報告先たち ~LET [[ %~item に `endpoints$jR ~memberは在する, かつ その値は~arrayである ]ならば その値 / ~ELSE_ ε ] ◎ ↓
- ~IF[ %報告先たち ~EQ ε ] ⇒ ~CONTINUE ◎ If item has no member named "endpoints", or that member’s value is not an array, skip to the next item.
- %名前 ~LET [[ %~item に `group$jR ~memberは在する ]ならば その値 / ~ELSE_ `default^l ] ◎ Let name be item’s "group" member’s value if present, and "default" otherwise.
- ~IF[ %~group~list 内に[ `名前$eG ~EQ %名前 ]なる`報告先~group$は在る ] ⇒ ~CONTINUE ◎ If there is already an endpoint group in groups whose name is name, skip to the next item.
- %報告先~list ~LET 空~list ◎ Let endpoints be an empty list.
-
%報告先たち 内の ~EACH( %報告先~item ) に対し: ◎ For each endpoint item in the value of item’s "endpoints" member:
- %url ~LET [ %報告先~item に `url$jR ~memberは在するならば その値 / ~ELSE_ ε ] ◎ ↓
- ~IF[ %url ~EQ ε ]~OR[ %url は~stringでない ] ⇒ ~CONTINUE ◎ If endpoint item has no member named "url", or that member’s value is not a string, skip to the next endpoint item.
- %優先度 ~LET [ %報告先~item に `priority$jR ~memberは在するならば その値 / ~ELSE_ 1 ] ◎ ↓
- ~IF[ %優先度 は非負~整数でない ] ⇒ ~CONTINUE ◎ If endpoint item has a member named "priority", whose value is not a non-negative integer, skip to the next endpoint item.
- %重み ~LET [ %報告先~item に `weight$jR ~memberは在するならば その値 / ~ELSE_ 1 ] ◎ ↓
- ~IF[ %重み は非負~整数でない ] ⇒ ~CONTINUE ◎ If endpoint item has a member named "weight", whose value is not a non-negative integer, skip to the next endpoint item.
- %報告先~list に次のようにされた`報告先$を付加する ⇒# `~url$eP ~SET `~URL構文解析する$( %url ), `優先度$eP ~SET %優先度, `重み$eP ~SET %重み, `失敗数$eP ~SET 0, `再試行時刻$eP ~SET ~NULL ◎ Let endpoint be a new endpoint whose properties are set as follows: ◎ url • The result of executing the URL parser on endpoint item’s "url" member’s value. priority • The value of the endpoint item’s "priority" member, if present; 1 otherwise. weight • The value of the endpoint item’s "weight" member, if present; 1 otherwise. failures • 0 retry_after • null ◎ Add endpoint to endpoints.
- %下位domain~flag ~LET [ 次が満たされるならば `include^l / ~ELSE_ `exclude^l ] ⇒ %~item 内に `include_subdomains$jR ~memberは在する, かつ その値 ~EQ ~T ◎ ↓
- %~group~list に[ 次のように設定された 新たな`報告先~group$ ]を付加する ⇒# `名前$eG ~SET %名前, `下位domain~flag$eG ~SET %下位domain~flag, `有効秒数$eG ~SET %有効秒数, `作成時刻$eG ~SET 現在の時刻印, `報告先~list$eG ~SET %報告先~list ◎ Let group be a new endpoint group whose properties are set as follows: ◎ name • name subdomains • "include" if item has a member named "include_subdomains" whose value is true, "exclude" otherwise. ttl • item’s "max_age" member’s value. creation • The current timestamp endpoints • endpoints ◎ Add group to groups.
- %~client ~LET 次のようにされた 新たな`~client$ ⇒# `生成元$cL ~SET %生成元, `報告先~group~list$cL ~SET %~group~list ◎ Let client be a new client whose properties are set as follows: ◎ origin • origin endpoint-groups • groups
- ~IF[ `報告用~cache$内に,`生成元$に対応する`~client$は在る ] ⇒ その~clientを %~client に置換する ◎ If there is already an entry in the reporting cache for origin, replace it with client.\
- ~ELSE ⇒ `報告用~cache$に,`生成元$に対応する`~client$として %~client を挿入する ◎ Otherwise, insert client into the reporting cache for origin.
4. 報告の送達
様々な特色機能が、時を経るにつれ,~UAの`報告用~cache$内に`報告$の~listを~queueすることになる。 ~UAは、定期的に,現在 処理待ちにある報告の~listを取り出して,それらに結付けられている報告先へ送達することになる。 この文書は、~UAが従うべき~scheduleは定義しない。 ~UAは、報告を適時に送達するための文脈的~情報を — 利用者~体験への影響0との兼ね合いも含め — 十分に有するものと見做される。 ◎ Over time, various features will queue up a list of reports in the user agent’s reporting cache. The user agent will periodically grab the list of currently pending 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 a 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.
4.1. 媒体~型
`application/reports+json^c が、指定された報告先へ報告を `POST^hm するときに利用される媒体~型を与える。 ◎ The media type used when POSTing reports to a specified endpoint is application/reports+json.
4.2. 報告先~group用に~dataを~queueする
次の~algoは、所与の ⇒# %~data ( 直列化-可能な~obj ), %種別 ( 文字列 ), %報告先~group ( 文字列 ), %設定群 ( `環境~設定群~obj$ ), %url ( `~URL$, 省略時は ε ) ◎終 から,`報告$を作成した上で、それを未来に送達するために`報告用~cache$の~queueに追加する: ◎ Given a serializable object (data), a string (type), another string (endpoint group), an environment settings object (settings), and an optional URL (url), the following algorithm will create a report, and add it to reporting cache’s queue for future delivery.
- %報告 ~LET 次のように初期化された 新たな`報告$~obj ⇒# `本体$rP ~SET %~data, `~UA$rP ~SET `navigator.userAgent$m の現在の値, `~group名$rP ~SET %報告先~group, `種別$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 group • endpoint group 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.
- %報告 を`報告用~cache$に付加する ◎ Append report to the reporting cache.
- %環境 ~LET %設定群 の`~realm実行~文脈$の`~realm$の`~ES大域~環境$ ◎ Let environment be settings’s realm execution context’s realm’s ECMAScript global environment.
- `報告用~観測器に通知する$( %環境, %報告 ) ◎ Execute §5.2 Notify reporting observers on environment with report with environment and report.
注記: `報告用~観測器$が観測するのは、同じ`環境~設定群~obj$からの報告に限られる。 ◎ Note: reporting observers can only observe reports from the same environment settings object.
注記: 報告~内の直列化された~URLからは,[ `~username$url, `~password$url, `素片$url ]は剥取られる。 能力~URL 節を見よ。 ◎ Note: We strip the username, password, and fragment from the serialized URL in the report. See §10.1 Capability URLs.
注記: ~UAは、何か事由があれば,報告を却下して~MAY。 具体例として、この~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は、`報告用~観測器$と相互作用するべきでないので,上の最後の段を走らすべきでない。 ◎ Note: Non user agent clients (with no JavaScript engine) should not interact with reporting observers, and thus should return in step 6.
4.3. %~group から報告先を選ぶ
注記: この~algoは、~DNS `SRV record$ 用に利用される ~target選定~algo と同じである。 ◎ Note: This algorithm is the same as the target selection algorithm used for DNS SRV records.
この~algoは、所与の ( `報告先~group$ %~group ) に対し, %~group 内に適格な`報告先$があれば、それらから一つを それぞれの[ `優先度$eP, `重み$eP ]を織り込んだ上で選ぶ: ◎ Given an endpoint group (group), this algorithm chooses an arbitrary eligible endpoint from the group, if there is one, taking into account the priority and weight of the endpoints.
-
~IF[ %~group は`失効した$ ] ⇒ ~RET ~NULL ◎ If group is expired, return null.
注記: この事例では、~UAは,`~client$から %~group を除去して~MAY。 あるいは、後で一括して`~garbage収集-$して~MAY。 ◎ Note: In this case, the user agent MAY remove group from its client, or it may wait and collect garbage en masse at some point in the future as described in §7.2 Garbage Collection.
- %報告先~list ~LET %~group の`報告先~list$eGの複製 ◎ Let endpoints be a copy of group’s endpoints list.
- %報告先~list から`処理待ち$ePにある報告先をすべて除去する ◎ Remove every endpoint from endpoints that is pending.
- ~IF[ %報告先~list は空である ] ⇒ ~RET ~NULL ◎ If endpoints is empty, return null.
- %優先度 ~LET [ %報告先~list 内の各~報告先の`優先度$eP ]の最小~値 ◎ Let priority be the minimum priority value of each endpoint in endpoints.
- %報告先~list から[ `優先度$eP ~NEQ %優先度 ]なる報告先をすべて除去する ◎ Remove every endpoint from endpoints whose priority value is not equal to priority.
- ~IF[ %報告先~list は空である ] ⇒ ~RET ~NULL ◎ If endpoints is empty, return null.
- %総-重み ~LET [ %報告先~list 内の各~報告先の`重み$eP ]の総和 ◎ Let total weight be the sum of the weight value of each endpoint in endpoints.
- %R ~LET 次を満たすように~randomに選んだ数 ⇒ 0 ~LTE %R ~LT %総-重み ◎ Let weight be a random number ≥ 0 and < total weight.
-
%報告先~list 内の ~EACH( %報告先 ) に対し:
- %総-重み ~DECBY %報告先 の`重み$eP ◎
- ~IF[ %総-重み ~LTE %R ] ⇒ ~RET %報告先
- ~Assert: この段に達することはない。 ◎ It should not be possible to fall through to here, since the random number chosen earlier will be less than total weight.
4.4. 報告の送信-法
~UAは、報告を送信するときは,次の手続きを実行する: ◎ A user agent sends reports by executing the following steps:
【 この訳では、以下に現れる “~map” に対し,`有順序~map$に定義される記法を流用するが、~map内を反復する際の順序については(有意になるかもしれないが),原文には言及されていない。 】
- %報告たち ~LET [ `報告用~cache$内に~queueされた`報告$~objの~list ]の複製 ◎ Let reports be a copy of the list of queued report objects in reporting cache.
- %報告先~map ~LET 空~map — これは、`報告先$を[ `報告$~objの~list ]に対応付ける ◎ Let endpoint map be an empty map of endpoint objects to lists of report objects.
-
%報告たち 内の ~EACH( %報告 ) に対し: ◎ For each report in reports:
-
%報告先 ~LET 次の下位手続きを走らせた結果 ◎ ↓↓
- %生成元 ~LET %報告 の`~url$rPの`生成元$ ◎ Let origin be the origin of report’s url.
- %~client ~LET `報告用~cache$内の, %生成元 に対応する`~client$ ◎ Let client be the entry in the reporting cache for origin.
- %報告先~候補 ~LET [ 次を満たす`報告先~group$ %G は在るならば `~groupから報告先を選ぶ$( %G ) / ~ELSE_ ~NULL ] ⇒ [ %G ~IN %~client の`報告先~group~list$cL ]~AND[ %G の`名前$eG ~EQ %報告 の`~group名$rP ] ◎ If there exists an endpoint group (group) in client’s endpoint-groups list whose name is report’s group: • Let endpoint be the result of executing §4.3 Choose an endpoint from a group on group.
- ~IF[ %報告先~候補 ~NEQ ~NULL ] ⇒ ~RET %報告先~候補 ◎ If endpoint is a not null: • Append report to endpoint map’s list of reports for endpoint. • Skip to the next report.
-
%生成元 に`上位domain合致-$する `RFC6797$r ~EACH( %親~生成元 ) に対し 【順序も有意になるが、言及されていない】 : ◎ For each parent origin that is a superdomain match for origin [RFC6797]:
- %~client ~LET `報告用~cache$内の, %親~生成元 に対応する`~client$ ◎ Let client be the entry in the reporting cache for parent origin.
- %報告先~候補 ~LET [ 次を満たす`報告先~group$ %G は在るならば `~groupから報告先を選ぶ$( %G ) / ~ELSE_ ~NULL ] ⇒ [ %G ~IN %~client の`報告先~group~list$cL ]~AND[ %G の`名前$eG ~EQ %報告 の`~group名$rP ]~AND[ %G の`下位domain~flag$eG ~EQ `exclude^l ] ◎ If there exists an endpoint group (group) in client’s endpoint-groups list whose name is report’s group and whose subdomains flag is "include": • Let endpoint be the result of executing §4.3 Choose an endpoint from a group on group.
- ~IF[ %報告先~候補 ~NEQ ~NULL ] ⇒ ~RET %報告先~候補 ◎ If endpoint is an endpoint: • Append report to endpoint map’s list of reports for endpoint. • Skip to the next report.
- ~IF[ %報告先 ~NEQ ~NULL ] ⇒ %報告 を %報告先~map[ %報告先 ] に付加する ◎ ↑↑
- ~ELSE ( %報告 はどの`報告先$にも合致しなかった) ⇒ ~UAは、この時点で`報告用~cache$から直に %報告 を除去して~MAY。 あるいは,高~負荷のときは、未来のある時点に`~garbage収集-$するよう それを待機して~MAY。 ◎ If we reach this step, the report did not match any endpoint and the user agent MAY remove report from the reporting cache directly. Depending on load, the user agent MAY instead wait for §7.2 Garbage Collection at some point in the future.
-
-
%報告先~map を成す ~EACH( %報告先 → %報告たち ) ) に対し: ◎ For each (endpoint, reports) pair in endpoint map:
- %生成元~map ~LET 空~map — これは、`生成元$を[ `報告$~objの~list ]に対応付ける ◎ Let origin map be an empty map of origins to lists of report objects.
-
%報告たち 内の ~EACH( %報告 ) に対し:
- %生成元 ~LET %報告 の`~url$rPの`生成元$
- ~IF[ %生成元~map[ %生成元 ] ~EQ ε ] ⇒ %生成元~map[ %生成元 ] ~SET 新たな~list
- %生成元~map[ %生成元 ] に %報告 を付加する
-
%生成元~map を成す ~EACH( %生成元 → %生成元~用の報告たち ) に対し — 次の手続きは非同期に実行する: ◎ For each (origin, per-origin reports) pair in origin map, execute the following steps asynchronously:
- %結果 ~LET `報告先へ報告たちを送達するよう試みる$( %報告先, %生成元, %生成元~用の報告たち ) ◎ Let result be the result of executing §4.5 Attempt to deliver reports to endpoint on endpoint, origin, and per-origin reports.
-
~IF[ %結果 ~EQ `成功^i ]: ◎ If result is "Success":
- %報告先 の ⇒# `失敗数$eP ~SET 0, `再試行時刻$eP ~SET ~NULL ◎ Set endpoint’s failures to 0, and its retry_after to null.
- %報告たち 内の ~EACH( `報告$ %報告 ) に対し ⇒ `報告用~cache$から %報告 を除去する ◎ Remove each report in reports from the reporting cache.
-
~ELIF[ %結果 ~EQ `報告先を除去する^i ] ⇒ `報告用~cache$から %報告先 を除去する ◎ Otherwise, if result is "Remove Endpoint": • Remove endpoint from the reporting cache.
注記: %報告たち は、他の`報告先$への送達があり得るので`報告用~cache$に残り続ける。 ◎ Note: reports remain in the reporting cache for potential delivery to other endpoints.
-
~ELSE( %結果 ~EQ `失敗^i ): ◎ Otherwise (if result is "Failure"):
- %報告先 の`失敗数$eP ~INCBY 1 ◎ Increment endpoint’s failures.
-
%報告先 の`再試行時刻$eP ~SET ~UAが選ぶ未来のある時点 ◎ Set endpoint’s retry_after to a point in the future which the user agent chooses.
注記: ここでは,どの時点か~~決定するための 特定0の~algoは指定しないが、~UAには,次のようにすることが奨励される ⇒ [ 何らかの類の — 失敗数に応じて再試行~期間を増やすような — べき乗打ち切り待機法( `exponential backoff^en )~algo ]を使役した上で、その増分に~randomなゆらぎも加えて,[ 一時的な失敗により,同じ~scheduleで再試行されている他の報告と衝突する ]ことはないことを確保する。 ◎ Note: We don’t specify a particular algorithm here, but user agents are encouraged to employ some sort of exponential backoff algorithm which increases the retry period with the number of failures, with the addition of some random jitter to ensure that temporary failures don’t lead to a crush of reports all being retried on the same schedule.
良い~algoを述べる適度な文献を示す。 何もなければ wikipedia 。 ◎ Add in a reasonable reference describing a good algorithm. Wikipedia, if nothing else.
注記: ~UAは、収集された[ 報告/報告先 ]のうち一部のみ送達するよう試みることにしても~MAY(例えば、一度にすべての報告を送信すると 帯域幅を過度に消費するとき, 等々)。 報告が~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 when they’re successfully delivered, skipped reports will simply be delivered later.
4.5. %報告先 へ %報告たち を送達するよう試みる
この~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.
- %~collection ~LET 新たな~ES `Array^jT ~obj `ECMA-262$r ◎ Let collection be a new ECMAScript Array object [ECMA-262].
-
%報告たち 内の ~EACH( %報告 ) に対し: ◎ For each report in reports:
-
%~data ~LET 次のようにされた~propを有する新たな~ES `Object^jT `ECMA-262$r ⇒# `age^c ~SET %報告 の`時刻印$rPから現在の時刻までの ~millisecondsによる時間差, `type^c ~SET %報告 の`種別$rP, `url^c ~SET %報告 の`~url$rP, `user_agent^c ~SET %報告 の`~UA$rP, `body^c ~SET %報告 の`本体$rP ◎ Let data be a new ECMAScript Object with the following properties [ECMA-262]: ◎ 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
注記: ~skewの対象である~client側の時計には,依拠できないので、絶対的な時刻印ではなく, `age^c 属性を送達する。 時計~skew 節も見よ ◎ Note: Client clocks are unreliable and subject to skew. We therefore deliver an age attribute rather than an absolute timestamp. See also §11.2 Clock Skew
- %報告 の`試行数$rP ~INCBY 1 ◎ Increment report’s attempts.
- %~collection に %~data を付加する ◎ Append data to collection.
-
-
%要請 ~LET 次のようにされた新たな`要請$ `FETCH$r ⇒# `~url$rq ~SET %報告先 の`~url$eP, `生成元$rq ~SET %生成元, `~header~list$rq ~SET `~header$( `Content-Type^h / `application/reports+json^l ) のみからなる新たな`~header~list$, `~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, `非安全-要請~flag$rq ~SET ~ON, `資格証~mode$rq ~SET `include^l, `本体$rq ~SET %~collection に対し `JSON.stringify()$m ~algo `ECMA-262$r を適用した結果
【† 原文は “`skip-service-worker flag^en ~SET ~ON” だが、 `FETCH$r の更新により, “~sw~mode” に置き換えられた。 】【†† 原文には重複して “行先 ~SET 空~文字列” もあるが、更新-時の削除漏れであろう。 】
◎ Let request be a new request with the following properties [FETCH]: ◎ 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" skip-service-worker flag • Set. initiator • "" destination • "report" destination • "" mode • "cors" unsafe-request flag • set credentials • "include" body • The string resulting from executing the JSON.stringify() algorithm on collection [ECMA-262] - %要請 を`~fetch$する`~taskを~queueする$ ◎ Queue a task to fetch request.
- %応答 を待機する【?】 ◎ Wait for a response (response).
- ~RET %応答 の`~status$rsに応じて,次に与える値 ⇒# `~ok~status$( `200^st 〜 `299^st )であるならば `成功^i / `410$st ( Gone ) `RFC7231$r ならば `報告先を除去する^i / ~ELSE_ `失敗^i ◎ If response’s status is an OK status (200-299), return "Success". ◎ If response’s status is 410 Gone [RFC7231], return "Remove Endpoint". ◎ Return "Failure".
5. 報告用~観測器
`報告用~観測器@ ( `reporting observer^en )は、一部の種別の`報告$を,~JSから観測する — それは、~JSにおいては `ReportingObserver$I ~objにより表現される。 ◎ A reporting observer observes some types of reports from JavaScript, and is represented in JavaScript by the ReportingObserver object.
各`~ES大域~環境$には、次に挙げるものが結付けられる: ◎ ↓
- `登録-済み観測器~list@ ( `registered reporting observer list^en ) ◎ Each ECMAScript global environment 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 ECMAScript global environment has a report buffer,\
- この`~ES大域~環境$内で生成された`報告$たちが成す`~list$。 初期~時には空とする。 報告たちは、生成された順序で格納される。 ◎ which is a list of reports that have been generated in that ECMAScript global environment. This list is initially empty, and the reports are stored in the same order in which they are generated.
- 注記: `報告~buffer$の目的は、`報告用~観測器$が,自身が作成される前に生成された報告を( ~optionsの `buffered$m を介して)観測できるようにすることである。 例えば、報告には,観測器が作成-可能になる前に生成されるものもある — ~page読込みの早い段階や,報告を観測したいと望む~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.
5.1. ~interface `ReportingObserver^I
interface `ReportBody@I { }; interface `Report$I { readonly attribute `DOMString$ `type$m; readonly attribute `DOMString$ `url$m; readonly attribute `ReportBody$I? `body$m; }; [`Constructor$m(`ReportingObserverCallback$I %callback, optional `ReportingObserverOptions$I %options)] interface `ReportingObserver@I { void `observe$m(); void `disconnect$m(); `ReportList$I `takeRecords$m(); }; callback `ReportingObserverCallback@I = void (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.
- `~options@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
- この構築子の被呼出時には、次を走らせ~MUST ⇒ ~RET 次のようにされた新たな `ReportingObserver$I ~obj ⇒# `~callback$ob ~SET %callback, `~options$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
-
被呼出時には、次を走らせ~MUST: ◎ The observe() method, when invoked, must run these steps:
- %環境 ~LET 此れが属する`~ES大域~環境$ ◎ Let environment be the ECMAScript global environment associated with the context object.
- %環境 の`登録-済み観測器~list$に此れを`付加する$set ◎ Append the context object to the registered reporting observer list of its associated ECMAScript global environment.
- ~IF[ 此れの `~options$ob の `buffered$m ~EQ ~F ] ⇒ ~RET ◎ If the context object’s buffered option is false, return.
- 此れの`~options$ob の `buffered$m ~SET ~F ◎ Set context object’s buffered option to false.
- %環境 の`報告~buffer$内の ~EACH( %報告 ) に対し ⇒ `観測器に報告を追加する$( %報告, 此れ ) ◎ For each report in the report buffer associated with environment, execute §5.3 Add report to observer with report and the context object.
- `disconnect()@m
- 被呼出時には、次を走らせ~MUST ⇒ 此れが属する`~ES大域~環境$の`登録-済み観測器~list$から此れを`除去する$ ◎ The disconnect() method, when invoked, must run these steps: • If the context object is not registered, return. • Remove the context object from the registered reporting observer list of its associated ECMAScript global environment.
- `takeRecords()@m
-
被呼出時には、次を走らせ~MUST: ◎ The takeRecords() method, when invoked, must run these steps:
- %報告たち ~LET 此れの`報告~queue$obを`~cloneする$ ◎ Let reports be a copy of the context object’s report queue.
- 此れの`報告~queue$obを`空にする$ ◎ Empty the context object’s report queue.
- ~RET %報告たち ◎ Return reports.
5.2. 報告用~観測器に通知する
この~algoは、報告の内容を`登録-済み$の`報告用~観測器$から可用にする。 それは、所与の ( `~ES大域~環境$ %環境, `報告$ %報告 ) に対し,次を走らす: ◎ This algorithm makes report’s contents available to any registered reporting observers on the provided ECMAScript global environment environment.
- %環境 に`登録-済み$の ~EACH( `報告用~観測器$ %観測器 ) に対し ⇒ `観測器に報告を追加する$( %報告, %観測器 ) ◎ For each ReportingObserver observer registered with environment, execute §5.3 Add report to observer on report and observer.
- %~buffer ~LET %環境 の`報告~buffer$ ◎ ↓
- %~buffer に %報告 を`付加する$ ◎ Append report to the report buffer associated with environment.
- ~IF[ %~buffer の`~size$ ~GT 100 ] ⇒ %~buffer から先頭の~itemを`除去する$ ◎ If the report buffer now contains more than 100 reports, remove the item at the beginning of the report buffer.
5.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.
- ~IF[ %観測器 の`~options$ob の `types$m ~memberは在する ]~AND[ %種別 ~NIN その~memberの値 ] ⇒ ~RET ◎ If observer’s options has a non-empty types member which does not contain report’s type, return.
-
%観測器 の`報告~queue$obに[ 次のように初期化された新たな `Report$I ]を`付加する$ ⇒# `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? ◎ ↑Append r to observer’s report queue.
- ~IF[ %観測器 の`報告~queue$obの`~size$ ~EQ 1 ] ⇒ 次を走らす`~taskを~queueする$ ⇒ `報告用~観測器を呼出す$( %観測器 が属する`~ES大域~環境$ ) ◎ If the size of observer’s report queue is 1, Queue a task to §5.4 Invoke reporting observers with notify list with a copy of the registered reporting observer list of the ECMAScript global environment associated with observer.
5.4. 報告用~観測器を呼出す
この~algoは、それまでに観測された各[ 挙動の報告 ]用に,観測器の`~callback$obを呼出す。 それは、所与の ( %環境 ) に対し,次を走らす: ◎ This algorithm invokes observer callback functions for reports of previously observed behavior.
-
%環境 の`登録-済み観測器~list$内の ~EACH( %観測器 ) に対し: ◎ For each ReportingObserver observer in notify list:
- ~IF[ %観測器 の`報告~queue$obは空である ] ⇒ ~CONTINUE ◎ If observer’s report queue is empty, then continue.
- %報告たち ~LET %観測器 の`報告~queue$obを`~cloneする$ ◎ Let reports be a copy of observer’s report queue
- %観測器 の`報告~queue$obを`空にする$ ◎ Empty observer’s report queue
- `~callbackを呼出す$( %観測器 の`~callback$ob, « %報告たち, %観測器 », %観測器 ) ⇒ 例外が投出されたときは ⇒ その`例外を報告する$ 【反復は継続する】 ◎ Invoke observer’s callback with a list of arguments consisting of reports and observer, and observer as the callback this value. If this throws an exception, report the exception.
6. 報告~種別
6.1. 廃止予定
`廃止予定~報告@ ( `deprecation report^en )は、[ ~browserにて利用されている ある~APIや特色機能が、未来における~browserの更新-時には働かなくなる ]ものと予期されることを指示する。 ◎ Deprecation reports indicate that a browser API or feature has been used which is expected to stop working in a future update to the browser.
`廃止予定~報告$の`報告~種別$は、 `deprecation^l とする。 ◎ Deprecation reports have the report type "deprecation".
`廃止予定~報告$は、`報告用~観測器から可視$である。 ◎ Deprecation reports are visible to ReportingObservers.
interface `DeprecationReportBody@I : `ReportBody$I { readonly attribute `DOMString$ `id@mRB; readonly attribute `Date$? `anticipatedRemoval@mRB; readonly attribute `DOMString$ `message@mRB; readonly attribute `DOMString$? `sourceFile@mRB; readonly attribute `long$? `lineNumber@mRB; readonly attribute `long$? `columnNumber@mRB; };
`廃止予定~報告$の`本体$rPは、~JS内では `DeprecationReportBody$I により表現され,次に挙げる~fieldを包含する: ◎ A deprecation report’s body, represented in JavaScript by DeprecationReportBody, contains the following fields:
- `id@jRB ⇒ 実装~定義な文字列であって,除去されることになる特色機能や~APIを識別するもの。 この文字列は、関係する報告を~group化したり数えるために利用できる。 ◎ id: an implementation-defined string identifying the feature or API that will be removed. This string can be used for grouping and counting related reports.
- `anticipatedRemoval@jRB ⇒ ~JS `Date$jT ~obj( ISO 8601 文字列として具現化される) — [ 指定された~APIが無い~browser~version( “`beta^en” や他の `pre-release channels^en は除外する)は、概ね,いつ一般に可用になるか ]を指示する。 この値は、警告を~sortしたり優先度をあてがうために利用されるべきである。 未知の場合、この~fieldは ~NULL にされるべきである — その場合、廃止予定~報告の優先度は低いもの(実際には除去されないこともある)と見なされるべきである。 ◎ anticipatedRemoval: A JavaScript Date object (rendered as an ISO 8601 string) indicating roughly when the browser version without the specified API will be generally available (excluding "beta" or other pre-release channels). This value should be used to sort or prioritize warnings. If unknown, this field should be null, and the deprecation should be considered low priority (removal may not actually occur).
- `message@jRB ⇒ 人から読める詳細を伴う文字列 — 概して,開発者~consoleに表示されるものに合致するような。 ~messageは、所与の `id$jRB ごとに一意になることは保証されない(例:~APIがどう利用されていたかなどの,追加の文脈を包含することもある)。 ◎ message: A human-readable string with details typically matching what would be displayed on the developer console. The message is not guaranteed to be unique for a given id (eg. it may contain additional context on how the API was used).
- `sourceFile@jRB ⇒# 指示された~APIを最初に利用した~fileが既知ならば それ / ~ELSE_ ~NULL ◎ sourceFile: If known, the file which first used the indicated API, or null otherwise.
- `lineNumber@jRB ⇒# `sourceFile$jRB 内で 指示された~APIを最初に利用した箇所が既知ならば その行番号 / ~ELSE_ ~NULL ◎ lineNumber: If known, the line number in sourceFile where the indicated API was first used, or null otherwise.
- `columnNumber@jRB ⇒# `sourceFile$jRB 内で 指示された~APIを最初に利用した箇所が既知ならば その列番号 / ~ELSE_ ~NULL ◎ columnNumber: If known, the column number in sourceFile where the indicated API was first used, or null otherwise.
6.2. 介入
`介入~報告@ ( `intervention report^en )は、[ ~UAは、~appからの要請を尊守しないものと裁定した 【 “~UAは~appに介入した” 】 ]ことを指示する(例えば[ 保安/処理能/利用者を煩わせる ]などの理由から)。 報告を成す~propたちは、 `anticipatedRemoval$jRB が不在であることを除き,`廃止予定~報告$用のものと同じにされている。 ◎ Intervention reports indicate that a user agent has decided not to honor a request made by the application (e.g. for security, performance or user annoyance reasons). Note that the report properties are the same as those for deprecation reports, except for the absence of anticipatedRemoval.
`介入~報告$の`報告~種別$は、 `intervention^l とする。 ◎ Intervention reports have the report type "intervention".
`介入~報告$は、`報告用~観測器から可視$である。 ◎ Intervention reports are visible to ReportingObservers.
interface `InterventionReportBody@I : `ReportBody$I { readonly attribute `DOMString$ `id@mIB; readonly attribute `DOMString$ `message@mIB; readonly attribute `DOMString$? `sourceFile@mIB; readonly attribute `long$? `lineNumber@mIB; readonly attribute `long$? `columnNumber@mIB; };
`介入~報告$の`本体$rPは、~JS内では `InterventionReportBody$I により表現され,次に挙げる~fieldを包含する: ◎ An intervention report’s body, represented in JavaScript by InterventionReportBody, contains the following fields:
- `id@jIB ⇒ 実装~定義な文字列であって,生じた特定の介入を識別するもの。 この文字列は、関係する報告を~group化したり数えるために利用できる。 ◎ id: an implementation-defined string identifying the specific intervention that occurred. This string can be used for grouping and counting related reports.
- `message@jIB ⇒ 人から読める詳細を伴う文字列 — 概して,開発者~consoleに表示されるものに合致するような。 ~messageが所与の `id$jIB ごとに一意になることは保証されない(何が介入に導いたかについての追加の文脈を包含することもある)。 ◎ message: A human-readable string with details typically matching what would be displayed on the developer console. The message is not guaranteed to be unique for a given id (e.g. it may contain additional context on what led to the intervention).
- `sourceFile@jIB ⇒# 指示された~APIを最初に利用した~fileが既知ならば それ / ~ELSE_ ~NULL ◎ sourceFile: If known, the file which first used the indicated API, or null otherwise.
- `lineNumber@jIB ⇒# `sourceFile$jIB 内の(介入を促した)~offending挙動が既知ならば、その行番号 / ~ELSE_ ~NULL ◎ lineNumber: If known, the line number in sourceFile of the offending behavior (which prompted the intervention), or null otherwise.
- `columnNumber@jIB ⇒# `sourceFile$jIB 内の(介入を促した)~offending挙動が既知ならば、その列番号 / ~ELSE_ ~NULL ◎ columnNumber: If known, the column number in sourceFile of the offending behavior (which prompted the intervention), or null otherwise.
7. 実装にあたっての考慮点
7.1. 送達
開発者にアリな限り素早く~feedbackを供するため、~UAは,アリな限り早く報告を送達するよう試みるべきである。 しかしながら,これには、利用者への影響0との兼ね合いも加味される — 利用者が~~優先される。 そのことを念頭に、~UAは、利用者の活動や文脈について自身が有する知識に基づいて,報告の送達を延期して~MAY。 ◎ 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.
不必要な~data~costを防止するため、~UAは、報告の送達を 利用者にとって~networkが高速で軽くなるまで,まるごと保留することを選んで~MAY。 ◎ 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は、生成元に応じて報告の優先度を~~操作して~MAY(おそらく,利用者が最も頻繁に訪問する生成元を優先する?) ◎ The user agent MAY choose to prioritize reports from particular origins over others (perhaps those that the user visits most often?)
7.2. ~garbage収集
~UAは、`報告用~cache$内に在る[ `報告$ / `報告先~group$ / `報告先$ ]を定期的に巡回した上で,関連しなくなったものは破棄するべきである。 これらには、次が含まれる: ◎ Periodically, the user agent SHOULD walk through the cached reports and endpoints, and discard those that are no longer relevant. These include:
-
次のいずれかを満たす`報告先~group$:
- `失効した$もの ◎ endpoint groups which are expired
- ある任意の期間(一週間くらい?)利用されていないもの ◎ endpoint groups which have not been used in some arbitrary period of time (perhaps a ~week?)
- `失敗数$ePが[ ~UA定義な閾値( 5 回くらいが適度?) ]を超過したもの ◎ endpoints whose failures exceed some user-agent-defined threshold (~5 seems reasonable)
-
次のいずれかを満たす`報告$:
- `試行数$rPが[ ~UA定義な閾値( 5 回くらいが適度?) ]を超過したもの ◎ reports whose attempts 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.
8. 報告の見本
POST / HTTP/1.1 Host: example.com ... Content-Type: application/reports+json [{ "type": "csp", "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", "directive": "script-src", "policy": "script-src 'self'; object-src 'none'", "status": 200, "referrer": "https://evil.com/" } }, { "type": "hpkp", "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" "include-subdomains": false, "served-certificate-chain": [ "-----BEGIN CERTIFICATE-----\n MIIEBDCCAuygAwIBAgIDAjppMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT\n ... HFa9llF7b1cq26KqltyMdMKVvvBulRP/F/A8rLIQjcxz++iPAsbw+zOzlTvjwsto\n WHPbqCRiOwY1nQ2pM714A5AuTHhdUDqB1O6gyHA43LL5Z/qHQF1hwFGPa4NrzQU6\n yuGnBXj8ytqU0CwIPX4WecigUCAkVDNx\n -----END CERTIFICATE-----", ... ] } }, { "type": "nel", "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": { "referrer": "https://www.example.com/", "server-ip": "234.233.232.231", "protocol": "", "status-code": 0, "elapsed-time": 143, "age": 0, "type": "http.dns.name_not_resolved" } }]
9. 自動化
この文書は、[ ~UAによる自動化/~appを~testする ]目的で, `WebDriver$r 仕様~用に いくつかの`拡張~command$wdを定義する。 ◎ For the purposes of user-agent automation and application testing, this document defines a number of extension commands for the [WebDriver] specification.
9.1. ~test報告を生成する
`拡張~command$wd `Generate Test Report@ は、`報告$の生成を,~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$wdは、以下に従って定義される: ◎ The extension command is defined as follows:
dictionary `GenerateTestReportParameters@I { required `DOMString$ `message@mTR; `DOMString$ `group@mTR; };
~HTTP~method | 接頭辞 | 名前 |
---|---|---|
`POST^c | `/session/{session id}/reporting^c | `generate_test_report^c |
`remote end steps$wd は、次を走らす: ◎ The remote end steps are:
- ~IF[ %parameters は ~JSON Object【?】 でない ] ⇒ ~RET 次を伴う`~WebDriver~error$wd ⇒ `~WebDriver~error~code$wd ~SET `invalid argument$wd ◎ If parameters is not a JSON Object, return a WebDriver error with WebDriver error code invalid argument.
- %~message ~LET 次を遂行した結果 ⇒ `trying$wd to get %parameters’s `message$mTR property ◎ Let message be the result of trying to get parameters’s message property.
- ~IF[ %~message ~EQ ~NULL ] ⇒ ~RET 次を伴う`~WebDriver~error$wd ⇒ `~WebDriver~error~code$wd ~SET `invalid argument$wd ◎ If message is null, return a WebDriver error with WebDriver error code invalid argument.
- %~group ~LET 次を遂行した結果 ⇒ `trying$wd to get %parameters’s `group$mTR property ◎ Let group be the result of trying to get parameters’s group property.
- ~IF[ %~group ~EQ ~NULL ] ⇒ %~group ~SET `default^l ◎ If group is null, set group to "default".
- %本体 ~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 `現在の閲覧~文脈$wdの`環境~設定群~obj$にて`作動中の文書$ ◎ Let settings be the environment settings object of the current browsing context’s active document.
- `報告先~group用に~dataを~queueする$( %本体, `test^l, %~group, %設定群 ) ◎ Execute §4.2 Queue data as type for endpoint group on settings with body, "test", group, and settings.
- ~RET 次を伴う `success^en ⇒ ~data ~SET ~NULL ◎ Return success with data null.
10. 保安~上の考慮点
10.1. 能力~URL
~URLには,それ自体が有価値なものもある。 そのような~URLが,この仕様の報告処理の仕組みを介して漏洩される可能性を軽減するため、`報告$の出自者として格納される~URLからは,[ 資格証, `素片$url ]の~dataは剥取られる。 しかしながら,特色機能により、そのような~dataが 報告の`本体$rPを介して意図せず漏洩される可能性も,依然としてある。 実装者は、報告の本体に包含された~URLに対しても,同様に剥取られることを確保するべきである。 ◎ Some URLs are valuable in and of themselves. To mitigate the possibility that such URLs will be leaked via this reporting mechanism, we strip out credential information and fragment data from the URL we store as a report’s originator. It is still possible, however, for a feature to unintentionally leak such data via a report’s body. Implementers SHOULD ensure that URLs contained in a report’s body are similarly stripped.
11. ~privacy上の考慮点
11.1. ~network漏洩
この報告処理の仕組みは帯域外であり,~pageが開かれていることに依拠しないので、 利用者が[ ある~network上にいる間に生成された報告が,別の~network上にいる間に送信される ]ことも — 報告の送信-元~pageが明示的に開かれていなくとも — まったくアリになる。 ◎ Because this reporting mechanism is out-of-band, and doesn’t rely on a page being open, 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, even if they don’t explicitly open the page from which the report was sent.
軽減策を考慮する。 例えば、ある~networkを別のへ変更したときに,報告を落とすこともできるような。 BackgroundSync/issues#107 ◎ Consider mitigations. For example, we could drop reports if we change from one network to another. <https://github.com/w3c/BackgroundSync/issues/107>
11.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.
11.3. 非同一生成元の相関
複数の生成元がすべて同じ報告先を利用する場合、その報告先は,[ それぞれから生成元~付きの報告を受信する ]ことになるので、特定0の利用者がある~websiteの集合とやりとりしたことを学習できることになる。 これは、[ 協同する複数の生成元による,同じ情報を追跡する能 ]がある現状を,より悪化させるものには見えない。 それは、[ 今日における `<img>^c でアリなもの ]以上の新たな追跡~能を是認するものではない。 ◎ 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.
11.4. 下位domain
この仕様は、~host上の~~任意の資源が[ その~hostや, その各 下位domain ]用の報告先の集合を宣言できるようにする。 それ自体には( 報告用~cacheの消去-法 節に注記するものを超えるような)~privacy上の含意はない — 報告先~自身は,どのような実の動作もとらず、特色機能は,これらの報告先を明示的に利用して~opt-intoする必要があるので。 それらの特色機能には,まず間違いなく~privacy上の含意があるので、それらが生成元~境界を超えて可能化されるべきかどうかは,注意深く考慮するべきである。 ◎ This specification allows any resource on a host to declare a set of reporting endpoints for that host and each of its subdomains. This doesn’t have privacy implications in and of itself (beyond those noted in §11.5 Clearing the reporting cache), as the reporting endpoints themselves don’t take any real action, as features will need to opt-into using these reporting endpoints explicitly. Those features certainly will have privacy implications, and should carefully consider whether they should be enabled across origin boundaries.
11.5. 報告用~cacheの消去-法
~UAの`報告用~cache$は、利用者の~webにおける活動についての~dataを包含するので、~UAは,この~dataを注意深く取扱うべきである。 特に、[ ~site~data, 閲覧~履歴, 閲覧~cache, これらに類するもの ]を消去する能を,利用者に供する~UAは、`報告用~cache$も消去し~MUST。 これには、処理待ちの報告たちに加え,それらの送信-先の報告先たちも含まれることに注意。 両者とも消去され~MUST。 ◎ A user agent’s reporting cache contains data about a user’s activity on the web, and user agents ought to handle this data carefully. In particular, if a user agent gives users the ability to clear their site data, browsing history, browsing cache, or similar, the user agent MUST also clear the reporting cache. Note that this includes both the pending reports themselves, as well as the endpoints to which they would be sent. Both MUST be cleared.
11.6. 報告処理の不能化-法
報告処理は、ある~~範囲までは,公共性に関わる。 報告が送達されることは、総じて,誰にとっても有用であろう。 ~bugを修正できる開発者には,直接的な便益があり、それにより利用者たちが楽しむ~siteも,より安定的かつ楽しめるものになるので、利用者も間接的な便益を得ることになる。 具体例として,~CSPは、~siteの防壁~内にありうる穴について開発者に警戒を促すことにより,~XSS攻撃に対する集団免疫 【`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は,利用者が報告処理を適度な粒度で不能化できるようにし~MUST。 ◎ 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].
12. IANA 考慮点
12.1. `Report-To^h
恒久的~message~header登記簿は、次の登録で更新されるべきである: `RFC3864$r ◎ The permanent message header field registry should be updated with the following registration: [RFC3864]
~header名前 | `Report-To^h |
---|---|
適用-可能な~protocol | http |
~status | 標準 |
~~著作/変更管理者 | W3C |
仕様~文書 | この仕様( `Report-To^h ~HTTP 応答~header 節を見よ) |
12.2. `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
- `application/json^l 媒体~型~用に指定されものに一致する。 `RFC8259$r を見よ。 ◎ Encoding considerations are identical to those specified for the "application/json" media type. See [RFC8259].
- 保安~上の考慮点 ◎ Security considerations
- §10 Security Considerations を見よ。 ◎ See §10 Security Considerations.
- 相互運用性の考慮点 ◎ Interoperability considerations
- この文書は、適合する~messageの形式と その解釈を指定する。 ◎ This document specifies the format of conforming messages and the interpretation thereof.
- 公表された仕様 ◎ Published specification
- § 媒体~型 ◎ §4.1 Media Type
- この媒体~型を利用する応用 ◎ 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.