Fetch Metadata Request Headers（日本語訳）

◎要約

この文書は、一群の~fetch~metadata要請~headerを定義する — それらは、次のために十分な情報を~serverに供することを目指す ⇒ 所与の要請に対し，~serviceするか否かについて、当の要請が［為された仕方, どの文脈で利用されることになるか］に基づいて，先天的に裁定を下す。 ◎ This document defines a set of Fetch metadata request headers that aim to provide servers with enough information to make a priori decisions about whether or not to service a request based on the way it was made, and the context in which it will be used.

1. 序論

【！Interesting】 ~web~appは、一般に，~webに公開される多数の端点（ `endpoint^en ） — ［利用者についての敏感な~dataを露呈する／利用者に利する動作をとる］かもしれない端点 — を伴うことになる。利用者の~browserは，［それらの端点に向けて要請を為すよう，容易に仕向けられ得ることに加え、利用者の `ambient^en な【当の環境に暗黙に備わる】資格証（ ~cookie, ~intranet内で利用者が有する特権, 等々）を含む］ので、濫用を避けるためには，~appは［それらの端点が働く仕方について，特に気を付ける］必要がある。 ◎ Interesting web applications generally end up with a large number of web-exposed endpoints that might reveal sensitive data about a user, or take action on a user’s behalf. Since users' browsers can be easily convinced to make requests to those endpoints, and to include the users' ambient credentials (cookies, privileged position on an intranet, etc), applications need to be very careful about the way those endpoints work in order to avoid abuse.

気を付けることは、一部の事例（ “単純な” ~CSRF）においては難しく，他の事例（非同一-~site探索, 計時~攻撃, 等々）においては実用的にはアリでないものと判明している。後者の分類には、［ある種の応答を生成するために必要yな~server側の処理, および長さの測定］に基づく計時~攻撃が含まれる（~web~page上での計時~攻撃を介するものも，`受動的~network攻撃者$も含まれる）。 ◎ Being careful turns out to be hard in some cases ("simple" CSRF), and practically impossible in others (cross-site search, timing attacks, etc). The latter category includes timing attacks based on the server-side processing necessary to generate certain responses, and length measurements (both via web-facing timing attacks and passive network attackers).

後者の分類を軽減するため、 ~serverが［所与の要請に応答するかどうかについて、要請が為された仕方に基づいて，もっと賢い裁定を下せる］ならば，助けになるであろう。例えば，ある銀行の~server上の “預金全部を転送する” 端点が `img$e ~tagから参照されることを期待することは、まずあり得ないと見受けられる。同様に `evil.com^s が正当な要請を為してくるとはまったくもって考えにくい。 ~serverがこれらの要請を — ~app~backendへ送達することなく — 先天的に却下できれば理想的である。 ◎ It would be helpful if servers could make more intelligent decisions about whether or not to respond to a given request based on the way that it’s made in order to mitigate the latter category. For example, it seems pretty unlikely that a "Transfer all my money" endpoint on a bank’s server would expect to be referenced from an img tag, and likewise unlikely that evil.com is going to be making any legitimate requests whatsoever. Ideally, the server could reject these requests a priori rather than delivering them to the application backend.

ここでは、［ ~UAが，外向けの要請に追加的な文脈を追加することにより、 ~serverがこの種の裁定を下すことを可能化する］ための仕組みを述べる。それは、［ ~serverへ，一連の`~fetch~metadata~header$内に~metadataを伴わせて送達する］ことにより，［ ~appが，一連の事前条件を~testした結果に基づいて要請を素早く却下する］ことを可能化する。その働nは、欲されるなら，~app層の上（逆~proxy, ~CDN, 等々）に持上げることさえできる。 ◎ Here, we describe a mechanims by which user agents can enable this kind of decision-making by adding additional context to outgoing requests. By delivering metadata to a server in a set of fetch metadata headers, we enable applications to quickly reject requests based on testing a set of preconditions. That work can even be lifted up above the application layer (to reverse proxies, CDNs, etc) if desired.

1.1. 例

`picture$e 要素により生成された要請は、次の~HTTP要請~headerを包含することになる： ◎ A request generated by a picture element would result in a request containing the following HTTP request headers:

Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site

~page内の~linkを利用者が~clickして生じた `https://example.com^s から `https://example.com/^s への ~top-level~naviによる結果の要請は、次の~HTTP要請~headerを包含することになる： ◎ A top-level navigation from https://example.com to https://example.com/ caused by a user’s click on an in-page link would result in a request containing the following HTTP request header:

Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1

2. ~fetch~metadata~header

以下の各~節では、各種 `~fetch~metadata~header@ を定義する。それぞれ、 ~serverにとって関心事になる［ `要請$の属性］を公開する。 ◎ The following sections define several fetch metadata headers, each of which exposes an interesting request attribute to a server.

2.1. `Sec-Fetch-Dest^h ~HTTP要請~header

`Sec-Fetch-Dest@h ~HTTP要請~headerは、 `要請$の`行先$rqを~serverに公開する。それは、 `~token$sfを値にとる`有構造~header$ `I-D.ietf-httpbis-header-structure$r でなければナラナイ。その~ABNFは： ◎ The Sec-Fetch-Dest HTTP request header exposes a request's destination to a server. It is a Structured Header whose value MUST be a token. [I-D.ietf-httpbis-header-structure] Its ABNF is:

Sec-Fetch-Dest
	= `sf-token$P【！sh-token】

`Sec-Fetch-Dest^h 用の妥当な値は、 `Fetch$r により定義される`要請$の妥当な`行先$rqたちが成す集合を含む。 ◎ Valid Sec-Fetch-Dest values include the set of valid request destinations defined by [Fetch].

まだ未知な要請~種別との前方-互換性を~supportするため、 ~serverは，妥当でない値を包含する場合にはこの~headerを無視するベキである。 ◎ In order to support forward-compatibility with as-yet-unknown request types, servers SHOULD ignore this header if it contains an invalid value.

`fetch()$c の行先は空~文字列になる【 `empty^l に対応する（下記）】 ⇒ `Sec-Fetch-Dest: empty^s ◎ // fetch()’s destination is the empty string: Sec-Fetch-Dest: empty
`img$e の行先は `image^l になる ⇒ `Sec-Fetch-Dest: image^s ◎ // <img>’s destination is "image" Sec-Fetch-Dest: image
`new Worker()$c の行先は `worker^l になる ⇒ `Sec-Fetch-Dest: worker^s ◎ // new Worker()’s destination is "worker" Sec-Fetch-Dest: worker
~top-level~naviの行先は `document^l になる ⇒ `Sec-Fetch-Dest: document^s ◎ // Top-level navigations' destinations are "document" Sec-Fetch-Dest: document
`iframe$e による~naviの行先は `iframe^l になる ⇒ `Sec-Fetch-Dest: document^s ◎ // <iframe> navigations' destinations are "iframe" Sec-Fetch-Dest: iframe

`~Sec-Fetch-Dest~headerを設定する@ ときは、所与の ( `要請$ %要請 ) に対し： ◎ To set the Sec-Fetch-Dest header for a request r:

~Assert： %要請の`~URL$rqは`信用に価し得る~URL$である。 ◎ Assert: r’s url is a potentially trustworthy URL.
%~token ~LET %要請の`行先$rq
~IF［ %~token ~EQ 空~文字列］ ⇒ %~token ~SET `empty^l ◎ Let header be a Structured Header whose value is a token. ◎ If r’s destination is the empty string, set header’s value to the string "empty". Otherwise, set header’s value to r’s destination.

注記：処理を単純~化するため、 `行先$rq `FETCH$r に対する空~文字列は，明示的に `~token$sf `empty^l に対応付けられる。 ◎ Note: We map Fetch’s empty string destination onto an explicit "empty" token in order to simplify processing.
%要請の`~header~list$rq内で`有構造~field値を設定する$( `Sec-Fetch-Dest$h / %~token を値にとる`~token$sf ) ◎ Set a structured field value `Sec-Fetch-Dest`/header in r’s header list.

2.2. `Sec-Fetch-Mode^h ~HTTP要請~header

`Sec-Fetch-Mode@h ~HTTP要請~headerは、 `要請$の`~mode$rqを~serverに公開する。それは、 `~token$sfを値にとる`有構造~header$ `I-D.ietf-httpbis-header-structure$r である。その~ABNFは： ◎ The Sec-Fetch-Mode HTTP request header exposes a request's mode to a server. It is a Structured Header whose value is a token. [I-D.ietf-httpbis-header-structure] Its ABNF is:

Sec-Fetch-Mode
	= `sf-token$P【！sh-token】

次に挙げるものが、 `Sec-Fetch-Mode^h 用の妥当な値になる ⇒＃ `cors^l, `navigate^l, `no-cors^l, `same-origin^l, `websocket^l ◎ Valid Sec-Fetch-Mode values include "cors", "navigate", "no-cors", "same-origin", and "websocket".＼

`~Sec-Fetch-Mode~headerを設定する@ ときは、所与の ( `要請$ %要請 ) に対し： ◎ To set the Sec-Fetch-Mode header for a request r:

~Assert： %要請の`~URL$rqは`信用に価し得る~URL$である。 ◎ Assert: r’s url is a potentially trustworthy URL.
%~token ~LET %要請の`~mode$rq ◎ Let header be a Structured Header whose value is a token. ◎ Set header’s value to r’s mode.
%要請の`~header~list$rq内で`有構造~field値を設定する$( `Sec-Fetch-Mode$h / %~token を値にとる`~token$sf ) ◎ Set a structured field value `Sec-Fetch-Mode`/header in r’s header list.

2.3. `Sec-Fetch-Site^h ~HTTP要請~header

`Sec-Fetch-Site@h ~HTTP要請~headerは、［ `要請$の起動元の生成元, `要請$の~targetの生成元］の関係性を公開する。それは、 `~token$sfを値にとる`有構造~header$ `I-D.ietf-httpbis-header-structure$r である。その~ABNFは： ◎ The Sec-Fetch-Site HTTP request header exposes the relationship between a request initiator’s origin and its target’s origin. It is a Structured Header whose value is a token. [I-D.ietf-httpbis-header-structure] Its ABNF is:

Sec-Fetch-Site
	= `sf-token$P【！sh-token】

次に挙げるものが、妥当な `Sec-Fetch-Site^h 値になる ⇒＃ `cross-site^l, `same-origin^l, `same-site^l, `none^l ◎ Valid Sec-Fetch-Site values include "cross-site", "same-origin", "same-site", and "none".＼

`~Sec-Fetch-Site~headerを設定する@ ときは、所与の ( `要請$ %要請 ) に対し： ◎ To set the Sec-Fetch-Site header for a request r:

~Assert： %要請の`~URL$rqは`信用に価し得る~URL$である。 ◎ Assert: r’s url is a potentially trustworthy URL.
%~token ~LET `same-origin^l ◎ Let header be a Structured Header whose value is a token. ◎ Set header’s value to same-origin.
~IF［ %要請は`~navi要請$であって、利用者が~UAと明示的にヤリトリして生じた（例：直に~addressを打込んだ, ~bookmarkを~clickした, 等々）］ ⇒＃ %~token ~SET `none^l； ~GOTO `最後の段^i ◎ If r is a navigation request that was explicitly caused by a user’s interaction with the user agent (by typing an address into the user agent directly, for example, or by clicking a bookmark, etc.), then set header’s value to none.

注記：いくぶん拙く定義されたこの段についての詳細は、 § 利用者が直に起動した要請を見よ。 ◎ Note: See § 4.3 Directly User-Initiated Requests for more detail on this somewhat poorly-defined step.
%要請~生成元 ~LET %要請の`生成元$rq ◎ ↓
%要請の`~URL~list$rq内の ~EACH( %~URL ) に対し： ◎ If header’s value is not none, then for each url in r’s url list:
1. %~URL生成元 ~LET %~URL の`生成元$url ◎ ↓
2. ~IF［ ( %~URL生成元, %要請~生成元 ) は`同一-生成元$である］ ⇒ ~CONTINUE ◎ If url is same origin with r’s origin, continue.
3. %~token ~SET `cross-site^l ◎ Set header’s value to cross-site.
4. ~IF［ ( %~URL生成元, %要請~生成元 ) は`同じ~site$でない］ ⇒ ~BREAK ◎ If r’s origin is not same site with url’s origin, then break.
5. %~token ~SET `same-site^l ◎ Set header’s value to same-site.
`最後の段^i ⇒ %要請の`~header~list$rq内で`有構造~field値を設定する$( `Sec-Fetch-Site$h / %~token を値にとる`~token$sf ) ◎ Set a structured field value `Sec-Fetch-Site`/header in r’s header list.

2.4. `Sec-Fetch-User^h ~HTTP要請~header

`Sec-Fetch-User@h ~HTTP要請~headerは、 `~navi要請$は利用者の作動化により誘発されたかどうかを公開する。それは、 `真偽値$sfを値にとる`有構造~header$ `I-D.ietf-httpbis-header-structure$r である。その~ABNFは： ◎ The Sec-Fetch-User HTTP request header exposes whether or not a navigation request was triggered by user activation. It is a Structured Header whose value is a boolean. [I-D.ietf-httpbis-header-structure] Its ABNF is:

Sec-Fetch-User
	= `sf-boolean$P【！sh-boolean】

注記：この~headerは、 `~navi要請$用に限り，その値が ~T† のときに限り送達される【† ~field値においては `?1^l として表現される】。将来においては、この~headerの視野を，下位資源~要請も一般に含むよう拡げることも適理かもしれない — その情報を公開することにより改善されるような一部の利用事例を~~明文化できれば（かつ，関心事になるすべての下位資源~要請~種別~用に状態sを定義する仕方について合意されれば）— が、さしあたり，~navi要請には明瞭な利用事例があるので、相互運用可能に定義するのは，単直と見受けられる。 ◎ Note: The header is delivered only for navigation requests, and only when its value is true. It might be reasonable to expand the headers' scope in the future to include subresource requests generally if we can spell out some use cases that would be improved by exposing that information (and if we can agree on ways to define that status for all the subresource request types we’d be interested in), but for the moment, navigation requests have clear use cases, and seem straightforward to define interoperably.

`~Sec-Fetch-User~headerを設定する@ ときは、所与の ( `要請$ %要請 ) に対し： ◎ To set the Sec-Fetch-User header for a request r:

~Assert： %要請の`~URL$rqは`信用に価し得る~URL$である。 ◎ Assert: r’s url is a potentially trustworthy URL.
~IF［ %要請は`~navi要請$でない］~OR［ %要請の`利用者が作動化したか$rq ~NEQ ~F ］ ⇒ ~RET ◎ If r is not a navigation request, or if r’s user-activation is false, return.
%要請の`~header~list$rq内で`有構造~field値を設定する$( `Sec-Fetch-User$h / `真偽値$sf ~T ) ◎ Let header be a Structured Header whose value is a token. ◎ Set header’s value to true. ◎ Set a structured field value `Sec-Fetch-User`/header in r’s header list.

3. ~Fetch, ~HTMLとの統合

`Sec-Fetch-User$h を~supportするため， `要請$には`利用者が作動化したか$rqがあり、 ~HTMLの`~fetchingにより~navi~paramsを作成する$~algoにより拡充されない限り， ~F をとる。 ◎ To support Sec-Fetch-User, request has a user-activation which is false, unless otherwise populated by HTML’s create navigation params by fetching algorithm.

各種`~fetch~metadata~header$は、 ~Fetchの “`~HTTP~network-or-cache~fetch$” ~algoの中で，次の手続きを利用して外向けの要請に付加される。統合の詳細については、その仕様 `FETCH$r に諮られたし。 ◎ Fetch Metadata headers are appended to outgoing requests from within Fetch’s "HTTP-network-or-cache" algorithm, using the following steps. Consult that specification for integration details [FETCH].

`~fetch~metadata~headerたちを付加する@ ときは、所与の ( `要請$ %要請 ) に対し： ◎ To append the Fetch metadata headers for a request, given request r:

~IF［ %要請の`~URL$rqは`信用に価し得る~URL$でない］ ⇒ ~RET ◎ If r’s url is not an potentially trustworthy URL, return.
`~Sec-Fetch-Dest~headerを設定する$( %要請 ) ◎ Set the Sec-Fetch-Dest header for r.
`~Sec-Fetch-Mode~headerを設定する$( %要請 ) ◎ Set the Sec-Fetch-Mode header for r.
`~Sec-Fetch-Site~headerを設定する$( %要請 ) ◎ Set the Sec-Fetch-Site header for r.
`~Sec-Fetch-User~headerを設定する$( %要請 ) ◎ Set the Sec-Fetch-User header for r.

4. ~securityと~privacyの考慮点

4.1. ~redirect

~UAは、 ~redirect連鎖を成す各~要請に伴って `Sec-Fetch-Site$h ~headerを送信することになる。混同を軽減するため、この~headerの値は，［非同一-生成元／非同一-~site ］への~redirectが在る下では，切り替わることになる。 ◎ The user agent will send a Sec-Fetch-Site header along with each request in a redirect chain. The header’s value will shift in the presence of cross-origin or cross-site redirection in order to mitigate confusion.

`~Sec-Fetch-Site~headerを設定する$~algoは、 ~header値として `none^l を送信する事例は別として， `要請$の`~URL~list$rq全体を一巡する — 要請の`現在の~URL$rq %現~URL に対し， ~header値として次を送信することになる：

~list内のすべての~URLは %現~URL と`同一-生成元$であるならば ⇒ `same-origin^l
他の場合，~list内のすべての~URLは %現~URL と`同じ~site$であるならば ⇒ `same-site^l
他の場合（~list内のある~URLは %現~URL と非同一-~siteである） ⇒ `cross-site^l

◎ The algorithm to set the Sec-Fetch-Site header walks the request's entire url list, and will send＼ cross-site if any URL in the list is cross-site to the request’s current url,＼ same-site only if all URLs in the list are same-site with the request’s current url, and＼ same-origin only if all URLs in the list are same-origin with the request’s current url.

例えば `https://example.com/^s が `https://example.com/redirect^s を要請したとする： ◎ For example, if https://example.com/ requests https://example.com/redirect,＼

初期~要請の `Sec-Fetch-Site$h 値は `same-origin^l になる。 ◎ the initial request’s Sec-Fetch-Site value would be same-origin.＼
前段の応答が `https://subdomain.example.com/redirect^s へ~redirectされた場合、対する要請の `Sec-Fetch-Site$h 値は `same-site^l になる（ `https://subdomain.example.com/^s, `https://example.com/^s の`登録-可能な~domain$は同じなので）。 ◎ If that response redirected to https://subdomain.example.com/redirect, that request’s Sec-Fetch-Site value would be same-site (as https://subdomain.example.com/ and https://example.com/ have the same registrable domain).＼
前段の応答が `https://example.net/redirect^s へ~redirectされた場合、対する要請の `Sec-Fetch-Site$h 値は `cross-site^l になる（ `https://example.net/^s は［ `https://example.com/^s ／ `https://subdomain.example.com/^s ］と`同じ~site$でないので）。 ◎ If that response redirected to https://example.net/redirect, that request’s Sec-Fetch-Site value would be cross-site (as https://example.net/ is not same-site with https://example.com/ and https://subdomain.example.com/).＼
前段の応答が，巡り巡って~~元の `https://example.com/^s へ~redirectされた場合でも、最終-要請の `Sec-Fetch-Site$h 値は `cross-site^l になる（~redirect連鎖は `https://example.net/^s を含むが、それでも，他の~URLと`同じ~site$ではないので）。 ◎ If that response redirects all the way back to https://example.com/, the final request’s Sec-Fetch-Site value would still be cross-site (as the redirect chain includes https://example.net/, which is still not same-site with the other URLs.

注記： `Sec-Fetch-Site$h が値 `none^l をとる特別な事例~用には、共通的な［ `shortlink^en【短縮~URL】を~copyして~URL~barの中へ~pasteする事例］を~supportするため， ~redirectを経た後もその値を保守することが適理になると見受けられる。すなわち、 ~UAが［ ~URL~barによる `https://sho.rt/link^s への~navi ］を［値 `none^l を伴う `Sec-Fetch-Site$h として扱う］ことを選ぶ場合、［ ~redirect後における `https://target.com/long/path/goes/here^s への~navi ］も，同様に［値 `none^l を伴う `Sec-Fetch-Site$h を表明する］ベキである。 ◎ Note: For the special case of Sec-Fetch-Site: None, it seems reasonable to maintain that value through redirects in order to support the common case of copy/pasting shortlinks into the address bar. That is, if a user agent chooses to treat an address-bar navigation to https://sho.rt/link as Sec-Fetch-Site: none, a post-redirect navigation to https://target.com/long/path/goes/here should likewise assert Sec-Fetch-Site: none.

4.2. `Sec-^h 接頭辞

この文書に定義される各~headerは、どれも `Sec-^h が接頭され， `禁止~要請~header$【！禁止~応答~header名】になるので、 ~JSからは改変-不能になる。したがって、［悪意的な~web~siteが、偽造した~metadataを要請に伴わせて送信するよう，~UAを仕向ける］ことは，防止される。これにより、 ~siteは［自身による，広告された情報に対し適理に応答する能］に少しは確信を持てるようになるはずである。 ◎ Each of the headers defined in this document is prefixed with Sec-, which makes them all forbidden response-header names, and therefore unmodifiable from JavaScript. This will prevent malicious websites from convincing user agents to send forged metadata along with requests, which should give sites a bit more confidence in their ability to respond reasonably to the advertised information.

4.3. 利用者が直に起動した要請

`~Sec-Fetch-Site~headerを設定する$とき、 ~UAは，当の~navi要請が “利用者のヤリトリにより明示的に生じたもの” かどうか判別するよう依頼される。このいくぶん拙く定義された句は、 ~HTMLから~~引用した示唆【！~HTMLnav#navigating-across-documents】による： “~UAは、利用者~向けに，`~navigable$を明示的に［ ~navigateする／読込直す／読込ngを停止する］仕方を供してもヨイ。” 【この~~引用は、~HTMLの更新に倣うよう，原文から改めている。】 ◎ When setting the Sec-Fetch-Site header, user agents are asked to distinguish between navigation requests that are "explicitly caused by a user’s interaction". This somewhat poorly defined phrase is pulled from HTML, which suggests that "A user agent may provide various ways for the user to explicitly cause a browsing context to navigate, in addition to those defined in this specification."

目標は、所与の（悪意的にもなり得る）~web~siteにより制御される “~web的な” ~navi （例： ~link, `window.location$c 設定子, ~form提出, 等々）と，そうでないもの（例：利用者が~UAの~URL~bar, ~bookmark, 等々とヤリトリして生じたもの）とを判別することにある。前者は、 `Sec-Fetch-Site$h ~headerに値［ `same-origin^l, `same-site^l, `cross-site^l ］のうち適切なものを伴わせて送達することになる。後者は、値 `none^l で判別されることになる — 当の要請は、それを実際に担当した特定の~siteは無く，利用者による直な意図を何らかの~~形で表現するものであり、信用-済みとして扱うことを~serverに許容することは，イミを成すので。 ◎ The goal is to distinguish between "webby" navigations that are controlled by a given (potentially malicious!) website (e.g. links, the window.location setter, form submissions, etc.), and those that are not (e.g. user interaction with a user agent’s address bar, bookmarks, etc). The former will be delivered with a Sec-Fetch-Site header whose value is same-origin, same-site, or cross-site, as appropriate. The latter will be distinguished with a value of none, as no specific site is actually responsible for the request, and it makes sense to allow servers to treat them as trusted, as they somehow represent a user’s direct intent.

各~UAは，それぞれが別個な［ヤリトリの集合］を備えると見込まれる。それらがどの分類に該当するかは，~UAごとに異なるかもしれず、その場合，それらの事例~用に自動化された~test一式を共有するのは難しくなる。しかしながら、共通な挙動については，揃えた方が理想的であろう — いくつか例を挙げる： ◎ Each user agent is likely to have a distinct set of interactions which might fall into one or the other category, and it will be hard to share an automated test suite for these cases. Still, it would be ideal to align on behavior for those which are likely to be common. Sme examples follow:

~URL~barからの~navi ◎ Navigation from the address bar:＼: 一般~事例においては、［この種の~naviは，利用者が直に起動したものと扱って，値 `none^l を伴う `Sec-Fetch-Site$h を内包する］ベキである。 ~UAにとっては、 ~URL~barの中へ値を~pasteすることに関して，そのような~naviを利用者が自身で打込んだときとは別個に扱う経験則を含めることも適理になり得る（とりわけ，特定の生成元まで “~copy” 動作をナゾれる場合には）。 ◎ In the general case, this kind of navigation should be treated as directly user-initiated, and include Sec-Fetch-Site: none. It may be reasonable for user agents to include heuristics around pasting values into the address bar (especially if the "copy" action can be traced to a specific origin), and to treat such navigations distinctly from those which the user types themselves.
~UAに備わる~UIからの~navi （ ~bookmark, 新たな~UItab~page, 等々） ◎ Navigation from user agent UI (bookmarks, new tab page, etc):＼: そのような~UIにおいて利用者が~linkとヤリトリしたときは、［ ~UAの~URL~barにおける入力と同様に扱って，値 `none^l を伴う `Sec-Fetch-Site$h を内包する］ことにより、 ~naviを利用者が起動したものとするベキである。 ◎ A user’s interaction with links in user agent UI should be treated similarly to their input in the user agent’s address bar, including Sec-Fetch-Site: none to demarcate the navigation as user-initiated.
~linkの文脈~menuからの~navi （例： “新たな~UIwindow内に開く”） ◎ Navigation from a link’s context menu (e.g. "Open in new window"):＼: ~linkの~targetは，それを呈示した~pageにより制御されるので、 ~UAはその~naviを~siteが制御しているものと扱って，~linkを制御している~siteと開かれた~siteとの関係性~用に `Sec-Fetch-Site$h ~headerを適切に設定するベキである。 ◎ as the link’s target is controlled by the page on which the link is present, user agents should treat the navigation as site-controlled, and set the Sec-Fetch-Site header appropriately for the relationship between the site which controls the link and the site which is being opened.
~link上での Ctrl＋~click ◎ Ctrl-click on a link:＼: 前項で論じた~linkの文脈~menuに適用されるものと同じ主旨と結論が適用される。 ◎ the same arguments and conclusions apply here as apply to a link’s context menu, discussed directly above.
履歴を通した~navi （例：~UAの “戻る” ~button） ◎ Navigation through history (e.g. a user agent’s "back" button):: 【まだ何も記されていない】
~drag-and-drop ◎ Drag-and-drop:＼: ここでの挙動は、 ~dragされた内容の~sourceに基づいて判別することが適理に見受けられる。内容が，ある~UItabから~dragされた場合、 ~UAは，その生成元を確かめられるはずなので、それに則って `Sec-Fetch-Site$h を設定する。内容が他所から~dragされた場合（例：~UAの~bookmark~barや，別の~appから, 等々）、値 `none^l を伴う `Sec-Fetch-Site$h が適切になるであろう。 ◎ It seems reasonable to distinguish behavior here based upon the source of the dragged content. If content is dragged from a tab, the user agent should be able to ascertain its origin, and set Sec-Fetch-Site accordingly. If content is dragged from elsewhere (the user agent’s bookmark bar, another app entirely, etc), then Sec-Fetch-Site: none may be appropriate.

4.4. 拡張が起動した要請

一部の~UAは、要請を為す能力がある拡張を~supportする — ［利用者に自身の~web体験に対する制御をもっと与えるため，定例の~web内容を超えた力が与えられ得る］ような。これらは，~web~platformの視野からはいくぶん外れるが、 ~UAには，そのような要請が~serverに対しどう表現されるかを注意深く考慮することが奨励される。一般に、 ~UAは，次に挙げる 2 つの目標を満たすことが理想的になろう： ◎ Some user agents support extensions which are capable of making requests, and which can be empowered beyond regular web content in order to give users more control over their web experience. While these are somewhat outside the scope of the web platform, user agents are encouraged to carefully consider how these requests are to be represented to servers. In general, it would be ideal for user agents to satisfy two goals:

所与の~site用に特別な特権を伴わない拡張は、当の~siteの~server側の `~fetch~metadata^cite ~logicを迂回するような要請を為し得ない。 ◎ Extensions without special privileges for a given site cannot cause requests that would bypass that site’s server-side Fetch Metadata logic.
【~server側の】開発者が拡張による要請を認識できる — ［そのような要請が，~serverの `~fetch~metadata^cite ~logicから免除される］ようにすることも開発者が選べるよう。これは、正当な利用者の利益を損なうことなく， `~fetch~metadata^cite による保護を開発者が確信をもって配備する能を高める。 ◎ Developers can recognize extensions' requests so that they can be exempted from the server’s Fetch Metadata logic if it chooses to do so. This increases developers' ability to confidently deploy Fetch Metadata protections without undermining legitimate user interests.

以上の目標を念頭に、 ~UAには，次に挙げる挙動を実装することが奨励される： ◎ With these goals in mind, user agents are encouraged to implement the following behaviors:

ある拡張が所与の~URLへ~accessする許可を有さない場合、拡張によるその~URLへの要請は — 通常~web要請と同じく — 値 `cross-site^l を伴う `Sec-Fetch-Site$h ~headerを包含することもできる。 ~accessする許可を有する場合、 `Sec-Fetch-Site$h の値は `same-origin^l にすることもできる。 ◎ If an extension does not have permission to access to a given URL, its requests to that URL could contain a Sec-Fetch-Site header whose value is cross-site, just as a normal web request would. If the extension does have access to a given URL, the Sec-Fetch-Site value could be same-origin.
拡張~文脈から外への要請には、 `実装定義$な値 — 拡張が起動した要請と~webが起動した要請を判別することを~serverに許容する値 — を伴う `Origin$h ~headerを内包することもできる。 ◎ The Origin header could be included with outgoing requests from extension contexts, with an implementation-defined value that allows servers to distinguish extension-initiated requests from web-initiated requests.

5. 配備~上の考慮点

5.1. `Vary^h

所与の端点の応答が ~clientから`~fetch~metadata~header$内に送達された値に依存する場合、開発者は — ~cacheが応答を適切に取扱うことを確保するため — 適切な `Vary$h ~header `RFC9110$r を内包するよう気を付けるベキである。例えば： `Vary: Accept-Encoding, Sec-Fetch-Site^s ◎ If a given endpoint’s response depends upon the values the client delivers in a Fetch metadata header, developers should be careful to include an appropriate Vary header [RFC9110], in order to ensure that caches handle the response appropriately. For example, Vary: Accept-Encoding, Sec-Fetch-Site.

5.2. ~headerの肥大化

この文書の~~過去の~versionでは、単独の `Sec-Metadata^h ~headerを`辞書$sfを内容とするよう定義していた。後続な論（および `Mark Nottingham^en 氏による優れた `mnot-designing-headers$r ）から、単独の辞書から離れて，［それぞれが単独の`~token$sfのみを包含する，一連の単純な~header ］とするよう設計を切り替えた。この設計は、 ~HTTPの現在の~HPACK圧縮~algoの下では，有意により良く遂行されるはずである。 ◎ An earlier version of this document defined a single Sec-Metadata header, whose contents were a dictionary. Subsequent discussion (as well as Mark Nottingham’s excellent [mnot-designing-headers]) shifted the design away from a single dictionary to a series of simple headers, each of which contains only a single token. This design should perform significantly better under HTTP’s current HPACK compression algorithms.

この論題についての更なる論は w3ctag/design-reviews#280 にて考査されている。 ◎ Further discussion on the topic can be found on the review thread in w3ctag/design-reviews#280.

6. ~IANA考慮点

恒久的~message~header~field~registryは、次に与える`~fetch~metadata~header$用の登録で更新されるベキである `RFC3864$r 【この訳では、各~headerを一括して示す】： ◎ The permanent message header field registry should be updated with the following registrations for Fetch metadata headers: [RFC3864]

~header~field名: `Sec-Fetch-Dest^h; `Sec-Fetch-Mode^h; `Sec-Fetch-Site^h; `Sec-Fetch-User^h
適用-可能な~protocol: ~http
位置付け: 標準
著作者
変更~制御者: 編集者
仕様~文書: この仕様 — 次に挙げる各~節 ⇒＃ § `Sec-Fetch-Dest^h ~HTTP要請~header, § `Sec-Fetch-Mode^h ~HTTP要請~header, § `Sec-Fetch-Site^h ~HTTP要請~header, § `Sec-Fetch-User^h ~HTTP要請~header

◎ 6.1. Sec-Fetch-Dest Registration ◎ Header field name • Sec-Fetch-Dest Applicable protocol • http Status • standard Author/Change controller • Me Specification document • This specification (See § 2.1 The Sec-Fetch-Dest HTTP Request Header) ◎ 6.2. Sec-Fetch-Mode Registration ◎ Header field name • Sec-Fetch-Mode Applicable protocol • http Status • standard Author/Change controller • Me Specification document • This specification (See § 2.2 The Sec-Fetch-Mode HTTP Request Header) ◎ 6.3. Sec-Fetch-Site Registration ◎ Header field name • Sec-Fetch-Site Applicable protocol • http Status • standard Author/Change controller • Me Specification document • This specification (See § 2.3 The Sec-Fetch-Site HTTP Request Header) ◎ 6.4. Sec-Fetch-User Registration ◎ Header field name • Sec-Fetch-User Applicable protocol • http Status • standard Author/Change controller • Me Specification document • This specification (See § 2.4 The Sec-Fetch-User HTTP Request Header)

7. 謝辞

この仕組みの設計に~~相当な~supportを供された，次の方々に感謝する：

Thanks to Anne van Kesteren, Artur Janc, Dan Veditz, Łukasz Anforowicz, Mark Nottingham, and Roberto Clapis, who all provided substantial support in the design of this mechanism.