[要約] RFC 8674は、HTTPリクエストヘッダーにおける"safe"プリファレンスの定義と使用方法を提供するものであり、安全なリソース操作を強制することを目的としています。
Independent Submission M. Nottingham
Request for Comments: 8674 December 2019
Category: Informational
ISSN: 2070-1721
The "safe" HTTP Preference
「安全な」HTTPプリファレンス
Abstract
概要
This specification defines a preference for HTTP requests that expresses a desire to avoid objectionable content, according to the definition of that term by the origin server.
この仕様は、元のサーバーによるその用語の定義に従って、不快なコンテンツを回避したいという要望を表すHTTP要求の設定を定義します。
This specification does not define a precise semantic for "safe". Rather, the term is interpreted by the server and within the scope of each web site that chooses to act upon this information.
この仕様は、「安全」の正確な意味を定義していません。むしろ、この用語はサーバーによって解釈され、この情報に基づいて行動することを選択した各Webサイトの範囲内で解釈されます。
Support for this preference by clients and servers is optional.
クライアントとサーバーによるこの設定のサポートはオプションです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8674.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8674で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
1.1. Notational Conventions
2. The "safe" Preference
3. Security Considerations
4. IANA Considerations
5. References
5.1. Normative References
5.2. Informative References
Appendix A. Sending the "safe" Preference from Web Browsers
Appendix B. Supporting the "safe" Preference on Web Sites
Acknowledgements
Author's Address
Many web sites have a "safe" mode to assist those who don't want to be exposed (or have their children exposed) to content to which they might object.
多くのWebサイトには、「セーフ」モードがあり、反対する可能性のあるコンテンツに公開されたくない（または子供を公開したくない）人々を支援します。
However, that goal is often difficult to achieve because of the need to go to every web site that might be used and navigate to the appropriate page (possibly creating an account along the way) to get a cookie [RFC6265] set in the browser, for each browser on every device used.
ただし、ブラウザで設定されたCookie [RFC6265]を取得するために、使用される可能性のあるすべてのWebサイトにアクセスし、適切なページに移動する（途中でアカウントを作成する可能性がある）必要があるため、この目標を達成することはしばしば困難です。使用されているすべてのデバイスのブラウザごとに。
A more manageable approach is for the browser to proactively indicate a preference for safe content. A user agent that supports doing so (whether it be an individual browser or through an operating system HTTP library) need only be configured once to ensure that the preference is advertised to a set of sites, or even all sites.
より管理しやすいアプローチは、ブラウザーが安全なコンテンツの設定を積極的に示すことです。これをサポートするユーザーエージェント（個別のブラウザーであっても、オペレーティングシステムのHTTPライブラリを介してであっても）は、設定がサイトのセットまたはすべてのサイトに通知されることを保証するために一度だけ構成する必要があります。
This specification defines how to declare this desire in requests as an HTTP Preference [RFC7240].
この仕様は、HTTP Preference [RFC7240]としてリクエストでこの欲求を宣言する方法を定義します。
Note that this specification does not define what content might be considered objectionable, so the concept of "safe" is not precisely defined. Rather, the term is interpreted by the server and within the scope of each web site that chooses to act upon this information.
この仕様では、好ましくないと見なされる可能性のあるコンテンツは定義されていないため、「安全」の概念は正確には定義されていません。むしろ、この用語はサーバーによって解釈され、この情報に基づいて行動することを選択した各Webサイトの範囲内で解釈されます。
That said, the intent is to allow end users (or those acting on their behalf) to express a desire to avoid content that is considered objectionable within the cultural context of that site; usually (but not always), the objectionable content is content unsuitable for minors. The safe preference is not intended to be used for other purposes.
とはいえ、その目的は、エンドユーザー（またはその代理人）が、そのサイトの文化的コンテキスト内で好ましくないと見なされるコンテンツを避けたいという要望を表明できるようにすることです。通常（常にではありませんが）、不快なコンテンツは未成年者には不適切なコンテンツです。安全な設定は、他の目的で使用するためのものではありません。
Furthermore, sending the preference does not guarantee that the web site will use it or that it will apply a concept of "objectionable" that is consistent with the requester's views. As such, its effect can be described as "best effort" and not to be relied upon. In other words, sending the preference is no more reliable than going to each web site and manually selecting a safe mode, but it is considerably easier.
さらに、プリファレンスを送信しても、Webサイトがそれを使用すること、または要求者の見解と一致する「不快な」という概念を適用することは保証されません。そのため、その効果は「ベストエフォート」として説明でき、信頼することはできません。つまり、設定を送信することは、各Webサイトにアクセスして手動でセーフモードを選択することよりも信頼性は高くありませんが、はるかに簡単です。
It is also important to note that the safe preference is not a reliable indicator that the end user is a child; other users might have a desire for unobjectionable content, and some children might browse without the preference being set.
安全な設定は、エンドユーザーが子供であることを示す信頼できる指標ではないことにも注意してください。他のユーザーは問題のないコンテンツを望んでいる可能性があり、一部の子供は設定を行わずに閲覧する可能性があります。
Note also that the cultural context applies to the hosting location of a site, the content provider, and the source of the content. It cannot be guaranteed that a user agent and origin server will have the same view of the concept of what is objectionable.
文化的コンテキストは、サイトのホスティングロケーション、コンテンツプロバイダー、およびコンテンツのソースに適用されることにも注意してください。ユーザーエージェントとオリジンサーバーが不快なものの概念について同じ見解を持つことは保証できません。
Simply put, it is a statement by (or on behalf of) the end user indicating that "if your site has a safe setting, this user is hereby opting into that, according to your definition of the term."
簡単に言えば、「サイトに安全な設定がある場合、このユーザーは、用語の定義に従って、この設定を選択する」というエンドユーザー（またはその代理）による声明です。
The mechanism described in this document does not have IETF consensus and is not a standard. It is a widely deployed approach that has turned out to be useful and is presented here so that server and browser implementations can have a common understanding of how it operates.
このドキュメントで説明されているメカニズムには、IETFの合意がなく、標準ではありません。これは広く採用されているアプローチであり、有用であることが判明しました。ここでは、サーバーとブラウザーの実装がその動作方法について共通の理解を持つことができるようにここに示します。
This mechanism was presented for publication as an IETF Proposed Standard but was not approved for publication by the IESG because of concerns that included the vagueness of the meaning of "safe", the ability of a proxy to insert the hint outside of a user's control, the fact that there was no way to know whether the hint was or was not applied to the response returned by the server, and the possibility that the use of this preference may incentivize increased censorship and/or targeting of minors.
このメカニズムは、IETF Proposed Standardとして公開するために提示されましたが、「安全」の意味のあいまいさ、ユーザーの制御の外にヒントを挿入するプロキシの機能を含むため、IESGによる公開は承認されませんでした。ヒントがサーバーから返された応答に適用されたかどうかを知る方法がなかったという事実と、この設定を使用すると、検閲の増加や未成年者のターゲティングが促進される可能性があります。
The specification was updated to address those concerns, but the IESG did not approve progressing this document as an IETF Proposed Standard. As a result, it has been published in the Independent Stream.
仕様はこれらの懸念に対処するために更新されましたが、IESGはこのドキュメントの進行をIETF提案標準として承認しませんでした。その結果、Independent Streamで公開されました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
When present in a request, the safe preference indicates that the user prefers that the origin server not respond with content that is designated as objectionable, according to the origin server's definition of the concept.
リクエストに存在する場合、安全なプリファレンスは、ユーザーがオリジンサーバーの概念の定義に従って、オリジンサーバーが不快と指定されたコンテンツで応答しないことを好むことを示します。
For example, this is a request that includes the safe preference:
たとえば、これは安全な設定を含むリクエストです：
GET /foo.html HTTP/1.1
Host: www.example.org
User-Agent: ExampleBrowser/1.0
Prefer: safe
Typically, user agents that emit the safe preference will include it in all requests with the "https" URI scheme, although some might expose finer-grained controls over when it is sent; this ensures that the preference is available to the applicable resources. User agents MUST NOT emit the safe preference on requests with the "http" URI scheme (see Section 3). See Appendix A for more information about configuring the set of resources the safe preference is sent to.
通常、安全なプリファレンスを発行するユーザーエージェントは、「https」URIスキームを使用するすべてのリクエストにそれを含めますが、送信時に細かい制御を公開するものもあります。これにより、該当するリソースで設定を利用できるようになります。ユーザーエージェントは、 "http" URIスキーム（セクション3を参照）を使用したリクエストで安全な設定を発行してはなりません（MUST NOT）。安全なプリファレンスが送信されるリソースのセットの構成の詳細については、付録Aを参照してください。
The safe preference MAY be implemented in common HTTP libraries (e.g., an operating system might choose to insert the preference in requests based upon system-wide configuration).
安全な設定は、一般的なHTTPライブラリに実装される場合があります（たとえば、オペレーティングシステムは、システム全体の構成に基づいて、設定を要求に挿入することを選択する場合があります）。
Origin servers that utilize the safe preference ought to document that they do so, along with the criteria that they use to denote objectionable content. If a server has more fine-grained degrees of safety, it SHOULD select a reasonable default to use and document that; it MAY use additional mechanisms (e.g., cookies [RFC6265]) to fine-tune.
安全な設定を使用するオリジンサーバーは、不快なコンテンツを示すために使用する基準とともに、そうすることを文書化する必要があります。サーバーがよりきめ細かい安全性を備えている場合は、使用する適切なデフォルトを選択し、それを文書化する必要があります。追加のメカニズム（Cookie [RFC6265]など）を使用して微調整できます（MAY）。
A response corresponding to the request above might have headers that look like this:
上記のリクエストに対応するレスポンスには、次のようなヘッダーが含まれる場合があります。
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/html
Preference-Applied: safe
Server: ExampleServer/2.0
Vary: Prefer
Here, the Preference-Applied response header [RFC7240] indicates that the site has applied the preference. Servers are not required to send Preference-Applied (even when they have applied the preference) but are encouraged to where possible.
ここで、Preference-Applied応答ヘッダー[RFC7240]は、サイトが設定を適用したことを示しています。サーバーは、（設定を適用した場合でも）Preference-Appliedを送信する必要はありませんが、可能な限り推奨されます。
Note that the Vary response header needs to be sent if the response is cacheable and might change depending on the value of the Prefer header. This is not only true for those responses that are safe but also the default unsafe response.
応答がキャッシュ可能で、Preferヘッダーの値に応じて変更される可能性がある場合は、Vary応答ヘッダーを送信する必要があることに注意してください。これは、安全な応答だけでなく、デフォルトの安全でない応答にも当てはまります。
See Section 4.1 of [RFC7234] for more information about the interaction between the Vary header field and web caching.
Varyヘッダーフィールドとウェブキャッシュの間の相互作用の詳細については、[RFC7234]のセクション4.1をご覧ください。
See Appendix B for additional advice specific to web servers wishing to use the safe preference.
安全な設定を使用したいWebサーバーに固有の追加のアドバイスについては、付録Bを参照してください。
The safe preference is not a secure mechanism; it can be inserted or removed by intermediaries with access to the request stream (e.g., for "http" URLs). Therefore, it is prohibited from being included in requests with the "http" scheme.
安全な設定は安全なメカニズムではありません。リクエストストリームへのアクセス権を持つ仲介者によって挿入または削除できます（たとえば、「http」URLの場合）。そのため、「http」スキームのリクエストに含めることは禁止されています。
Its presence reveals information about the user, which may be of assistance in fingerprinting the user by sites and other entities in the network. This information provides insight into the preferences of the user and might be used to make assumptions about user; thus, it could be used to identify categories of users for purposes such as targeting (including advertising and identification of minors). Therefore, user agents SHOULD NOT include it in requests when the user has expressed a desire to avoid such attacks (e.g., some forms of private mode browsing).
その存在は、ユーザーに関する情報を明らかにします。これは、ネットワーク内のサイトや他のエンティティによるユーザーのフィンガープリント作成に役立つ可能性があります。この情報は、ユーザーの好みに対する洞察を提供し、ユーザーに関する仮定を行うために使用される場合があります。したがって、ターゲティング（広告や未成年者の識別を含む）などの目的でユーザーのカテゴリを識別するために使用できます。したがって、ユーザーがそのような攻撃を回避したいという要望を表明した場合、ユーザーエージェントはそれをリクエストに含めるべきではありません（例：プライベートモードブラウジングの一部の形式）。
By its nature, including the safe preference in requests does not ensure that all content will actually be safe; content is safe only when servers elect to honor it.
本質的に、リクエストに安全な設定を含めると、すべてのコンテンツが実際に安全になるとは限りません。コンテンツは、サーバーがそれを尊重することを選択した場合にのみ安全です。
Even then, a malicious server might adapt content so that it is even less safe (by some definition of the word). As such, this mechanism on its own is not enough to ensure that only safe content is seen; those who wish to ensure that will need to combine its use with other techniques (e.g., content filtering).
それでも、悪意のあるサーバーがコンテンツを改造して、（単語の定義によっては）安全性を低下させる可能性があります。そのため、このメカニズムだけでは、安全なコンテンツのみが表示されることを保証するには不十分です。それを確実にしたい人は、その使用を他の技術（例えば、コンテンツフィルタリング）と組み合わせる必要があります。
Furthermore, the server and user may have differing ideas regarding the semantics of "safe". As such, the safety of the user's experience when browsing from site to site, as well as over time, might (and probably will) change.
さらに、サーバーとユーザーは、「安全」のセマンティクスに関して異なる考えを持っている可能性があります。そのため、サイト間をブラウジングするときのユーザーエクスペリエンスの安全性は、時間とともに変化する可能性があります（おそらく変化します）。
Per this specification, IANA has registered the following entry in the "HTTP Preferences" registry [RFC7240]:
この仕様により、IANAは「HTTP Preferences」レジストリ[RFC7240]に次のエントリを登録しています。
* Preference: safe
* 好み：安全
* Description: Indicates that safe (i.e., unobjectionable) content is preferred.
* 説明：安全な（つまり、問題のない）コンテンツが優先されることを示します。
* Reference: RFC 8674
* リファレンス：RFC 8674
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<https://www.rfc-editor.org/info/rfc7234>。
[RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, DOI 10.17487/RFC7240, June 2014, <https://www.rfc-editor.org/info/rfc7240>.
[RFC7240] Snell、J。、「Prefer Header for HTTP」、RFC 7240、DOI 10.17487 / RFC7240、2014年6月、<https://www.rfc-editor.org/info/rfc7240>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[RFC6265] Barth、A。、「HTTP State Management Mechanism」、RFC 6265、DOI 10.17487 / RFC6265、2011年4月、<https://www.rfc-editor.org/info/rfc6265>。
Appendix A. Sending the "safe" Preference from Web Browsers
付録A. Webブラウザーからの「安全な」設定の送信
As discussed in Section 2, there are many possible ways for the safe preference to be generated. One possibility is for a web browser to allow its users to configure the preference to be sent.
セクション2で説明したように、安全な設定を生成するには多くの方法があります。 1つの可能性は、Webブラウザーがそのユーザーに送信される設定を構成できるようにすることです。
When doing so, it is important not to misrepresent the preference as binding to web sites. For example, an appropriate setting might be a checkbox with wording such as:
その際、設定をWebサイトへのバインドと偽って伝えないことが重要です。たとえば、適切な設定は次のような文言のチェックボックスです。
[] Request safe content from web sites
[] Webサイトから安全なコンテンツをリクエストする
along with further information available upon request.
リクエストに応じて利用可能な詳細情報とともに。
Browsers might also allow the safe preference to be locked to prevent modification without administrative access or a passcode.
ブラウザでは、安全な設定をロックして、管理アクセスやパスコードなしでの変更を防ぐこともできます。
Note that this specification does not require browsers to send the safe preference on all requests, although that is one possible implementation; alternate implementation strategies include blacklists and whitelists.
この仕様では、ブラウザがすべてのリクエストで安全な設定を送信する必要はありませんが、これは可能な実装の1つです。代替の実装戦略には、ブラックリストとホワイトリストが含まれます。
Appendix B. Supporting the "safe" Preference on Web Sites
付録B. Webサイトの「安全な」設定のサポート
Web sites that allow configuration of a safe mode (for example, using a cookie) can add support for the safe preference incrementally; since the preference will not be supported by all clients immediately, it is necessary to have another way to configure it.
セーフモードの構成（たとえば、Cookieの使用）を許可するWebサイトは、セーフ設定のサポートを段階的に追加できます。プリファレンスはすべてのクライアントですぐにサポートされるわけではないため、別の方法で構成する必要があります。
When honoring the safe preference, it is important that it not be possible to disable it through the web site's interface, since the safe preference may be configured and locked down by the browser or computer's administrator (e.g., a parent). If the site has such a means of configuration (e.g., stored user preferences) and the safe preference is received in a request, the "safer" interpretation ought to be used.
安全な設定は、ブラウザまたはコンピューターの管理者（親など）によって構成およびロックされる可能性があるため、安全な設定を尊重する場合、Webサイトのインターフェイスから無効にできないことが重要です。サイトにそのような構成手段（たとえば、保存されているユーザー設定）があり、安全な設定がリクエストで受信された場合、「より安全な」解釈を使用する必要があります。
The appropriate level of safety is a site-specific decision. When selecting it, sites ought to bear in mind that disabling the preference might be considerably more onerous than using other means, especially if the preference is generated based upon the operating system configuration.
安全性の適切なレベルは、サイト固有の決定です。それを選択するとき、特に設定がオペレーティングシステムの構成に基づいて生成されている場合、設定を無効にすることは他の手段を使用するよりもかなり面倒になる可能性があることをサイトは覚えておく必要があります。
Sites might offer different levels of safety through web configuration; they will need to either inform their users of what level the safe hint corresponds to or provide them with some means of adjusting it.
サイトによっては、Web構成を通じてさまざまなレベルの安全性が提供される場合があります。安全なヒントが対応するレベルをユーザーに通知するか、ユーザーにそれを調整する手段を提供する必要があります。
If users express a wish to disable safe mode, the site can remind them that the safe preference is being sent and ask them to consult their administrator (since the safe preference might be set by a locked-down operating system configuration).
ユーザーがセーフモードを無効にすることを希望する場合、サイトはセーフ設定が送信されていることをユーザーに通知し、管理者に問い合わせるよう依頼できます（安全な設定はロックダウンされたオペレーティングシステム構成によって設定される可能性があるため）。
As explained in Section 2, responses that change based upon the presence of the safe preference need to either carry the "Vary: Prefer" response header field or be uncacheable by shared caches (e.g., with a "Cache-Control: private" response header field). This is to avoid an unsafe cached response being served to a client that prefers safe content (or vice versa).
セクション2で説明したように、安全設定の存在に基づいて変化する応答は、「Vary：Prefer」応答ヘッダーフィールドを保持するか、共有キャッシュでキャッシュできないようにする必要があります（たとえば、「Cache-Control：private」応答ヘッダーを使用）。フィールド）。これは、安全なコンテンツを好むクライアントに安全でないキャッシュされた応答が提供されるのを防ぐためです（またはその逆）。
Acknowledgements
謝辞
Thanks to Alissa Cooper, Ilya Grigorik, Emma Llanso, Jeff Hughes, Lorrie Cranor, Doug Turner, and Dave Crocker for their comments.
コメントを提供してくれたAlissa Cooper、Ilya Grigorik、Emma Llanso、Jeff Hughes、Lorrie Cranor、Doug Turner、Dave Crockerに感謝します。
Author's Address
著者のアドレス
Mark Nottingham
マーク・ノッティンガム
Email: mnot@mnot.net
URI: https://www.mnot.net/