1. 序論
◎非規範的文書から為された要請や, 文書から他所への~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. ~security
~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（`能力~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 policy
- `~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.
- `同一-生成元~referrer要請@ ◎ same-origin-referrer request
- 次を満たす`要請$ ⇒ その［ `~referrer~URL$, `現在の~URL$rq ］の`生成元$urlは`同一-生成元$である ◎ A Request request is a same-origin-referrer request if the origin of request’s referrerURL and the origin of request’s current URL are the same.
- `非同一-生成元~referrer要請@ ◎ cross-origin-referrer request
- `同一-生成元~referrer要請$でない`要請$。 ◎ A Request is a cross-origin-referrer request if it is not a same-origin-referrer request.
3. ~referrer施策
`~referrer施策@ は、 `ReferrerPolicy$I に挙げられるいずれかの文字列である。 ◎ 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との統合＠#integration-with-fetch$, `§ 各種~algo＠#algorithms$ に与えられる。 ◎ 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として利用されるときに， 要請に対する既定の基準~施策を供する。 この施策は、 特定の要請に対しては， ~link型 `noreferrer$v の様な仕組みを介して締付けられることもある。 ◎ 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.
`既定の~referrer施策@ は、 `strict-origin-when-cross-origin$l とする。 ◎ The default referrer policy is "strict-origin-when-cross-origin".
3.1. `no-referrer^l
最も単純な施策は `no-referrer$l であり、 どの`生成元$へ送信される要請にも， ~referrer情報は伴われないことを指定する。 `Referer$h ~headerは、 まるごと省略されることになる。 ◎ The simplest policy is "no-referrer", which specifies that no referrer information is to be sent along with requests to any origin. The header Referer 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 施策は、 ~OR↓ を満たす要請に対しては， その全部的な`~referrer~URL$【！を`~referrer用に~URLを削る$】を~referrer情報として送信するよう指定する： ◎ The "no-referrer-when-downgrade" policy sends a request’s full referrerURL stripped for use as a referrer for requests:
- その［ `~referrer~URL$, `現在の~URL$rq ］は、どちらも`信用に価し得る~URL$である ◎ whose referrerURL and current URL are both potentially trustworthy URLs, or
- その`~referrer~URL$は、 `信用に価し得る~URL$でない ◎ whose referrerURL is a non-potentially trustworthy URL.
他方，次を満たす【すなわち，上を満たさない】要請は、 ~referrer情報を包含せず， `Referer$h ~headerは送信されないことになる。 ⇒ ［ `~referrer~URL$は`信用に価し得る~URL$である ］~AND［ `現在の~URL$rqは`信用に価し得る~URL$でない ］ ◎ Requests whose referrerURL is a potentially trustworthy URL and whose current URL is a non-potentially trustworthy URL 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.
3.3. `same-origin^l
`same-origin$l 施策は、 `同一-生成元~referrer要請$を為すときには， 全部的な`~referrer~URL$を~referrer情報として送信するよう指定する。 ◎ The "same-origin" policy specifies that a request’s full referrerURL is sent as referrer information when making same-origin-referrer requests.
他方，`非同一-生成元~referrer要請$は、 ~referrer情報を包含せず， `Referer$h ~headerは送信されないことになる。 ◎ Cross-origin-referrer 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.
`https://example.com/page.html^s に在る文書に `same-origin$l 施策が設定されていて，それは `https://script.example.com^s に在る~module~scriptを~fetchし，それは `https://example.com/descendant.js^s に在る子孫~scriptを~fetchする場合、 この子孫~scriptへの要請には， `Referer$h ~headerは送信されないことになる。 ◎ If a document at https://example.com/page.html sets a policy of "same-origin", and fetches a module script at https://script.example.com, which then fetches a descendant script at https://example.com/descendant.js, the request for the descendant script would send no Referer header.
そのわけは、 子孫~scriptへの要請の`現在の~URL$rqは `https://example.com/descendant.js^s になる一方， その`~referrer~URL$は `https://script.example.com^s になり、 `非同一-生成元~referrer要請$を為すからである。 ◎ This is because the descendant script request’s current URL is https://example.com/descendant.js, while its referrerURL is https://script.example.com, making the request cross-origin-referrer.
3.4. `origin^l
`origin$l 施策は、［ `同一-生成元~referrer要請$ ／ `非同一-生成元~referrer要請$ ］を為すときに，［ 要請の`~referrer~URL$を`直列化-$oした結果 ］を~referrer情報として送信するよう指定する。 ◎ The "origin" policy specifies that only the ASCII serialization of the request’s referrerURL is sent as referrer information when making both same-origin-referrer requests and cross-origin-referrer requests.
注記： 生成元に対する この直列化は， `https://example.com^s の様になる。 `Referer$h ~header内に妥当な~URLが送信されることを確保するため、 ~UAは，生成元に文字 U+002F（ `/^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 allows 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.
`https://example.com/page.html^s に在る文書に `origin$l 施策が設定されていて，それは `https://script.example.com^s に在る~module~scriptを~fetchし，それは `https://descendant.example.com^s に在る子孫~scriptを~fetchする場合、 この子孫~scriptへの要請には， `https://script.example.com/^s を値に伴う `Referer$h ~headerが送信されることになる。 ◎ If a document at https://example.com/page.html sets a policy of "origin", and fetches a module script at https://script.example.com, which fetches a descendant script at https://descendant.example.com, the request for the descendant script will send a Referer header with a value of https://script.example.com/.
3.5. `strict-origin^l
`strict-origin$l 施策は、 要請が ~OR↓ を満たすならば， `~referrer~URL$の`生成元$url【！`生成元$】を`直列化-$oした結果を送信する： ◎ The "strict-origin" policy sends the ASCII serialization of the origin of the referrerURL for requests:
- その［ `~referrer~URL$, `現在の~URL$rq ］は、 どちらも`信用に価し得る~URL$である ◎ whose referrerURL and current URL are both potentially trustworthy URLs, or
- その`~referrer~URL$は、 `信用に価し得る~URL$でない ◎ whose referrerURL is a non-potentially trustworthy URL.
他方，次を満たす【すなわち，上を満たさない】要請は、 ~referrer情報を包含せず， `Referer$h ~headerは送信されないことになる。 ⇒ ［ `~referrer~URL$は`信用に価し得る~URL$である ］~AND［ `現在の~URL$rqは`信用に価し得る~URL$でない ］ ◎ Requests whose referrerURL is a potentially trustworthy URL and whose current URL is a non-potentially trustworthy URL 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/.
`http://example.com/page.html^s に在る文書に `strict-origin$l 施策が設定されていて，それは `https://script.example.com^s に在る~module~scriptを~fetchし，それは `http://descendant.example.com^s に在る子孫~scriptを~fetchする場合、 この子孫~scriptへの要請には `Referer$h【！`referrer$v】 ~headerは送信されないことになる。 ◎ If a document at http://example.com/page.html sets a policy of "strict-origin", and fetches a module script at https://script.example.com, which then fetches a descendant script at http://descendant.example.com, the request to the descendant script would not send a Referrer header.
3.6. `origin-when-cross-origin^l
`origin-when-cross-origin$l 施策は、 次を~referrer情報として送信するよう指定する： ◎ The "origin-when-cross-origin" policy specifies that＼
- `同一-生成元~referrer要請$を為すときには、 要請の全部的な`~referrer~URL$ ◎ a request’s full referrerURL is sent as referrer information when making same-origin-referrer requests, and＼
- `非同一-生成元~referrer要請$を為すときには、 要請の`~referrer~URL$の`生成元$url【！`生成元$】のみを`直列化-$oした結果 ◎ only the ASCII serialization of the origin of the request’s referrerURL is sent as referrer information when making cross-origin-referrer requests.
注記： `origin-when-cross-origin$l 施策に対しては、 ~protocol昇格も考慮される — 例えば， `http://example.com/^s から `https://example.com/^s への要請は、 `非同一-生成元~referrer要請$になる。 ◎ 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-referrer requests.
注記： `origin-when-cross-origin$l 施策の下では、 ~HTTPS~referrerの生成元を， 暗号化されていない~HTTP要請の一部として~network越しに送信することが許容される。 この懸念には、 `strict-origin-when-cross-origin$l 施策が取組む。 ◎ Note: The "origin-when-cross-origin" policy allows 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.
`https://example-1.com^s に在る文書に `origin-when-cross-origin$l 施策が設定されていて，それは `https://example-2.com/module.js^s に在る~module~scriptを~fetchし，それは `https://example-1.com/descendant.js^s に在る子孫~scriptを~fetchする場合、 この子孫~scriptへの要請には， `https://example-2.com/^s を値に伴う `Referer$h ~headerが送信されることになる。 ◎ If a document at https://example-1.com sets a policy of "origin-when-cross-origin", and fetches a module script at https://example-2.com/module.js, which then fetches a descendant script at https://example-1.com/descendant.js, the request to the descendant script would send a Referer header with a value of https://example-2.com/.
`https://example-1.com^s に在る文書に `origin-when-cross-origin$l 施策が設定されていて，それは `https://example-2.com/module.js^s に在る~module~scriptを~fetchし，それは `https://example-2.com/descendant.js^s に在る子孫~scriptを~fetchする場合、 この子孫~scriptへの要請には， `https://example-2.com/module.js^s を値に伴う `Referer$h ~headerが送信されることになる。 ◎ If a document at https://example-1.com sets a policy of "origin-when-cross-origin", and fetches a module script at https://example-2.com/module.js, which then fetches a descendant script at https://example-2.com/descendant.js, the request to the descendant script would send a Referer header with a value of https://example-2.com/module.js.
3.7. `strict-origin-when-cross-origin^l
`strict-origin-when-cross-origin$l 施策は： ◎ The "strict-origin-when-cross-origin" policy specifies that＼
- `同一-生成元~referrer要請$を為すときには、 要請の全部的な`~referrer~URL$ ◎ a request’s full referrerURL is sent as referrer information when making same-origin-referrer requests, and＼
- `非同一-生成元~referrer要請$を為すときには、 要請の`~referrer~URL$の`生成元$url【！`生成元$】のみを`直列化-$oした結果 ◎ only the ASCII serialization of the origin of the request’s referrerURL when making cross-origin-referrer requests:＼
を、要請が次を満たすならば，~referrer情報として送信するよう指定する： ◎ ↓
- その［ `~referrer~URL$, `現在の~URL$rq ］は、どちらも`信用に価し得る~URL$である ◎ whose referrerURL and current URL are both potentially trustworthy URLs, or
- その`~referrer~URL$は、 `信用に価し得る~URL$でない ◎ whose referrerURL is a non-potentially trustworthy URL.
他方，次を満たす【すなわち，上を満たさない】要請は、 ~referrer情報を包含せず， `Referer$h ~headerは送信されないことになる。 ⇒ ［ `~referrer~URL$は`信用に価し得る~URL$である ］~AND［ `現在の~URL$rqは`信用に価し得る~URL$でない ］ ◎ Requests whose referrerURL is a potentially trustworthy URL and whose current URL is a non-potentially trustworthy URL 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.
`https://example.com/page.html^s に在る文書に `strict-origin-when-cross-origin$l 施策が設定されていて，それは `https://script.example.com^s に在る~module~scriptを~fetchし，それは `http://descendant.example.com^s に在る子孫~scriptを~fetchする場合、 この子孫~scriptへの要請には， `Referer$h ~headerは送信されないことになる。 ◎ If a document at https://example.com/page.html sets a policy of "strict-origin-when-cross-origin", and fetches a module script at https://script.example.com which then fetches a descendant script at http://descendant.example.com, the request to the descendant script would send no Referer header.
これが~UAの`既定の~referrer施策$であり、 指定された施策が無い場合に適用されることになる。 ◎ This policy is the user agent’s default, and will be applied if no policy is otherwise specified.
3.8. `unsafe-url^l
`unsafe-url$l 施策は、［ `非同一-生成元~referrer要請$ ／ `同一-生成元~referrer要請$ ］どちらにも，全部的な`~referrer~URL$を伴わせて送信するよう指定する。 ◎ The "unsafe-url" policy specifies that a request’s full referrerURL is sent along for both same-origin-referrer requests and cross-origin-referrer requests.
`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.
注記： この施策は、 その名が示すとおり安全でない。 この施策は、 ~secureな資源であっても， ~secureでない生成元へ向けて生成元と~pathを漏洩することになる。 そのような施策を敏感になり得る文書に設定するときは、 その影響iを注意深く考慮すること。 ◎ Note: The policy’s name doesn’t lie; it is unsafe. This policy will leak origins and paths from secure resources to insecure origins. Carefully consider the impact of setting such a policy for potentially sensitive documents.
3.9. 空~文字列
空~文字列は、 `~referrer施策$がないことに対応する： ◎ The empty string "" corresponds to no referrer policy,＼
- 他所で定義される`~referrer施策$があれば、 それに~fallbackする。 ◎ causing a fallback to a referrer policy defined elsewhere, or＼
- そのような より高~levelの施策が可用でない場合、 `既定の~referrer施策$に~fall-backする。 これは例えば、 `FETCH$r の`~main~fetch$~algoにて起こる。 ◎ in the case where no such higher-level policy is available, falling back to the default referrer policy. This happens in Fetch’s main fetch algorithm, for example.
`referrerpolicy＠~HTMLlinks#attr-hyperlink-referrerpolicy$a 属性を有さない~HTML `a$e 要素に対しては、 その~referrer施策は 空~文字列になる。 したがって， `a$e 要素に対する~clickにより起動される~navi要請は、［ `a$e 要素の`~node文書$の`施策~容器$docの`~referrer施策$pC ］の下で送信されることになる。 その~referrer施策もまた空~文字列であった場合、 要請の`~referrerを決定する$~algoは， それを `strict-origin-when-cross-origin$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 a element’s node document’s policy container’s referrer policy. 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 "strict-origin-when-cross-origin".
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＠~HTMLlinks#attr-hyperlink-referrerpolicy$a 属性
- `img$e 要素の `referrerpolicy＠~HEimages#attr-img-referrerpolicy$a 属性
- `iframe$e 要素の `referrerpolicy＠~HEembed#attr-iframe-referrerpolicy$a 属性
- `link$e 要素の `referrerpolicy＠~HEmetadata#attr-link-referrerpolicy$a 属性
- `script$e 要素の `referrerpolicy＠~HEscripting#attr-script-referrerpolicy$a 属性
- ［ `a$e ／ `area$e ］要素~上の `noreferrer$v ~link関係を介して。 ◎ Via the noreferrer link relation on an a, or area 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 に定義され， `RFC9110$r に定義される `~ABNF~list拡張＠~HTTPinfra#abnf.extension$（ #%規則 ） も利用される： ◎ 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 5.6.1 of [RFC9110].
"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全体の構文解析-に失敗しないようにするためにある。 新たな施策~値をどうすれば配備できるかの詳細は、 `§ 未知な施策~値＠#unknown-policy-values$ に述べる。 ◎ 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.
注記： 上の~ABNF内に利用される引用符は、 ~literal文字列を指示するものである — `Referrer-Policy^h ~header値は、 引用符で括るべきでない。 ◎ Note: The quotes in the ABNF above are used to indicate literal strings. Referrer-Policy header values should not be quoted.
［ `§ ~Fetchとの統合＠#integration-with-fetch$, `§ ~HTMLとの統合＠#integration-with-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. 用法
◎非規範的保護される資源は、 `Referrer-Policy^h ~headerの値として `no-referrer^c を指定することにより，~referrer漏洩eを防止できる： ◎ 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^h を送信しないことは同義なのか、はっきりしない。】 ◎ This will cause all requests made from the protected resource’s context to have an empty Referer [sic] header.
4.2. `meta^e 要素を介する送達
◎非規範的~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 内容~属性を介する送達
◎非規範的~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. ~referrer施策の継承
◎非規範的~referrer施策は、 ~HTMLにより定義されるとおり，`施策~容器$の継承の仕組みに従って継承される。 ◎ Referrer policy is inherited following the inheritance mechanism of policy containers, as defined by HTML.
5. ~Fetchとの統合
◎非規範的~Fetch仕様は、 ~redirectに追従する前に，要請の~referrer施策を更新できるよう， `~HTTP~redirect~fetch$を成す最後に近い段【！Step 19】にて［ `~redirectに対し要請の~referrer施策を設定する$手続き ］を~callする。 ◎ The Fetch specification calls out to § 8.2 Set request’s referrer policy on redirect before Step 19 of the HTTP-redirect fetch, so that a request’s referrer policy can be updated before following a redirect.
~Fetch仕様は、 `~main~fetch$を成す最初に近い段【！Step 8】にて［ `要請の~referrerを決定-$する手続き ］を~callして， その結果を利用して %要請 の`~referrer$rqを設定する。 供された~URLを直列化して， %要請 の `Referer$h ~headerを設定することは、 ~Fetchが担当する。 ◎ 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との統合
◎非規範的~HTML標準は、［ (1) `~navi$の間 ／ (2) `~workerを走らせて$いる間 ］に，［ 受信された応答の `Referrer-Policy$h ~headerから`~referrer施策$を決定した結果 ］を利用して［ (1) による結果の`文書$／ (2) による結果の `WorkerGlobalScope$I ］の［ `施策~容器$doc／`施策~容器$wG ］の`~referrer施策$pCを設定する。 ◎ 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's policy container’s or WorkerGlobalScope's policy container’s referrer policy.
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:
【† `~CSS~stylesheet$に関しては、 現在は， `CSS-VALUES-4^r `§ ~URL処理~model＠~CSSVAL#url-processing$ にて指定されている。 （要請の`~referrer$rqは，そこで設定されるので、 以下において それを設定する段は，今や重複と見なされよう。） 】
所与の ( ［`~CSS~stylesheet$／`~CSS宣言~block$］ %S, `要請$ %要請 ) に対し： ◎ ↑↓
-
~IF［ %S は`~CSS~stylesheet$である ］： ◎ ↓
-
~IF［ %S の`所在$ss ~NEQ ~NULL 【すなわち，外部~stylesheet】 ］ ⇒ %要請 の ⇒＃ `~referrer$rq ~SET %S の `所在$ss, `~referrer施策$rq ~SET %S の`~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を処理して， それを — `文書に対するときと同じ仕方＠~ORIGIN#policy-container-referrer-policy$で — 当の~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】：
- ~Assert： %S の`所有者~node$ss ~NEQ ~NULL
- %文書 ~LET %S の`所有者~node$ssの`~node文書$
- %要請 の ⇒＃ `~referrer$rq ~SET %文書 の`~URL$doc, `~referrer施策$rq ~SET %文書 の`施策~容器$docの`~referrer施策$pC
-
-
~ELSE （ %S は`~CSS宣言~block$である）： ◎ Otherwise,＼
- ~Assert： %S は、 %要請 を起動した埋込元が，ある要素に対し［ 要素の `style$a を構文解析する／要素~用に`呈示~用~hint$を実装する ］ことにより作成されたものである — この事例では、 %S の`所有者~node$dBは，要素を指しているものと見做す。 ◎ 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,＼
- %文書 ~LET %S の`所有者~node$dBの`~node文書$ ◎ ↓
- %要請 の ⇒＃ `~referrer$rq ~SET %文書 の`~URL$doc, `~referrer施策$rq ~SET %文書 の`施策~容器$docの`~referrer施策$pC ◎ 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 policy container’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群 ~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群 を成す ~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も伴わせて配備できるようにするため （`§ 未知な施策~値＠#unknown-policy-values$に述べるとおり）， 複数の施策~値にわたって~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 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 referrer policy to policy.
8.3. 要請の~referrerを決定する
所与の要請にて，送信する正しい~referrer情報は、 次の手続きに詳細に示すとおり， 要請の`~referrer施策$rqを精査することにより決定できる。 ◎ Given a request request, we can determine the correct referrer information to send by examining its referrer policy as detailed in the following steps,＼
この手続きは、 所与の ( `要請$ %要請 ) に対し，［ `~referrerなし^i ／ `~URL$ ］を返す： ◎ which return either no referrer or a URL:
- %施策 ~LET %要請 の`~referrer施策$rq ◎ Let policy be request’s 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 %文書 の`容器~文書$doc【！が`属する閲覧~文脈$の`容器~文書$】 ◎ 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$enV ◎ 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用に~URLを削る$( %~referrer~source ) ◎ Let request’s referrerURL be the result of stripping referrerSource for use as a referrer.
- %~referrer生成元 ~LET `~referrer用に~URLを削る$( %~referrer~source, ~T （ “生成元のみ” ） ) ◎ Let referrerOrigin be the result of stripping referrerSource for use as a referrer, with the origin-only flag set to true.
- ~IF［ `~URL直列化する$( %~referrer~URL ) の結果の文字列の長さ ~GT 4096 ］ ⇒ %~referrer~URL ~SET %~referrer生成元 ◎ If the result of serializing referrerURL is a string whose length is greater than 4096, set referrerURL to referrerOrigin.
- この時点で，~UAは、［ ~data漏洩eを最小限にする~~目的において，任意な施策~上の考慮点を施行する ］ためとして，［ %~referrer~URL ／ %~referrer生成元 ］を改めてもヨイ。 例えば，~UAは、 ~URLを生成元に削ったり，その~hostを［ 改変する／空~文字列に置換する ］, 等々を行うこともできる。 ◎ The user agent MAY alter referrerURL or referrerOrigin at this point to enforce arbitrary policy considerations in the interests of minimizing data leakage. For example, the user agent could strip the URL down to an origin, modify its host, replace it with an empty string, etc.
- %要請 の `~referrer~URL@ は、 この時点における %~referrer~URL として~~確定される。 ◎ ↑
- %現在の~URL ~LET %要請 の`現在の~URL$rq ◎ ↓
-
この段の記述では、 次の条件 `同一-生成元^i, `降格^i を利用する：
- `同一-生成元^i
- ［ %~referrer~URL の`生成元$url, %現在の~URL の`生成元$url ］は`同一-生成元$である （すなわち、 %要請 は`同一-生成元~referrer要請$である）
- `降格^i
- ［ %~referrer~URL は`信用に価し得る~URL$である ］~AND［ %現在の~URL は`信用に価し得る~URL$でない ］
~RET %施策 の値に応じて、 次のうち対応する段に与える値： ◎ Execute the statements corresponding to the value of policy:
注記： ［ %要請 の`~referrer$rq ~EQ 空~文字列 ］の場合、 この~algoが~Fetchから~callされることはない。 ◎ Note: If request’s referrer policy is the empty string, Fetch will not call into this algorithm.
- `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 referrerURL is a potentially trustworthy URL 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 the origin of referrerURL and the origin of request’s current URL are the same, then return referrerURL. • If referrerURL is a potentially trustworthy URL and request’s current URL is not a potentially trustworthy URL, then return no referrer. • Return referrerOrigin.
- `same-origin$l ⇒＃ `同一-生成元^i ならば %~referrer~URL ／ ~ELSE_ `~referrerなし^i ◎ "same-origin" • If the origin of referrerURL and the origin of request’s current URL are the same, then return referrerURL. • Note: This same-origin check determines whether or not the request is same-origin-referrer. • Return no referrer.
- `origin-when-cross-origin$l ⇒＃ `同一-生成元^i ならば %~referrer~URL ／ ~ELSE_ %~referrer生成元 ◎ "origin-when-cross-origin" • If the origin of referrerURL and the origin of request’s current URL are the same, then return referrerURL. • Return referrerOrigin.
- `no-referrer-when-downgrade$l ⇒＃ `降格^i ならば `~referrerなし^i ／ ~ELSE_ %~referrer~URL ◎ "no-referrer-when-downgrade" • If referrerURL is a potentially trustworthy URL and request’s current URL is not a potentially trustworthy URL, then return no referrer. • Return referrerURL.
8.4. ~referrerとして利用するために~URLを削る
`Referer$h ~headerの値として~URLを外へ送信するときには、 以下の~algoに従って，~URLの一定の部位を含めないモノトスル。 この~algoは、 ~URLの［ `素片$url, `~username$url, `~password$url ］成分を削ることに加え， %生成元のみか に ~T が与えられた場合には［ `~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 must 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.
この~algoは、 所与の ( `~URL$ %~URL, 真偽値 %生成元のみか （省略時は ~F ） ) に対し，次を走らす： ◎ ↑ • Assert: url is a URL.
- ~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 ~SET 空~文字列, `~password$url ~SET 空~文字列, `素片$url ~SET ~NULL ◎ Set url’s username to the empty string. ◎ Set url’s password to the empty string. ◎ Set url’s fragment to null.
-
~IF［ %生成元のみか ~EQ ~T ］ ⇒ %~URL の ⇒＃ `~path$url ~SET « 空~文字列 », `~query$url ~SET ~NULL ◎ If the origin-only flag is true, then: • Set url’s path to « the empty string ». • 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をまるごと抑止することを利用者に許容してもヨイ。 ◎ 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. ~securityの考慮点
10.1. 情報~漏洩e
次に挙げる`~referrer施策$は、 ~secureでない~transportを介して，~secureな~siteの［ 生成元／~URL ］を漏洩するかもしれない ⇒＃ `origin$l, `origin-when-cross-origin$l, `unsafe-url$l ◎ 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.
これらの施策は、 ~secureな~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, `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", 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".
任意の二つの施策に対し，どちらがより厳密かは、 明瞭でない。 例えば，~secureでない~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.
他方，より厳密でない施策の設定が許容されれば、 作者は， `§ 未知な施策~値＠#unknown-policy-values$にて述べた安全な~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^en, `Jochen Eisinger^en ］両氏による `Meta referrer＠http://wiki.whatwg.org/wiki/Meta_referrer$en 文書に基づく。 ◎ This specification is based in large part on Adam Barth and Jochen Eisinger’s Meta referrer document.
次に挙げる施策に`貢献された＠https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0085.html$ `Francois Marier^en 氏に ⇒＃ `same-origin$l, `strict-origin$l, `strict-origin-when-cross-origin$l ◎ Francois Marier contributed the same-origin, strict-origin, and strict-origin-when-cross-origin policies.