1. 序論
~INFORMATIVE文書から発行された要請や, 文書から他所への~naviには、 `Referer$h ~headerが結付けられる。 `Referer$h ~headerは,[ ~linkに~link型 `noreferrer$v を伴わせる ]ことで抑止できるが、作者は,いくつかの理由で この~headerをより直接的に制御したいと望むかもしれない: ◎ Requests made from a document, and for navigations away from that document are associated with a Referer header. While the header can be suppressed for links with the noreferrer link type, authors might wish to control the Referer header more directly for a number of reasons:
1.1. ~privacy
ある~SNSが,各~利用者に~profile~pageを供していて、利用者は,自身の~profile~pageに,好みの~bandへの~hyperlinkを追加するとする。 ~SNSは、他の利用者がそれらの~hyperlinkを追ったときに,利用者の~profile~URLを~bandの~web~siteには漏洩させたくないと望むかもしれない( ~profile~URLは、~profileの所有者の識別情報を露呈するかもしれないので)。 ◎ A social networking site has a profile page for each of its users, and users add hyperlinks from their profile page to their favorite bands. The social networking site might not wish to leak the user’s profile URL to the band web sites when other users follow those hyperlinks (because the profile URLs might reveal the identity of the owner of the profile).
しかしながら,その種の~linkが~SNSを出自にしていることを — ~linkに包含されている特定の利用者の~profileは露呈することなく — ~bandの~web~siteに伝えたいと望む~SNSもあるかもしれない。 ◎ Some social networking sites, however, might wish to inform the band web sites that the links originated from the social networking site but not reveal which specific user’s profile contained the links.
1.2. 保安
~HTTPSと[ ~URLに基づく~session識別子 ]を利用する~web~appは、[ ~URL内の,利用者の~session識別子 ]を漏洩させることなく,他の~web~site上の~HTTPS資源へ~linkしたいと望むかもしれない。 ◎ A web application uses HTTPS and a URL-based session identifier. The web application might wish to link to HTTPS resources on other web sites without leaking the user’s session identifier in the URL.
~URL自体を,何らかの能力を是認する仕組みとして利用する~web~appもある。 ~referrerを制御できれば、この種の~URL( capability URL )が `Referer^h ~headerを介して漏洩されるのを防止する一助になる。 `CAPABILITY-URLS$r ◎ Alternatively, a web application may use URLs which themselves grant some capability. Controlling the referrer can help prevent these capability URLs from leaking via referrer headers. [CAPABILITY-URLS]
能力~URLは,他の仕方でも漏洩され得るので、~referrerを制御するだけでは,漏洩-の~~可能性すべてを制御するには十分でないことに注意。 ◎ Note that there are other ways for capability URLs to leak, and controlling the referrer is not enough to control all those potential leaks.
1.3. ~trackback
~HTTPS越しに~hostされている~blogは、~HTTP越しに~hostされている~blogへ~linkして,~trackback~linkを受信したいと望むかもしれない。 ◎ A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and receive trackback links.
2. ~~主要な概念と各種用語
- `~referrer施策$
- `~referrer施策$は、[ 下位資源の`~fetch$, ~prefetch, ~naviの遂行- ]時に `Referer$h ~headerを拡充するときに利用される~algoを改変する。 この文書は、`~referrer施策$に対する種々の挙動を定義する。 ◎ A referrer policy modifies the algorithm used to populate the Referer header when fetching subresources, prefetching, or performing navigations. This document defines the various behaviors for each referrer policy.
- どの`環境~設定群~obj$も,[[ その~objを`~client$rqとするような,`要請$ ]すべてに対し,既定で利用される`~referrer施策$ ]を得るための~algoを持つ。 ◎ Every environment settings object has an algorithm for obtaining a referrer policy, which is used by default for all requests with that environment settings object as their client.
- `同一生成元~要請@
- `非同一生成元~要請@
- `要請$は、[ その`生成元$rq, その`現在の~url$rqの`生成元$url ]が`同一生成元$であるとき,同一生成元~要請とされ、そうでなければ 非同一生成元~要請とされる。 ◎ A Request request is a same-origin request if request’s origin and the origin of request’s current url are the same. ◎ A Request is a cross-origin request if it is not same-origin.
3. ~referrer施策
`~referrer施策@ は、次のいずれかである ⇒ 空~文字列, `no-referrer^l, `no-referrer-when-downgrade^l, `same-origin^l, `origin^l, `strict-origin^l, `origin-when-cross-origin^l, `strict-origin-when-cross-origin^l, `unsafe-url^l ◎ A referrer policy is the empty string, "no-referrer", "no-referrer-when-downgrade", "same-origin", "origin", "strict-origin", "origin-when-cross-origin", "strict-origin-when-cross-origin", or "unsafe-url".
enum `ReferrerPolicy@I { "", "no-referrer", "no-referrer-when-downgrade", "same-origin", "origin", "strict-origin", "origin-when-cross-origin", "strict-origin-when-cross-origin", "unsafe-url" };
以下の各 下位~節にて、各種`~referrer施策$(空~文字列も含む)を説明する。 それらの効果を評価するための詳細な~algoは、 ~Fetchとの統合, 各種~algo 各 節に与えられる。 ◎ Each possible referrer policy is explained below. A detailed algorithm for evaluating their effect is given in the §5 Integration with Fetch and §8 Algorithms sections.
注記: `環境~設定群~obj$が与える~referrer施策は、その`環境~設定群~obj$が`要請~client$rqとして利用されるときに,要請に対する既定の基準~施策を供する。 この施策は、特定の要請に対しては, `noreferrer$v ~link型の様な仕組みを介して,締付けられることもある。 ◎ Note: The referrer policy for an environment settings object provides a default baseline policy for requests when that environment settings object is used as a request client. This policy may be tightened for specific requests via mechanisms like the noreferrer link type.
3.1. `no-referrer^l
最も単純な施策は、 `no-referrer$l である。 それは、特定0の`要請~client$rqから発行され,任意の`生成元$へ送信される どの要請にも,~referrer情報は伴われないことを指定する。 `Referer$h ~headerは、まるごと省略されることになる。 ◎ The simplest policy is "no-referrer", which specifies that no referrer information is to be sent along with requests made from a particular request client to any origin. The header will be omitted entirely.
`https://example.com/page.html^s に在る文書に `no-referrer$l 施策が設定されている場合、 `https://example.com/^s への~naviに際しては(あるいは他のどの~URLであれ), `Referer$h ~headerは送信されないことになる。 ◎ If a document at https://example.com/page.html sets a policy of "no-referrer", then navigations to https://example.com/ (or any other URL) would send no Referer header.
3.2. `no-referrer-when-downgrade^l
`no-referrer-when-downgrade$l 施策は、次のいずれかに該当する要請を発行するときには,~referrer情報として全部的~URLを送信するよう指定する:
- `~TLSで保護され$た `環境~設定群~obj$から`信用に価し得る~URL$への要請。
- `~TLSで保護され$てない`~client$rqから~~任意の`生成元$への要請。
他方、[ `~TLSで保護され$た`~client$rqから`信用に価し得ない~URL$への要請 ]は,~referrer情報を包含せず、 `Referer$h ~headerは,送信されないことになる。 ◎ Requests from TLS-protected clients to non- potentially trustworthy URLs, on the other hand, will contain no referrer information. A Referer HTTP header will not be sent.
`https://example.com/page.html^s に在る文書に `no-referrer-when-downgrade$l 施策が設定されている場合、 `https://not.example.com/^s への~naviに際しては, `https://example.com/page.html^s を値に伴う `Referer$h ~headerを送信することになる — 両~資源とも,その生成元は`信用に価し得る~URL$なので。 ◎ If a document at https://example.com/page.html sets a policy of "no-referrer-when-downgrade", then navigations to https://not.example.com/ would send a Referer HTTP header with a value of https://example.com/page.html, as neither resource’s origin is a non-potentially trustworthy URL.
その同じ~pageから `http://not.example.com/^s への~naviに際しては, `Referer$h ~headerは送信されないことになる。 ◎ Navigations from that same page to http://not.example.com/ would send no Referer header.
これは、他のどの施策も指定されていない場合における,~UAの既定の挙動である。 ◎ This is a user agent’s default behavior, if no policy is otherwise specified.
3.3. `same-origin^l
`same-origin$l 施策は、特定0の`~client$rqから`同一生成元~要請$を発行するときに,[ 全部的~URLを`~referrer用に削った$結果 ]を~referrer情報として送信するよう指定する。 ◎ The "same-origin" policy specifies that a full URL, stripped for use as a referrer, is sent as referrer information when making same-origin requests from a particular client.
他方,`非同一生成元~要請$は、~referrer情報を包含せず, `Referer$h ~headerは送信されないことになる。 ◎ Cross-origin requests, on the other hand, will contain no referrer information. A Referer HTTP header will not be sent.
`https://example.com/page.html^s に在る文書に `same-origin$l 施策が設定されている場合、 `https://example.com/not-page.html^s への~naviに際しては, `https://example.com/page.html^s を値に伴う `Referer$h ~headerを送信することになる。 ◎ If a document at https://example.com/page.html sets a policy of "same-origin", then navigations to https://example.com/not-page.html would send a Referer header with a value of https://example.com/page.html.
その同じ~pageから `https://not.example.com/^s への~naviに際しては, `Referer$h ~headerは送信されないことになる。 ◎ Navigations from that same page to https://not.example.com/ would send no Referer header.
3.4. `origin^l
`origin$l 施策は、特定0の`~client$rqから[ `同一生成元~要請$ / `非同一生成元~要請$ ]を発行するときに,[ `要請~client$rqの`生成元$enVのみを`直列化-$oした結果 ]を~referrer情報として送信するよう指定する。 ◎ The "origin" policy specifies that only the ASCII serialization of the origin of the request client is sent as referrer information when making both same-origin requests and cross-origin requests from a particular client.
注記: 生成元に対する この直列化は, `https://example.com^s の様になる。 `Referer^h ~header内に妥当な~URLが送信されることを確保するため、~UAは,生成元に 文字 U+002F SOLIDUS( `/^l )を付加することになる( `https://example.com/^s の様に)。 ◎ Note: The serialization of an origin looks like https://example.com. To ensure that a valid URL is sent in the 'Referer' header, user agents will append a U+002F SOLIDUS ("/") character to the origin (e.g. https://example.com/).
注記: `origin$l 施策の下では、~HTTPS~referrerの生成元は,暗号化されていない~HTTP要請の一部として,~network越しに送信されるようになる。 `strict-origin$l 施策がこの懸念に取組む。 ◎ Note: The "origin" policy causes the origin of HTTPS referrers to be sent over the network as part of unencrypted HTTP requests. The "strict-origin" policy addresses this concern.
`https://example.com/page.html^s に在る文書に `origin$l 施策が設定されている場合、 どの`生成元$であれ,そこへの~naviは、`信用に価し得る~URL$でない場合でも `https://example.com/^s を値に伴う `Referer$h ~headerを送信することになる。 ◎ If a document at https://example.com/page.html sets a policy of "origin", then navigations to any origin would send a Referer header with a value of https://example.com/, even to URLs that are not potentially trustworthy URL.
3.5. `strict-origin^l
`strict-origin$l 施策は、次のいずれかに該当する要請を発行するときに,`要請~client$rqの`生成元$enVを`直列化-$oした結果を送信する: ◎ The "strict-origin" policy sends the ASCII serialization of the origin of the request client when making requests:
- `~TLSで保護され$ている`環境~設定群~obj$から `信用に価し得る~URL$への要請。 ◎ from a TLS-protected environment settings object to a potentially trustworthy URL, and
- `~TLSで保護され$ていない`環境~設定群~obj$から 任意の`生成元$への要請。 ◎ from non-TLS-protected environment settings objects to any origin.
他方,`~TLSで保護され$ている`要請~client$rqから `信用に価し得ない~URL$への要請は、~referrer情報を包含せず, `Referer$h ~headerは送信されないことになる。 ◎ Requests from TLS-protected request clients to non- potentially trustworthy URLs, on the other hand, will contain no referrer information. A Referer HTTP header will not be sent.
`https://example.com/page.html^s に在る文書に `strict-origin$l 施策が設定されている場合、 `https://not.example.com^s への~naviに際しては, `https://example.com/^s を値に伴う `Referer$h ~headerを送信することになる。 ◎ If a document at https://example.com/page.html sets a policy of "strict-origin", then navigations to https://not.example.com would send a Referer header with a value of https://example.com/.
同じ~pageから `http://not.example.com^s への~naviに際しては, `Referer$h ~headerを送信しないことになる。 ◎ Navigations from that same page to http://not.example.com would send no Referer header.
`http://example.com/page.html^s に在る文書に `strict-origin$l 施策が設定されている場合、 `http://not.example.com^s / `https://example.com^s への~naviに際しては, `http://example.com/^s を値に伴う `Referer$h ~headerを送信することになる。 ◎ If a document at http://example.com/page.html sets a policy of "strict-origin", then navigations to http://not.example.com or https://example.com would send a Referer header with a value of http://example.com/.
3.6. `origin-when-cross-origin^l
`origin-when-cross-origin$l 施策は、特定0の`~client$rqから,次のものを~referrer情報として送信するよう指定する:
- `同一生成元~要請$を発行するときには、全部的~URLを`~referrer用に削った$結果。
- `非同一生成元~要請$を発行するときには、`要請~client$rqの`生成元$enVのみを`直列化-$oした結果。
注記: `origin-when-cross-origin$l 施策に対しては、~protocol昇格も考慮される — 例えば, `http://example.com/^s から `https://example.com/^s への要請は、`非同一生成元~要請$になる。 ◎ Note: For the "origin-when-cross-origin" policy, we also consider protocol upgrades, e.g. requests from http://example.com/ to https://example.com/, to be cross-origin requests.
注記: `origin-when-cross-origin$l 施策の下では、 ~HTTPS~referrerの生成元は,暗号化されていない~HTTP要請の一部として,~network越しに送信されるようになる。 `strict-origin-when-cross-origin$l 施策がこの懸念に取組む。 ◎ Note: The "origin-when-cross-origin" policy causes the origin of HTTPS referrers to be sent over the network as part of unencrypted HTTP requests. The "strict-origin-when-cross-origin" policy addresses this concern.
`https://example.com/page.html^s に在る文書に `origin-when-cross-origin$l 施策が設定されている場合、 `https://example.com/not-page.html^s への~naviに際しては, `https://example.com/page.html^s を値に伴う `Referer$h ~headerを送信することになる。 ◎ If a document at https://example.com/page.html sets a policy of "origin-when-cross-origin", then navigations to https://example.com/not-page.html would send a Referer header with a value of https://example.com/page.html.
その同じ~pageから `https://not.example.com/^s への~naviに際しては、 `https://example.com/^s を値に伴う `Referer$h ~headerを送信することになる — `信用に価し得ない~URL$の場合でも同様になる。 ◎ Navigations from that same page to https://not.example.com/ would send a Referer header with a value of https://example.com/, even to URLs that are not potentially trustworthy URLs.
3.7. `strict-origin-when-cross-origin^l
`strict-origin-when-cross-origin$l 施策は、特定0の`要請~client$rqから発行される[ `同一生成元~要請$に対しては,全部的~URLを`~referrer用に削った$結果 / `非同一生成元~要請$に対しては,`要請~client$rqの`生成元$enVのみを`直列化-$oした結果 ]を~referrer情報として送信するよう指定する — 次のいずれかに該当する場合に: ◎ The "strict-origin-when-cross-origin" policy specifies that a full URL, stripped for use as a referrer, is sent as referrer information when making same-origin requests from a particular request client, and only the ASCII serialization of the origin of the request client when making cross-origin requests:
- `~TLSで保護され$ている`環境~設定群~obj$から `信用に価し得る~URL$へ ◎ from a TLS-protected environment settings object to a potentially trustworthy URL, and
- `~TLSで保護され$ていない`環境~設定群~obj$から 任意の`生成元$へ ◎ from non-TLS-protected environment settings objects to any origin.
他方,`~TLSで保護され$ている`~client$rqから `信用に価し得ない~URL$への要請は、~referrer情報を包含せず, `Referer$h ~headerは送信されないことになる。 ◎ Requests from TLS-protected clients to non- potentially trustworthy URLs, on the other hand, will contain no referrer information. A Referer HTTP header will not be sent.
`https://example.com/page.html^s に在る文書に `strict-origin-when-cross-origin$l 施策が設定されている場合、 `https://example.com/not-page.html^s への~naviに際しては, `https://example.com/page.html^s を値に伴う `Referer$h ~headerを送信することになる。 ◎ If a document at https://example.com/page.html sets a policy of "strict-origin-when-cross-origin", then navigations to https://example.com/not-page.html would send a Referer header with a value of https://example.com/page.html.
同じ~pageから `https://not.example.com/^s への~naviに際しては、値 `https://example.com/^s を値に伴う `Referer$h ~headerを送信することになる。 ◎ Navigations from that same page to https://not.example.com/ would send a Referer header with a value of https://example.com/.
同じ~pageから `http://not.example.com/^s への~naviに際しては、 `Referer$h ~headerを送信しないことになる。 ◎ Navigations from that same page to http://not.example.com/ would send no Referer header.
3.8. `unsafe-url^l
`unsafe-url$l 施策は、特定0の`要請~client$rqから発行される[ `非同一生成元~要請$ / `同一生成元~要請$ ]の両者に対し,[ 全部的~URLを`~referrer用に削った$結果 ]を伴わせて送信するよう指定する。 ◎ The "unsafe-url" policy specifies that a full URL, stripped for use as a referrer, is sent along with both cross-origin requests and same-origin requests made from a particular client.
`https://example.com/sekrit.html^s に在る文書に `unsafe-url$l 施策が設定されている場合、 `http://not.example.com/^s への~naviに際しては(あるいは他のどの生成元であれ), `https://example.com/sekrit.html^s を値に伴う `Referer$h ~headerを送信することになる。 ◎ If a document at https://example.com/sekrit.html sets a policy of "unsafe-url", then navigations to http://not.example.com/ (and every other origin) would send a Referer HTTP header with a value of https://example.com/sekrit.html.
注記: この施策は、その名が示すとおり安全でない。 この施策は、`~TLSで保護され$た資源であっても,非保安的~生成元へ向けて,生成元と~pathを漏洩することになる。 そのような施策を ~sensitiveになり得る文書に設定するときは、その影響0を注意深く考慮すること。 ◎ Note: The policy’s name doesn’t lie; it is unsafe. This policy will leak origins and paths from TLS-protected resources to insecure origins. Carefully consider the impact of setting such a policy for potentially sensitive documents.
3.9. 空~文字列
空~文字列は、`~referrer施策$がないことに対応する:
- 他所で定義される`~referrer施策$があれば、それに~fallbackする。
- そのような より高~levelの施策が可用でない場合は、既定の `no-referrer-when-downgrade$l になる。 この既定は、要請の`~referrerを決定する$~algoにて起こる。
`referrerpolicy$a 属性を有さない,~HTML `a$e 要素に対しては、その~referrer施策は 空~文字列になる。 したがって, `a$e 要素に対する~clickにより起動される~navi要請の送信-時には、[ `a$e 要素の`~node文書$の`~referrer施策$doc ]が伴われることになる。 その~referrer施策もまた空~文字列であった場合、要請の`~referrerを決定する$~algoは,それを `no-referrer-when-downgrade$l と同じに扱うことになる。 ◎ Given a HTML a element without any declared referrerpolicy attribute, its referrer policy is the empty string. Thus, navigation requests initiated by clicking on that a element will be sent with the referrer policy of the a element’s node document. If that Document has the empty string as its referrer policy, the §8.3 Determine request’s Referrer algorithm will treat the empty string the same as "no-referrer-when-downgrade".
4. ~referrer施策の送達
`要請$の`~referrer施策$rqは、次のいずれかの仕方で送達される: ◎ A request’s referrer policy is delivered in one of five ways:
- `Referrer-Policy$h ~headerを介して。 ◎ Via the Referrer-Policy HTTP header (defined in §4.1 Delivery via Referrer-Policy header).
- [ 値 `referrer$v をとる `name$a 内容~属性 ]を有する `meta$e 要素を介して。 ◎ Via a meta element with a name of referrer.
-
一部の要素~上の `referrerpolicy@a 内容~属性を介して:
- [ `a$e / `area$e ]要素~上の `referrerpolicy^a 属性
- `img$e 要素~上の `referrerpolicy^a 属性
- `iframe$e 要素~上の `referrerpolicy^a 属性
- `link$e 要素~上の `referrerpolicy^a 属性
- [ `a$e / `area$e / `link$e ]要素~上の `noreferrer$v ~link関係を介して。 ◎ Via the noreferrer link relation on an a, area, or link element.
- 暗黙的に,継承を介して。 ◎ Implicitly, via inheritance.
4.1. `Referrer-Policy^h ~headerを介する送達
`Referrer-Policy@h ~HTTP~headerは、当の被保護~資源の文脈~下で[ 発行される要請 / 作成される`閲覧文脈$ ]において,[ ~UAが その~referrer情報に何を含めるべきか ]を決定する際に適用する~referrer施策を指定する。 ◎ The Referrer-Policy HTTP header specifies the referrer policy that the user agent applies when determining what referrer information should be included with requests made, and with browsing contexts created from the context of the protected resource.
この~headerの名前と値の構文は、次の~ABNF文法に述べる — この~ABNFは、 `RFC5234$r に定義され, `RFC7230$r に定義される #%規則 ~ABNF拡張も利用される: ◎ The syntax for the name and value of the header are described by the following ABNF grammar. ABNF is defined in [RFC5234], and the #rule ABNF extension used below is defined in Section 7 of [RFC7230].
"Referrer-Policy:" 1#(`policy-token$P / `extension-token$P) `policy-token@P = "no-referrer" / "no-referrer-when-downgrade" / "strict-origin" / "strict-origin-when-cross-origin" / "same-origin" / "origin" / "origin-when-cross-origin" / "unsafe-url" `extension-token@P = 1*( `ALPHA$P / "-" )
注記: `Referer^h ~headerは英語として綴りが誤っているが、この~header名は,そうでない。 ◎ Note: The header name does not share the HTTP Referer header’s misspelling.
注記: `extension-token$P は、この~headerに未知の施策~値が含まれていても,~browserが~header全体の構文解析-に失敗しないようにするためにある。 新たな施策~値をどうすれば配備できるかの詳細は、 未知の施策~値 節 に述べる。 ◎ Note: The purpose of extension-token is so that browsers do not fail to parse the entire header field if it includes an unknown policy value. §11.1 Unknown Policy Values describes in greater detail how new policy values can be deployed.
~Fetchとの統合 節, ~HTMLとの統合 節 にて, `Referrer-Policy^h ~headerを処理する方法を述べる。 ◎ §5 Integration with Fetch and §6 Integration with HTML describe how the Referrer-Policy header is processed.
4.1.1. 用法
~INFORMATIVE被保護~資源は、 `Referrer-Policy^h ~headerの値として `no-referrer^c を指定することにより,~referrerの漏洩を防止できる: ◎ A protected resource can prevent referrer leakage by specifying no-referrer as the value of its Referrer-Policy header:
Referrer-Policy: no-referrer
これは、被保護~資源の文脈から発行されるすべての要請の `Referer^h ~headerを空にすることになる。 【 Referer 自体は送信されるのか?】 ◎ This will cause all requests made from the protected resource’s context to have an empty Referer [sic] header.
4.2. `meta^e 要素を介する送達
~INFORMATIVE~HTML標準は、~markupを介して`~referrer施策$を設定できるようにするため、 `meta$e 要素に対する `referrer$v ~keywordを定義している。 ◎ The HTML Standard defines the referrer keyword for the meta element, which allows setting the referrer policy via markup.
4.3. `referrerpolicy^a 内容~属性を介する送達
~INFORMATIVE~HTML標準は、[ その一部の要素に対し適用される,`~referrer施策~属性$の概念 ]を定義している。 例えば: ◎ The HTML Standard defines the concept of referrer policy attributes which applies to several of its elements, for example:
<a href="http://example.com" referrerpolicy="origin">
4.4. 入子の閲覧文脈
~INFORMATIVE~HTML標準と~Fetch標準は、[ `srcdoc$a 属性を有する `iframe$e 要素などの,`応答$から作成されたものでない ]/[ `blob^sc ~URLから作成された ]入子の閲覧文脈に対し,その`~referrer施策$を[ 作成元~閲覧文脈/ `blob^sc ~URL ]から継承する方法を定義している。 ◎ The HTML Standard and Fetch Standard define how nested browsing contexts that are not created from responses, such as iframe elements with their srcdoc attribute set, or created from a blob URL, inherit their referrer policy from the creator browsing context or blob URL.
5. ~Fetchとの統合
~INFORMATIVE~Fetch仕様は、~redirectに追従する前に,要請の~referrer施策を更新できるよう,`~HTTP~redirect~fetch$の最後の手前の段にて[ `~redirect上で要請の~referrer施策を設定する$ ]を~callする。 ◎ The Fetch specification calls out to §8.2 Set request’s referrer policy on redirect before Step 13 of the HTTP-redirect fetch, so that a request’s referrer policy can be updated before following a redirect.
~Fetch仕様は、`~main~fetch$の段 8 にて[ `要請の~referrerを決定-$する ]を~callし、その結果を, %要請 の`~referrer$rqを設定するときに利用する。 ~fetchが、供された~URLの直列化して, %要請 の `Referer^h ~headerを設定する責を負う。 ◎ The Fetch specification calls out to §8.3 Determine request’s Referrer as Step 8 of the Main fetch algorithm, and uses the result to set the request’s referrer property. Fetch is responsible for serializing the URL provided, and setting the `Referer` header on request.
6. ~HTMLとの統合
~INFORMATIVE~HTML標準は、[ (1) `~navi$の間 / (2) `~workerを走らせて$いる間 ]に,[ 受信された応答の `Referrer-Policy^h ~headerから`~referrer施策$を決定した結果 ]を利用して,[ (1) による結果の `Document$I の`~referrer施策$doc / (2) による結果の `WorkerGlobalScope$I の`~referrer施策$wk ]を設定する。 これは、後で,対応する`環境~設定群~obj$により利用される。 この設定群は、自身から起動される`~fetch$の`要請~client$rqとして~~働く。 ◎ The HTML Standard determines the referrer policy of any response received during navigation or while running a worker, and uses the result to set the resulting Document or WorkerGlobalScope's referrer policy. This is later used by the corresponding environment settings object, which serves as a request client for fetches it initiates.
注記: W3C による HTML5 は、[ `referrerpolicy$a 内容~属性 / `referrerPolicy^m ~IDL属性 / `meta$e に対する `referrer$v ~keyword / [ ~naviや, 走っている~worker ]との統合 ]を定義していない。 W3C による HTML5 にもこの仕様を~~働かせるためには、 `HTML$r からこれらを複製する必要がある。 ◎ Note: W3C HTML5 does not define the referrerpolicy content attributes, or referrerPolicy IDL attributes, or the referrer keyword for meta, or the integration with navigation or running a worker. For this spec to make sense with W3C HTML5, those would need to be copied from [HTML].
7. ~CSSとの統合
~CSS標準は、~stylesheetから参照される資源を~fetchする方法を指定していない。 しかしながら,実装は、所与の~stylesheetにより起動される`要請$ %要請 の~referrerに関係する各種~propを,次に従って設定するべきである: ◎ The CSS Standard does not specify how it fetches resources referenced from stylesheets. However, implementations should be sure to set the referrer-related properties of any requests initiated by stylesheets as follows:
-
~IF[ %要請 は`~CSS~stylesheet$ %S から起動された ]: ◎ ↓
-
~IF[ %S の`所在$ss ~NEQ ~NULL 【すなわち,外部~stylesheet】 ] ⇒ %要請 の ( `~referrer$rq, `~referrer施策$rq ) ~SET %S の ( `所在$ss, `~referrer施策$ss ) ◎ If a CSS style sheet is responsible for the request, and its location is non-null, set the referrer to its location, and the referrer policy to its referrer policy.
この段は、~CSS~stylesheetが `Referrer-Policy$h ~headerを処理して,それを — 文書の`~referrer施策$docに対するときと同じ仕方で — 当の~stylesheetの `~referrer施策@ss として格納することを要求する。 ◎ This requires that CSS style sheets process `Referrer-Policy` headers, and store a referrer policy in the same way that Documents do.
- ~ELSE 【すなわち,~inline~stylesheet】 ⇒ %要請 の ( `~referrer$rq, `~referrer施策$rq ) ~SET %S の`所有者~node$ssの`~node文書$の ( `~URL$doc, `~referrer施策$doc ) ◎ If a CSS style sheet with a null location is responsible for the request, set the referrer to its owner node’s node document’s URL, and the referrer policy to its owner node’s node document’s referrer policy.
-
- ~ELSE( `~CSS宣言~block$は、 %要請 を起動した埋込元が,ある要素 %要素 に対し[ %要素 の `style$a を構文解析するか, %要素 用に`呈示hint$を実装する ]ことにより作成された) — この事例では、この宣言~blockの`所有者~node$は, %要素 を指しているものと見做す ⇒ %要請 の ( `~referrer$rq, `~referrer施策$rq ) ~SET %要素 の`~node文書$の ( `~URL$doc, `~referrer施策$doc ) ◎ Otherwise, a CSS declaration block that was created by the embedder is responsible for the request - either from parsing of an element’s style attribute, or to implement an presentational hint for an element. We assume that in this case the CSS declaration block’s owner node points to that element, and set the referrer to the block’s owner node’s node document’s URL, and the referrer policy to the block’s owner node’s node document’s referrer policy.
注記: `要請$の[ `~referrer$rq, `~referrer施策$rq ]両~値とも,その`要請$の作成-時の各種~値に基づいて設定される。 文書の~referrer施策が その存続中に変化した場合、文書~内の~inline~stylesheetによる要請に結付けられている施策も変化することになる。 ◎ Note: Both the value of the request’s referrer and referrer policy are set based on the values at the time a given request is created. If a document’s referrer policy changes during its lifetime, the policy associated with inline stylesheet requests will also change.
8. 各種~algo
8.1. `Referrer-Policy^h ~headerから~referrer施策を構文解析する
次の手続きは、所与の`応答$ %応答 に対し,その `Referrer-Policy^h ~headerから得られる`~referrer施策$を返す: ◎ Given a Response response, the following steps return a referrer policy according to response’s 'Referrer-Policy' header:
- %施策~token~list ~LET `~header~listから値を抽出する$( %応答 の`~header~list$rs, `Referrer-Policy^h ) ◎ Let policy-tokens be the result of extracting header list values given `Referrer-Policy` and response’s header list.
- %施策 ~LET 空~文字列 ◎ Let policy be the empty string.
-
%施策~token~list 内の~EACH( %~token ) に対し ⇒ ~IF[ %~token は`~referrer施策$である ]~AND[ %~token ~NEQ 空~文字列 ] ⇒ %施策 ~SET %~token ◎ For each token in policy-tokens, if token is a referrer policy and token is not the empty string, then set policy to token.
注記: この~algoは、新たな施策~値を,旧~UA用の~fallbackも伴わせて配備できるようにするため( 未知の施策~値 節 に述べるように),複数の施策~値にわたって~loopする。 ◎ Note: This algorithm loops over multiple policy values to allow deployment of new policy values with fallbacks for older user agents, as described in §11.1 Unknown Policy Values.
- ~RET %施策 ◎ Return policy.
8.2. ~redirect上で %要請 の~referrer施策を設定する
この~algoは、所与の ( `要請$ %要請, `応答$ %実~応答 ) に対し, %実~応答 内に `Referrer-Policy^h ~headerがあれば,それに則って %要請 の`~referrer施策$rqを更新する。 ◎ Given a request request and a response actualResponse, this algorithm updates request’s associated referrer policy according to the Referrer-Policy header (if any) in actualResponse.
- %施策 ~LET %実~応答 の `Referrer-Policy^h ~headerから`~referrer施策を構文解析-$した結果 ◎ Let policy be the result of executing §8.1 Parse a referrer policy from a Referrer-Policy header on actualResponse.
- ~IF[ %施策 ~NEQ 空~文字列 ] ⇒ %要請 の`~referrer施策$rq ~SET %施策 ◎ If policy is not the empty string, then set request’s associated referrer policy to policy.
8.3. %要請 の~referrerを決定する
所与の`要請$ %要請 に対し,送信する正しい~referrer情報は、次の手続きに詳細に示すように, %要請 の`~referrer施策$rqを精査することにより決定できる。 この手続きは、 `~referrerなし^i, `~URL$のいずれかを返す: ◎ Given a Request request, we can determine the correct referrer information to send by examining the referrer policy associated with it, as detailed in the following steps, which return either no referrer or a URL:
- %施策 ~LET %要請 の`~referrer施策$rq ◎ Let policy be request’s associated referrer policy.
- %環境 ~LET %要請 の`~client$rq ◎ Let environment be request’s client.
- %~referrer~source ~LET ~NULL ◎ ↓
-
%要請 の`~referrer$rqに応じて: ◎ Switch on request’s referrer:
- `client^l
-
-
~IF[ %環境 の`大域~obj$は `Window$I ~objである ]: ◎ If environment’s global object is a Window object, then
- %文書 ~LET %環境 の`大域~obj$に`結付けられている文書$ ◎ Let document be the associated Document of environment’s global object.
- ~IF[ %文書 の`生成元$docは`不透明な生成元$である ] ⇒ ~RET `~referrerなし^i ◎ If document’s origin is an opaque origin, return no referrer.
- ~WHILE[ %文書 は`~iframe-srcdoc文書$である ] ⇒ %文書 ~SET [[ %文書 が`属する閲覧文脈$ ]を入子にしている`閲覧文脈~容器$ ]の`~node文書$ ◎ While document is an iframe srcdoc document, let document be document’s browsing context’s browsing context container’s node document.
- %~referrer~source ~SET %文書 の`~URL$doc ◎ Let referrerSource be document’s URL.
- ~ELSE ⇒ %~referrer~source ~SET %環境 の`作成時の~URL$ ◎ Otherwise, let referrerSource be environment’s creation URL.
-
- `~URL$
- %~referrer~source ~SET %要請 の`~referrer$rq ◎ Let referrerSource be request’s referrer.
注記: %要請 の`~referrer$rq ~EQ `no-referrer^l の場合、この~algoは~Fetchから~callされない。 ◎ Note: If request’s referrer is "no-referrer", Fetch will not call into this algorithm.
- %~referrer~URL ~LET %~referrer~source を`~referrer用に削った$結果 ◎ Let referrerURL be the result of stripping referrerSource for use as a referrer.
- %~referrer生成元 ~LET [ `生成元のみ~flag$ ~SET ~ON ]の下で, %~referrer~source を`~referrer用に削った$結果 ◎ Let referrerOrigin be the result of stripping referrerSource for use as a referrer, with the origin-only flag set to true.
-
この段の記述では、次の条件 `同一生成元^i, `降格^i を利用する:
- `同一生成元^i
- %要請 は`同一生成元~要請$である
- `降格^i
- [ %環境 ~NEQ ~NULL ]~AND[ %環境 は`~TLSで保護され$ている ]~AND[ %要請 の`現在の~url$rqは `信用に価し得ない~URL$である ]
~RET %施策 の値に応じて、次のうち 対応する段にて与えられる値: ◎ Execute the statements corresponding to the value of policy:
- `no-referrer$l ⇒ `~referrerなし^i ◎ "no-referrer" • Return no referrer
- `origin$l ⇒ %~referrer生成元 ◎ "origin" • Return referrerOrigin
- `unsafe-url$l ⇒ %~referrer~URL ◎ "unsafe-url" • Return referrerURL.
- `strict-origin$l ⇒# `降格^i ならば `~referrerなし^i / ~ELSE_ %~referrer生成元 ◎ "strict-origin" • If environment is not null: •• If environment is TLS-protected and request’s current URL is not a potentially trustworthy URL, then return no referrer. • Return referrerOrigin.
- `strict-origin-when-cross-origin$l ⇒# `同一生成元^i ならば %~referrer~URL / ~ELSE_ `降格^i ならば `~referrerなし^i / ~ELSE_ %~referrer生成元 ◎ "strict-origin-when-cross-origin" • If request is a same-origin request, then return referrerURL. • If environment is not null: •• If environment is TLS-protected and request’s current URL is not a potentially trustworthy URL ••• Return no referrer. • Return referrerOrigin.
- `same-origin$l ⇒# `同一生成元^i ならば %~referrer~URL / ~ELSE_ `~referrerなし^i ◎ "same-origin" • If request is a same-origin request, then return referrerURL. • Otherwise, return no referrer.
- `origin-when-cross-origin$l ⇒# `同一生成元^i ならば %~referrer~URL / ~ELSE_ %~referrer生成元 ◎ "origin-when-cross-origin" • If request is a cross-origin request, then return referrerOrigin. • Otherwise, return referrerURL.
- `no-referrer-when-downgrade$l ⇒# `降格^i ならば `~referrerなし^i / ~ELSE_ %~referrer~URL ◎ "no-referrer-when-downgrade" • If environment is not null: •• If environment is TLS-protected and request’s current URL is not a potentially trustworthy URL, then return no referrer. • Return referrerURL.
注記: ~Fetchは、この~algoを~callする前に[ %要請 の`~referrer施策$rq ~NEQ 空~文字列 ]になることを確保する。 ◎ Note: Fetch will ensure request’s referrer policy is not the empty string before calling this algorithm.
8.4. ~referrerとして利用するために %~url を削る
~URLの一定の部位は、 `Referer^h ~headerの値として送信するときには,含められては~MUST_NOT: ~URLの[ `素片$url, `~username$url, `~password$url ]成分は、~URLを外へ送信する前に削られるべきである。 この~algoは、 `生成元のみ~flag@ も受容する( 省略-時は ~OFF ) — ~ON の場合、~URLの[ `~path$url, `~query$url ]成分も削られ,[ `~scheme$url, `~host$url, `~port$url ]成分のみが残されることになる。 ◎ Certain portions of URLs MUST not be included when sending a URL as the value of a 'Referer' header: a URLs fragment, username, and password components should be stripped from the URL before it’s sent out. This algorithm accepts a origin-only flag, which defaults to false. If set to true, the algorithm will additionally remove the URL’s path and query components, leaving only the scheme, host, and port.
- ~IF[ %~url ~EQ ~NULL ] ⇒ ~RET `~referrerなし^i ◎ If url is null, return no referrer.
- ~IF[ %~url の`~scheme$urlは`局所~scheme$である ] ⇒ ~RET `~referrerなし^i ◎ If url’s scheme is a local scheme, then return no referrer.
- %~url ~SET %~url の複製 【この段は、訳者による補完】
- %~url の ( `~username$url, `~password$url, `素片$url ) ~SET ( 空~文字列, ~NULL, ~NULL ) ◎ Set url’s username to the empty string. ◎ Set url’s password to null. ◎ Set url’s fragment to null.
-
~IF[ `生成元のみ~flag$ ~EQ ~ON ] ⇒ %~url の ( `~path$url, `~query$url ) ~SET ( ~NULL, ~NULL ) ◎ If the origin-only flag is true, then: ◎ Set url’s path to null. ◎ Set url’s query to null.
- ~RET %~url ◎ Return url.
9. ~privacy上の考慮点
9.1. 利用者による制御
この仕様のすべては、[[ `Referer^h ~headerを介して外へ送信される情報 ]を変更するような~option ]を,~UAが利用者に提供することを防止するものと解釈されるべきでない。 具体例として、~UAは,~page上で作動中の`~referrer施策$にかかわらず, `Referer^h ~headerをまるごと抑止することを利用者に許容して~MAY。 ◎ Nothing in this specification should be interpreted as preventing user agents from offering options to users which would change the information sent out via a 'Referer' header. For instance, user agents MAY allow users to suppress the referrer header entirely, regardless of the active referrer policy on a page.
10. 保安~上の考慮点
10.1. 情報の漏洩
`~referrer施策$[ `origin$l / `origin-when-cross-origin$l / `unsafe-url$l ]は、非保安的~transportを介して,保安的~siteの[ 生成元/~URL ]を漏洩するかもしれない。 ◎ The referrer policies "origin", "origin-when-cross-origin" and "unsafe-url" might leak the origin and the URL of a secure site respectively via insecure transport.
これらの施策は、保安的~transportを採用している~siteの抗力を下げるにもかかわらず,仕様に含められている。 ◎ Those three policies are included in the spec nevertheless to lower the friction of sites adopting secure transport.
作者は、既定の施策を超える情報は漏洩されないことを確保したい場合は、代わりに[ `same-origin$l, `strict-origin$l, `strict-origin-when-cross-origin$l, `no-referrer$l ]のいずれかを言明する施策を利用するべきである。 ◎ Authors wanting to ensure that they do not leak any more information than the default policy should instead use the policy states "same-origin", "strict-origin", "strict-origin-when-cross-origin" or "no-referrer".
10.2. より厳格でない施策に降格する
この仕様は、より厳格でない施策への降格を禁止しない — 例えば `no-referrer$l から `unsafe-url$l へなど。 ◎ The spec does not forbid downgrading to less strict policies, e.g., from "no-referrer" to "unsafe-url".
任意の二つの施策に対し,どちらがより厳格であるかは、明白でない。 例えば,非保安的~transport越しの下では、 `no-referrer-when-downgrade$l は情報を漏洩しない一方で, `origin$l は漏洩することになるが、後者の方が 非同一生成元~naviにわたって露呈する情報は,より少ない。 ◎ On the one hand, it is not clear which policy is more strict for all possible pairs of policies: While "no-referrer-when-downgrade" will not leak any information over insecure transport, and "origin" will, the latter reveals less information across cross-origin navigations.
他方,より厳格でない施策の設定が許容されれば、作者は, 未知の施策~値 節 にて述べた安全な~fallbackを定義できるようになる。 ◎ On the other hand, allowing for setting less strict policies enables authors to define safe fallbacks as described in §11.1 Unknown Policy Values.
12. 謝辞
この仕様のかなりの部分は Adam Barth, Jochen Eisinger による Meta referrer 文書に基づく。 ◎ This specification is based in large part on Adam Barth and Jochen Eisinger’s Meta referrer document.