セキュリティキャンプ2023Webセキュリティクラス応募課題をやる

最後に一つの文章にする

多分思いつくだけ書いたほうがよい

書かなかったら、なかったことにされるだけ

■ Q.1（応募のモチベーションについて）

「Webセキュリティクラス」の講義のうち、特に受講したいと思う講義（複数可）に関して、その講義で「どのようなことを・なぜ学びたいか」を教えてください。とりわけ「なぜ学びたいか」の部分に関連して、いま応募を考えているあなたが感じておられる課題意識や、あなたの関心領域が伝わってくるような解答を歓迎します。

t6o_o6t.icon

B3『クラウドネイティブセキュリティの実践と戦略』

事前に調べること

Kubernatesを使用する

本を借りる

カスタムコントローラーについて

eBPFについて

B4『Webサービスにおける安全な認証とID連携の実装』

事前にやること

OAuth2を含むアプリケーションを実装する

理由

OAuth2のフローは、過去に学習したことがある。

Discord

チャット・通話アプリ

ボットによる自動化など、ユーザーがプログラミングで様々な拡張を加えることができる。

OAuth2のフローを介してアクセストークンを取得し、認可されたユーザーのリソースの取得（アイコンや、参加しているグループ）、グループの設定変更（『スラッシュコマンド』の管理）をするWebアプリケーションを実装した。

一方で、サービス間の連携を「実装する」側には未だ立ったことがない。

これの原因は、今までに連携システムを自ら設計する必要がなかったからである。

外部のアプリケーションが自分のアプリケーションからリソースを取得できると便利になるケースは、過去になかったと思う。

セキュアなOAuth2の実装に参加できるようにしたい。

メモ

ユーザーが機能を拡張できること

この面白さは普段自分がそうしているので強く感じる

...そのためにセキュアなOAuth2などを実装できるようになりたい

B6『ソースコード解析によるWebアプリケーションの脆弱性調査』

事前にやること

理由

脆弱性調査の具体的な方法が分からず、困っていた

本に載っているような一般的な脆弱性を知識として学ぶことはあっても、具体的なケースに対応することの難しさを感じていた。

そのため脆弱性調査の手法をハンズオン形式で学ぶ機会を得たいと以前から考えていた。

B7『Policy as Code入門』

理由

ポリシーをコードで表現するとはどういうことか？どのようなメリットがあって活動が広がったのか？

講義概要を読んで、取り組み内容が面白いと思ったため。

■ Q.2（これまでの経験について）

以下の経験について、差し支えのない範囲でできるだけ具体的に教えてください:

(1) Web アプリケーションの設計・開発経験（※ どんな些細なものでも構いません）

(2) 一般のプログラミングの経験（※ 使ったことのある言語や、その用途などを教えてください。レイヤは問いません）

(3) コンテナ技術の利用経験

(4) CI/CD 環境のセットアップ・利用経験

なお、この問は「この応募課題を提出する時点での経験」を問うものです。この応募課題を見た時点での経験はなくても構いませんし、この応募課題の記入にあわせての学習を歓迎します。

t6o_o6t.icon

Webアプリケーションの設計・開発経験

趣味のプロジェクトで、以下のようなアプリケーションを作っていました。

アプリ概要

Discordボット

いやこれ別のやつだ

別のやつというか、Webの次にボットを実装する予定だったな

このボット → 改修を計画 → Web → ボット

結末

大学受験に合わせてプログラミングをしなくなり、他メンバーも活動が減っていったため、完成しないまま今に至る。

構成

フロントエンド

TypeScript

アプリケーションを型安全に保つことで、予期しないバグを取り除く。

React

Next.js

コンポーネント

MUI

テンプレートとして利用した。

実際にはsxプロパティで独自のスタイリングを加えた。

バックエンド

Next.js

複雑な処理は要求されないため、Next.jsのAPI RoutesでAPIエンドポイントを実装した。

データベース

Prisma（ORM）

PlanetScale

無料枠が大きかったため。

Next.jsがPlanetScale x Prismaのサンプルを公開していたことも遠因である。

これ以前にはFirebaseのFirestoreを利用することが多かったです。

テスト

Storybook

コンポーネントのカタログを作り、メンバー間でイメージを共有する目的で導入した。

各コンポーネントは、通常の表示と特殊ケースそれぞれにStoryを実装した。

Chromatic

作成したStorybookをインターネットで公開するために使用した。

プロトタイピング

Adobe XD

その他

Prettier

Hygen

コンポーネントの形式を統一し、スムーズにコーディングできるように設定した。

hygenコマンドを実行して、コンポーネントの種類などを選択すると、自動的に .tsx、.module.css、 .stories.tsx ファイルの入ったディレクトリが作成される。

最近では、使い捨てるReactアプリを書くときはViteを使用しています。

思い出した

Discordのボットメッセージ管理アプリ

PythonのFlask（FastAPI?）でバックエンド

データベースはどうしていただろう？

Vue.jsでフロントエンド

一般のプログラミング経験

趣味でよく使ったもの

JavaScript / TypeScript

利用例

Discordボット

TTS（送信されたテキストメッセージを音声チャットで合成音声を用いて再生する）

概要

日本で運用されているTTSボットの中には、複数の音声チャンネルでの使用が不可能だったり、無料で安定して稼働しないものがあった。

このプロジェクトでは、5個程度のTTSボットアカウントを、ユーザーが1つのコマンドで適切に呼び出せるようにするのが目的だった。

構成

client

各音声チャンネルで常駐するボット

controllerによる参加命令を受け取って、ボイスチャンネルでの音声再生を開始する。

音声は、OpenJTalkを用いて合成した。

VOICEVOXを試したが、合成に時間がかかり、リアルタイムに音声を合成するのは難しいと判断し、OpenJTalkを利用した。

OpenJTalkはもともと共有ライブラリで提供されていた。

Node.jsにおける共有ライブラリの使用は、メモリ管理が煩雑である。

有志が、Javaを用いてOpenJTalkの音声合成機能をWeb APIとして提供するWebサーバーを実装していたため、これをDockerで実行することを決めた。

controller

ユーザーのボット呼び出しリクエストに応答する。

client, controllerはともにDockerコンテナ上で稼働する。

clientを稼働させるDockerコンテナは、ボットアカウントごとに立ち上げる。

音声合成までは実装したが、先に書いたWebアプリと同様、グループメンバーの活動が自然消滅し、開発を終了した。

Firebaseを用いたメンバーのプロフィールCRUD

Dockerを用いて稼働しました。

Scrapboxのピン留め自動化スクリプト

ScrapboxというWikiでは、ページをトップページ上部でピン留めすることが可能。

しかし、ピン留めを一気に外したり、入れ替えたりする機能がなく、管理が煩雑だった。

そこで、ユーザーがページの入れ替えを簡単に行えるUserScriptを実装した。

Scrapboxでは、UserScriptという、ユーザー自身にのみ適用されるJavaScript拡張を行うことができる。

ユーザーに与えられたピン留め順に設定するための最小手順を実装したが、過程でバグが多く発生した。

最終的には、想定したすべてのケースで問題なく動作した。

今思うと、テストを先に書くべきだったと思う。

実現可能性を検証するPOCが、結果的に上手く行ってしまってテストを書かないまま進めてしまった。

動画再生

Web上で動画編集をするアプリを自作したく、動画再生の手法を検討した。

動画編集アプリの要件として、プロジェクトファイルに指定されている動画ファイルを自動的に読みだせる、というものがあった。

FileHandler保存の検証

一般的なinput要素を用いた方法では、プロジェクト再開時にユーザーが動画ファイルを再度指定する必要がある。

セキュリティ上、これ以外の方法でファイルのFileHandlerを再取得するのは不可能と思われる。

ChatGPTはこれについて、FileHandlerをIndexedDBに保存することを提案した。

実際に検証すると、IndexedDBにオブジェクトを保存する際、オブジェクトには「構造化複製アルゴリズム」が適用され、ファイルの読み出し用のメソッドが消失してしまうことが分かった。

以上から、OPFSと呼ばれる領域に、過去に読み込んだ動画ファイルをキャッシュしておくことにした。

File System Access APIでは、OPFSに保存したデータはユーザーの許可なく読み書きが可能である。

考えた動画編集アプリの構成は、動画ファイルから、再生ヘッドが置かれているフレームの画像を取得し、フレーム画像に対してエフェクト等を加えて表示するものった。

Reactによる動画フレームの取得@1

Reactで指定したフレームの画像を逐一取得するプロトタイプを作ろうとした。

フレーム数はinput要素で指定する。

通常は、setTimeoutで自動的にフレーム数が増加する。

Stateの動作が不安定になったため、useRefを用いて実装した。

現在フレーム数に応じて、ffmpeg.wasmに動画フレームを取得する命令を実行する

実際には、非常に重く、1フレームごとに数秒時間がかかる状況だった。

また、ffmpeg.wasmの仕様上動画全体をオンメモリに読みだす必要があり、性能面でも難しかった。

Reactによる動画フレームの取得@2

フレーム画像の取得を適切に実装するのは難しいと考え、ブラウザの実装に依存する方向で検討した。

video要素の内容を1 / fps秒間隔でcanvasに転送する

これはChromeでは問題なく動作しました。

Chrome以外のブラウザ、主にFirefoxではcanvasのレンダーが無視できないほど遅く、60FPSを実現するには至りませんでした。

また、エンコード時にはユーザーの操作なく動画を高速に読み込んでいく必要があると考えました。

現在はWebCodecsを用いた実装を検討しています。

動画をデコードするにあたり、デコードに必要な最小限なバイト列を読み出したいと考えています。

現状、作業は1か月ほど中断しています。

動画ファイルの構造（主にMPEG4フォーマット）を正しく理解できていないと感じた

興味の移り変わり

ソケットプログラミング、ソフトウェアルーターの自作など、書籍を元に取り組んでいます。

オセロの実装

以前、Pythonでオセロを行うDiscordボットを作成していました（後述）。

BitBoardを用いて比較的高速なオセロプログラムを実装しました。

描画をcanvasで行います。

高校のパソコンで、パソコン授業の暇な時間を使って実装したため、ソースコードは残っていません。

AIについて、見よう見まねでしたが、古典的なMin-Max法、α-β法による効率的な候補手探索を実装しました。

C言語

高校で基礎的なC言語を学習しました。

競技プログラミングでC++を利用していますが、問題を解き学習するプロセスをうまく実行できず、何度も中断と再開を繰り返しています。

最近、『TCP/IP ソケットプログラミング C言語編』（オーム社）の学習に用いました。

ポインタ、構造体などの基本的な扱いは理解しています。

Python

Discordボット

オセロをDiscord上でプレイできるDiscordボットを開発しました。

このボットは100を超えるグループで利用され、自分が初めてアプリを多くの人に利用してもらう体験となりました。

より多くの人に使ってもらうために、棋譜確認などの機能拡張を行いました。

ボットは当時無料枠を提供していたHerokuで稼働しました。

趣味で一度以上使ったことのあるもの

bash

大学のポータルサイトの作業を自動化するために1時間に1回アクセスしてセッションを延長し続けるスクリプトを書きました。

GitHub Actionsで動作しています。

Vue

Discordでは、ボットアカウントで送信したメッセージを他ユーザーが編集することができません。

Webブラウザから、ボットアカウントの過去のメッセージを編集できるようにするアプリケーションを開発しました。

Svelte

Rust

学校で勉強したもの

C言語

Java

C# / Unity

高校教員のオリジナルの教材で学習しました。

プログラミング言語ではありませんが・・・

Webページを作成するため

HTML

CSS

JSX

Dockerfile

docker-compose.yml

コンテナ技術の利用経験

Docker

Dockerは上述した一部のアプリケーションを稼働するために利用しています。

Devcontainer

以下の時に利用します。

Linux環境でプログラムを実行したいとき

複数人での長期間の開発を想定しているとき

Docker Compose

複数のコンテナを稼働する際に利用します。

CI/CD環境のセットアップ

上述した、Conoha VPSで稼働したDiscordボットをデプロイするにあたり、以下のようなGitHub Actionsを書きました。

リリースが行われるとVPSにSSH接続し、git pullを実行しプログラムを実行します。

当時別のGitHub Organizationで開発を行っており、そのOrganizaztionを削除したため、現在当時のリリースは確認できません。

■ Q.3（あなたの感心・興味について）

Web に関連するサービス・プロダクトを作って提供することに関連する技術で、いまあなたが興味を持っているものがあれば、それについて自由に説明してください。少しでも Web との関連性がある技術であれば、それがハードウェア領域に近いものでも、ソフトウェア領域に近いものでも構いません。

t6o_o6t.icon

新しくなくても良いのかな。

React Suspence

swc

SSG

ブラウザのAPI

Service Workerと連携することでクライアントにプッシュ通知を送信することができる。

過去のWebは、ユーザーがWebページを開いて情報を取得するのが当然だった。

Push APIが登場したことで、アプリは情報を

利用例

私が利用したことのある美容室では、来店時にプッシュ通知の送信可否を問われる。

有効にすると、適当なタイミングで来店をすすめる。

また、予約をした場合には予約内容を通知で知らせてくれる。

情報を取り扱うアプリケーション

大学のポータルサイト

WebAssemblyは、複数の言語からコンパイル可能な低水準の中間言語。

WebAssemblyへの利用例が多いプログラミング言語の1つがRust

WebブラウザはWebAssemblyを直接実行することができる。

WebAssemblyのメリットは、過去に開発された資産をWebアプリケーションの文脈でも再利用できる点である。

既知の問題点として、

今後、WebAssemblyがマシンのファイルシステムを直接操作できるようになると、できることの幅は更に高まる。

セキュアなファイルシステム操作を実現する方法として、OPFSがある。

OPFSでは、オリジンごとの

オリジンとは、URLのうちスキームとドメイン、ポート番号

スキームの呼び名がわからなかった

ポート番号がオリジンに噛んでくるのを知らなかった

CORSの文脈で頻繁に

SharedArrayBuffer

WebAssemblyでは

CORS

CORSとは、セキュアなAJAXを支えている仕組み。

解決する課題は、Webページに埋め込まれたJavaScriptが、不正なリソースをダウンロードできる点。

JavaScriptではあるURLにfetchする際、CORS情報を添付する。

サーバーは、レスポンスに「このオリジンを閲覧しているならこのレスポンスを表示して良い」という内容の情報を加えて送信する。

ブラウザはその情報を読んで、オリジンの表示の可否を判断する。

Electron

過去に開発された資産をWebアプリケーションで再利用するという視点では、Electronの話題も欠かせない。

Electronは、Node.jsをベースとして、JavaScriptで動作するGUIアプリケーションを構築できるフレームワーク。

Electronを使ったアプリケーションの代表例が Discord。

DiscordはWebブラウザ上で動作する

WindowsやMacOSユーザー向けにスタンドアロンなElectron版アプリが頒布されている。

多くの場合、Electron版アプリのほうが先に機能がリリースされている

Webブラウザ上で実行するという制約から、Webブラウザ版の機能リリースが抑えられていると推察する

まじでなんでもいいの？

Web API？

これ、「Webに関連」するっていうのを、「Web由来の技術である」と考えると一気に狭まってしまう

自分の興味のあることのなかで、Webを使って実現できるもの、という視点で書いたほうがよい

いや、説明したい用語（Scrapboxに書いたもの）を今説明し直せばいいじゃないか

最近の

自分語りは後でいいや

■ Q. 4（Web に関連する脆弱性・攻撃技術の検証）

(1) 事例の概要

(2) 攻撃手法の詳細

(3) その他その事例に関して感じたこと・気がついたこと

なお、本設問では、関連する仕様や攻撃の適用可能な条件についての詳細な理解が垣間見えるような記述や、理解を深めるために行ったこと（例: ローカルで行った再現実験等）に関する記述を歓迎します。

t6o_o6t.icon

これがだいじだね

いくつか書いて、色々表現できたものをあげようか

まずはこれを書こう

興味を持った理由

そんなことができるの？？

できたら不安

自分が過去に作ったWebサイトは？

(1) 事例の概要

事例について調べる。

英単語

exploit

不適切な実装

組み立てる実装をすべきではない

ユーザー入力が必要なら組み立てる「自前」実装をすべきではない

この攻撃が可能になるのは、デフォルトで CSS ファイルをロードするときに、HTTP ヘッダーの Location で指定されたすべてのリダイレクトに従うためです。

あれ？

なんかこういうのあったよな

どこで見たのか忘れたけど

結論

このWebアプリは、テーマの切り替え機能を実装した。

color_schrmeパラメータの値からtheme.{PARAMETER}.cssというパスを組み立てる実装をした。

埋め込むパラメータ値のサニタイズをしなかったので、任意のパスのCSSを読み込めた。

さらに、&を用いる（実体文字参照）ことで自由にパスを指定できてしまう。

対策

動的にロードするパスを組み立てるときはサニタイズをする。

組み立てに使える文字列を制限する。

ここでは、PARAMETERに指定可能な文字列のセットを事前に定義し、判定する。

数日後

このWebサイトで紹介されているClient Side Path Traversalとは、

1. ユーザーの入力を、

2. リクエストパスの組み立てに利用して、

3. 入力に適切なサニタイズを施さなかったため、

4. 攻撃者はパラメータにスラッシュ（%2F）やバックスラッシュ（%）を使ったURLをユーザーに与えることで、任意のURLにアクセスさせられる。

/../../api/

本当に分かった

今回の脆弱性では、CSSファイルを相対パスで自由に指定することができる。

そのうえで、相対パスに自由にパラメータまで埋め込むことができる。

任意のURLへリクエストを発生させることができるということ。

OAuth2のエンドポイントを組み合わせると、

1. OAuth2でログイン

2. stateを用いて、callbackに攻撃者の所有しているWebサイトのCSSファイルのURLを設定する。

3. ログインが完了すると（実際にはすでに行われている）、callbackにリダイレクトされる。

https://mc-beta-cloud.acronis.com/mc/?color_sheme=%2F..%2F..%2F..%2Fapi%2F2%2Fidp%2Fauthorize%2F%3Fclient_id%3Dfb2bf44e-ac14-444a-b2a9-e5e81fe73b80%26redirect_uri%3D%252Fhci%252Fcallback%26response_type%3Dcode%26scope%3Dopenid%26state%3Dhttp%253A%252F%252Flocalhost%252Fcss%252Fcore.css%26nonce%3Dbhgjuvrrvpwauibleqhvfqat

https://mc-beta-cloud.acronis.com/api/2/idp/authorize?client_id=...&state=http://localhost/css/core.css?nonce=...qat.css

相対パスを正しく解釈できていなかった。

今回相対パスのbaseにあたるのは、window.location.href

cssのパスがどのようになるかを考えよう。

https://mc-beta-cloud.acronis.com/mc/theme./../../../api/2/idp...

これが最終的なリクエスト先となる。

Mediに書いてあったJavaScriptのサンプルを実際に動かして、

それがどうして/api/2になるのかはChatGPTと確認した

OAuth2の話をしよう

1. OAuth2認証

2. この場所にリダイレクトされる

リダイレクトさせたいならこれを直接貼ってはいけないの？

分かった

これは既にログインしているユーザーには一切バレないのが重要なんだ

https://www.youtube.com/watch?v=srPv75HS6Nk

たしかに参考動画のPoCでも、ユーザーはログイン画面を見ることなく、通常のページを表示している。

ページ内容はサーバーから返されている

CSSはJavaScriptでロードされるが、そこに割り込んでそのロード処理を

バックグラウンドでOAuth2処理を実行して、コールバックまで到達させている

いや違うかな

パストラバーサルとCSSインジェクションがこの報告の主な部分だ

1. パストラバーサルできますよね

2. これを使うとCSSを読み込むつもりでOAuth2のリクエストをさせることも可能だよね

3. OAuth2のリダイレクト先には絶対URLを指定できるから、リダイレクト先にCSSを置けば、2.のリクエストで攻撃者のCSSを読み込ませることもできるよね

利用者からするとCSSの読み込み処理に割り込んでOAuth2が実行されて、そのあと何事もなくCSSを読み込ませることも可能かな

あとはこれがユーザー情報の窃取にどう関わってくるのかが見えない

分かった

動画内で

(1)

具体的な事例は現時点では少ない。

(2)

攻撃手法は完全にわかった

■ Q.5（Web に関連する標準や実装の調査）

以下は Cookies Having Independent Partitioned State (CHIPS) という仕組みに関する Explainer です:

同 Explainer を読み、これに派生・関連した仕組みや動向を調査してください。その上で、可能な限りの実験を行いながら、以下の 5 点について簡潔にまとめてください。

(1) CHIPS 自体の概要

※ 例: これは〜という課題意識のもと、〜という変更を〜に行うものである。これにより、〜が〜のような形で解決される。

(2) CHIPS の背景課題について掘り下げて調査した結果

※ 例: 先述の課題〜とは、より詳細には〜ということである。この課題意識は Web のユーザ視点では〜につながるものであり、Web プラットフォーム自体の開発に関わる人の視点では〜という課題意識があったようだ。なぜこのような課題意識が解決されてこなかったかと言えば、〜によると、〜というのが一因なのかもしれない。

(3) CHIPS や、それから派生した仕様・仕組みに関する実験

※ 実際にどう課題が解消されているか、逆に何が解決できていないのか納得できるまで手を動かしているような解答を歓迎します。時間的制約はあると思いますから、可能な限りで構いません。

※ 例: ブラウザの試験的機能や関連するサーバサイド実装などの試験を行った。

※ 例: PoC を書いて実際にブラウザでロードしてみた結果、〜という挙動だった

※ 例: 仕様にはこう書いてあるが、挙動がそれと異なる。実際 Chromium の実装を確認すると、〜となっていた。

(4) その他気がついたこと・思ったこと ・疑問・感想

※ 例: この仕様は一見不合理に見えたが、調査中に見つけた〜という仕様との兼ね合いを考えると、〜という理由から合理的であるように感じた。

※ 例: 一方調査の過程で、〜という仕様との整合性が取れているのかは気になった。実際の実装を用いて確認してみると、この点に関しては、実装間で処理結果が異なる。

(5) 疑問や感想を元に、さらに応募用紙提出後から掘り下げていくために取りたい行動

※ あればで構いません。掘り下げきったと思う場合は、継続的に関連トピックの進展を追いかける方法のイメージをぜひ教えて下さい。

CHIPSについて調べる。

(1)

CHIPSの説明を考える

CHIPSとは、あるWebサイトAに埋め込まれたWebサイトCがやり取りするCookie（サードパーティーCookieと呼ぶ）を、同様にCを埋め込んだWebサイトBや、トップレベルサイトとしてのCにおけるCookieと分離する仕組みである。

Webサイトへのアクセスには、ユーザーが直接WebサイトのURLにアクセスする場合と、ほかのWebサイトに埋め込まれる形でアクセスする場合がある。

前者をトップレベルサイトという。

CHIPSは、トップレベルサイトごとにCookie情報を分離する仕組みである。

異なるトップレベルサイトでは、そこに埋め込まれたWebサイトのCookieの状態も異なる。

こっちの解説のがいいな。

CHIPSは何を解決するか

CHIPSは、Webサイトの埋め込みを利用したユーザーを

従来、Cookie情報はWebサイトごとに分離されてこなかった。

地図アプリ Hoge Map を例に考える。

Hoge Mapは、ユーザーが最近検索した位置をCookieに保存する。

ECサイト Huga Shop は、地図をアプリ上に埋め込みたいと考えた。

Huga Shopは、Hoge MapをWebサイトに埋め込む実装をした。

もしHoge Mapが、Cookieにユーザーを識別するユニークな番号を持っていたらどうなる？

CHIPSがなかったら

Hoge Mapは、Huga Shop上の埋め込みをユーザーが利用した際に、Cookie情報を元に「Huga Shopを利用したユーザーA」と「Hoge MapのアカウントB」を紐づけることができる。

この例では、Hoge Mapは、Huga Shopを利用するユーザーの動向をトラッキングすることができる。

CHIPSがあったら

Hoge MapとHuga Shopは異なるトップレベルドメインを持っている。

CookieがPartitioningされるので、Hoge Mapにトップレベルサイトとしてアクセスした場合と、Huga Shop上の埋め込みを利用した場合では、異なるCookieが読み書きされる。

Hoge MapがHuga Shopのユーザーを先の方法でトラッキングするのは難しい。

Cookieの分離はドメイン単位で行われる。

First-Party Setsを用いると、複数のドメインでCookieを共有できる。

(2)

従来のWebでは、サードパーティCookieを利用したクロスサイトトラッキングが行われてきた。

JavaScriptなどでユーザーの閲覧履歴を取得することは難しいため、サードパーティCookieを用いたクロストラッキングでユーザーの利用状況を取得するという仕組みである。

ユーザーの利用状況は、Web上でターゲティング広告を表示するのに有効だった。

広告業者から見ればトラッキング情報は、自身の業績を向上させるために必要な道具である。

一般のWebユーザーから見れば、許可なく自身の利用状況を取得できてしまう状況である。

サードパーティCookieのPartitioningやブロックがなければ、トラッキングを拒否することもできない。

FirefoxやSafaliは、サードパーティCookieをデフォルトでブロックする方針で対応してきた。

特にFirefoxはプライバシー保護を重視する傾向にあり、非営利団体のMozillaが運営している。

Chromeを運営するGoogleは広告業を行っているため、広告の支えであるサードパーティCookieは、ブロックせずにいた。

Googleの主張では、FirefoxのようにサードパーティCookieをブロックすれば、広告業者は新たなトラッキング手法を求めて、不適切なフィンガープリンティングを実行する可能性がある。

サードパーティCookieのブロックにより適切な広告を表示できなければ、パブリッシャーの資金が半分程度まで下落するとも主張した。

適切な広告を表示できないと、広告主は十分な広告効果が得られない。

パブリッシャーは広告主に広告の基盤を販売する組織なので、適切な広告を表示できなければ、販売実績は悪化するだろう。

広告業が縮小すると、今までWebで文書を無料で公開してきたユーザーが報酬を受け取れなくなり、現在のWebが崩壊すると主張する。

したがって、GoogleはサードパーティCookieを廃止こそすれど、ユーザーのトラッキング情報を取得する新しいメカニズムを実装する道を選んだ。

トラッキングができないと、適切なターゲティング広告を表示できないからである。

Googleが、プライバシーと広告を両立させるために提案したのが、FLoCだった。

思うに、広告とプライバシーを両立させるのは極めて困難である。

ここで侵害されうるプライバシーとは、ユーザーの利用状況である。

たとえFLoCのように

広告業者は、ユーザーにマッチした広告を表示するために、ユーザーの行動追跡情報を必要とする。

GoogleがWebの流れを自身の思い通りに操作できてしまうほど巨大なのも、この混乱の原因である。

GoogleはPartitioningを提案したが、FirefoxのようにすべてのブラウザがサードパーティCookieをブロックすれば、開発者もまた、サードパーティCookieを利用しない方向へ進んだだろう。

FLoCは各種機関から批判を受けたが、このような提案をせざるを得なかったのも、Googleが広告業を営んでいるからだ。

Googleは、ユーザーのプライバシー保護を推進しようとしているが、その企業体質から、トラッキングを廃止することには踏み切れない。

重要なのは、以下の点である。

ユーザーが、自身の持つどの情報をWebに公開するのかを制御できるようにすること。

(2)

？

Googleがなんでこんなことやってるの？

広告業に支障が出るでしょ

GoogleはWebの流れを主導したうえで広告業も両立しようとしているのか

解決できていない点…

PartitioningがすべてのWebサイトで行えているわけではない、という点かな

scrapbox.io

youtube.com

Cookie以外にもトラッキングの方法がある？

それこそフィンガープリントとか

フィンガープリントへのカウンターは用意してるんだっけ

Chromeは、FirefoxのサードパーティーCookieをすべてブロックする方針は、現在の広告モデルとの軋轢を生むという趣旨の主張だった

結局そこへの対応はPartitionへの移行を段階的にする、というだけなんだな

すべてPartitionになってしまえば、結局パブリッシャーは新しい広告手法を考えなければならない

GoogleといえばCookie周りでひと悶着あったな

ユーザーをグループ分けするんだったか

これ、FLEDGEだ

説明を読んで確信した

まあそうだよね

このまま廃止を開始したら悪質な方法が生まれてしまうから

トラッキングはほかの悪用が利くので、目的ごとに制限された新しいAPIを形作ろうという感じかな

クロスサイトである必要がないのなら、そうでないほうが安心だ

ユーザーは自分の情報がどこに反映されているか把握できないからね

Topics APIは、閲覧履歴に基づいた広告の表示を提供する

従来広告業者がトラッカーを使ってやっていたことを、純粋な形でできるようにする

ユーザーの関心に基づいた広告の表示

FLoCはTopic APIに代替された

FLoCが撤回され、Topics APIが発表された

(3)

疑問

ドメインをFirst-Party Setsに登録する開発者が、登録されるドメインの管理者であるという保証はあるのか？

Googleのような広告業者が、広告を表示するWebサイトのドメインをすべてFirst-Party Setsに追加して、今までどおりトラッキングできるという可能性はないのか？

First-Party Sets~~？？

やるしかないじゃん...

時間ないので23:59に間に合わなかったら「こういう実験がしたかったけど」みたいに言おうか

(5) 今後の動向