要約

  • RFC 8890は、他の当事者と利益が衝突するとき人間であるエンドユーザーを優先する。ただしIETF自身、政府系参加者、市民社会の専門家、協議参加者のいずれにも、利用者全体を当然に代表する資格を与えていない。
  • RFC 9110のuser agentは、HTTPリクエストを開始するクライアントプログラムであり、人間がその場で操作しているとは限らない。サンドボックスや設定の伝達は技術的権能であって、本人確認や包括的同意ではない。
  • 「代表している」という一語を、影響を受ける層、利益・被害の仕組み、協議の欠落、デフォルトと選択、権限境界、代替実装、移行費用、観測結果という連結可能な記録に置き換える必要がある。

画面を閉じても、プログラムはリクエストを送る。同期処理が動き、フィードが更新され、クローラーが巡回し、機器が定期通信をする。RFC 9110は、こうしてリクエストを開始するクライアントプログラムをuser agentと定義する。人がその瞬間に触れている必要はない。

すると「利用者の代理」という日本語の響きが、仕様上の役割を超えてしまう。送信主体であることから、意思の代弁者であることへ。設定を実装したことから、利用者の利益を知っていることへ。標準化会合に出たことから、影響を受ける人々の委任を受けたことへ。どの飛躍にも、途中の証拠がない。

Mark Nottinghamが著したRFC 8890は、エンドユーザーを優先すべきだと正面から述べながら、その飛躍を認めない。だからこそ、この文書は標語ではなく監査の起点になる。

リクエストを出す者と、結果を引き受ける者

プロトコルから見えるのは、どのプログラムがメソッドやヘッダーを組み立て、どの設定を適用したかである。そこから、人の在席、理解、同意、本人性までは導けない。共有端末では一つのデフォルトが複数人に働く。企業管理端末では、組織の方針が個人の選好より先に適用される。アクセシビリティーツールは、サービスが把握しない変換を加えることもある。

RFC 8890がいうエンドユーザーは、機器を管理する人に限定されない。接続カメラに写る人、センサーのある場所に入る人、自動処理の結果を受ける人も含み得る。リクエストを出していない人が、最も大きな影響を受ける場合さえある。

したがって最初の記録はuser agentの文字列ではなく、影響を受ける人の地図でなければならない。役割、状況、受ける利益と負担を分ける。同じ人でも、読む側と発信する側、買う側と売る側では求めるものが変わる。「利用者はこう望む」という単数形は、その違いを隠す。

優先順位は委任状ではない

RFC 8890は、エンドユーザーと別の当事者の利益が衝突するとき、前者を優先するよう促す。一方で、IETFに利用者の善を見抜く特別な能力があるとはしない。技術者自身の経験を一般化できず、政府の支援を受けた参加者が管轄内の全利用者を代表するとも、市民社会の専門家が広い共同体の委任を当然に持つとも言わない。

影響を受ける共同体への協議は必要だが、協議したという事実だけでは代表性を保証できない。この線引きは重要である。優先とは、競合する利益をどう扱うかという判断原則だ。代表とは、誰が誰に、何を、どの範囲で委ね、失敗時にどう責任を問うかという関係である。

前者を強く掲げても、後者は自動生成されない。むしろ利用者優先を本気で採るなら、決定者が利用者を知ったつもりになる危険を記録しなければならない。

user agentは防波堤になれるが、議会にはなれない

RFC 8890は、user agentが個人の利益を表す力を不完全と認めつつ、なお構造的な価値があるとする。ブラウザーは、遠隔サービスに端末全体を渡さず、表示、保存、機器アクセス、コード実行を限定する。サンドボックスや権限の仲介は、サービス側の自由を狭める。

しかし一つの境界は、すべての害を防がない。ファイルへの直接アクセスを止めても追跡は残る。許可画面があっても、繰り返し表示されれば拒否は形骸化する。拡張機能が一つの利益を守り、別の危険を増やすこともある。実装者が利用者を守る決定をしながら、自社の流通支配を強める可能性もある。

評価単位を小さくする必要がある。どの制御が、どのサービス能力を、誰のどの利益のために、どのオリジンと期間で制限するのか。初期値は何か。取り消しは可能か。実際に適用されたと確認できるか。これらが一つの機能の証拠になる。

RFC 6973は、利用者の関与、同意、選好表明、データ最小化、セキュリティーを別々に扱う。たとえば設定値が送られたとしても、それが本人による選択か、製品のデフォルトか、組織の強制かを区別しなければならない。表明できない利益まで、ソフトウェアが推測して委任されたことにはできない。

被害は人数で消えない

RFC 8890は「エンドユーザーへの悪影響」を自動判定する式を示していない。主張された影響を標準化の場で議論し、根拠と反証を扱い、判断を記録するよう求める。単に「利用者に悪い」と言うだけでは足りないが、数値が乏しい、提案者が少ない、本人が会合を去ったという理由で問題を無視してもならない。

RFC 7282の粗い合意は、発言者数ではなくissueの解消を重視する。humは投票ではなく、議長が状況を探る端緒である。異論を出した人が不在になっても、未解決の技術的影響は残る。

影響記録には、対象層、利益または被害が生じる因果、利用できるデータ、想定外の環境、代替案、負担の分配、不確実性を残すべきだ。利用者同士の利益が衝突するなら、平均像ではなく厳しい条件で試す。避けられない妥協は、誰が費用を負うかまで明示する。

ここで決定者のインセンティブも見える。会議参加者や実装者は調整の速さや市場上の利益を得る一方、不在の人がプライバシーや移行費用を負うかもしれない。参加者であることと、損失を引き受けるprincipalから委任されたことは別である。

協議は開いた窓であって、代理投票箱ではない

RFC 8890は、影響を受ける共同体の流儀に合わせた接触と、意外な形で変更を押しつけないことを求める。技術者向けメーリングリストやBOFは、そこで活動しない人、別の言語を使う人、まだ将来の影響を認識していない人には届かない。

RFC 8752のESCAPEワークショップは、出版社、コンテンツ集約、オープンWebをめぐる意見を集めた具体例である。何を聞き、どの論点が出たかは示せる。しかし出席者が世界中の出版社、広告関係者、読者、記述対象者を代表したとは示せない。

協議の記録には、主催者、招待経路、言語、アクセシビリティー、回答した層、欠けた層、示されたissue、回答、変更と不変更の理由を含める。「誰から聞いたか」と「誰から委任されたか」を別欄にする。

その区別は専門家の価値を下げない。むしろ、専門知識を根拠として使いながら、全体を代表するという架空の責任を負わせずに済む。沈黙した人を同意者として数えることも防げる。

別のアイコンがあるだけでは、移れるとはいえない

RFC 8890は、複数のuser agent実装が選択肢をつくり、実装者に利用者利益を考えさせるとみる。RFC 9518は、集中を抑える仕組みとしてswitchingを分析する。ただし代替が実在し、移るための時間、資源、技能、調整、機能損失が許容できることが条件である。

別のアプリをインストールできても、データ、認証情報、設定、拡張、業務フロー、アクセシビリティーが移らなければ出口は狭い。OSのデフォルトを変えられるか。企業ポリシーが許すか。セキュリティー警告や学習をやり直すか。合わなかったとき戻れるか。これらを実際に測って初めてswitching costになる。

仕様の複雑さも実装多様性を減らす。逆に規定不足が独自拡張を必要にし、交換を困難にする場合もある。ブランドが多くても、同じエンジン、配布経路、方針決定に依存していれば、競争可能性は限られる。

出口の記録は、人の層ごとに所要時間、失った機能、必要な支援、デフォルト状態、移行後の結果、戻る能力を残すべきだ。user agentが利用者の利益から離れたとき、本当に役割を失い得ることが、最も具体的な規律になる。

第三者の力には入口と終端が要る

RFC 9518は、第三者の参加には少なくとも一方のprimary partyによる積極的な行為が必要で、観測と制御は機能に必要な範囲へ限定すべきだと述べる。同文書はIndependent streamのInformational RFCで、Nottingham個人の見解を示す。IETF全体の合意でも、普遍的な法でもない。

それでも監査項目としては明確だ。user agentが能動的に選ばれたか、初期搭載か、組織による強制か。何を読み、変換し、保存し、遮断できるか。どこで権限を取り消し、何に置き換えられるか。一度ページを取得したいという行為は、すべての二次利用への包括同意ではない。

この入口と終端が見えなければ、保護する中介者がいつの間にか流通の門番になる。選択の事実だけでなく、選択できなかった人も記録する必要がある。

Mark Nottinghamの署名が意味する範囲

RFC 8890はNottinghamを著者として掲げ、IAB streamのInformational RFCとして、発行時のIAB合意を表す。Internet Standardではなく、IETF合意を表す文書でもない。本人の2020年の解説も、強制ではなく説得を目的とする指針だと境界を示している。

RFC 9110はIETF Standards Trackで、Roy Fielding、Mark Nottingham、Julian Reschkeの三人が編集した集団的なHTTP標準化の成果である。編集者名は役割を追跡可能にするが、実装支配権を意味しない。

RFC 9518はIndependent streamのInformational RFCで、見解は著者のものだと明記する。切り替えや中介者の分析は検証可能な視点であって、共同体の委任状ではない。

IETF Datatrackerのプロフィールは、HTTP、URL、RSS/Atom、QUICにまたがるNottinghamの貢献と確認時点の役割を示す。HTTPやWebの所有、ブラウザー方針の決定、IETF結果の支配、利用者全体の代弁を示すものではない。

「代表」を分解した記録をつなぐ

まずリクエストの外側も含む影響層を特定し、役割ごとの利益と被害の仕組みを書く。次に協議の到達範囲と欠落を残す。その後で、選ばれたuser agent、選択主体、デフォルト、設定、権限境界、実際の強制、独立した代替、移行費用を追う。最後に層ごとの結果と、標準化側のissue処理を結ぶ。

各記録は隣を代用できない。設定値は十分な説明を受けた選好を証明せず、協議は委任を証明せず、代替製品名は出口を証明せず、一部の改善はすべての人の福祉を証明しない。

エンドユーザーを優先するとは、誰かが利用者になり代わることではない。影響を受ける人を判断の中心から消さず、中介者の力を狭くし、選び直す力と結果を検証可能にすることだ。すべての利用者を代弁できないuser agentだからこそ、その限界を示す証拠によって評価できる。

出典