00:00
今日はブラウザの話をするってことで、OSSのブラウザって言えば、一番有名なのがGoogleのChromiumなのかなと思うんですけど、
正直毎日ブラウザは使ってるんですけど、ブラウザが実際どんなことをしていて、どんな実装になってるかって正直分かってないんですよね。
まあ、そうですよね。正直、現在のブラウザってやってること多すぎるので、多分全体像を掴んでる人そもそもいるのかっていう話ではあるんですよ。
うんうん。
けど、今回ちょっと自分も一部しか知らないので、今回ブラウザって実は結構巨大なデータを使わないといけないケースがいくつもあって、
ほうほうほう。
それが結構面白いんですよ、実装。一つ一つ微妙に違って。その辺の紹介できたらなと思ってます。
ありがとうございます。ちなみに、大きいデータ、巨大なデータっていうと具体的にどんなものなんですかね。
ちょっとこれから多分、具体例話していかないと分かんないと思うんで、ちょっとそこを具体例一個一個話していければなと思ってます。
はい。
で、まず一つ目が、HSTSプリロードってやつ紹介したいなと思っていて、
うんうんうん。
現代のインターネットって全部HTTPSじゃないですか。
はい、そうですね。
全部暗号化されてるじゃないですか。
で、けどなんか古いやつとかで、例えばHTTPが残ってましたっていう時に、
大抵のサイトってHTTPで来たらHTPSにリダイレクトするようになってるんですよね。
そうですね。サーバー側で勝手にリダイレクトしてって感じですよね、設定的には。
そうですね、設定して。
はい。
で、やってるのが最近だと普通だと思うんですけど、一回HTPSに来たらもうHTTPには絶対リクエストしないでほしいっていう設定ができるんですよ。
それはサーバー側でって感じですかね。
サーバー側でヘッダーを返すと、もうこのドメインに対してはHTPS以外絶対アクセスしないでくださいっていうのをブラウザーに教えることができるんですね。
なるほど、それはステータスっていうかレスポンスに含められるって感じじゃないですかね。
そうですね。HTTPヘッダーでストリクトトランスポートセキュリティっていうヘッダー、ちょっと長いんですけど、っていうヘッダー名のやつがあって、
そのヘッダーを返すとブラウザーはこのドメインはHTTPは絶対アクセスしちゃいけないんだっていう風になるので、
今後HPのURLとか踏んでも内部でリダイレクトになって、そのHPSにしかリクエストいかなくなるんですよ。
おー、便利。
そう、これがね、HSTSってやつです。
なるほど。
で、HSTプリロードっていうのはまたちょっと違くて、もうそのこのドメインはもうHPS以外絶対に使わないので、
もうその絶対にアクセスしないでくださいっていうのを登録することができて、
先にってことですかね。
そうですね。そのHSTSだと何が問題かっていうと、一番最初のアクセスは絶対HPになっちゃうんですよ。
HPとURLだと。
一番最初のコネクションっていうか、一番最初にアクセスした時ですかね。
そうですね。一番最初のアクセスは絶対にHPになってしまう。
03:04
で、その後HPSにリダイレクトした後はHPSでずっといけるんだけど、
一番最初にHPで踏んじゃったら、やっぱどうしても最初にHPになっちゃうんですね。
絶対に一回はアクセスしてしまうってことですね。
そのタイミングで、例えば何か乗っ取るとか、そういうのが可能っちゃ可能なんですよね。
なるほど。
そうですね。で、HSTSプリロードっていうのは、
どっかサイトがあって、そのサイトに自分のドメイン、
HSTSプリロード登録してくださいみたいなのを送ることができて、フォームがあって、
そこに送っとくと、なんかしばらくすると、
ブラウザーはそのドメインに対してHTTPSでしかアクセスしなくなるんですよ。
それはクライアント単位なのか、それともドメイン単位なんですかね。
全体で共有される。
ドメイン全体です。そのドメインでってやつで、
あと特殊なやつが、例えばGoogleが持ってるんですけど、.
devっていうドメインがあって、なんとか.devってドメインあるんですけど、これは
ちょっと特殊で、ト
ップレベルドメイン単位でHSTSプリロードが設定されているってやつで、.
devってドメインはもうHTTPは設定できないんですよ。
じゃあ、明示的に.dev、
例えばhenteco.devっていうドメインを取った時に、
ウェブサーバー、エンジンXとか建てるわけじゃないですか、
その時に80番ポートでHTTPのサーバーを建てたとしても、
アクセスできないってことなんですかね。
ブラウザーからはアクセスできないです。
カールとかだったらアクセスできるけど、
カールだったらアクセスできちゃいますね。
なるほど、Chromiumとかの場合はそもそもブロックされちゃうんですね。
ブロックっていうか内部でリダイレクトされるんですよ。
あーなるほど。
内部で自動的にリダイレクトになって、
実際のリクエストではHTTPのリクエストは絶対飛ばないっていう風になってる。
クライアント側で勝手に443ポートにしてみたいな感じになっちゃうんですね。
勝手にHPSにしてって感じですね。
なるほど、そんな設定があるんですか。
そんな設定が実はあって、
サイトに登録するとしばらくするとアクセスできなくなるんですね。
で、これって自分昔聞いたときに、
それってどうやってるんだろうと思って。
単純に気になりますね。
単純に気になって、結構前なんで10年ぐらい前かなに、
Chromiumのソースコード頑張って読んだことあって。
ChromiumのソースコードってC++なんで結構読むの大変なんですけど、
当時頑張って読んだらすごいびっくりして、
何メガバイトってあるすっごいでっかいJSONファイルがあって、
そのJSONファイルを人間が手でコミットしてるんですよ。
Chromiumのソースコードの中に。
そんなことがあり得るんですかね。
そんなことあるって俺も思ったんだけど、
マジでやってるんですよ。で、今もやってますこれは。
それはプリロードの機能のために各ドメインを登録していってるっていう。
そうです。HSプリロードに登録されたドメインが全部JSONファイルの中に入ってて、
06:04
これ全部入ってるんですよ。だからめっちゃでかいんですよ。
誰かが1個例えばシェルスクリプトみたいなものを用意されてて、
それを実行した結果プリロードの結果のJSONファイルとして生成されたものを
コミットしてるみたいな感じなんですかね。
具体的にどうやってるかわかんないんですけど、
多分どっかのデータベースか何かに保存されていて、
それを多分出力して多分それを登録してるんだと思うんですよね。
すごいですね。
これをソースコードのコミット権持ってる人が定期的にマージュしている。
で、今もこれはずっとマージュされ続けてます。
すごい運用でカバーされてますね。
めっちゃ運用でカバーされてるんですよ。で、これがめちゃくちゃでかい。
そのJSONファイル自体が。
JSONファイル自体がめちゃくちゃでかい。
なるほど。じゃあもうJSONファイルとしてソースコードにコミットされてるっていうことは
ビルドされた時に同梱されてるんですよね。
同梱されてます。だからみんながChromiumとかChromeダウンロードするときに
もう実はその中に入っている。
じゃあさっき片杉さんが言っていたちょっと経てば
HTTPSでアクセスすることになるみたいな感じのちょっとっていうのは
Chromeのバージョンアップってことなんですかね。
そうですね。
具体的には。
具体的にはその誰かがコミットして、Chromeのソースコードにコミットして
それがリリースされるまで。
もうちょっとやりようあるだろうと思うんですけど、なんとなく。
今そうなってるんですよ。
なんでですかね。
なんでなのかはちょっと分からないんですが、今そうなっている。
多分運用が一番軽いんだと思うんですよね。
結局そのリクエストしちゃうと、それが個人情報漏れちゃうじゃないですか、プライバシーが。
なるほど。
なのでそのプライバシー絶対漏らさないようにしようとすると、ローカルで完結させるしかないんですよね。
そうなるとこうなってしまう。
なんとなくGCSとかにJSONファイルを置いておいて、一番最初に取りに行けばいいじゃんとは、なんとなくは思うんですけど、
そのリクエストの手間というか、そこにローカルで完結できてないというところもちょっと脆弱性としてあるので。
脆弱性というかプライバシーですね。
なるほど。
まずJSONがあります。すっげえでっかいJSONがまずChromiumソースコードの中にありますと。
話はこれで終わらなくてですね。
すっげえでっかいJSONも、これもこれで大変で、結局その中に今アクセスしようとしているドメインが入っているのかどうか探さないといけないじゃないですか。
JSONをパースする必要性があるってことですよね。
JSONパースも大変だし、一個一個見ていかないといけないじゃないですか。
はい。
これでどうすんのっていう。これ自体も結構大変な処理なんですよ、実は。
そのドメイン数が膨大だからと。
あまりにも多いから。
で、ここで何を使うかっていうとTryTreeっていうのを使ってるんですよ。
09:02
TryTree。
TryTreeっていうデータ構造があって、これちょっと説明すると、
例えばA単語で、車のカーとか、あとカードとか、あとケアとか、あと猫のキャット、あとドッグとかこういう単語があったとして、まずルートがありますと。
で、ルートの次にCって単語が多かったからCがきます。
で、その次に、TryTreeは一文字ずつやるんですけど、その次にAがあったからAがきます。
その次に、カーがRだからRがきて、これで終わりですよっていうやつと、Rの後にカードはDがその後続くから、Rの後にDがくるんですよ。
っていう感じで、圧縮というか、その非構造としてやると。
そうすると結構ギュッとデータがするし、あと探索も簡単なんですね。
単純に全てのドメインを平行でデータ構造として持ってるわけじゃなくて、非構造で管理されている。
非構造で管理されている。
で、それがあれなんですかね、ドメインの逆順だったりとかするんですかね。
そうなんですよ。多分Javaとかのパッケージ名ってドメイン名逆になってるじゃないですか。
example.comっていうのがcom.exampleみたいなことですよね。
それって何でかっていうと結局データ構造としては、example.comだったらcomの方が上じゃないですか。
ルートというか。
ルート的にはcomの下にexampleがある。だから順番として逆なんですよね、データ構造的には。
だからドメインを逆にして、トップレベルドメインが一番最初に来た上で、このtrytreeで並べるっていう風になっている。
逆順のドメインで書いてるのはこの非構造から来てるってことなんですね。
そうですね。
データの整理として。
trytreeにしたいからっていうところですね。
なるほど。で、Chromiumはそういった非構造で高速に検索して、で、ドメインを判断してるみたいな感じなんですかね。
そう、そのドメインがhttpsプリロードに入るかっていうのを高速に判定できるんですね。
で、このtrytreeって、じゃあ我々使うことあるかっていうと、実はあって、例えばなんか子ども向けのウェブサイトやっていて、
その特定の単語は絶対表示したくない、例えばR18系の単語は絶対表示したくないとか、
けどそれって一個一個、例えばR18系の単語を辞書で持っておいて一個一個探索していくと、すっごい時間かかっちゃうじゃないですか。
これがすごい膨大な量だったら。
なんかもう1万とか2万とか1億とか。
もっと全然多かったら、フィルタリングするだけでもすっごい時間かかっちゃうんですよね。
そういう時にtrytreeってよく使われるんですよ。
12:00
なるほど。
特定の文字列が入ってたら、例えばその40、なんか400番台返すとか、なんかアラート出すとか、
なんかそういうのを実装したい時に結構trytreeって使われるし、
あと我々もうちょっと身近な部分で言うと、これはtrytreeよりradixtreeっていう方が使われるんだけど、
URLのルーティングでめちゃくちゃルーティングの数が多いですってなると、
どんどんどんどんルーティングのどの関数で呼び出すんだみたいなので、探すのですっごい時間かかっちゃうんだよね。
ルーティングって言うと、getのこのメソッド、例えばスラインデックスだったりとか。
スラインデックスとか、例えばスラAPI、スラなんとかにたくさんAPIありますとかあるじゃないですか。
パスが分かれてる系ですよね。
パスがたくさん分かれている。で、trytreeってさっき言った通り1文字ずつなんだけど、
URLのルーティングだとtrytreeも使われるんだけど、radixtreeって方がよく使われてて、
radixtreeは今言った通り、スラAPI、スラみたいなある程度グルーピングできるじゃないですか。
URLのルーティングって結構物によるけど。
ディレクトリごとにってことですよね。
そうですね。なので、trytreeは1文字ずつなんだけど、radixtreeはある程度グルーピングする。
基本的にはロジックは一緒なんだけど、そういう違いがあって、
結構URLのルーティングだとradixtreeの方がどっちかというと人気があるかなという印象ですね。
なので、すっごいURLのルーティングが多い場合は、そのradixtreeとかtrytree使わないともう遅くて厳しいんですよ。
これ、数が多くないとあんまり使わないかもしれないけど。
検索するときに効率的な検索方法をブラウザーも使ってるし、例えばそういうサーバーと。
サーバーのルーティング、ルーター。
ルーティング、炎とかそういうフレームワークは。
炎も確かに選べるんですよ、いくつか。で、trytreeの実装もあったはず。
なるほど。
なので、ルーティングの数がめっちゃ多い場合は、trytreeとかradixtreeのロジックにしないと厳しくて、
結構そのルーティングライブラリーだと、結構trytreeとかradixtreeの実装してるやつはあるはず。
なので、我々結構意外と身近なんですよ、この構造って。
確かに、なんかもう日常的に使われてますね。
そう、使われてるんですよ。こんなのいつ使うのっていう人たまにいるんですけど、全然あります。
普通に毎日使ってますね。
そうなんですよ。それが実はHSTSプリロードでも使われているデータ構造になります。
で、そんな高速に検索してくれるというか、どれがちゃんとドメインとして登録されてるのかっていうのが判別がつくので、
クローブとかでアクセスした時に簡単に即座に。
即座に、これはIPでアクセスしちゃダメだっていうのを判定できる。
全然待ってる感じしないですもんね、そんなめちゃくちゃ巨大なデータでクライアント側で処理してるみたいなこと全く思ってなかったので。
そう思わないじゃないですか。それはこの実装のおかげでもうすぐできるからなんですよね。
15:05
じゃあこれなんか多分やらないですけど、Chromiumにちょっと自分で手を入れてこのTryTreeですかね、
TryTreeの機構造を普通に全部if文で書いてみるみたいなことしたらめちゃくちゃ遅くなるんですかね。
やったことないけど、遅いんじゃないですかね。結構URLのルーティングとかだと結構ベンチマック出てると思いますよ。
TryTree使ったときと使わないときで、エンドポイントが何個あったらこんぐらい遅くなりますみたいなのは結構そういうのでベンチマークは出てると思うんで。
結構短いですよ、その手のベンチマークは実は。
なるほど。他にもChromiumで巨大なデータ扱ってるところとかあったりするんですか。
またそれとつながりったわけじゃないんだけど、セーフブラウジングっていう機能で、今言ったドメインってたまになんかあるじゃないですか、フィッシングサイトとか危険なやつ。
ドメインが通報されたりとかそんな感じですかね。
犯罪に使われてるドメインとか、そういうドメインってそもそもアクセスできないようにしてほしいじゃないですか。
うん、してほしい。
その機能がChromiumにあるんですけど、これもこれで結局さっきと似たような問題があるんですよね。
なんか似てる感じがしますよね。
そうそう、なんか毎回アクセス、このドメイン大丈夫ですかみたいなのをGoogleに聞いてたら、全部Googleに包抜けじゃないですか、そのユーザーのプライバシーが。
うん、確かに。
けどセーフブラウジングの大きい特徴としては、なんか機能発生した犯罪のドメインがあって、それをすぐ配信したいですよね。
即時性が機能ですもんね。
そう、HSSプリロードだと即時性特にいらないんだけど、セーフブラウジングは割と早めに配信したい。
じゃあなんか全然違うアーキテクチャを持ってそうですね、ここに関しては。
そう、全然違うですよね。で、これどうやってるかっていうと、そのURLそのものをやっぱり持っちゃうと、HSSプリロードみたいにとんでもなくデカいデータになっちゃうし、
それをなんか1日1回ダウンロードとかしたらとんでもなくデカくなっちゃうじゃないですか。
はい。
なので、これはシャーニゴルのハッシュ地を取ってURLの、で、その先頭のもう4バイトだけのリストを持っとく。
それをダウンロードさせているんですよね、ブラウザーが定期的に。
こっちはダウンロードなんですね。
定期的にダウンロードしていて。
配信されてるんですね。
そう、で、先頭の4バイトだけハッシュ地を持っていて、で、ドメインにアクセスする前に、そのシャーニゴルのハッシュ地取って先頭の4バイトを見て、
なかったら大丈夫。で、もしあったら、これちょっと危ないサイトかもしれないから、
Googleに聞いて、これ危なくないですかって聞いて、大丈夫だったら大丈夫。
じゃあなんか2段階みたいな感じなんですかね。
18:01
リクエスト数を減らすっていう目的でこういうことをやっているんですよね。
そのシャーニゴルでハッシュ化された先頭の4バイトを見るのは、なんか最初のフィルタリングみたいな感じですかね。
最初のフィルタリングで、毎回リクエストしてたらプライバシーも何もないし、あとパフォーマンスも普通に悪くなるから、そのリクエスト数をできるだけ減らす。
で、4バイトしかないのは、別に多少衝突してもいいっていう、衝突しても最終的にGoogleに確認するから、ちょっとぐらいは衝突してもいいよねっていうので、結構短くなってる。
でも現実問題、衝突しますもんね、きっと。
衝突するはず。4バイトしかないから。
大事なドメインであっても、Googleに問い合わせが発生してしまうってことですもんね。
してます。
運が悪かったですね、そのドメインが。
運が悪かったらなりますね。
なるほど。そういう仕組みが、セーフブラウジングっていうような仕組みがChromiumの中に入ってる。
入ってる。実は。
それもかなり瞬時に行われてるのかなって感じ。
瞬時に行ってますね。毎回ドメイン見て、大丈夫そう、大丈夫じゃなさそうって。
なんか厳密に言うと、ドメインだけじゃなくて、URLのパスとかもいろいろ対象になってるらしいんだけど、基本的なロジックは一緒ですね。
ドメイン、パス含めてフルパスでシャーリングを見て、先頭の4バイト見てみたいな感じなんですかね、じゃあ。
そうですそうです。
なんかその、Google側、Googleのサーバー側持ってる、このドメインは危ないみたいないうリスト、きっといっぱいあるじゃないですか。
そっちのデータ量もすごいえげつないことになってそうですね。
そっちのデータ量多分結構でかいんだと思うんですよね。どんぐらいあるか全然わかんないけど。
そっちの検索のアルゴリズムとかも起構造とかになってたりするんですかね。
多分普通にデータベースのインデックスだと思うんで、B3とかだと思いますよ。
なるほど。そこは高速に返してっていう形で。
そうですね。
なってるんですね。
それがセーフブラウジングですね。
面白い。
そうなんですよ。やっぱり、HSDプリロードと比較しても、やっぱりデータの特性って違うじゃないですか。求めてるものも違う。
全然違いますね。
だから当然その実装も違うんですよ。
ちなみにここまで聞いててあれなんですけど、これはChromiumだけが実装してる機能なんですか。
何ですかね。先ほどのプリロードにしろセーフブラウジングにしろ。
そんな詳しくないけど、多分Firefoxも実装してるんじゃないかな。遠い実装からちょっと把握してないけど。
同じような仕組みは持ってるって感じなんですかね。
持っているはず。
ブラウザであれば。ただ別に標準化されてるわけじゃないですよね。
HSSプリロードはどうなんだろう。ちょっと標準化までは追ってないけど。
HSSはもちろん標準だけどって感じですね。
ちょっとそこら辺若干気になるところではありますが、Google側のインフラとべったりなセーフブラウジングとかも多分使用上あると思うんで。
21:06
標準っていうよりかはChromeの安全性の機能みたいな感じなんですかね。
そうですね。Chromeのユーザーが怪しいサイトにアクセスしないようにするための仕組みって感じですね。それをGoogleが提供しているっていう形ですね。
そこら辺でもしかしたらあれなんですかね。例えば子どもが見ちゃいけないサイトとかの仕組みとかもしかしたらこういうセーフブラウジングみたいな形で動いてたりするんですかね。また別なんですかね。
その辺のやつって多分DNSレベルでやってることが多いんじゃないかなと思いますね。
また別のレイヤーでやってるって感じですかね。
ブラウザでやるというよりも、そういうことやってくれてるDNSサービスっていくつかあるから、そういうサービスを使うほうが一般的かなと思いますね。
なるほど。そういうものがあるんですね。
ありますね。
DNSレベルでブロックしてって感じですね。
ありますあります。そういうサービス。
なるほど。またじゃあそれは別で。
ブラウザの機能ではないですね。
セーフブラウジングの方は低レイヤーのブロックシステムみたいな感じですね。
本当にこれはダメってやつ。ガチで犯罪に使われてますみたいなやつがセーフブラウジングで防がれてますね。
なるほど。面白いです。こんなの普通にブラウザエンジニアとして仕事してて、ブラウザ普通に使ってますけど、一回も聞いたことないですからね。今までのやつ。
たぶんね、中身に対して興味持たないとこういうのあるんだと思わないと思うんですよね。だからやっぱりこのPodcastで取り上げる価値あるんじゃないかなと思ってこの話をやってきたんですね。
面白い。他にあったりしますか?
まだあってですね。次がね、まず大前提をいろいろ話すんだけど、さっきからHTTPSの話をしてるんだけど、最近のトレンドとしてTLS証明書の執行。
要はこのTLS証明書やっぱり発行しちゃダメだったとか、例えば何か侵入されたとか、普通に間違えちゃったとか、そういうのでこの証明書は信用しちゃダメですみたいなのがたまに発生するんですよ。
その証明書の執行をどうやって確認するかっていうのがTLS界隈だと結構話題になっていて、以前だとOCSPっていう仕組みを使うのが一般的で、
OCSPはTLS証明書を発行した会社が大体運営してるんだけど、そのOCSPに対してこのTLS証明書って執行してますかって聞くと、
執行してますって返ってきたら執行してるっていう形なんですよね。
証明書を発行した会社が独自にここでやってるって感じですかね。
ここでやってるって感じです。
この証明書を自分発行したんだけど、やっぱり執行してますよみたいな感じ。
クライアントがこの証明書を信用して大丈夫っていうので確認しに来るんですよ。
24:02
証明書を発行した元のサーバーに。
そうです。人に聞きに来る。
知ってるのは、その証明書を発行した会社が知ってるのはもちろん自分が発行した証明書のみですよね。
そうです。
証明書によってアクセスするOCSPはもちろん違いますね。
OCSPサーバーはもちろん違う。
その情報とかは証明書の中に入ってるって感じですよね。
だから、どこから発行されたかっていう情報が入ってるからってことですよね。
そうですね。けど、これ毎回そのリクエストしてるの、
OCSPサーバーにリクエストするのは大変なんで、時間もパフォーマンスも悪くなっちゃうし。
なので、OCSPステイプニングっていうのも以前はよく使われていて、
そのOCSPサーバーから返ってくる情報をサーバーで直接返しちゃう。
そのドメインのサーバーから直接返しちゃうっていうのがOCSPステイプニングっていうやつで、
これでOCSPのアクセスしなくてもよくなるので便利でしょっていうのがありました。
ちょっと分かってないのは、ドメインのサーバーが返してしまう。
つまり、アプリケーションが動いてるサーバーが返すってこと。
そうですね。CDNがやることが多いと思うんだけど。
なるほど。それは特殊な設定しなくてもいい感じにされるって感じなんですか?
CDNだったらそうですね。NGXとかだと特殊な設定しないといけないけど、
特殊な設定って何秒か設定かけばって感じだけど。
そうやっておけば、このドメインの証明書であれば、そのドメインのサーバーが返すよっていう形の設定になるんですね。
その証明書の執行情報を返してくれる直接っていうのがOCSPステープニングってやつだったんですけど、
これって今ちょっと自分ごまかした部分があって、このOCSPサーバーは執行情報を返すって言ったときに、
これって自分が失敗したときのこと言わなかったんだよね。
執行してますって言われたら執行するって言ったけど、
じゃあ他のレスポンス返ってきたとか、もしくはそのレスポンスがそもそも返ってこなかったときどうするかって今自分意図的に言わなかったんだけど、
どうするかっていうと、単純に無視します。
なるほど。
つまりこれ意味ないんじゃないのっていう。結局執行しててもOCSPサーバーに対してリクエスト失敗したら、
本当は執行してるのに正当な証明書だって見なしちゃうんですよ、今のブラウザって。
クライアント側が、この証明書執行してませんかって問い合わせたリクエストが失敗したとしても、OKと見なすってことですよね。
仕方ないよねっていう。
これはただの確認だから素通ししようみたいな感じですね。
ほとんどのケースで大丈夫だから素通ししようみたいな感じで、
実際OCSPサーバーに対してリクエストアクセスさせないみたいな攻撃も出てきてるんですよ。
この証明書を本当は執行してもう使われてないんだけど、
信頼してはいけないんだけど素通しさせるためにそういった攻撃をするってことですね。
そうです。
27:00
その時点でもうダメじゃんっていう、セキュリティの機能としてはダメだよね。
それって生前説で運用がされてるからってことですよね。
それにだいぶ近い気はしますね。
しかもプライバシーの問題もあって、結局そのCAの証明書を発行してる会社に対して、
今から自分この証明書のサーバーにアクセスしますよって伝えてるようなもんじゃないですか、これって。
そうですね、確かに。
だからプライバシーの問題もあるし、しかもセキュリティ的にこれ意味ないよねみたいな、
無視されちゃうんだから意味ないよねっていう批判があったんですよ。
ゴモゴモだ。
なので、OCSPやめようっていう、もう意味ないからやめようっていうのが最近のトレンドなんですよ。
それはクライアント側の実装として、この方式だと証明書の発行というか信頼性がなくなるので、
実装としてちょっと他の方法にやっていこうみたいな感じなんですかね。
どっちからっていう感じではないかもしれないんだけど、結構CA側がやめてるんだよね。
その証明書発行してる側がもうOCSP意味ないし、しかもなんかめちゃくちゃリクエストきてしんどいからもうやめますみたいになってる。
サポートしませんよって。
そう、サポートしませんよってなってて。結構ね、OCSPやめますっていうところがある、最近。
まあ確かに、てかそうなってくると、じゃあもう全部素通しになっちゃいますよね。
そう、全部素通しになっちゃうから、じゃあテレス証明書本当に執行したやつどうすんのってなって、
最近の動きとしては、もうだからそもそも有効期限短くしましょうっていうのを今動いてるんですよ。
はいはいはい。
で、今もうちょっとずつもう何年かけて数年かけてどんどん今短くなるっていうのも動いとれてるから、
今は1年1ヶ月、1年プラス1ヶ月ぐらいがマックスなんだけど、今どんどんどんどん短くなる予定なんですよ、これから。
いやそう、これ最近知ったんですけど、自分が仕事でサーバー立ててるわけなんですけど、
そこで発行してる証明書、サーバー側の証明書をこの間更新しまして、有効期限6ヶ月なんですよ、びっくりしました。
そう、つい最近ね、6ヶ月になったんですよ。ちょっと前まで1年いけたんだけど、もういけないです。
そう、あれ去年1年だったのにと思って、これまた6ヶ月後に更新しないといけないっていう、びっくりした時期がありました。
まだね、6ヶ月はまだ緩和で、緩和措置で、さらにどんどん短くなってきます、これから。
これが何か1ヶ月とかになるんですかね。
確か45日ぐらいだったかな、1ヶ月ごとぐらいに更新すれば大丈夫ぐらいの感じ。
じゃあその動きというか、そういったところがOSSPから来てるんですね。サポート。
OSSPが使い物にならないからっていう理由で、今証明書がどんどん短くなってる。
ちなみに短くしたからいいんですかね。証明書の有効期限が短いから、執行してるっていうのは自明だよね。
30:04
執行した後に悪用できる期間が単純に短くなるって話なんだよね、これって。
なるほど。だから短くするってことですね。
だから短くする。執行しても悪用できる期間を短くすれば旨味も少なくなるよねっていうのが、最近の証明書自体を短くするっていう動きなんだよね。
で、実はOSSPの前はCRLってやつがあったんですよ。
CRL。
これは全ての証明書の執行情報のリストをブラウザーが全部ダウンロードするっていうやつで、これ昔だったからまだいいけど、今の証明書の執行情報ってとんでもない量あるから、これ無理じゃないですか。
だからもうどんどん増えてきますよね、単純に執行情報が。
そう、どんどん増えていくし。だからOSSPダメだから、じゃあやっぱCRL復活させるかみたいになったんだけど、いやいやいや無理でしょってなったんですよ。
だって消えることないですもんね、執行情報の。
いや、証明書は期間が来たら消える。
あ、そっかそっかそっか。有効期限の期間が来たら消えるからどんどんフラッシュはされていくけどもってことですね。
けど、やっぱり執行されているものが多いから、もうすごいデータ量なんですよ。
で、Chromiumは実は最近CRLSetsっていうのを実装していて、ただこれは全執行情報じゃなくて、
ChromeというかGoogleが、これは需要だよねっていう執行情報だけ選んで配ってるらしいんですよ。
完全なCRLじゃないっていう。
けど、一応CRLのサブセットみたいなのを配っていて、だからChromiumとかChromeは本当にやばい証明書の執行情報は先に執行できるようになっている。
なるほど。その有効期限が来る前に使わなくできるってことですね。
ができる。だからCRLSetsなんだけど、けどこれって全部じゃないじゃないですか。
全世界ロボットではないですね。
ではない。で、今回話したいのはFirefoxのCRLiteの実装の方なんですよ。
これってなんかChromeというか、ChromeってやっぱGoogleが作ってるから、なんか現実的というか、やっぱ企業だから、
やっぱ現実的に動けばいいよねっていうのがあるんだけど、Firefoxってもう世界中のインターネットを平等に扱いたいみたいなのがあるんですよ。
思想的にですね。
思想的に。だから、
モジュラの思想的に平等にちゃんとインターネットは立ってるっていうような形なんですかね。
そう、そんな感じだから、CRLSetsなんて甘えだと。
甘え。強いな。
もう全部やれと。っていうのがFirefoxなんですよ。だから今回取り上げたいのはFirefoxのCRLiteの方。
でも、Liteってつくからりはなんか全部ではなさそうなんですけどね。
これがね、全部なんですよ。
なんなんだLiteって。
あの、言うとね、さっきのセーフブラウジングの話と若干似てるんだけどさ、
ブルームフィルターっていうのをちょっと説明したくて、これもハッシュ値を使うんですけど、
33:05
例えばハッシュ値、何でもいいんだけど取って、それを例えば割り算して、
その余り、例えばなんか16ビットだったら、まずは16で割って、
その余りのところのビットを0から1にする。
ってやると、例えばその同じこと、セーフブラウジングと似たようなことできるじゃないですか。
今の説明だと若干わかった気になるぐらいのわからなさがあったんだけど、
つまり、セーフブラウジングと似たようなチェック方式を
セーフブラウジングのときは、そのハッシュ値取った先頭4バイトとか取ってきてたんだけど、
先頭4バイトでもいいんだけど、割り算したときの余りを、その余りのところでビットを立てる。
そうすると、その同じハッシュ値だったらわかるじゃないですか。
それが実はブルームフィルターってやつで、今1個だけで言ったんだけど、
実際ね、1回だけしかハッシュ取らない実装って世の中結構あるんだけど、ブルームフィルターって言いつつ。
けど実際には何個か取った方が良くて、これは物によるんだけど、
1個がいいってケースは多分ほぼないはずで、
大体の場合は何回かハッシュの余りを取って、それぞれのビットを全部立てて、
そのビットが全部立ってたら、これは存在している。
1個でも外れてたら存在してないっていう風に判定する。
このブルームフィルターを使うと、それが存在してるか存在してないかっていうのがすぐわかるんですよ。
ブルームフィルターっていう役割としては、
簡単に言うと、証明書が存在するかどうかを見てるってこと。
今回ね、証明書は一旦置いといて欲しくて、
なるほど。
ブルームフィルターってデータ構造を考えて欲しくて、
そのデータが存在してるかしてないかだけを見たいっていう時に使われるデータ構造。
あるかどうかってことですね。
あるかどうか。
存在するかどうかを見る時にブルームフィルターっていうアルゴリズムを使う。
そうなんですよ。これってウェブサービスとかでもたまに使われてて、
例えばタグとかたくさんあった時に、そのタグが登録されてるのかどうかっていうのを、
毎回データベースにアクセスしてたら時間かかってしまうとか、
あと確認したいタグがめちゃくちゃたくさんあるとか。
セレクト、アスタリスク、ウェア。
ウェアでタグ名を指定するとか。
そうですよね。
それがたくさんあると大変だとか、そういう時に実は使われることあるんですよ、ブルームフィルターって。
そのハッシュ値取るだけですぐにそれが存在してるかどうかわかるから。
けど、これってちょっと考えればわかるんだけど、
ブルームフィルター上で存在してるってなった時に、本当に存在してるかってわかんないんですよね。
36:00
擬容性があるんですよ。
若干あるんですね。本当に存在するかいないかっていうところが。
存在しない場合は絶対にフラグ立ってないから、
存在してたら絶対フラグ立ってるから、フラグが立ってなかったら絶対存在してないんですよ。
なので、フォルスネガティブはないんですよ、絶対に。
けど、フォルスポジティブ、フラグ立ってるけど実はないっていうのはある。
ややこしい、ちょっと自分も頭混乱してきたけど。
ブルームフィルターはフォルスネガティブはないけど、フォルスポジティブがあるっていうのが特徴なんですよ。
なるほど。
なので、フォルスポジティブが許容されるデータだったら、ブルームフィルターは結構使われる。
高速に使えるからってことですね。
高速だし、あとデータサイズがすっごい縮むんですよ、ブルームフィルターって。
めちゃくちゃデータサイズが小さくできるから結構便利。
便利。っていうのがブルームフィルター。
そういうアルゴリズムがあるとして、それがどうファイアフォックスのさっきのライトに繋がるんですかね。
そうなんですよ。これってでもダメなんですよね。ブルームフィルター普通に使ったらダメで、何でかっていうと、このドメイン執行してますかって聞いて、
執行してますってブルームフィルター帰ってきたとして、それが本当に執行してるかわかんないんですよ。
これがもし執行してないのに執行してますって言ったら大事故になっちゃうじゃないですか。
執行してないのに執行してますって言ってたら、このサイトは信頼がないみたいな判定になっちゃいますよね、ファイアフォックス上では。
それはダメだ。
絶対ダメなんですよ。だからブルームフィルターは使えないはずなんですよ。
けどここでよく考えてほしくて、今のTLS証明書って実はCTログって言って、TLSの証明書を発行したら絶対にログに残るんですよ。
今のChromeって、Chromiumもそうなんだけど、ChromiumとかChromeってCTログがないTLSの証明書って有効にならないんですね。
なるほど。CTログっていうのはその証明書を発行した時に記録される?
そうです。CAが証明書発行した人がそこCAログっていうのに登録しないと、そもそもChromiumとかで有効にならない。
そのログは全世界共通みたいな感じなんですか?
全世界で見れますね。
全てのデータベースで統合されたものって感じなんですかね。
どうなってるかわかんないけど、自分は統合されたサイトで見てますよ。RSSとかも配信されてるから、そういうところで見てますよ僕は。なのでCTログは結構簡単に見れます。世界中で。
なんか最近話題になったのが、そのCTログに証明書を発行した瞬間に、そのドメインに対して攻撃が発生すると。
それがCTログを見てるからみたいな感じなんですよね、攻撃者は。
昔は例えば開発環境とかで、ドメイン名を例えば何数とかにして、これでもうバレないだろうとかって思ってた人、昔いると思うんだけど、
39:07
今はCTログっていうのがあるので、どんなにドメイン複雑にしても、CTログ残っちゃうから、TLS証明書を発行したら残っちゃうから、すぐバレます。
ドメイン、その個別の証明書を発行してた場合ですよね。
そうですね。
アスタリスクとかだったら、ワイドカードとかだったら。
ワイドカード証明書だったら大丈夫。
ちょっと話戻して、CTログ。
CTログに、要は発行、世の中に存在してるTLS証明書って、全部CTログ見ればわかるんですよ。
はいはい。
全体集合がわかるんですよ。
で、擬容性がいくら擬容性があるって言っても、じゃあ世界中全てのTLS証明書で計算して、
全部でちゃんと正しいのが出る。
ブルームフィルターだったら大丈夫じゃないですか。
だってCTログにある世界中全てのTLS証明書で確認して、擬容性が起こらないブルームフィルターがあれば大丈夫。
大丈夫ですね。
で、これどうやるかっていうと、まずブルームフィルター作ります。
で、全世界のTLS証明書を通します。
で、ご判定いくつかされるじゃないですか。
そのご判定されたやつだけでもう一回ブルームフィルター作るんですよ。
そうすると結構サイズ縮むから、それでもう一回ブルームフィルターやる。
で、擬容性がゼロになるまでブルームフィルター作るんですよ。
つまりブルームフィルターというものを何個か作っておいて、
しかもそれは事前計算が可能ってことですね。
そうですね。全体集合がすでに分かってるから全部計算できるんですよ。
これ多段ブルームフィルターで一個一個確認していって、なんか決勝戦みたいな。
もう最後までやり続けて、最後の最後まで擬容性がゼロになるまでやり続ける。
ちょっと気になるのが、CTログ。今もずっと更新されてるわけじゃないですか、そのログ。
この多段ブルームフィルター、終わらなくないですか。
良い指摘で、多段ブルームフィルター作った後に新規追加されたやつは、
擬容性が発生する可能性はゼロではないです。
ただめちゃくちゃ低い確率です。
なるほど。そこにかけるってことですね。
そこにかける。
もう全ての多段、複数ブルームフィルターあるから全部素通りするっていうのは相当な確率ですね。
しかも結構1日1回とかかな、どれくらいの頻度かわかんないけど結構な頻度で作り直してるんで。
このブルームフィルター、多段ブルームフィルターをですよね。
そうですね。
この多段ブルームフィルターを配ることによって、ローカルでその全ての証明書の執行情報を見つけられるっていうのを
ファイアフォックスはなんとやっている。
なんかすごいことしてますね。
なんか、そこまで頑張るって感じが。
そこまで頑張るって自分も思うんだけど、
42:02
ファイアフォックスはやっぱり世界中の、特別化したくないみたいな思想で頑張ったんだと思うんですよ。
思想強いなって感じなんですけど。
思想強めで。
実はちょっと1個残念なお知らせがあって、自分が今説明したCR Liteは1個世代が前のCR Liteなんですよ。
最新CR Lite。
最新のCR Liteはブルームフィルター実は使ってなくて、ブルームフィルターよりもっと圧縮できるアルゴリズムを使っているらしいです。
なので1世代前なんですけど、ただ基本的な考え方は一緒で、
世界中すべてのTLS証明書をCT Logが取ってきて、世界中すべての証明書に対して擬容性が発生しないデータ構造っていうのを多段で作るっていう基本的な構造は変わらないです。
なんでそっちを説明しないかっていうと、自分も他人に説明できるほど理解をしていないという悲しい感じになっているので、1世代前の方を説明しました。
なるほど。なんていうか、ここの部分開発してる人ももちろんモジュラにいるかなと思うんですけど、なんて言うんですかね、すごいですね。
いやこれ本当に多段ブルームフィルターはね、本当にそこまでやるかと思ったけど、すごい勉強になりましたね個人的に。
ブルームフィルター前から知ってたんだけど、擬容性あるもんだと思ってたから、全体集合が決まってるんだったら多段であれば擬容性最終的にゼロになるよねっていう。
なんていうんだろう、なんとなくなんですけど、ちょっとブルームフィルター使うのは頭いい感じがするじゃないですか、ちょっとなんかコンピューターサイエンスな感じがするじゃないですか。
コンピューターサイエンスある程度やってた人は知ってるけど、まあまあそうですね。
で、CTログで全部を通せばいいやんっていうのはなんか力で解決してる感がありますね。
そうですね、やっぱりその数学とかの理論的にはやっぱり無限に要素が無限にあったらブルームフィルターって絶対あの必ず擬容性が出ちゃうんだけど、
現実世界に無限はないから。
有限だよねっていう。
絶対有限だから、なんか頑張れば終わるよねっていう。
じゃあモジュラーのCAのサーバー上ではずっと新しいフィルターの方ですかね、今のブルームフィルターじゃないとは思うんですけど、新しいフィルターの実装がずっと動き続けてるってことですね。
ずっと動き続けてるはずで、新しいロジックの方が多分計算時間かかると思うんだよね。圧縮はされるんだけど、計算に時間かかると思うんで、多分すごい頑張って計算してるんだと思いますよ。
大変なことになってそうなんですね。
大変で、その代わり配る必要があるファイルのサイズっていうのは、まあそれでもデカいんだけど、そこそこ圧縮できるっていう。
で、その配ってるファイル、その結果のファイルはリモートで配布してるんですか。
1日複数回とか確かダウンロードしないといけないはずなんで、だからHSFリロードとかとは全然違う。
別に組み込まれてるわけでもなくて、定時で例えば1時とかにダウンロードしてきてみたいなことがされてるってことですか。
45:07
そうですね。具体的な実装は知らないけど、定期的にダウンロードしてきて使っている。
なるほど、そういう実装になってるんですね。
ファイアフォックスの実装ですね。今回唯一ファイアフォックスの実装です。
やっぱ全然違いますね。クロミウムとファイアフォックスで。
ファイアフォックスの方がちょっと地層強めな印象はありますね。
強め。で、クロミウムの方はちょっと現実に寄ってますね。
現実に寄ってる。全部返さなくても重要なやつだけ返せばいいでしょっていう考え方。
分かるって感じがする。そのなんか証明書が有効期限をどんどん短くしていくと、
最終的には45日とか1ヶ月にしていくよっていう流れの中で、
ファイアフォックスはCRライトという形で事前にフィルタリングできるような仕組みを持ってるわけじゃないですか。
これ変わってくるんですかね、ファイアフォックスの方も。それともずっとやり続けるんですかね。
それも正直分かんないですね。もうみんながいろいろやってるんですよね。
だからテレビの証明書の有効期限を短くするってやつも通ったし、
ブラウザーブラウザーで何とか執行情報を早めに取れないのかっていうのを頑張ってやってるんだよね。
各クライアント側で模索してるって感じなんですね。
みんなが模索してる正しいかっていうか、そういうやり方を模索してるのが今なので、
正直CRライトがずっとこのまま続くかどうかも分からないっていうのが今ですね。
なるほど。基本的には有効期限を短くした方が安全だよね。だからそっちに倒してるっていうような業界も。
動きもあるけど、結局執行した後、やっぱり有効期限残ってるから、その残っている有効期限の間は悪さできちゃうよねっていうツッコミがあるんだよね。
現実としてね。
それに対する買いが、クロミウムとファイアフォックスでちょっと微妙に違うっていう感じですね。
なるほど。面白いな。全然ファイアフォックス使うか、クロミウム使うか、クローム系使うか、
こういうところを見て、別にたぶんCRライト実装してるからやっぱファイアフォックス使うんだよなみたいな人もすごい特殊だと思うんですけど、
きっと居はするだろうなとは思うので、世界の中に。
そうですね。やっぱりこういう実装、勉強になるんで普通にみんなも追ったらいいんじゃないかなと思ってますね。
面白い。ちょっと結構いい時間になってきたので。
でもね、あともう一個紹介したいんですよ。
もう一個紹介したいんですよ。
じゃあ最後にもう一個いきましょうか。
こっちは割と軽いやつなんだけど、正式名称はよく分かんないんだけど、パーバセイブリソースURLパターンズとかって呼んだらいいのかなと思っていて。
長いな。
あのね、これね、Chromiumのソースコードの中で使われてるだけで、なんか呼び名がついてるわけじゃないから、何て呼んでるのかよく分かんないんだよね。
48:03
どういうものなんですかね。
我々の世代って、JQueryめっちゃ帰った世代じゃないですか、我々。
もうJavaScriptを使うんだったらJQueryを使えと。
JQueryみたいな、我々そういう世代じゃないですか。
当時JQueryの時代って、なんかそのCDNでJQuery配ってるサイトがあって。
ありましたね。
これを使った方が、JQuery手元にダウンロードしなくてよくなることあるから、早いよみたいなこと言われた経験ないですか。
あります。
あるじゃないですか。けどこれって今のブラウザで成り立たないんですよ。
なんでかっていうと、今のブラウザだとそのプライバシーすごい気にしてるから、
例えばそのJavaScriptのキャッシュとかあると、もうロード時間とか全然短くなっちゃうんだよね。
だからその人がそのキャッシュ持ってるって、もう結構簡単に分かっちゃうんですよ。
キャッシュ情報でプライバシーが。
例えば、どっかのAってサイトに行ったら、このBってファイルをJavaScriptダウンロードします。
他のサイトに行った時に、そのBのファイルをダウンロードさせたら、一瞬で終わりましたと。
でなったら、その人がAってサイトに行ったっていうのが簡単に分かっちゃうんですよね。
サイトの履歴が分かるってことですね。
その人が過去というか直近どこのサイトに行ったのかっていうのが結構簡単に分かってしまう。
これはプライバシーが流出しちゃうよねっていうところで、できなくなったんですよ。
キャッシュがそのドメインごとにパーティショニングされていて、
もう特定のサイトでダウンロードしたキャッシュは別のサイトでは使えない。
っていう感じになってるんですね、現状。
っていう実装に結構前になったんですよ。
けど、これってやっぱり遅くなるじゃないですか。
すでにダウンロードしてるファイルをまた別のドメインに行ったらダウンロードしないといけないから。
単純に非効率ですよね。
単純に非効率だし、実際昔Yahooの人に聞いたことあるんだけど、
Yahooだともう取れてるらしくて、この仕様のせいでもうYahoo全体のパフォーマンスが落ちてる。
ウェブのパフォーマンスが落ちてるっていうデータも取れてるって聞いたことあって、
結構多分CDNの事業者とかだと、この仕様のせいで多分そのトラフィックの利用量増えてるから気づいてるはずなんだよね。
この仕様のせいでどんどんどんどんダウンロード数増えてると。
だってもう何倍だよって感じですよね、そのドメインごとなんで。
ドメインごとに。例えばさっき言ったJQueryもそうだし、あとGoogleアナリティクスみたいないろんなアナリティクス系とか各サイトで全部ダウンロードしないといけないってなって、
いやちょっとさすがにパフォーマンス落ちてるよねっていうので、もういいんじゃないかと。
例えばさっき言ったJQueryとか、あとGoogleアナリティクスとかってもうみんな使ってるから、
もうそれがキャッシュあったところでどこのサイト行ったかなってわかんないじゃん。
特定はできないですよね。
特定できない。多すぎて。
で、さっきちょっとパワーパシーブリソースURLパターンズって言ったんだけど、パワーパシーブって、
自分も初めて知ったんだけど、病気が蔓延するの。蔓延って意味らしいんですよ。
51:06
要は蔓延してるURL。
なるほど。めちゃくちゃ有名なURLってことですね。
有名とか、もういろんなところにもう蔓延しちゃってるURL。
っていうので、これはもういいじゃないかと。
キャッシュがあったら、それもキャッシュパーショニングしないで、もう絶対に使っちゃうよっていう。
なるほど。じゃあ、特定のURLのみなんですね。
特定のURLが、けどこれがウケるのが、Chromeのソースコードの中に書いてあるんですよ。
ベタ書き?
ベタ書きで、JQueryとか書いてあるんですよ、普通。Googleアナリティクスとか。
ただ、これがベタ書きされてるのは実はコメントアウトされていて、
実際のソースコードに書かれてるのはバイト列が書かれてて、
これのバイト列は、そのコメントに書かれてるURLをZstandardっていう圧縮形式で圧縮したやつなんですよね。
Zstandardの話もしておくと、割と最近Chromiumに追加されたんだけど、
もともとGzipっていうのがずっと使われてきて、圧縮フォーマットとして。
今のWebってGzipがほぼ全てのアプリケーションを対応してるんだよね、Gzip。
Gzip対応してないと、レスポンスサイズ5倍ぐらいになっちゃうから、みんな対応してるんだけど、
結構前なんだけど、ブロトリっていうのも出てきたんですよ。
ブロトリ。
Gzipの代わりにブロトリのほうが圧縮さらにできるよっていうのがブロトリで、
ブロトリの特徴を言うと、その辞書ファイルっていうのがあって、
この辞書ファイルが結構特徴的で、HTMLとかJavaScriptとかCSSによく出てくるようなものが辞書ファイルにすでに登録されてるんですよ、ブロトリの。
なるほど、登録されてるから圧縮がしやすいよね。圧縮がさらにされるよねってことですね。
HTMLとかCSSとかJavaScriptに関しては圧縮率が高くなりやすい。
なのでGzipの欠点としては、すごいちっちゃいファイルを圧縮すると逆に容量増えちゃうって問題があるんですよ、Gzipって。
けどブロトリも全くないわけじゃないんだけど、これもそもそも圧縮フォーマットの宿命だから全くないわけじゃないんだけど、
ブロトリの場合、HTMLとかCSSとかによく出てくるやつはすでに辞書ファイルあるから、ちっちゃくても結構縮むんだよね。
DIVとかですよね。
DIVとかあるはず。本当によくあるやつだなみたいなのが、ブロトリの辞書ファイル面白いから見てみたらいいと思うんだけど、結構あるあるみたいなやつが結構登録されてる。
なのでそのブロトリっていうのはある。ブロトリっていうのは結構ウェブ上では使えるんだけど、ブラウザーの普及率はすごく高いから使えるんだけど、
ブロトリにはすごい致命的な欠点があって、圧縮のコストがすごい高いんだよね。
圧縮するのに時間がかかっちゃう。
時間かかっちゃう。だからGzipよりも普通にブロトリに、Gzipの代わりにブロトリ使っちゃうとレイテンシーが大きくなっちゃって、結局パフォーマンス落ちちゃうんだよね、大抵の場合。
54:05
なので実際にはブロトリせっかくあんのに、ほとんどみんなGzip使ってて、ブロトリはCSSとかJavaScriptみたいな静的なファイルを事前に圧縮して返すっていう用途でしか使われてないんだよね、ブロトリは。
で、それをやっぱりGzipの代わりのやつ欲しいよねっていうので、割と最近Chromium追加されたのがZstandardっていうやつで、
Zstandardは元々Facebookが作ったやつで、多分一番有名なのはマイスケールのデータ圧縮するために使ってたんだけど、Zstandardって。
最近はブラウザでも使ったらいいんじゃないっていうので、Zstandardが最近ブラウザにちょっとずつ入り始めてる。
なのでZstandardの特徴としてはもう軽いんだよね、とにかく。実はブロトリよりも圧縮率は悪いんだけど、軽いからGzipの置き換えに使えるっていうのがZstandardで。
で、なので最近Zstandard入ったんで、そのZstandardでそのURLのパターンが圧縮されたやつが入ってる。
バイナリーがバイナリーコードとして含まれてるってことですね、ソースコード。
そう、Zstandard圧縮されたバイナリーがソースコードに入っていて、多分これ一応ね、URL200個ぐらいあるんですよ。
これ、CheckEllyとかGoogle Analyticsとかいろいろ書かれてるんだけど、あとTikTokとかも書かれてたんだけど。
なんかね、その200個ぐらいあって、その200個そのままURLベタ書きすると、ちょっとChromiumのバイナリーサイズが増えちゃうじゃないですか。
なんで、ソースコード上ではZstandard圧縮しておいて、実際使うときはZstandardで展開する。
Zstandardだったらそんな時間かかんないからっていう風な使われ方をしていて、
これはね、なかなか特にね、ChromiumのソースコードにCheckEllyとかって思いっきり書いてあるのがね、結構ウケるので、
結構ね、これはね、今まで話したやつとはちょっと軸ずれるんだけど、
これはこれでね、面白いから紹介しました。
そういう実装になってるんだっていうところと、あとなんか特別扱いするものがあるんですね、やっぱし。
そうなんですよ。結構ね、今のウェブブラウザって本当にいろんなことやってるし、
このURLだけ特別みたいなのが全然あるんで、結構ね、やっぱChromiumのソースコードってみんな読まないから、
結構ブラックボックスだと思うんだけど、結構ね、こんなことやってんの?みたいなやつ結構あるので、ブラウザって。
やっぱね、ブラウザの中身に興味持ったら結構いろいろ見えてくるもの変わるんじゃないかなって個人的には思ってますね。
ありがとうございます。なんか結構面白い話聞けたかなと思うんですけど、
なんて言うんですかね、Chromiumのソースコードってかなり巨大じゃないですか、絶対に。
なんか片杉さんが読み始めたきっかけみたいなのって、ちなみにあったりするんですか。
57:01
そういう意味で言うと、自分もね、気になったところしか読まないので、そんな全体読むってことはないんだけど、
やっぱり最近AIが出てきたので、AIに聞くと結構教えてくれたりはしますね。
ただ、やっぱり気をつけてほしいのは、Chromiumのソースコードってめっちゃでかいんで。
そうですよね、巨大ですよね。
AIのトークン一瞬で使い果たすんで、そこは気をつけてほしいし、やっぱり実際やると、
我々みたいにウェブアプリケーションを普段作ってますみたいな人と、
Chromiumみたいな超巨大な、しかもシープラプラを触ってますみたいな人だと、
多分AIコーディングに対する印象って違うと思うんだよね。
絶対違いそう。
そう、なんか規模が違いすぎるし、AIのトークン消費量も全然違うし、
多分その辺の印象は、やっぱり普段見てるアプリケーションよりって全然違うと思うんで、
なんか我々みたいにウェブアプリケーションで使って便利だから、
みんなも便利でしょみたいなふうに安易に思わない方がいいんじゃないかなって思ってたりしますね。
AIの利用ですよね。
AIの利用で、ウェブアプリケーション作れるから他のも余裕でしょとか思わない方がいいと思ってますね。
全然違う世界ですもんね、だって。
全然違う。
アプリケーションレイヤーをやってるところと、ブラウザーの本当にコア機能をC++で書いてるようなチームなんてのは、
全然、多分同じソフトウェアエンジニアだとしても全然違う世界線だと思うので。
自分もこの前、Chromiumでちょっと今回のやつは別の仕様とか調べさせたんだけど、
本当に一瞬でAIのトークンのやつ終わってしまったので。
じゃあ、Chromium開発してるようなチームとかってどうしてるんですかね。
まだ手で書いてたりするんですかね。
まあ、なんか多分完全に自動化とかはできてないって聞いていて、やっぱ半分ぐらいは手で書いてるっていうのは以前聞きましたかね。
この辺もやっぱ状況ですぐ変わると思うんだけど、やっぱり今のウェブアプリケーションみたいに、
もう結構AIにあれだけでもいいじゃんみたいなこと言ってる人はいない印象がある。
なんかそんな楽観的というか、そんな簡単な話じゃねえよって。
そうそう、そんな感じ。
規模感全然違えんだよって話ですね。
そうですね。
なんかここの部分だけ見たいみたいな、ソースコード全体を解析対象としてしまうとめちゃくちゃ巨大なんで、
なんかこの部分だけいい感じに抽出してみたいみたいな、なんかいいやり方、チップスとかあったりするんですかね。
片瀬さんの中でそのAIの使い方。
いや、自分は正直そんなでかいソースコード扱ってないから普段。
ほんとたまにChromium調べたいなぐらいしかないからあんまりないっすね。
溶けるわけじゃないですか、Chromium調べてるときに。
そうですね、もう溶ける一瞬で。
溶けるけど、溶けるまでの間に頑張るみたいな、そんな感じなんですかね、現状が。
いやどうなんだろうな。
いや自分もね、その辺はあんまうまくやれてないし、そもそも自分もね、Chromiumのソースコード当たりつけらんないんで、
やっぱりある程度経験があって、この辺でしょって当たりつけられる人はこの辺調べてくださいとか言えると思うんだけど、
1:00:02
やっぱ普段Chromium触ってない自分みたいな人間からすると、もう全体見て調べてくださいとしか言いようがないので、難しいかなと思いますね。
あのとっつき、なんかタッチポイントわかんないし、そもそも。
わかんない、マジでわかんない。
AIが出る前はもう頑張って単語で検索して、それっぽいクラスとか、クラスはないか、それっぽいヘッダーファイルとか見つけてきて、
なんかそのいろいろ見たいとかっていうのをやって頑張って見つけてきたんだけど、
最近はね、そこまでやらなくてもAIが見つけてくれるんで、以前よりはだいぶハードル下がってると思いますよ。
とはいえってところですね。
とはいえ大変だけど、以前よりは本当に下がってます、ハードル。
そもそもC++を読むというところのハードルはAIによってかなり下がってるわ。
かなり下がってる。
下がってはいるとは思うので、そこの部分に関してはいいけども、とにかく巨大だし、
ブラウザが扱ってるデータは全世界のものだからとにかく巨大なんだというようなところですね、今回の話は。
そうですね、今回の話は。
でもね、ちょっと話すとね、ファイアフォックスはね、最近ラストが増えてきてて、
この辺のアルゴリズムもなんか外出し、ライブラリーとして外出しされてることも最近ちょっとずつ増えてきてるんで、
ファイアフォックスのソースコードだとラストかもしれない場所によるけど。
なるほど、ちょっとパッケージ分けて開発されてたりとかするんですかね。
今回紹介したロジックとかも一部GitHubで公開されたりとかするので、
ラストのコードで、興味ある人はそういうの見てみたらいいかもしれないですね。
なんかやっぱそこら辺のブラウザの低レイヤーというのかちょっと分かんないんですけど、
やっぱここら辺の速度を気にするだったりとか、あとは堅牢にするみたいなところでラストの利用とかがどんどん、
C++の機械としてラストが増えてきてるんですかね。
そうですね、もともとモジュラーがC++の置き換えで、
ブラウザを実装できるC++を置き換えられる言語が欲しいっていうので作ったのがラストなので。
そういうモチベーションなんですね。
もともとそういうモチベーションで作られた言語なので、
ちゃんとそのモチベーション通りのものがちゃんと実装されてるっていう感じですね。
なるほど、じゃあもしかしたら違うかもしれないですけど、
Googleの場合はGoとかが入ってくるのかなとは思うけど。
Goは入ってこなくて、ラストもChromiumにラスト入れようって話確かあったと思うんで、
なんで、ラストっすよ、基本的にブラウザは。
ラストにどんどん置き換えられていくって感じですね、じゃあ。
そうですね。
じゃあ今後はラストにどんどん置き換えられていったら、
ちょっとずつC++をやるから読みやすくなってくる。
かもしれないですね。
感じがしますね、未来においては。
ありがとうございます。ちょっと今回はかなり趣向が違うような話できたかなと思うんですけど、
最後にブラウザについて、Chromiumのソースコードリーディングについて何かあったりしますか。
そうですね、ソースコード読むというよりも、自分結構そういうの調べるの好きで、
例えばCRL周りとかそのOCSPが配置されて、CRLどうすんのみたいなのが結構話題になっていて、
1:03:06
その時に色々調べてたらこういうの見つけて、ソースコードとかも調べていったら色々出てきたって感じだったので、
ぜひこういうところにみんなも興味を持ったら結構色々わかるんじゃないかな、
結構わかるというか、今までにない資座とか得られるんじゃないかなと思ったりはしますね。
いいですね。ありがとうございます。
では今回はここまでにしたいと思います。
ヤウヨロズのOSSでは毎回一つのOSSを取り上げて、
それについて片付いてエンテコで技術的なところも深掘りしながら話をしていく番組になっています。
今後もその名の通りヤウヨロズのOSSを取り上げていけたらなと思ってますので、
ぜひお聞きのプラットフォームでフォローのほうと高評価のほうをお願いします。
またこのOSSについても取り上げてほしいなどありましたらコメントをいただけると非常に嬉しいです。
番組についての感想も非常にお待ちしておりますので、ぜひともよろしくお願いします。
Xなどでつぶやく際にはハッシュタグヤウヨロズのOSS、ヤウヨロズは800万、感じですね、をつけてください。
それでは今回もありがとうございました。
ありがとうございました。
