A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://www.asahi-net.or.jp/~ax2s-kmtn/internet/link/REC-webmention-20170112.html below:

Webmention

【注意】 このドキュメントは、W3CのWebmention W3C Recommendation 12 January 2017の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2017年1月20日

要約

Webmentionは、自身のサイトで任意のURLについて言及する時に、そのことを通知するシンプルな方法です。受信者の観点から見れば、他のサイトで言及される時に通知をリクエストする方法の1つです。

この項は非規範的です。

この仕様は、IndieWebコミュニティからW3Cに寄稿されました。Webmentionに関するより詳細な歴史と発展については、IndieWeb wikiで見ることができます。

このドキュメントのステータス

この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。

このドキュメントは、ソーシャル・ウェブ・ワーキンググループによって勧告として公開されました。このドキュメントに関してコメントを行いたい場合には、public-socialweb@w3.org(購読、アーカイブ)にお送りください。どのようなコメントでも歓迎します。

ワーキンググループの実装報告書を参照してください。

このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。

このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

W3Cは、この勧告で指定されている機能はFetchに対する変更の影響を受けないと予想しています。

このドキュメントは、2015年9月1日のW3Cプロセス・ドキュメントによって管理されています。

目次
  1. 1. はじめに
    1. 1.1 ソーシャル・ウェブ・ワーキンググループ
    2. 1.2 背景
    3. 1.3 概要
    4. 1.4 プロトコルの要約
  2. 2. 適合性
    1. 2.1 適合性のクラス
    2. 2.2 テストスイートと報告
  3. 3. Webmentionプロトコル
    1. 3.1 Webmentionの送信
      1. 3.1.1 ターゲットに関して言及するソース・ドキュメントの作成
      2. 3.1.2 送信者による受信者Webmentionエンドポイントの発見
      3. 3.1.3 送信者による受信者への通知
      4. 3.1.4 更新された投稿に対するWebmentionの送信
      5. 3.1.5 削除された投稿に関するWebmentionの送信
    2. 3.2 Webmentionの受信
      1. 3.2.1 リクエストの検証
      2. 3.2.2 Webmentionの検証
      3. 3.2.3 エラー応答
      4. 3.2.4 既存のWebmentionの更新
  4. 4. セキュリティに関する留意点
    1. 4.1 悪用の防止
    2. 4.2 GETリクエストの限界
    3. 4.3 ローカルホストへのWebmentionの送信回避
    4. 4.4 クロスサイト・リクエスト・フォージェリ
    5. 4.5 保護されている資源へのアクセス制限
    6. 4.6 セキュリティとプライバシーの点検
  5. 5. その他の留意点
    1. 5.1 HTMLではないコンテンツからのWebmentionの送信
    2. 5.2 大規模データセットに対するWebmentionの送信
    3. 5.3 発見におけるキャッシュ・ヘッダーの尊重
  6. 6. IANAに関する留意点
  7. A. フォーム・エンコードされたプロパティのURI
  8. B. 拡張
    1. B.1 Vouch
    2. B.2 Salmention
    3. B.3 Private Webmention
  9. C. 資源
    1. C.1 記事
    2. C.2 実装
  10. D. 謝辞
  11. E. 変更履歴
    1. E.1 11月1日の勧告案から勧告までの変更
  12. F. 参考文献
    1. F.1 規範的な参考文献
    2. F.2 参考情報の参考文献
1. はじめに

Webmentionは、あるURLが別のURLにリンクされているという通知です。例えば、アリス(Alice)が彼女のブログで面白い投稿を行ったとします。そして、ボブ(Bob)が彼自身のサイトで、彼女の投稿に対する応答を、アリスの元の投稿にリンクして書きます。ボブの公開用ソフトウェアにより、彼女の記事に応答があったことを通知するWebmentionがアリスに送信されると、アリスのソフトウェアは、その応答を元の投稿に関するコメントとして表示できます 。

Webmentionの送信はブログの投稿に限らず、その他の種類のコンテンツや応答にも使用できます。例えば、応答は、イベントへのRSVP(回答リクエスト)、他者の投稿に対する「お気に入り」の表示、他者の投稿の「ブックマーク」など、様々なものでありえます。Webmentionは、別々のウェブサイトでこれらの相互作用を可能にし、分散型のソーシャル・ウェブを可能にします。

1.2 背景

この項は非規範的です。

Webmention仕様は、[Pingback]仕様を簡素化したバージョンとして始まりました。PingbackではソースとターゲットのURLをXML-RPCペイロードで送信する必要があったのを、Webmentionでは、フォーム・エンコードされたペイロードに簡素化しており(HTMLのフォームで容易に使用できるように)、フォーム・エンコードされたペイロードに対応するツールは多く存在しており、XML-RPCによるシステムの他の部分のコードの思いがけない露呈に弱くありませんでした。

その後、Webmentionは、リクエストの送信と検証の詳細についても引き続きより完全に規定し、ソース・ドキュメントが更新または削除された時の通知の送信をサポートするように拡張されました。より詳細な情報がIndieWeb wikiのWebmention FAQにあるもしれません。

1.3 概要

この項は非規範的です。

典型的なWebmention流れは次の通りです。

  1. アリスがいくつかの面白いコンテンツを彼女のサイトに投稿します（Webmentionを受信するように設定）。
  2. ボブがこのコンテンツを見て彼のサイトでそれに関するコメントを行い、アリスの元の投稿にリンクを返します。
  3. ボブの公開用ソフトウェアが、Webmentionを用いて、アリスの投稿がボブの投稿のURLによってリンクされたことを彼女のサーバーに自動的に通知します。
  4. アリスの公開用ソフトウェアが、彼女の投稿に関する言及が実際にボブの投稿に含まれているかを検証した後に、彼女のサイトにこの情報を掲載します。
1.4 プロトコルの要約

この項は非規範的です。

Webmentionは、ターゲットについてソースURLで言及されたことをそのターゲットに通知するために、ソースURL「から」ターゲットURL「に」送信されます。

  1. アーロン(Aaron)というユーザが、彼のブログで投稿を行います。
  2. バーナビー(Barnaby)というユーザが、アーロンの投稿にリンクされている彼のブログで投稿を行います。
  3. 投稿を公開した後に(つまり、投稿がURLを持った後に)、バーナビーのサーバーは、公開プロセスの一部としてアーロンの投稿の言及に気づきます。
  4. バーナビーのサーバーは、Webmentionエンドポイントを見つけるために、アーロンの投稿でWebmention発見を行います(見つからなければ、プロセスを終了)。
  5. バーナビーのサーバーは、下記を含んだWebmention通知をアーロンの投稿のWebmentionエンドポイントに送信します。
  6. アーロンのサーバーがWebmentionを受信します。
  7. アーロンのサーバーは、Webmentionのtargetがアーロンのブログ上の有効なpermalinkであるかを検証します(そうでなければ、プロセスを終了)。
  8. アーロンのサーバーは、targetに対するハイパーリンクがWebmention(リダイレクト後の、検索時に[FETCH])のsourceに含まれているかを検証します(そうでなければ、プロセスを終了)。
2. 適合性

このドキュメントの「しなければならない(MUST)」、「してはならない(MUST NOT)」、「必須である／要求される(REQUIRED)」、「することになる(SHALL)」、「することはない(SHALL NOT)」、「すべきである／する必要がある(SHOULD)」、「すべきでない／する必要がない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「することができる／してもよい(MAY)」、「選択できる／任意である(OPTIONAL)」というキーワードは、[RFC2119]で記述されているように解釈されるべきです。

2.1 適合性のクラス

Webmentionの実装は、送信者か受信者のいずれかです。この項では両者に対する適合性基準について記述します。

下記は、既知の種類のWebmention実装です。

送信者

Webmention送信者(Webmention Sender)は、Webmentionを送信する実装です。送信者がWebmentionを送信するためには、受信者がアクセスできるURLに最初にドキュメントがなければなりません。

Webmention送信者の適合性基準については、Webmentionの送信で説明しています。

下記は、いくつかの既知の種類のWebmention送信者です。

受信者

Webmention受信者(Webmention Receiver)は、受信者のWebmentionエンドポイントが公言されている1つ以上のターゲットURLに対するWebmentionを受信する実装です。Webmentionを受信するためには、受信者のWebmentionエンドポイントを公言するURLがなければなりません。そのURLは、完全に別のシステムやドメインに存在しえるため、受信者の実装の一部とは見なされません。

Webmention受信者の適合性基準については、Webmentionの受信で説明しています。

下記は、いくつかの既知の種類のWebmention受信者です。

2.2 テストスイートと報告

http://webmention.net/implementation-reports/で実装報告を提出してください。手順は当該URLで提供しています。実装報告テンプレートは、webmention.rocksで入手可能なテストを参照します。

webmention.rocksでは、自身の実装の実演テストを行うために用いることができる多くのテストケースが提供されています。エラー発生時に詳細なレスポンスが得られるため、Webmention実装の開発中に用いると有用なツールでもあります。

3. Webmentionプロトコル

この仕様は、HTMLとHTTPの両方のリンク関係に関して[HTML5]で定義されているとおりにlink relレジストリを用います。

3.1 Webmentionの送信 3.1.1 ターゲットに関して言及するソース・ドキュメントの作成

Webmentionは、ターゲットについてソースURLで言及されたことをそのターゲットに通知するために、ソースURL「から」ターゲットURL「に」送信されます。Webmentionが送信可能となる前に、Webmentionの送信先となるソースURLが存在している必要があり、それはブログの投稿であることが多いですが、どのような種類のコンテンツであってもかまいません。

例えば、https://waterpigs.example/post-by-barnabyのURLに、アーロンの投稿へのリンクを有する下記のHTMLを記述することができます。

例1

<!doctype html>
<html>
  <body>
    <a href="https://aaronpk.example/post-by-aaron">This is a great post</a>
  </body>
</html>
3.1.2 送信者による受信者Webmentionエンドポイントの発見

送信者は、ターゲットURLを取って来て(そして、リダイレクトに従い[FETCH])、webmentionというrelの値を持つHTTP Linkヘッダー[RFC5988]をチェックしなければなりません(MUST)。ドキュメントのコンテンツ・タイプがHTMLである場合、送信者は、webmentionというrelの値を持つHTMLの<link>と<a>要素を探さなければなりません(MUST)。これらが複数存在している場合は、最初のHTTP Linkヘッダーが優先され、その後にドキュメントの順に最初の<link>または<a>の要素が続きます。送信者は、3つのオプションをすべてサポートし、この順序でフォールバックを行わなければなりません(MUST)。

エンドポイントは相対URLでありえ(MAY)、その場合、送信者は[URL]に従ってtarget URLに対して相対的にそれを解決しなければなりません(MUST)。

エンドポイントにはクエリ文字列パラメータを含むことができ(MAY)、それは、クエリ文字列パラメータのまま保持されなければならず(MUST)、Webmentionリクエストの送信時にPOSTのBODYパラメータとして送信してはなりません(MUST NOT)。

送信者は、GETリクエストを行う前に最初にHTTP HEADリクエスト[RFC7231]を行ってLinkヘッダーをチェックすることができます(MAY)。

例2

GET /post-by-aaron HTTP/1.1
Host: aaronpk.example
HTTP/1.1 200 OK
Link: <http://aaronpk.example/webmention-endpoint>; rel="webmention"

<html>
<head>
...
<link href="http://aaronpk.example/webmention-endpoint" rel="webmention" />
...
</head>
<body>
....
<a href="http://aaronpk.example/webmention-endpoint" rel="webmention">webmention</a>
...
</body>
</html>

送信者は、このリクエストがWebmention発見の一部として行われることを受取人に示すために、ターゲットURLを取って来る際に用いるHTTP User Agent[RFC7231]をカスタマイズすることができます(MAY)。その場合、User Agentに「Webmention」という文字列を含めることをお奨めします。これにより、なぜ発見のリクエストが行われたかを知るための示唆が与えられます。

3.1.3 送信者による受信者への通知

送信者は、x-www-form-urlencoded[HTML5]形式のsourceとtargetのパラメータをWebmentionエンドポイントにポストしなければならず(MUST)、そのsourceはリンクを含んだ送信者ページのURLであり、targetはリンク先ページのURLです。

WebmentionエンドポイントURLにクエリ文字列パラメータが含まれている場合は、クエリ文字列パラメータはそのまま保持されなければならず(MUST)、POSTのBODYに送信されてはならない(MUST NOT)ことに注意してください。

Webmentionエンドポイントはリクエストを認証して処理し、HTTPステータス・コード[RFC7231]を返します。ほとんどの場合、202 Accepted(受理)か201 Created(生成)が返されます。これは、DoS(Denial of Service)攻撃を防止するために、リクエストがキューに入れられ、非同期的に処理されていることを示します。応答コードが201であれば、Locationヘッダーには、リクエストのステータスをモニターするために使用できるURLが含まれるでしょう。

あらゆる2xxの応答コードは成功とみなされなければなりません(MUST)。

例3

POST /webmention-endpoint HTTP/1.1
Host: aaronpk.example
Content-Type: application/x-www-form-urlencoded

source=https:
target=https:


HTTP/1.1 202 Accepted
3.1.4 更新された投稿に関するWebmentionの送信

ソースURLが更新された場合は、送信者は以前に送信したWebmentionを再送信すべきで(SHOULD)(ドキュメントから削除された可能性があるURLに対するWebmentionの再送を含む)、そのURLで表示される新しいリンクにWebmentionを送信すべきです(SHOULD)。

これにより、Webmentionの受取人がソース・ドキュメントの表示を更新すること、または、URLのうちの1つについて言及した投稿が更新されたことを受取人に通知することが可能となります。

投稿が変更された際にWebmentionを送信する時には、送信者は、ターゲットがWebmentionエンドポイントを更新してしまっている場合に備え、各ターゲットURLのWebmentionエンドポイントの再発見を行わなければなりません(MUST)。

ソースURLへの応答がソースURLページで示されていれば(例えば、コメントとして)、送信者はそれをソースURLの更新として扱い、以前に送信したWebmentionを再送信すべきです(SHOULD)。

3.1.5 削除された投稿に関するWebmentionの送信

ソースURLが削除された場合は、送信者はそのURLに対してHTTP 410 Gone(消滅)のステータス・コードを返すべきで(SHOULD)、一般的に、投稿のプロパティーの値を空白にする、および／または、投稿の主要なコンテンツ(例えば、[h-entry]の名前および／またはコンテンツ)を「削除」に置き換えるなどの方法で、削除された投稿の「tombstone」(墓石。訳注:削除されたオブジェクトを表す)表現を表示すべきです(SHOULD)。その後、送信者はそのドキュメントに対し以前に送信したすべてのWebmentionにWebmentionを再送信すべきです(SHOULD)。

これにより、以前受信したWebmentionをコメントやその他の相互作用として表示していたであろう受信者は、削除をサポートしている場合には、更新のみをサポートしている受信者には妥当なフォールバックを提供しつつ、それを表示から削除することが可能となります。

3.2 Webmentionの受信

sourceとtargetのパラメータが含まれているPOSTリクエストを受信した時には、受信者はそのパラメータを検証すべきで(SHOULD)(下記のリクエストの検証を参照)、DoS攻撃を防止するために、リクエストをキューに入れ、非同期的に処理すべきです(SHOULD)。受信者がそれを処理する方法により、リクエストへの応答は3種類ありえます。

ステータスをチェックするために送信者が使用できるステータス・ページを受信者が作成する場合、受信者は、ステータスURLを指し示すLocationヘッダーを持つHTTP 201 Created(生成)という応答で回答しなければなりません(MUST)。応答のBODYにはコンテンツを含むことができます(MAY)。

例4

HTTP/1.1 201 Created
Location: http://aaronpk.example/webmention/DEhB9Jme

受信者がリクエストを非同期的に処理したにも関わらず、ステータスURLを返さない場合は、受信者はHTTP 202 Accepted(受理)という応答で回答しなければなりません(MUST)。応答のBODYにはコンテンツを含むことができ(MAY)、その場合、人間が読める応答が推奨されます。

例5

HTTP/1.1 202 Accepted

受信者がリクエストを処理し、検証ステップを同期的に実行することを選択すれば(非推奨)、成功時に200 OK(OK)のステータスで応答しなければなりません(MUST)。

3.2.1 リクエストの検証

受信者は、sourceとtargetが有効なURL[URL]であり、受信者がサポートしているスキームであることをチェックしなければなりません(MUST)。(ほとんどの場合、これは、sourceとtargetのスキームがhttpまたはhttpsであることをチェックすることを意味します)。

ソースURLがターゲットURLと同じであれば、受信者はリクエストを拒否しなければなりません(MUST)。

受信者は、targetが、Webmentionを受け入れることができる有効な資源であるかをチェックすべきです(SHOULD)。より詳細な検証を開始する前に無効なWebmentionを拒否するために、このチェックは同期的に行われるべきです(SHOULD)。「有効な資源」が何を意味するかは、受信者次第です。例えば、複数のドメインに対してWebmentionを受け入れることができる受信者もいれば、エンドポイントが置かれているのと同じドメインに対してのみWebmentionを受け入れることができる受信者もいます。

ターゲットURLにフラグメント識別子が含まれているかもしれないことに注意してください。そして、どのURLがWebmentionを受信できるのかを受信者が制限している場合には、URLがサポートされているかどうかをチェックする時にフラグメントを無視すべきです(SHOULD)。

3.2.2 Webmentionの検証

Webmentionの検証は、DoS(Denial of Service)攻撃を防止するために、非同期的な処理によるべきです(SHOULD)。

受信者が何らかの方法(投稿に関するコメントとして表示したり、「お気に入り」カウンターの数を増やしたり、投稿の著者を通知したり)でWebmentionを使おうとする場合、実際にそれがターゲットについて言及していることを確認するために、HTTPリダイレクトに従い(従うリダイレクトの数は制限すべき(SHOULD))、ソースにHTTP GETリクエストを実行しなければなりません(MUST)。受信者は、受け入れ可能なコンテンツ・タイプのプレファレンスを示すHTTP Acceptヘッダーを含めるべきです(SHOULD)。

受信者は、ソース・ドキュメントがターゲットURLについて言及しているかどうかを判断するためにper-media-typeの規則を用いるべきです(SHOULD)。例えば、[HTML5]ドキュメントでは、受信者は<a href="*">、<img href="*">、<video src="*">などのリンクを捜すべきです。JSON（[RFC7159]）ドキュメントでは、受信者は、値がURLに完全一致するプロパティーを捜すべきです。ドキュメントがプレーン・テキストである場合は、受信者は文字列を検索してURLを捜すべきです。その他のコンテンツ・タイプは実装者の裁量で処理できます。ソース・ドキュメントには、それが有効なWebmentionと見なされるために、target URLの完全一致が含まれていなければなりません(MUST)。

この段階で、受信者は、ソース・ページのコンテンツを、ソースから入手したその他のデータとともに、ターゲットのページやその他のページに掲載することができます(MAY)。例えば、受信者は、ソースのコンテンツを投稿に関するコメントとして表示したり、投稿を「お気に入り」にした人達のリストを表示するなど、同じようなWebmentionを送信した他の人達のリストに著者のプロフィール写真を表示したりすることができます。

注

ソース・ページのコンテンツを再掲載する時には、うっかりそのコンテンツの公開範囲を変更してしまわないように気をつけるべきです。例えば、制限された対象者にのみソース・ドキュメントを表示できる場合は、再掲載されたコンテンツが一般ユーザには決して表示されないようにすべきです。ソース・ドキュメントは、何らかの認証によって、または、受信者もその内側にいるファイアウォール内にソースURLがあるために、特定の対象者にに限定されているかもしれません。

3.2.3 エラー応答

送信者の行為が原因でWebmentionが成功しなかった場合は、400 Bad Request(不正リクエスト)のステータス・コードを返さなければならず(MUST)、応答本文にエラーの説明を含めることができます(MAY)。

ソースに対してGETリクエストを行う前に同期的に返される可能性のある送信者関連エラーは次のとおりです。

ソースURLのコンテンツを取って来た後に生じる可能性のある送信者関連エラーは次のとおりです。

受信者のサーバー側のエラーが原因でWebmentionが成功しなかった場合は、500 Internal Server Error(サーバー内部エラー)のステータス・コードを返すべきで(SHOULD)、応答本文にエラーの説明を含めることができます(MAY)。

3.2.4 既存のWebmentionの更新

受信者が、過去に同じsourceとtargetのWebmentionを受け取ったことがある場合は、次のとおりです。

4. セキュリティに関する留意点 4.1 悪用の防止 4.2 GETリクエストの限界

Webmentionプロトコルは、受信者のエンドポイントを発見するためにGET(またはHEAD)リクエストを行う送信者に依存し、その後に、リンクを検証するために送信者のウェブ・ページに対してGETリクエストを行う受信者が続きます。これは、送信者が受信者に任意のURLへのGETリクエストを実行させることができることを意味し、DoS媒介者の可能性が広がります。

受信者は、リンクの検証時に最初のHTTP HEADリクエストを行い、コンテンツ・タイプ、長さ、またはその他の返されたHTTPヘッダーを最初に検証した後に完全なGETリクエストを行うかどうかを決定できます(MAY)。

受信者は、送信者がリダイレクトを送信し続けた場合に、リダイレクトのループから抜け出せなくなるのを防止するために、数を20に制限するなど、従うHTTPリダイレクトの数に制限を設けるべきです(SHOULD)。

受信者は、未検証ソースURLを取得するデータ量と時間に制限を設けるべきです(SHOULD)。例えば、ソースURLが5秒以内に応答しなければ、失敗とみなすことができます。同様に、受信者は、そのページの最初の1MBのみを取って来ることができます。なぜなら、妥当なHTMLやJSONページはそれより小さいからです。

4.3 ローカルホストへのWebmentionの送信回避

送信者が受信者のWebmentionエンドポイントを発見した時に、そのエンドポイントがローカルホストやその他のループバック・アドレスであるというもっともな理由はほとんどありません。送信者が、認証が不要なローカルホストで動作するサービスを持っていれば、悪意のあるWebmention受信者は、送信者に任意のPOSTリクエストを行わせることができるWebmentionエンドポイントを作り出すことができます。

発見段階で、エンドポイントがローカルホストやループバックIPアドレス(127.0.0.0/8)であることに送信者が気づいた場合は、そのエンドポイントにWebmentionを送信すべきではありません(SHOULD NOT)。

4.4 クロスサイト・リクエスト・フォージェリ

この仕様は、認証ヘッダーやセッション・クッキーなどの追加のヘッダーやパラメータが含まれている可能性のあるWebmentionリクエストの特別な処理については定義していません。しかし、Webmentionエンドポイントが追加のヘッダーのあるリクエストを受け入れる場合は、クロスサイト・リクエスト・フォージェリ(CSRF)攻撃から自身を守るべきです(SHOULD)。CSRF攻撃を防止する1つの方法は、エンドポイントを発見する時にWebmention送信者がトークンを見つけられるように、Webmentionエンドポイントのクエリ文字列パラメータにCSRFトークンを含めることです。

例えば、ターゲットURLは、CSRFトークンが含まれているWebmentionエンドポイントを公言できます。

例6

GET /post-by-aaron HTTP/1.1
Host: aaronpk.example
HTTP/1.1 200 OK
Link: <http://aaronpk.example/webmention?csrf=Q0NTVhYjI0NTVkNDA3M>; rel="webmention"

その結果、Webmentionエンドポイントがリクエストを処理する時には、他の処理の前にCSRFトークンの妥当性を最初にチェックできます。

4.5 保護されている資源へのアクセス制限

攻撃者は、任意のURLを指し示すWebmentionエンドポイントを公言することができます。そのため、ファイアウォール内にあるサーバーや、通常は保護されている資源にアクセスできるサーバー上でWebmentionを送信するソフトウェアをインストールする場合、攻撃者がそのサーバーに対して、内部のサーバーにPOSTリクエストを送信させることができることを知っておくべきです。このサーバーが、次のどちらの場合も、保護されている資源にアクセスできないように予防策を講じるべきです(SHOULD)。

4.6 セキュリティとプライバシーの点検

自己点検質問票: セキュリティとプライバシー([security-privacy-questionnaire])に従って、下記の質問で、この仕様のセキュリティとプライバシーに関する留意点の概要を把握できます。

この仕様は、個人を特定できる情報を扱いますか?
Webmentionに関して唯一個人情報でありえるのはソースとターゲットのURLです。
この仕様は、価値の高いデータを扱いますか?
いいえ、関連する認証やその他の証明はありません。
この仕様は、複数の閲覧セッションにまたがって持続する新たな状態をオリジンに導入しますか?
いいえ
この仕様は、持続的なクロス・オリジンの状態をウェブで公開しますか?
Webmention受信者はWebmentionリクエストに関する情報を用いて一時的な資源を作成できます。
この仕様は、現在アクセスできないその他のデータをオリジンに公開しますか?
いいえ
この仕様は、新たなスクリプトの実行／読み込みメカニズムを可能としていますか?
いいえ
この仕様は、ユーザの所在へのアクセスをオリジンに認めていますか?
いいえ
この仕様は、ユーザのデバイス上のセンサーへのアクセスをオリジンに認めていますか?
いいえ
この仕様は、ユーザのローカル・コンピューター環境側へのアクセスをオリジンに認めていますか?
いいえ
この仕様は、他のデバイスへのアクセスをオリジンに認めていますか?
いいえ
この仕様は、ユーザ・エージェントのネイティブなUIを制御する手段をオリジンに認めていますか?
いいえ
この仕様は、一時的な識別子をウェブに公開しますか?
いいえ
この仕様は、当事者と第三者のコンテキストの挙動を区別しますか?
いいえ
この仕様は、ユーザ・エージェントの「シークレット」モード(incognito mode)のコンテキストにおいてどのように動作すべきですか?
Webmentionはいかなる状態も保持しないため、「シークレット」モード時における留意点はありません。
この仕様は、ユーザのローカルなデバイスにデータを保持しますか?
いいえ
この仕様は、デフォルトのセキュリティ特性をダウングレードすることを認めていますか?
いいえ
5. その他の留意点 5.1 HTMLではないコンテンツからのWebmentionの送信

ソース・ドキュメントがHTMLではなかったり(PDFなど)、シンプルなHTTP GETリクエストでは生のソースを取って来ることができなかったりする場合(ペイウォール内や、クリック・スルーのライセンス契約など)は、Webmentionを送信したいすべてのターゲットをリストアップしたHTMLの「ランディング・ページ」を設ける必要があります。このHTMLのランディング・ページを作成した後で、Webmentionの送信時に、そのURLをソースURLとして用いることができます。これにより、受信者は、完全なソース・ドキュメントの公表を避けながら、自身のターゲットURLに対するリンクを検証するために取って来ることができるURLを得ることができます。

HTMLのランディング・ページの作成は、学術論文などの制限的なコンテンツを参照する時のリンク先として便利な場所を提供することにより、自身のコンテンツに対するインバウンド・リンクの数を増大させるのに役立つ可能性があります。学術論文の場合、WebmentionターゲットURLとして使用できるように、ランディング・ページにはHTMLの参考文献リストが含まれているべきです。

5.2 大規模データセットに対するWebmentionの送信

Webmentionソース・ドキュメントが特に大きい場合は(表内に数千のレコードが含まれている大きなHTMLページや、非常に大きなJSONファイルなど)、そのソースURLを有するWebmentionを送信することは避けたいでしょう。それを行うと、自身の帯域幅の多くを用いて、受信者に全データセットをダウンロードさせることになります。あるいは、受信者は、自身の帯域幅の使用を限定するために、ファイルの最初の部分のみをダウンロードするかもれしず、潜在的に検証が失敗することになります。受信者があなたのソース・ドキュメントに再度リンクを掲載すれば、他の訪問者がそのリンクをたどり、不用意に全データセットをダウンロードするかもしれません。

ブラウザでの閲覧時には、大きなデータセットを複数のページに分割するのがよい慣行と考えられているのと同じくらい、Webmentionの送信時には、ソース・ドキュメントが大きければ、データのより小さなページからのみWebmentionを送信すべきです。データセットがHTMLであれば、(おそらく)既存のHTMLページをソースURLとして使用できます。データセットがJSONであれば、ソースURLとして使用できるページのより小さなJSONドキュメントでURLを作成する必要があるかもしれません。

6. IANAに関する留意点

下記のリンク関係型が[RFC5988]の6.2.1項でIANAにより登録されています。

関係名:
webmention
説明:
WebmentionプロトコルをサポートするターゲットURIを識別する。これにより、何らかの形の公開プロセスで資源について言及するクライアントがそのエンドポイントにコンタクトし、この資源が言及されたと知らせることができる。
参照:
W3C Webmention仕様(http://www.w3.org/TR/webmention/)
注:
これは、Refback、Trackback、Pingbackのものと同様の「Linkback」メカニズムである。しかし、異なるプロトコルが用いられており、したがって、独自のリンク関係型で発見できるべきである。
A. フォーム・エンコードされたプロパティのURI

実装においてsourceとtargetのパラメータをURIとして扱いたい場合は、その用語にhttp://www.w3.org/ns/webmention#という接頭辞を付与できます。

B. 拡張

この項は非規範的です。

下記のWebmention拡張仕様には、ウェブ上で実演できる2+相互運用が可能な実装があるため、ここで掲載しています。

B.1 Vouch

[Vouch]プロトコルはWebmentionに対するアンチ・スパム拡張です。

B.2 Salmention

[Salmention]プロトコルは、コメントやその他の相互作用を広めるためのWebmentionに対する拡張です。

B.3 Private Webmention

[Private-Webmention]プロトコルは、アクセス制御を有する投稿に対するWebmentionの送信と検証をサポートするWebmentionに対する拡張です。

C. 資源

この項は非規範的です。

C.1 記事

この項は非規範的です。

Webmentionに関する記事のリストはIndieWeb wikiで見つけることができます。

C.2 実装

この項は非規範的です。

Webmention実装のリストはwebmention.netで見つけることができます。

D. 謝辞

編集者は、Webmentionの元のドラフト仕様の提供に関し、Sandeep Shettyに感謝を表します。

さらに、編集者は、サポート、激励および熱意に関し、IndieWebコミュニティおよびその他の実装者(Amy Guy、Benjamin Roberts、Ben Werdmuller、Dave Wilkinson、Rob SandersonおよびTantek Celikを含むがこれに限らない)に感謝を表します。

E. 変更履歴

この項は非規範的です。

E.1 11月1日の勧告案から勧告までの変更 F. 参考文献 F.1 規範的な参考文献
[FETCH]
Anne van Kesteren. WHATWG. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML5]
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. HTML5. 28 October 2014. W3C Recommendation. URL: https://www.w3.org/TR/html5/
[RFC2119]
S. Bradner. IETF. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC5988]
M. Nottingham. IETF. Web Linking. October 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5988
[RFC7231]
R. Fielding, Ed.; J. Reschke, Ed.. IETF. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7231
[URL]

注: URLは様々な方法、様々なコンテキストで使用できます。厳密なURLを作成するためには、[RFC3986]と[RFC3987]を検討すると良いかもしれません。URLの仕様では、URLという用語、URLを扱うための様々なアルゴリズム、URLを構築、解析、解決するためのAPIが定義されています。開発者は、https://url.spec.whatwg.org/の進展を観察し、最新のURL開発についていくことをお奨めします。

警告として述べると、ウェブブ・ラウザと、HTMLコンテキストの外にあるその他のソフトウェアの山では、URLを処理する方法に著しい違いがあります。既存のWebコンテンツを壊すようなURL処理は受け入れられませんが、URL処理のある重要な部分は、実装に依存すると見なすべきです(例えば、file: URLの解析や、[RFC3986][RFC3987]構文下で構文エラーとなるようなURLの操作)。

Anne van Kesteren. WHATWG. URL Standard. Continually Updated Specification. URL: https://url.spec.whatwg.org/
F.2 参考情報の参考文献
[CSRF]
OWASP. Cross-Site Request Forgery. Living Document. URL: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
[Pingback]
Stuart Langridge; Ian Hickson. hixie.ch. Pingback 1.0. Stable Specification. URL: http://www.hixie.ch/specs/pingback/pingback
[Private-Webmention]
Aaron Parecki. IndieWeb. Private Webmention. Living Specification. URL: https://indieweb.org/Private-Webmention
[RFC7159]
T. Bray, Ed.. IETF. The JavaScript Object Notation (JSON) Data Interchange Format. March 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7159
[RFC7234]
R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. Hypertext Transfer Protocol (HTTP/1.1): Caching. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7234
[Salmention]
Ben Roberts; Tantek Celik. IndieWeb. Salmention. Living Specification. URL: https://indieweb.org/Salmention
[Vouch]
Aaron Parecki; Tantek Celik. IndieWeb. Vouch. Living Specification. URL: https://indieweb.org/Vouch
[XSS]
OWASP. Cross-Site Scripting. Living Document. URL: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
[h-entry]
Tantek Celik. microformats.org. h-entry. Living Specification. URL: http://microformats.org/wiki/h-entry
[security-privacy-questionnaire]
Mike West. W3C. Self-Review Questionnaire: Security and Privacy. 10 December 2015. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
Amy Guy. W3C. Social Web Protocols. 2 November 2016. W3C Working Draft. URL: https://www.w3.org/TR/social-web-protocols/

↑

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3