季節の移り変わり
こんばんは、Replay.fm 第58回です。
こんばんは。
こんばんは。
こんばんは。
さあ、寒くなりましたね。
え?
寒くなってきました。
あー寒くなったね。だいぶ寒いね。
今日とか普通に寒かったな。
今日、たぶん、相当久々に窓も開けずに、冷房もつけずに寝れそうな気がする。
いい話。
うん。
何もせずに22度。
いい話じゃないですか。
ちょっと寒すぎるなー、でも、なんか普通に。
うん。
もうちょっと、うーん、心の準備がという気持ちが。
心の準備。
まぁでも、ぼちぼち女装あったっしょ。
あったかもしんない。
そう言われず見るとあったかもしんない。
なんか、あんまなかった気がするんだよなー。
まぁ、なんかまぁ、年々女装が短くなってるという話はあるよね、普通に。
うーん、ある。
いやー、また風邪を引かないかどうかのバトルだと思ってるわ。
うん。
季節の代わりめ。
頑張っていけばね、気をつけて。
うん。
JavaScriptの信頼性
じゃあ、まぁ、ぼちぼち読んでいきますか。
うっす。
以上、一つ目。
えー、私読もうかな。
Improving the Trustworthiness of JavaScript on the Web
クラウドフレアの記事ですね。
で、この記事は何かというと
ちょっと前提としてめっちゃ難しいし記事も長くて
で、ちゃんと読もうと思ったら元のW3Cの仕様を読まないとなという気持ちを抱えつつ
斜め読みした上での理解を話せればなと思うんですけど
クラウドフレアをはじめとして
いくつかのウェブのプロバイダーとかなんですかね
いろいろサービスやってるところが
ウェブ上で展開されるJavaScriptファイルの信頼性を担保するための
仕様っていうのを策定していて
その話をしている、解説をしている記事ですと
仕様自体は確定とかじゃなくて
多分まだまだドラフトなんだけど
エクスペリメントというか概念実証し始めるのかな
ブログの記事の雰囲気的なそれぐらいのフェーズなんだけど
まだまだ柔らかい段階なんだけど
その話をしていて
前提として何を解決したいかの話からまず言うと
ウェブ上、今僕らNotionのページを開きながら
Riverside FMのページを開きながら収録をしてますけど
その上でいろんなJavaScriptが動いて
当然動いていて
JSが動かないサイトはほとんどないと思うんですけど
そのJS自体が信頼できるのかどうかみたいなところを
検証する仕組みってないですよねっていう話がありますと
具体的にどういうことかっていうと
記事中で対比として出してくれてるのが
アプリはどうでしょうみたいなところの対比がすごく分かりやすくて
アプリっていうのはiOSアプリとかAndroidアプリのことなんですけど
それらのネイティブアプリに焦点当ててみたらどうかっていうと
どっちもアプリをまずビルドする段階で
正当な開発者の証明が必要
その時点でアプリに含まれる全てのアセットとかコードっていうのは
証明がなされている状態だし
それをプラットフォームに展開するタイミングでも
当然アカウント情報とかいろいろキーが必要
なので少なくとも正規の方法で
iOSアプリとかAndroidアプリをインストールしてくる場合は
そのアプリ自体とかそのアプリの上で動いてるコードっていうのが
ある程度はアプリリリースした人が
作ったものであるっていうことを信頼できるよねっていう
もっと言い換えると
例えばアプリをインストールしてくるどっかの過程で
MaliciousのコードとかMalwareとか仕込まれてないよねっていうところに
一定の信頼性が持ってるよねっていう話が対比として抱えていて
一方でJavaScriptはどうかっていうと
基本的にはWeb上に配置してそのパスをHTMLが参照するだけ
なのでそれ以上でもそれ以下でもない仕組みだし
またその性質上 例えば
Notion開いてNotionのJSがいろいろ読み込まれる中で
そのJSファイルが全部NotionがバンドルアウトからビルドしたJSかというと
そうじゃないこともある話があるはずで
GTMのタグを埋め込んでとか
その外部のJSのタグが埋め込まれてたりとか
広告のJSが埋め込まれてみたいな
いろいろその開いてるページのオリジンとかドメイン以外のJSも
いろいろ読み込まれてるけど
でもそこに対して何の認証というか
それを信頼することを担保する仕組みないよねっていうのが
そもそもの課題感として書かれていて
そこに対して一つこういう方法を考えてるよっていうのが
前提の記事です
もう長いし
長いね
ちょっと複雑なんで
ちゃんと理解したかったらぜひ読んでくださいって感じなんですけど
課題と解決策
すごくざっくり
ざっくりの僕の理解を話すと
何をしようとしてるかっていうと
そもそも前提知識として
これマジで全然知らなくて
これ知ってんの常識なのかなって思いながら
ドキドキしながら読んだんですけど
サブリソース完全性っていう
サブリソースインテグリティですね
何かっていうとスクリプトタグで
何かJavaScript読むときに
その読み込むJavaScriptのハッシュを
HTML側にタグに一緒にセットすると
ブラウザ側でそのハッシュチェックをしてくれて
違うものが混ざってたら
JSON軸を防ぐっていう仕組みがあって
これをある種
少し拡張するような話っぽいんですと
ざっくり登場人物が2つあって
1つがそのページ
開いてるページにおける
マニフェストファイル的なものをまず1つ用意しますと
このマニフェストファイルには何が入るかっていうと
今開いてるページで読み込む
すべてのJavaScriptを含めた
アセットのリストというのが
リストとそのハッシュというのが全部書いてある
なので
あるページのトップページを読んだときに
そのトップページでJSONを5個読み込む
であればその5個の読み込む
フルのURLのURLと
その読み込むJSONのハッシュっていうのを
PairをJSONみたいな形で
まずマニフェストとして定義する
というのが1つと
またこのマニフェスト
もう1つはこのマニフェストに基づいて
ブラウザ側にどれぐらいの強度で
整合性チェックをしてほしいかというものを
どれぐらい細かく設定できるかわからないですけど
ある程度指示ができるっていうのがあって
その設定があるっていうのが2つ目
なので例えば
記事帳の例思い出せないな
思い出せないけど
例えばイメージとしては
一番多分ストリクトにやるんだったら
マニフェストファイルにある
ハッシュとJSONが一致しないんであれば
そもそも読み込みもしないでください
みたいな形で制御するっていう
方法もできるし
またグラデーションも多分つけられるのかな
いろいろその辺の強度みたいなのが
設定できると
イメージ的には勝手に解釈したのは
なんだっけ
思い出せない
CSPじゃないんだけど
クッキーのCSRF対策
セームサイト
そうです
セームサイト
LUX
ストリクトノンみたいな
そういう感じなのかなって勝手に解釈した
間違ってた ごめんなさい
その2つのセットで
ページ側で設定してあげるよっていうのが
スーパーざっくり言うとやること
当然記事帳にはそんな
今言ったほどシンプルな話じゃなくて
いろんな場所で
こういう部分でこういう仕組み入れて
こういうことを担保してるよみたいな
いろいろ細かくあって
その辺はちょっと
僕も良い勉強かなと思いつつ
ざっくり言うとそんなところですね
個人的にこれ読んで思ったのは
課題感は確かにっていうのと
そこに解決策を見出そうって発想が
正直持ってたことがなかったんで
なるほどなっていう部分と
実際にこれが
サービス作る側目線に立ったときには
フレームワークとかに
この辺の生成サポートしてくれないと
不可能だなっていう気持ちもありつつ
もしできるんだったら
例えば分かりやすいとこだと
Webスキミングで
JSに変なの混ぜ込まれるみたいなのとかに
対策になったりすんのかなと思いつつ
ただ結局そのマニフェストファイルまで書き換えられたら
アウトではあるから
例えば外部のやつ
読み込んでるやつがおかしくなったときに
ブロックするとか
めっちゃ有効そうな一方で
自社がホスティングするのに
混ぜ込まれるパターンとかは
その侵害のされ具合で
これ入れててもダメだよねってパターンあるかな
とかは思いつつ
ただ期日中で触れ合えてたら
なるほどなって思ったのは
どのタイミングでどのJSを
読み込むかみたいな部分の
ある種ログというか
記録としても残せるから
ないよりはいいんだろうな
みたいな部分はありつつとか
またちょっと
GTMで
CSPとかでしたっけ
どうしてもGTM使うと
CSP緩めざるを得ないみたいな
問題があると思うんだけど
そういう部分に対して
一定緩和になるのかなというか
変なJSがどうしても入り込む
口を塞げないけど
このままフェストと厳しいプリシを
敷いとけばそこのリスクを
ある程度緩和できるとかが
もしかしたらあるのかなとか思いつつ
今後に期待したいなという
まだまだ柔らかそうな雰囲気は
あるんですけど
とはいえブログ記事はしっかりしてるし
アプローチとして
どうなんだろうね
これ見たら思い出したのは
サインドエクスチェンジとその仕組み
サインドエクスチェンジってやつなんだけど
俺も説明できるほど
ちゃんと理解してないんだけど
Googleの仕組みなんですか
Googleの仕組みではないはずだな
こっちか
署名付きエクスチェンジ
パッケージ化したWebアプリケーションに対して
署名を付与して
みたいな
さっきのGoogleのあれは
プリフェッチ
サインドエクスチェンジが有効だったら
プリフェッチするよ
なるほどね
確かに近そうには見えるね
これは多分Webの世界に
アプリっぽいアプローチを持ち込んでる
さっきのCloudflareの
記事で言うところの
アプリっぽいアプローチを
持ち込む話なのかな
そうだね
これの場合は
ページ単位とかじゃなくて
サイト単位で
パッケージを事前に作って
プリフェッチするみたいな考え方なのかな
多分そういうイメージかな
PWAとか思い出させる
おぼろげに浮かんでくる
仕組みだね
そうなんだろうな
この記事で言うところの
やり方って
ユーザーコンテンツが
多いようなサイトとかどうなるんだろうね
大丈夫なのかな
ユーザーコンテンツ
次にもっかいハッシュを生成して
ツリーを再構築する
という感じなのかな
それで言うと多分HTML自体の
ハッシュとかを
話は出てきてないんだよね
あくまでそのページで読み込む
前提としては
ドキュメントは
多分ドキュメント侵害されちゃったら終わりだから
ドキュメントは
URL打ち込んで
帰ってきても正解なものだとしても
そのドキュメントから参照する
無数のリソースがあって
それが信頼できんようにみたいな部分が
起点になってる気がする
インテグリティマニフェストに
index.html含まれてるじゃん
サンプルで出てるやつ
本当だ
じゃあ確かに間違ってる
なるほどね
そもそもJSのコードが
っていう話をしててさ
HTML中にJSのコード書けるんだからさ
確かにそりゃそうっすね
確かにね
都度計算する
世界観なのか
まあ
これちゃんと読んでないんだけど
インテグリティマニフェスト自体はどうやって配信する?
ざっと見ようかと
した感じは分かんなかったんだよね
でもなんか
結構ね
込み入った仕組みだった気がするんだよな
多分ここに配置して読んでもらうとか
そんな単純な仕組みじゃなかったはずで
トランスパレンシーのサービス
これさだからなんか
なんだっけな
なんかのさ
記事で
ちょっと忘れちゃったけど
外部
外部から
中でやってることの
取り組みの正当性を検証できるようにしたよ
みたいなさ
なんかの仕組みの話があったじゃん
だいぶ前だけど
全く思い出せない
あったとしよう
多分それ系の話なんだろうな
やべー何のあれだったっけな
全く思い出せないな
そうねやっぱこの
マニフェスト自体は
多分
トランスパレンシーサービスを証明
してるのか
でブラウザはそれを検証する
第3者がいる仕組み
第3者がいる仕組み
なんだよね
もうちょっとね
もうちょっと
勉強してきますって気持ちがある
どうなんだろうね
わからんけど
そうだね
割とまだまだ初期段階で
あるんだよなJSに限らず
ASMとか画像とかでも
そこのサポートを
次ステップでやるって
言ってるからまだまだ
うん
そうっすね
今後に期待したいなって感じ
ですね
ドラフトはビッタブで終えるんだね
うーん
これ系なんか追ったことないから
あんまわかんねーなどこ見ればいいか
さっきの思い出せないやつが
全く
すげー気になる
なんだっけ
どこだっけな
Google Docsが見れる
やべー
やべー超気になるけど
超気になるけど
見つけらんねー
どこだっけ
それもCloudflareだった気がするんだけど
ここで読んだなら
Notion Airに聞けば出してくれるかもしれない
いやー
なんかちょっと曖昧すぎてどう聞いたらいいのかすら
わからん
いやー
頑張って絞るしかないねそしたら
いやーしょうがないな
キーワード的には多分
透明性とかなのかな
うん
しかも俺Notion Air使えねーしな
あーそうか私の
Notion Airなー
Web系じゃない気がするよ
あーなるほど
必ずしもWeb系ではなかった
まあでもあんまNotion Airに期待してないんだよな
正直ね
いやーもうやもやするなー
ふふふふ
やもやするなー
これな?これだっけな
いやだいぶ前なんだよ
だいぶ前なの多分
うーん
収録終わるまでに思い出しておいてください
はい
あー
もういいや
一切れ目から謎の苦しみ方をする
諦めよう
いやー夜しか眠れなくなっちゃう
残念だなー
よし
次お願いします
NISTの新パスワード基準
NISTが改訂したパスワード新基準
複雑性より長さ
定期変更より侵害したい
なんだこれInnovatopia
なんかこれ
多分Xに流れてきたのそのまま拾ってきただけなんだけど
はい
えっとなんかNISTって
NISTって呼んでいいのかどうなのかちょっと分かってないんだけど
まあNISTがえっと
なんかパスワード周りの
ガイドラインを更新したよっていう話で
これなんか結構多分長らく
ドラフトとしてずっとなんか
中身は伝わってた感じかなと思うんだけど
まあ正式リリースしたのかな
ちょっと一時操作をちゃんと当たってないから
あれなんだけど
でなんかまとめると
複雑さよりも長さを重視
その例えば文字集の多さとかよりも
えっとシンプルに長さを
重視してねって話だったりとか
定期的変更は不要だよって話とか
秘密の質問の配置だったりとか
あとはブロックリストって呼ばれてるんだけど
その漏えしたパスワードを
えっとブロックするのかな
えっというのが
推奨されたりというのがなんか
まあアップデートのポイントらしいです
日本版ガイドラインの影響
という話です
どうでしたか
ブロックリスト
いやーブロックリストやれんすかね
っていう
いや別にそんなに
ハワイインポンドからさデータ引っ張ってきて
えいってするだけだから
まあねやるだけだったら
実装自体は別に
まあそうね
いやなんかまあまあ
その世の会社が
どこまでちゃんとやりきれんのかな
っていうところには
ちょっと思いはしたけど
まあその
実装もこう実装すればいいわ
一瞬で思い浮かぶんだけど
そんな事情で手を入れられないサイトとか
なんていうか
なんだろうな
ユーザーに対する案内どうすんねんとかで
議論が止まってしまう会社とか
普通にあるんだろうな
とかぼんやり思いつつ
まあいいんじゃない
いやなんかまあまあ
いいんじゃないって言ってんのはなんか
ノーションの方にも書いたんだけど
別に間に受けすぎないっていうのも結構大事なことで
その
なんか
例えばだけど定期的変更が不要です
っていう風に言われたことによって
定期的変更は悪だ絶対ダメだ
っていう話にはならない
みたいなのは当然ある
例えばだけど
どうしてもなくせない
共有アカウント社内の
でも退職者がそれ使うのは困る
みたいなやつとか
定期的なり何らかのイベント
ベースで変更するしかない
じゃん
定期的変更と
イベントベースで毎回更新する
っていうのとどっちがいいですかってなったときに
定期的変更で妥協する
みたいな選択肢としては全然
あり得るかなと思う
理想的かと言うと
必ずしもそうじゃない
その通りなんだけど
それで言うと
なぜこうなったのか
みたいな部分の背景を
掴んどく方が大事だろうね
確かにね
っていうのと同様でブロックリストいる
みたいな話とかもさ
別に
結論いらないになるでも
それはそれでいいんじゃない
そうだね
この記事結構前なんだよね
12日だからいいのか
うん
そうだね
日本版のこれって何なんだろう
日本版のこれが
ちなみにNISTって読んでいいらしい
いいんだ
日本版のこれはない
ないか
なぜかと言うと
政府機関とか公共機関向けの
ガイドライン
っていうか
これをリファレンスしてる
例えば
金融業界向けの
めちゃくちゃ解像度低くて
申し訳ないんだが
なんかそれ系がある
それ系が
追従したら
一部業界は
対応迫られるとかあるのかな
ECI DSSが追従したら結構
対応迫られる
そうね確かに
ECI DSSとこれまずずれてんじゃん
しばらく多分だけど
文字数とか文字種の話とか
割とずれてた気がするけど
パスワード要件
そもそも4.0そうだよね
最近出たばっかだよね
12文字以上の長さ
数字と英字
NFCタグのセキュリティ
変更のポイント
そうだね
十分に複雑に構成する
最低年1回の更新
なるほどね
とうとうって感じですね
なかなか
ありがとうございます
じゃあ次
ウェブサイトへの
誘導展示用のNFCタグの設置に
気を付けよう
基準内容としては
一点して物理の話なんですけど
企業展示のときとかに
NFCタグを使って
展示をするみたいなケースにおいて
セキュリティ面で注意したほうが
いいですよってところを
さらっとまとめてくれていて
具体的には
2つかな
2つあって
1つはそのNFCタグ自体に
例えばかざしたら
サービスエージに飛べますよみたいな
表記をしたときに
そのNFCタグの中身
データ自体を書き換えられないように
気を付けましょうって話が1つあって
対策としては
書き込みだけを禁止するような
設定ができるからそういうもので
守れますよみたいな話とか
またそもそもNFCタグを
物理的に
差し替えられるっていう可能性もあるので
それに関しても気を付けましょう
みたいなところがあって
そこは
差し替えづらくするとか
適的に巡回するみたいな
割と愚直なことが書いてある
って感じですね
多分3分ぐらいで読めるぐらいの
あれかな
内容でした
オリジンバウンドクッキーズの提案
なんか結構
知らん
知らんかったというか
書き込みだけを防げるの
知らなかったなとか
あとはまあ発想としては
もちろんあるよね
似たようなやつでQR決済で
払い込み先を変える
みたいなのが
中国かなんかでちらっと
流行ってたけど
NFCも
高級ジェラーあるのかな
あんまそこは気になるな
と思います
あるよなっていう
気をつける
めちゃくちゃ重要な
そのユースケースに
使ってるかって言われると
そこまでじゃないのかな
と思うから
結構狙うとしたら
用意しゅうと
用意は必要だよね
無差別というか
例えばなんかさ
万博みたいなさ
超企画結構いろんな人が来ますみたいな
イベントとかで
聞こえるのが
あったら
刺さるかもね
確かに
それはそうだね
NFCタグ
シガーはアナログすぎて
パッと思いつかねえな
もっとデジタルな街だと
かざすことあんのかな
NFCタグをかざして
何かやる
まあ
意外と生活にないよな
意外とない
意外とないから
どうなんだろう
ゆえに
自分がやる場になる可能性は
ゼロじゃないから気をつけたいですね
NFCタグね
もうちょっと
あれがすごい地味だけど
スイッチボットのNFCタグ
の製品があって
使ってないけど
使おうと思ってた時あったから
そういうのとか
変だとされるかもしれないぐらいだな
うん
でもいいっすね
このRack Securityこったにブログはこういう
なんか
言い方あれだけど変な
変わりだね
変化系をぶっこんでくる
面白さが割とあるよ
なんかブログ名がいいよね
体現してるわこったにというか
はい
じゃあ
次
クッキーを
オリジンに紐づける
オリジンバウンドクッキーズの提案
仕様
2025年版
そのままの
タイトルそのままの話で
オリジンバウンドクッキーズ
っていう仕様が
IETFに提出されてるよ
っていう話です
2022年にも
Google勢から同様の提案があったんだけど
標準化に至ってなくて改めて
IETFにドラフトが提出されたっていう
状態らしいです
これから議論されるんじゃないかなっていう風に
書いてくれてる感じです
なんか
なんでこれをピックしてるかというと
なんか
動きとしてこういうのがあるよっていうのは紹介したい
っていうのが一つあるのと
なんか
元の提案の方ドラフトの方はさらっと
変わってきたので
明示的にこの動作を指定するのか
暗黙的にこの動作になるのかとか
ちょっとよくわかってないんだけど
記事の中で書かれてる
ドメイン属性つけると異なるポートにも送られるとかは
相変わらずバギーっていうかな
ちょっと分かりにくい挙動だな
って
確かに
クッキーはもうこれはこれでいいんじゃないかな
っていう風に個人的にはずっと思ってる部分も
あり
どうなのかな
でも正直オリジンより
なんか
柔軟かつ弱いっていう
言い方になると思うんだけど
使いやすさはそれはそれであるよなと思っていて
これが
必ずしも悪なのかと言われると
結構判断に悩む気がする
そうだね
なんかその
ウェブの面白さでもあり
難しさでもあると思うんだけど
ガチガチだけど使えないもん
でも多分誰も使わずに
実装されずに終わるだけだから
ブログに感謝
その辺の塩梅が難しいがゆえに
こんな感じになってるというか
ネクストクッキーが出てこない
ゆえんもなんか
そういう部分だよな
っていう気持ちになりますね
でも確かにね
この辺な
現代のウェブ開発最前線において
どこまで理解しなきゃいけないんだ
結構フレーマークがラップしちゃってて
何もわからずに
触ってる人が大半の気がするし
自分の底に
ウェブ開発に戻ると
落ちちゃいそうな気持ちも
どうなんだろうな
でもなんかさ
わからんけど
例えばだけどSSRのサイトで
認証どうしたらいいですか
みたいな相談って
なんか今も昔も変わらず
トピックとしてあるような
っていう気がしてて
そうだね
そうするとだからクッキーしかないんですよね
一発目にリクエストで何か飛ばさせたいんだったら
もうそれしかないんですよね
っていう話とかは
割と昔からよく知ってるような
まあ確かに
意外とラップされてないんだよね
でもなんか
大体そのままお金ネクストジェスト
だったら多分
そのセッションの
ミドルエラーが何種類かあって
なんか
わかんない
ネクストセッションクッキーみたいな
そういうパッケージ名
ベロッと一行書いたら
クッキーのセッションが動くよみたいな
そのコード側でセッションされるときは
そのクッキーがどうかとかじゃなくて
多分
標準的なセッションの
APIが生えててみたいな
感じだと思うんだよね
世界観としては
まあだからそこに印象基盤は別で立っててみたいな話になってくると
多分ややこしくなる
そうだね
インフラというか
もう一段アプリのもう一段
下に行ったときに理解が求められる
気がしたわ普通に
ウェブページは別のドメインで立って
とか
特殊な指標が生えてきたときにじゃあどうすんだよとか
セキュリティリスク
考えなきゃいけないよねっていう部分で
差が出る部分かもね
なんか寿命が何年あったら
いやでも無理だな
何年
何年経ったらすべてを理解した気持ちになれるんだろうと思ったけど
10年経ったら
20年分の
知識が上積みされるだけなんだよな
面白いっすね
はい
ありがとうございます
明日の風ブログさんも助かるいつも
ブログに感謝を述べていくか
じゃあブログに感謝を述べていくか
今日は
うん秋のね
いやマジありがてえよ
秋の大ブログ感謝祭
いいね
じゃあ早いっすけど
早っ
そうなんですよ
今日は寝心しかないし
まあサラサラっとした記事が多かったんで
最後以前のブログで
僕のほうから紹介したくて
サプライチェーンリスク
in VS Code Extension Market Places
っていう記事ですね
なんかVS Code拡張機能に
あるいは仕込まれたとか暗号通貨の進むだろう
なんかそういう記事ってもくさるほど
正直流れてくるんですけど
なんていうか
なんか
そういうなんかリサーチ系の記事ってよりかは
まあリサーチもかなり書いてあるけど
なんかそれに対してこういうことしたよ
っていうのと
緩和策みたいなのをちょっと紹介してくれてて
まあかなり興味深く
かつ勉強になるなと思ったんで
引っ張りました
で何かっていうと
時系列がね
記事読まないと思い出せないけど
多分今年の
前半かな多分なんか
3ヶ月以上前ぐらいから
そのVS Code上に
リリースされる拡張機能に
拡張機能の中に
シークレットがいろいろ含まれてますよ
っていう話がまず
ありますと
これは
おそらく拡張機能開発者が
間違えて
自分のローカル環境の
例えば.envとか
またAPIハードコードしちゃったみたいな
ものをバンドルして拡張機能に
拡張機能としてリリースしちゃって
で出ちゃってる
なんでまあ
なんていうか
ヒューマンエラーに基づく
ものなんだけどそれの数が割と多い
しViz側でそれを結構
見つけていたっていうのがあって
それをまあ
裏側でマイクロソフト
VSコードの安全性向上
ベースコードエクステンションのマーケットプレイスを管理してる
マイクロソフトとあともう一個
オープンなんたらっていうのが
NORAの
NORAっていうとこれ
なんでしょうね
ベースコードマーケットプレイスじゃないもう一個
でかいやつがあるんだけどそっちとコミュニケーション取って
解決に臨んできたよっていう
のが
やってきたことって感じ
ですと
で 具体的に
やったことが
素晴らしいというか
まあ
やれるなら
そうできたらベストだよねっていう解決策を
取っていて
一つは
あれかな
すでにリリースしちゃってる
ものかつ
中には
VSコードのエクステンションをリリースするための
トークンを
拡張機能として出しちゃってる
ってパターンがあって
これはちゃんとリボークしないと
その拡張機能を乗っ取れるって
状態になっちゃうので
それはもうマイクロソフトのほうで
リボークして開発者に
通知しましたっていうところと
あとは
拡張機能をリリースするタイミングで
その拡張機能の
バンドルとかファイルに全部
シークレットスキャンかけて何か検知されちゃったら
リリースを止めるっていう仕組みを
VSコードのマーケットプレス側に入れたっていう
ので
今は相対的には
安全になってますよっていう話があって
すごくシンプルにいい話だし
プロセスとしては
長いとしてはWizが気づいて
マイクロソフトに行って
多分協力して根本対策して
で今
この記事を出してるっていう形かな
あとは
拡張機能を使う側の目線で
何できるのみたいな話も
ちらっと触れていて
全然知らなかったんですけど
VSコードの場合は
マーケットプレスの場合は
エンタープライズの
で利用を想定するための
VSコードのホワイトリスト管理みたいなのが
できるらしくて
VSコードあんま使ってないから
わかんないんだけど
どうやって
束ねるんだろうというか
その辺はよくわかってないんですけど
そういう機能があるからそれを使うといいよとか
あともう一個面白かったのが
APIキーのスキャンをするときに
最近の多分モダンな
サービスのトークンとかは
サービスのトークンとかは
決まったプレフィックスとかがついてるじゃないですか
インタープトークンとか
GPAとかアンスコとか
で あの辺がついてるやつはいいんだけど
本当に段数みたいなやつを
設定してるやつは検知できないから
そういうのは困るみたいな
話があって
その辺はGoogleとMicrosoftが
一緒に買ってるんですけど
CASQって読むのかな
CASQっていう
Common Annotated Security Keyっていう
標準化みたいなのを
頑張ってるらしくて
そのAPIキーはこういうフォーマットで
その
文字列をやろうよみたいなのもあって
これに乗っ取れば
スキャナ側で機械的に検知できる
から
こういうのもあるよっていう紹介をしてくれてて
なるほどねっていう
仕様は結構複雑というか
長そうだね
そうなんだよね
パッと読んで理解できる
感じじゃなかった
BNFなんだこれ
なるほどね
これも
知らなかったなと思って
うっすらみんな
いろいろやってるのは知ってたけど
標準化の動きがあるの知らなかった
これいいよな
実際にAPIキー作ってるんだったら
これ引っ張ってきて
やっとけばいろいろ
嬉しいし迷いの余地はないっていう意味で
知っといてそうなのかもね
はいなんで結構
いい話だなと思って
持ってきました
APIキーの標準化
ありがとうございます
いい話
うん
いい話ね
いい話もっといっぱい
そうっすよ
記事でも取り上げるような
そのさ改造の情報がないから
わざわざ引っ張んなかったけど
ラクスルさんと
無印さんと
あともう一社ぐらいか
アサギもか
アサギは取り上げたか
そう
そうかも
ちらっとピオログの記事を取り上げた
そういうくらいニュースもありますが
こういう風に根本解決をする
っていう動きもあるんで
希望を持って生きていきたいな
って思う今日この頃でございます
はい
はい
はい
何その
はい
私もそう思います
はい
大丈夫?今日元気ないよ
マジで
元気だよ
本当に?ならいいっすけど
うん
いやなんか
こっちの音量はちっちゃいのかな
そういうこと?
声が小さいってこと?
声が小さいのか
テンションが低いのか
どっちか分かんない
両方じゃん
それは元気がないって言うんだよ
世間的には
別に声のトーンだけが
私ですけど
両方ということにしていてください
いやー
いやでもそうだね
喋って気づくけど喉かゆいな
マジで風邪ひかないように
皆さんも気をつけてください
終わったじゃんもうフラグが
フラグ
健康に
今週もキチガンガン読んでいきますよ
いやー願いは叶う
マジで
いや風邪ひいてらんないって
1回くらいひいてもいいけど
いややだよしんどいもん
バチバチ言っても
まあそんな感じか
58回
そうですね
徐々に年末ですけど
いやーもう年末だね
ご意見ご感想
お待ちしております
リプレイFM
ハッシュタグはXにおいては
僕が選挙したと言っても過言ではない
公式ハッシュタグと
させていただく
選挙宣言しないと
なんか
マシュマロとかやるか
あーマシュマロ
おもろいね
どうせなんも来ねえんだよ
まあそうだね
貼るだけ貼っとくか
なんか
僕は別に聞いてる
世紀的なやつでさ
お便りコーナーがあってさ
毎回お便り読んでるからすげえなと思ったけど
なんか
ツイッターのハッシュタグ見に行ったら
お便りさんがいるねいっぱい
そうなんだ
まあそうだよなと思って
感想を言ってくれる常連さんを
獲得しよう
だからアイ子のライブでいつも叫んでる人
みたいな感じ
いやほんとやめよう
そのコンテキスト
スーパーハイコンテキストな
多分
ここ1ヶ月で
俺一番今面白かったけど
喋り出すとよくない
だいたい同じ人が
叫ぶ
おしゃべりする
東京でも京都でも同じ人が叫んでる
不思議なんだよな
言いますよね
いやいいと思う
僕は大好きです
じゃあそんな感じで
じゃあ次回もみなさんまたお楽しみしてください
おやすみなさい
おやすみなさい
