ポスポメのブログの分析
こんばんは、Replay.fm第40回です。
こんばんは。40、40!
40なんですよ。
わお。
40週間目。
すごい。
40週間って聞くと長いね、なんか。
3年ぐらいやってる感じがするね。
40、そうだね、なんか、ちゃんと続いてるPodcastじゃないやつは、もう全部超えてるぐらいなんですよ、40回。
だっかり10ヶ月ってことでしょ?
10ヶ月なのか…あれ?
1月4週として…
あ、あ、10ヶ月。
でしょ?
そうそう。
さっきなぜか頭の中に慣れて終わっちゃった。頭おかしいわ。
眠…ちょっと疲れてるんじゃないですか?
10ヶ月か…
疲れてるかもしんない。
疲れてないよ、全然元気ですよ。
夜らしくね、頑張っていきたいと思うんですけど。
40か…まあ1年、1年か、1年記念なんか考えておいてください。
え、なんか買ってくれるんですか?
え?その…だる。そのノリだる。
なんで俺が買わなかったの?
いやいや、ありがとうって1年間付き合ってくれて。
いつもありがとうねって言って。
なんか買ってるか、三角コーンでも買ってあげるよ。
大学生ノリの。
三角コーンか…三角コーン、まあ会社に置いておこうか。
なんか三角コーンなんて使い道ないだろうって一般人が思ってたけど、
この前、家の近くのコンビニで、コンビニじゃない、公園で、
スケボーを練習している人たちが三角コーン2本持ち歩いてて、
なんか、あ、こういう需要あるんやと思ったから。
きっと誰かに送りつけられたんでしょう。
それでなくなくスケボー始めた。
そういう感じ、逆にね。
1年記念にはスケボー送るから、あ、間違えた。
もう疲れてるかもしれない。
きっと疲れてるんだよ。
まあ、次裏って名前書いて会社に置いとくから。
お願いします。
ちょっとMPつける前に行くか。
もうマジなやつじゃん、ウケる。
うん、マジですよ。
よし、1個目。
僕読むか。
お願いします。
緊急じゃないけど重要なことに取り組めるか。
ポスポメのプログラミング日記っていう。
あの、ポスポメさんですね。
今、紙なしでVPOEをやられてる。
僕もやはりメルカリ時代に被った、
めちゃくちゃ優秀なソフトエンジニアなんですけど。
はい、の記事ですね。
なんかね、読んだタイミングです。
結構ブログもついてて。
ツイッターでバズってるのかな?知らんけど。
まあまあまあまあ。
はい、そういう記事なんですけど。
内容としては、
最近のポスポメさんのブログがそもそもすごい良くて。
何でしょうね。
コニファーさんのお太ピミがね、すごいあるから。
ややしをぜひサブスクライブするといい。
もしないならしてもいいかなと。
するわ、うん。
多分VPOEをやって1年経ってるのかな。
まあ結構1年、2年以内になられたばっかなんで。
いろいろその仕事に絡んで、
何だろうな、こういうのあるけどこういう風に取り組もうとか、
そういう言語化すごいやっていて、
最近の記事はすごく勉強になるなと思いながら。
セカンドラインマネジメントの難しさと優秀な人材は大事という話が良かったな。
緊急性と重要性のトレードオフ
ああ、そうね。
ごめんなさい、再言っちゃいましたけど。
いい。
かつね、VPOE実践にやってる中でっていうのも、
まあ今っていいなと思ってるんですけど、
今回もそんな記事の中のうちの1つで、
タイトル通り緊急じゃないけど重要なことってあるよねっていうところに触れているところで、
まあ何でしょうね、
まあそんな具体的な話でも多分ソフトエンジニアリングとかプロダクト作ってる人だったら、
1回に思い浮かぶものがあると思うんですけど、
まあ締め切りはないんだけど、
まあ絶対にやった方がいいものってなおにして、
まあ常にあるんだけど、
そういうものをお座りにして、
まあ近畿なものばっかりやってしまうと、
まあどっかで組織の成長とか、
プロダクト成長みたいなところの足を引っ張ることになるよねっていうところがあって、
なんで、まあ絶対にいつかはやらなきゃいけないってものがある。
だけど、
まあ例えば記事で書いてあったのは、
まあインデビジュアルコントリビューターの立場とかだと、
やっぱどうしてもその緊急なものに向けなきゃいけない時間っていうのは長いので、
まあその上のレイヤーである、
EMしかり、VPOしかり、CTOしかりっていうところは、
まあICとか現場にその緊急なことっていうのは任せて、
まあどっちかっていうと重要なことにきちんと取り組んで、
長期的な目線で組織、
プロダクト内で成長していくことに時間を割くことが大事なんじゃないかっていう話。
ただ、言うはやすし。
で、
まあ例えその、
マネジメントのラインで言うとこの上のレイヤーであっても、
やっぱりなんか緊急なことに終わりがちっていうのはどうしてもあったり、
まあそもそも忙しいっていうのがあったりする。
から、まあじゃあそこでやっぱトレードオフ、
ある程度なんかいろんなトレードオフを取って、
その重要なことに取り組む時間っていうのをきちんと取らなきゃいけないよねっていうことを、
マネジメントの個人的な見解
ずらずらと書いてるって感じですね。
で、トレードオフっていうのは記事中で言うと具体的には、
例えばそのメンバーとのワンワンみたいなのを、
メンバーごとにグラデーションつけて、
頻度を減らしてもいい人は減らしてっていうところとか、
またミーティングの参加とかなのかな、
ああそうね、自分が不参加でもいいミーティングで参加しないとか、
自分がやってる作業を他の人に渡すみたいなことをして、
自分は重要なことに取り組むために脳みそを使う、
みたいなことが書いてあるって感じですね。
はい。
ぜひ、すごいすぐ読めるんで、
読んでみてほしいなと思うんですけど、
なんか当たり前のことを言ってるようで、
結構なんかうまく表現できないけど、
ブログ記事の文章にすごく説得力があるし、
VPOEとして真摯に向き合ってるんだなというのが分かってよかったなっていうのと、
あとはセキュリティにおいては、
特にこれ結構多い気がしていて、
重要なことっていうのが。
SREチームとかもそばで仕事してるから、
同じような似たようなことを話したことがあるんだけど、
なんだろうな。
カヤチームは、
例えば3ヶ月でこれリリースしたみたいな、
すごい分かりやすい短期で出る成果とか、
もしくは短期でやらなきゃいけないことみたいなのがすごいたくさんあって、
そういうイテレーションで進んでいくみたいな。
開発チームに長期でやらなきゃいけないことがないって言いたいわけじゃないんだけど、
割合としてはSREとかセキュリティのほうが多いんじゃないかなと思っていて、
そうなった時に、
例えばICの立場でも、
こういうマインドって結構大事なんじゃないかなと、
しみじみに思うし、
頑張れねばという気持ちになったというか。
あとはトレードオフみたいなところで言うと、
自分はこれまだあんま上手くできてないなっていう感覚があって、
なんだろうな、
上手く捨てるというか、
セキュリティで今持ってる領域の中で、
勇気を持って捨てるみたいな、
動きとかアクションはまだちょっと苦手だし取れてないなっていう部分があって、
そこはすごい身に染みるというか、
心に刻んで生きていかなきゃなって思いましたっていう感じですね。
そうね。
あとなんか触れてないけど、
結構これ、
コンテキストスイッチがめちゃくちゃ邪魔してくる領域だと思っていて、
ここで言うと、
緊急じゃないけど重要なことと、
頑張って手を動かさないといけないような部分とか、
急いでやんなきゃいけないことみたいな部分と、
組織をより成長させるとか、
そういうところの、なんていうか、
ものを考える脳みそってだいぶ動き方が違うと思っていて、
そうね。
だからこそ結構意識的に時間を取らないと、
要はなんて言ったらいいんだろうな、
それこそお風呂でしかこういうこと考えられない感じになっちゃうんだよな、なんか。
確かに意識したり、
強い意志でブロックしないと、
なんていうか、
実際にカレンダーも埋まるし、
カレンダー埋まってなくても作業で気づいたりするとしょうがないみたいな。
それで1週間終わるみたいな。
なので、っていう中でどのように時間を作るかっていうのは、
多分そういうところもありつつ、
どのように時間を作るかっていうところに結びついてるんじゃないかと思っていて。
確かに。
出ないリミティングが出ないっていうのはそうだし、
頻度を下げる、ワン・ワンの頻度を下げるっていうのもそうだし。
確かに。
EMやってた頃をちょっと思い出した。
そういえばそうだったなって気持ちになったな。
ワン・ワンはなんか難しいね。
難しいってことね。
結構、セキュリティーじゃないけど、
マネジメ、EMやってた頃はこのバランス感すごく難しかったな。
なんかしみじみ。
会社のフェーズにもよると思っていて、正直。
そうだね、そうだね。
いやー。
一概にこれが正解ですっていうのは多分ないんだけど。
ないね。
いやー。
なんかすごい懐かしいな。
これ多分3時間話せるやつある。
ワン・ワンのね、頻度を下げるみたいなのも結構人によるよなと思うし、なんか。
うーん、状況とかね。
その組織におけるマネジメントのフレームワーク次第でもあるだろうし。
うーん。
個人的にはなんかレポートラインはweeklyでとっておいて、
時間を短くすると、できるだけ時間を短くするとか、
なんかそういうやり方の方が好きかな。
うーん、まあ確かにね。
頻度下げないといけないほどワン・ワン入れないっていうのも大事なのかもしれんけどね。
そのチームのサイズ的な問題も多分あると思うし。
そうだね。
マネジメント人数を減らすって話だよね。
うーん。
そうね、そういうのもあると思う。
あとは作業を他の人に任せるっていうのはなんか結構。
でもなんかマネジメントレイヤーはマジでこれ本当に大事だなって思ったわ。
なんかさ、具体の作業に逃げちゃうよね。
そう、そうね。
やることわかってるものとやることよくわかんないものがあったときに、
どうしてもやることわかってるものの方に逃げちゃうから。
うーん。
あとはその自分がやったほうがいい呪いも多分、やっぱりずっと誘惑としてはあるから。
本当にそうだとしても、多分勇気を持って切り離していくこととかはすごい大事だなっていうのは結構身をもって思ったな。
まあなんか、自分がやったほうがいいことこそ人に任せたほうが多分よくって、
うんうん。
その、なんか自分がやったほうがいいのわかりきってることって多分十分にサポートができるじゃん。
そうだね、そうだね、確かに。
自分がなんかよくわからんことを人に任せると、なんかサポートもできないし、なんかぶん投げっぱなしになっちゃうから。
あー。
まあでも任せる相手次第かな、なんかその。
それはそうね。
うん、ジュニアなレベルだったらサポート必要だし、
だからそこもやっぱり変数が多いよね、なんか状況的に。
組織内マネジメントの重要性
まあだからこれが正解っていうのは当然ないんだろうけど。
うん。
いやー、でもなんかこの正解がない中で諦めない姿勢みたいなのをめっちゃやっぱ尊敬するな。
なんか、そこはめちゃくちゃ天と地ほどの差異があると思っていたんですね。
うんうんうん。
まあ正解ないし、7でやってる人は別に見たことはないけど、なんかやっぱ楽な方に流れちゃう可能性は全然あると思ってて。
そこに流れずに、なんか表現難しいけど。
まああとなんか組織としてのそのマネジメントのそのロールの人に対してのこう、なんか期待みたいなところも当然あると思っていて。
そうね。
うん。
まあ、そうね。
まあでもそこも規模感による気もするな、なんか。
思ったけど結構成熟した組織じゃないと、なんか期待値を下ろすってできないんじゃないかなって気もするんだよな。
うん。
いやでもわかんねえな、なんか期待値を具体、なんか抽象的な期待値しか下げらんどうなんだろうな、なんかわかんねえな。
いやわかんない、自分が思ったのは、その、なんか、うーん、まあでもそうか、わかんねえな。
うーん、難しいな。
いやでもそうね、ある程度言語化して渡すべきか、うん、ちょっと思い直したわ。
なんかICと違って期待値の抽象度はめちゃくちゃ高いと思うなっていう感じかな、感覚としては。
自分が今やった時では、会社からの期待値は、そのチームのアウトプットを最大化するみたいな感じだったんだけど、だいぶ抽象度高いじゃん。
うん。
で、でもこれを解釈して切り崩して、その抽象度を下げて自分の行動に落としていくのは、なんか、僕は結構、その当時のTENXの組織の枠組みの中ではEMの仕事だなと思ってやってたし、なんかそれが正しいんじゃないかなと思ってたから。
まあ本当にあくまで一例なんだけど、これがなんか組織でかくなったりしたら具体化するのかなって言われると、うーんどうなんだろうなーみたいな、ちょっと体験したことがないからわかんないなーとか、
まあたかだか9ヶ月しかEM僕はやってないんで、ちょっとあんまその経験したずらをするのもアレなんですけど。
うん。
まあでもこれはね、よかった。
しみるね。
しみるね。
AI技術の進化
この顔文字使うとポスポメさんが怒りになる。
ポスポメさん、そういえばブログでこの顔文字見ないんだよな。
確かに。
そう。スラックだとこれついてないことなかったよね。
うーん、必ずついてた。ポスポメさん辞めてからやっとスラックで使えるようになった、これ。
ウケる。
あの、どんな顔文字か気になる人は農場を見に来てください。
はい、そんな感じですか。
はい、そんな感じですね。
じゃあ次。
HTMLスペックチェンジ、エスケーピング、うん、and、うん、in、Attributes。
Chrome for Developersブログです。
これさ、どう読んだらいいんだろうね。
これさ、なんか。
なんて読んだらいいんだろう。
ブレイスとか知らなかったっけ。
MacのSayCommandって読みました。
これさ、音声読み上げソフトとかでさ、読んだらどう?
え、音声読み上げソフトだったらあれじゃない?
あ、でもどうなんだろう。こう、なんか省略しそうだなって思うけど。
シンボル、サイン、うーん。
すごいなんかさ、MacのSayCommandがさ、めっちゃ日本語対応になっとる。
あー、OSの設定に依存してる。
いつからこれ。なんか、昔さ、英語しか読み上げられなかったじゃん。
逆に今、英語、英語を読ませられないんだけど。
あー、俺も日本語になってんな。
まあいいっすよ、はい。
はい。
解説。
解説、はい。
解説。
解説、解説か。
解説、まだないよ。
はい、あのー、
あのー、なんだっけ、何カッコって読めばいいんだっけ?
えー、なんだろう。そう、結局日本語でも読めた。ちょっと待って。
えーっと、秘宝読み方。秘宝一覧読み方とかですよ。
なんて読むんだろうね。
まあいいっすよ、あの、HTMLタグの頭につける。山カッコ。
うん、私0x3cと0x3eって言われた方が分かりやすいんだけど。
まあ、はい。
はい。
あの、山カッコが、うーんと、
まあ、インラインHTMLやアウターHTMLとは当たらんだっけ?
うーんと、ゲットHTMLか。
ゲットHTMLか。
うん、が絡むところで、
えーっと、アトリビュートの中に、あの、HTMLエレメントのアトリビュートの中に入っている、
えーっと、この2つの文字の扱いがちょっと変わるよっていう話です。
うん。
はい。で、具体的には、えーっと、文字実体参照で、えーっと、書いてくるようになる。
今まで、えー、そのまんま、えーっと、0x3c、0x3eで書いてきたものが、えーっと、文字実体参照として書いてくるようになるという変更が入るらしいです。
入ったのかな、もう。
はい。
えーっと、まだオプトインで、はい、138、クロームの。
138にベー、あー、そうだね、うん。
そう、で、139でうまくいったら多分、
そうだね。
レモルトの挙動にするかな。
うんうんうん。
まあ結構。
あ、ファイアホックスもか。
うん、なんか、まあ、で、何のためにそんなことするのっていう話が、えーっと、MXSS、ミューテーションベストXSSの、えーっと、まあ何て言ったらいいんだろうな、なんか、
えーっと、まあ、原文にはその対策をこう助けるためみたいな書き方をされてるんだけど、うん、はい、なんか、そういう感じらしいです。
うん、これはなんかXSS各目線としては結構いい話っていう解釈で合ってるんですか、それともまあ、みたいな感じ。
うーん、うーん、なんかMXSSって結構難しくって、まあとはいえなんか、うーん、どうなんだろうね、おおむね、おおむねいい方向なんじゃないかな、多分。
うーん、MXSS。
いやMXSSはね、ごめん、説明がね結構難しくって、なんか、私もちゃんと説明できないな。
で、まあ割となんかその、説明としてはこの辺がかなり明瞭だねっていう記事を1個貼っといたのと、あの細かい具体例みたいなのをこうサラッと並べてくれてる記事がもう1個あって、うん、その2つを一応ノーションには貼っておいたんだけど、うん。
なんかね、その記事の中のちょっと下の方にツラツラいってもらって、ああ、その辺かな、えっと、うーん、まあその辺の話とか、
まあ要はHTMLコンテンツの差に対しては意味的に有害な部分をHTML文字列から取り除くことになるので、文字列をDOMノードに変換するにはHTML解析アルゴリズムで指定された方法によって解析する必要がある文字列からDOMへの解析はコンテキストに依存で、
すなわち周囲のコンテキストによって同じHTML文字列が異なるDOMノードに解析される場合がある。要はその下の例とかかな、えっと、
Divタグの中でHTMLのトジタグが欠けてるときにどういう解釈をするかと、テキストエリアの中でEMタグのトジタグがないときにどういう解釈、ブラウザがどういう解釈をするかみたいなのはコンテキストでまた変わるよねみたいな話とか。
要はこういう、こういうのっていう説明しかできないんだよ。
こういう稼働をついてってことだよね。確かにできそうな予感がする。
こういう解析処理のコンテキスト依存性のため、ユーザーが開発する文字列間HTMLサニタイズライブラリはMXSSと呼ばれるXSS形式攻撃クラスに対して本質的に脆弱であると書いていて、
こういう、こういうことっていう説明しかちょっと僕はできないんだけど。
なるほどね。サニタイズライブラリ。理解です。
ウェーブおもろいな。
多分概念自体は葉っぱ日記がほぼ初出なんじゃないかな。
葉っぱ日記って誰だっけ。名前忘れた。
長谷川さんの。
長谷川さんか。2010年。
長谷川さんが最先端で盛り上がっている話題としてMXSSというものがありますって書いてあるから、多分この時点でどっかで盛り上がってたんだろうね、きっとね。
なるほどね。2010年。だからもうこいつ自体の歴史は古いんだ。
そう、古い。
なるほど、じゃあまあいい話ではあるんですね。
ただでも、11年経っても私はMXSSというものを自分の言葉で割と綺麗には説明できないな。
ドムピューティファイの実装を読めるくらいじゃないと真に説明できるようになるなって。
そうかもしれない。
あの辺は多分そういうのめちゃくちゃ気使ってるんじゃないかと思うし。
いやー、Webって感じだな。
はい。
はい。
まあ面白いねって気持ちでした。
これで全然なんか気づいてなかった。
一応ね、破壊的変更なんで、Web勢はCACDとかでブラウザのレンダリングとかに依存してて壊れるかもっていうか。
そうだね。
覚えておくといいかも。
うん。
はい。
次。
いやー、はい。
ここ読もうかな。
ちょっと。
Discordの脆弱性とセキュリティ
Discord Flows Let Hackers Use Expired Invites in Malware Campaign っていうブリーピングコンピューターの記事ですね。
はい。
で、これは端的に言うとDiscordの脆弱性って言っちゃってるのか、脆弱性を利用してマルウェアを配布するキャンペーンが観測されてるよって話ですね。
で、マルウェアはなんていうか、インフォスティーダーなのかなとかなんで、それは置いといて。
このDiscordの脆弱性っていうのは結構面白いというか、前回の言葉で言うと人間っぽいなと思ったんで、紹介しようかなって感じなんですけど、
どういう脆弱性かっていうと、期限切れの招待リンクをお金払えば乗っ取れちゃうっていう脆弱性、端的に言うと。
で、どういうことかっていうと、時系列に言うとまず招待リンク、正規のやつが作られるじゃないですか。
で、これは別に誰でもDiscordで、サーバーに招待の言われるとか発行して、期限は無期限と有効期限切るやつ選べるらしいんだけど、今回の対象は有効期限が設定されるパターン。
で、多分攻撃に利用されそうなやつで言うと、有名サーバーのここから参加できますよみたいなツイートをするとか、どっかのサイトに置いとくみたいな。
そういうのに使うために招待リンクを作るっていうのがまずステップ目で、この招待リンクの期限が一定時間経って切れましたと。
このタイミングでインバリットな招待リンクになるはずなんだけど、そこで多分何かしらの課金をするとDiscordに任意の招待リンクを作るっていうことができるようになって、
この時に任意のっていうのは招待URLの通常は乱数があってランダムに生成される部分の文字列を自分の好きなものに指定できるっていう仕様があって、
ここにリンク切れの招待リンクのURLをそのまま指定すると作れちゃうっていう挙動をするので、
第三者はお金払えば有効期限切れのリンクは権利者もどれも全部乗っ取れちゃうっていうことができるっていうのが問題っていう感じ。
無期限であれば期限切れないし乗っ取れないし、期限切れる前も乗っ取れないんだけど、ここもなんかちょっと怪しくて挙動が。
乗っ取りたい奴の言う乱数部分に大文字が含まれてる場合は、そこを小文字に変えることで招待リンクを作れちゃうらしい。
これが乗っ取れるのかどうかは記事から読めておらなかったけど、その辺の挙動はちょっと怪しいというか、そこも穴になってしまったという話ですね。
なんでこれでめでたく乗っ取れるんで、攻撃者は乗っ取って、招待される先は正規のDiscordサーバーしかいけないんで、
ディスコードのセキュリティ問題
Discordサーバーに一番最初のイニシャルチャンネルみたいなところに適当にそれっぽいリンクを置いて、
このリンクを踏んでDiscordのアカウントをベリフィケーションしたらサーバーを招待されますみたいなのを置いといて、
あとはこの記事で紹介されてたのは今流行りのクイックフィックス攻撃が書いてあったって感じですね。
このパーシェルコマンドを実行してベリフィケーションしてくださいみたいな、で誘導させるっていう話。
正規乗っていうのは要は攻撃者が用意したDiscordのサーバーってことだよね。
そう。だから招待リンク乗っ取れてもそれを何か任意のURLにエフトできるわけではないから、そういう誘導の仕方をしてるっていう感じかな。
はい。なんかこれ油断したらギリ作っちゃいそうな仕様で結構あったって思ったけど、
まあでも、いやーでもなんかちゃんと考えてたらこうはならんかなっていうのと、
ちょっとエスパーで思ったのはこの課金したらリンク作れるっていうのがすごい後に作られたんだろうなみたいな。
いや多分そうだと思うし、そう思ったよ俺も。
うん。
そうだよね。
うん。
で、その時にうっかり行為をし忘れてた。
いやでもさ、その、なんか、どうしたらよかったと思いますか?
え、なんかさ、その、例えばだけど、じゃあその、プロダクトセキュリティのエンジニアとしてなんか面接を受けてたとします。
なんかこの事例を紹介されて、なんかあなただったら再発防止として何を提案しますか?聞かれたらどうする?
えーでも、もう一度発行したものは二度と使えないようにデータベースに残しといて。
あーどっちかっていうと、なんか類似の事例がもう起こらないようにしたいんです。
あー、なんか似たような機能作るときにどこで。
似たような機能っていうか、そのもっともっとふわっとその、まあ別にいいよ。
なんか多分、私がもしこれで面接聞くとしたら、なんかどのレベルの提案、どういうその抽象度の提案、で提案をしてくるかまた見ると思うから、
あの、別にその提案のそのレベル感は様々でいいと思うんだけど、なんかどっちかっていうと聞きたいっていうか、
質問の意図としては、要は仮に任意のリンクが作れるっていうのを後から作っていたとして、先にあった機能とこうして後からできてきた機能っていうので、
まあそれぞれ多分、なんていうか相互に開発者は絡みがないだろうし、なんか別にどっちもどっちの主要をそんなに把握してるわけでもないだろうしっていうのが容易に想像できるわけじゃん。
っていう中でじゃあプロダクトセキュリティに関わる人間として、なんかまあそういう類型のそのある機能に何かしらの機能を足しますっていう時に、
なんかこういうことが起こらないようにするためにはどうしたらいいですかねっていう。
めっちゃいい質問だね。このままなんか仕事の面接使いたいくらいだな。
まあ今ね、いやなんか頭の中に思い浮かんでるんだけど、それが正しいかをすごいちょっと考えていて、
まあなんかその開発において一つ結構実践したいし有効性が、網羅的ではないかもしれないけど有効なんじゃないかと思ってるのは、
CISAじゃないやつのセキュアバーディデザインっていう本ですね。
うんうん、オライリーかな。
有名なのかな。
いや違うな。
マイナビかな、マイナビの本があって。
で、なんかその考え方が結構活かせるんじゃないかなと思っていて、
まあその本の考え方はなんかセキュアに作ろうみたいなその発想で、
まあそもそも開発者が意識して完璧に実装するのはもうそもそも無理ですよっていう前提を認めていて、
だからXSSでスキルインジェクションとかはまあみんな知ってるかもしれないけど、
なんかその数多の攻撃手法、攻撃者目線で考えてそれを防ぐ行動を書くっていうのは、
まあ多分無理だろうっていう話からスタートするんだけど、
でも、じゃあなんかそのできないことをできないように堅牢な行動を書くっていうのはできるようにっていうところの問いかけをまあ一冊を通してしてる本なんですよね。
めちゃくちゃざっくり言うと。
だからなんか例えばその具体例であったのはそのECサイトのカート、
ちょっと面接だとしたらこれ多分長すぎなんだけど、
あえてちょっとそのECサイトのカート機能みたいなのがあったときに、
そのカートに入れる商品の数をマイナスになっちゃうみたいな仕様があって、
それに起因したバグで無料で本が買えちゃうバグがあったみたいな。
で、めちゃくちゃ損失が出たみたいな。
この事例は会社を特定できないようにその本の著者曰く、実際に起きたものをめちゃくちゃ再構築して、
でもこんなことがあったよっていうやつなんで、
実際に起きたのは多分それと全く同じなんやけど、マリティアのことが起きたって話があって、
じゃあこれどうしたら防げたんだろうみたいな話で言うと、
多分そのバグ自体結構本の中で全部きちんと解説されてるんだけど、
かなり複雑だし、そのバグが起きることを予測して作るのは多分不可能なんだけど、
じゃあカートの数ってマイナスにならないですよねみたいな。
じゃあマイナスになったらフェールするように作りましょうとか、
逆にじゃあカートの数が1000冊になりますかみたいな問いかけを仕様作る時点でできなかったんだけど、
本買う時ってどこまで行ってもせいぜいマジは50とか100でいいんじゃないみたいな。
じゃあそこで縛ろうってすることで、そもそもバグを作り込まないみたいなところはできる。
どの開発者でも意識すればできるし、
それは実装にいくつかのデザインパターンを使って落とすっていうこともできるし、
それをすることで自然と塞がる穴っていうのは実は結構あるよねっていう話がある。
話を戻すとこのディスコードのパターンとかも、
自分が自信ないのはそのロジックでこれを適用できるのか、
もうちょっと考えたいなという気持ちがあるんだけど、
同じ考えがある程度通用するんじゃないかなと思ってて、
招待リンク機能を作りましょう。
乱数生成で生成されるようにしましょう。
無期限で切れるパターンと無期限でパターンを作りましょうってなった時に、
じゃあ期限切れた後に、
今回の校舎の機能じゃなくても、
またもう一回生成した時に同じURLが出てきた時ってどうするんでしたかみたいな。
ある種セキュリティとか関係なく、ある種の異常系に対しての問いかけがあった時に、
それはまずいよね、じゃあそれを防ぐような仕組みを入れましょうっていう風にしてれば、
今回のやつって防げた可能性があるんじゃないかっていうのは結構思う。
だからセキュリティ運っていうか、異常系ちゃんと切り詰めてってやることで防げたんじゃないかなっていう気がする。
どうですか先生。
なんかでもこの事例に関しては全く同意権で、
このシナリオを、確かに異常系っていう純粋にこの機能、
後から付いたであろうこの機能ルームを問わずに、
そもそもこのリンクっていろんなとこに付けるから期限切れた後も残ってて、
その同じものが発行されたら困るよねみたいな話は確かにあると思うので、
そういうシナリオを事前に想定できてたとしたら、
多分同じような思考になるだろうなと思うので、
多分このIDにユニーク制約付けて論理削除してねっていう話をすると思うな、私だったら。
このシナリオを想定できてたらね。
分かんないけど、いくらディスコードの規模でも、
このIDを残しとくことでDBが死ぬとかないと思うんだよな。
DBが死ぬはないかもしれないけど、
発行するリンクの数に制約が出ちゃうかもなとは思うんだよね。
いくらディスコードの規模でも、
このエントロピーを使い果たすことがないのかどうかがちょっと自信ない。
そこは分からない。
まあなんか、この課金システムがない世界線でそれにもし自分が向けようとしたら、
まあ結構むずいけど、
プロダクトセキュリティの重要性
結構むずいけど、
じゃあなんか、
例えばそのエントロピーの限度にぶつかるのに、
2年ではぶつかんないよね、なんだったら。
じゃあ2年経ったらリリースしようかとかはあり得るのかもな。
2年、まあでもちょっと悩むな。難しいな。
たぶんそこの議論は発生すると思うんだよね。
難しいな。
いやでもなんか、
かぶせる選択肢ない気がすんだよな。
技術的にどうにかするしかない気がしちゃうんだけどな。
かぶらないフォーマットを模索するとかはありかもね。
例えばだけど、
このインバイトURLのユニークIDっぽいやつの冒頭2文字ぐらいを使って、
サーバーのIDみたいなのをそこに入れといて、
そこはだから同一サーバー内では共通で。
そうね、確かにね。
それはありだね。サーバーと必ずひも付くわけだから。
パスで1個切ってもいいよね、それでいうとね。
全然いいね。確かにね。
そういうデザインをしてもいいかもね。
公開情報だもんね、基本的には。
同じ状態してる時点で公開情報だから。
同じ空間の広さでもサーバーごとにその空間を持つことになるから、
全然使い果たすことってまずあり得ないよねっていう。
確かに。後からかぶせたよと思っても絶対に作れない。
そのサーバーに乗っ取られないっていうのは良さそう。
それでいいや。
っていうのをたぶんバチバチやらないといけない可能性があって。
なんか結構プロダクトセキュリティに関わる人間にとっての試行実験にはいい事案だなって見て思いました。
確かに。これこのトピックカットして面接に使うか。
冗談ですけど。
まあでも、なんか実例でもいいし実例じゃなくても。
こういうの結構いろいろ考えられそうです。
そうそうそう。
いやー、全然谷ごとじゃないよな。この後から使用追加系は。
うん。
なんかこっちをいじったらあっちが壊れたみたいなのはなんか普通によくある話だから。
うん。リリース。リリースしておしまいじゃない今の世界だからこその可能性かな。
うん。
はい。そんな感じです。いやーこれ面白かったな。
じゃあ次行きますか。
はい。全てのコーディングエージェントに独立した開発用コンテナ環境を与えられるコンテナユース。
ドッカー創業者がオープンソースで公開。
パブリックキーの記事ですね。
これ、俺読んだっけな。読んだことになっとった。
読んだことになってるんだよ。
まあ割とタイトル通りなんだよな。
割とタイトル通りだと思う。
コーディングエージェントより。
AIエージェントとコンテナ技術
タイトル。
タイトルにプラスするとしたらMCPサーバーとして実装されるとか。
そうそうそうそう。それだね。
でも逆に言うとそんぐらいなんじゃないかな。正直。
AIエージェントがMCP経由でコンテナにアクセスするっていう実装になってるんだよね。きっとねこれね。
そうだね。
AIエージェントが自律的に使えるサンドボックス的な開発環境をコンテナで提供できる。
使う側は、これOSSになってるのは使いたいな。
ちょっと使ってみるべきだったな。
まあでも、そうね。
それは自前でやらずとも観点にいけるみたいな感じなんだろうな。
ブリーフストーリーでもちろん。
どう思いました?
なんかでもこれで守れるのって何なんだっけっていうのはちょっと気になったな。
まあでもローカルで動かない。ホスト側で動かないから。
例えばパッと思いつくのはNPMインストールで変なの落としてマルウェアが発火してしまったときにアクセスできる範囲はかなり絞られるよねとか。
これなんかちょっとわかってない。
MCPと開発環境のセキュリティ
結局さ、ホストOS側でエージェントが動いてることには変わりがないんだよね。
そうなんだよ。
だからこのMCPしか触らないっていう状態を作れるかというと、そこは担保できない。
作れないと思う。
コメントに書いたんだけど、考えながらGitプッシュとかどうするんだろうと思ったけど、
多分それはもうあくまで開発環境だからイメージ的にはローカルファイル全部コンテナにマウントして編集とか。
そうなんだよね。でもそうすると結局コンテナの外に出てくる口があるじゃん。
そうだね。というかエアエージェントも常に外にいるから。
外にいるし、コンテナの中に例えばコンテナでNPMで変なもの落としてきちゃいましたみたいな状況もさ、
コンテナの外からマウントされてたらコンテナの外に出てくるわけじゃん。
だからセキュリティ的な分析というよりは単純に開発環境をめちゃくちゃにされてもいいよねっていうのが嬉しいのかもな。
セキュリティのことは正直、実はあんまり記事中では言及はないというか、あくまで副作用っていうか。
そういえばこのMCPを通じてコンテナにアクセスするよっていうアプローチはちょっと悪くないような気がしていて。
クローンさ、GitHubからリポジトリクローンしてきて、要はコンテナの中に直でクローンしてきて、
作業が終わったらプッシュしてコンテナはそのまま捨てるっていうのもありじゃん。
ありだね。もしくはそういう世界観なんじゃないかな。
っていう感じで、直接触らないで、かつ直接触れないでMCPを通じてやるよっていう形にしてあげて、
もっと言うとMCPを通じて触れればいいから直接アクセスできる必要は全くなくてっていう世界観が、
仮にそれできるんだったら、エージェント自体もコンテナの中に閉じ込めといて、
コンテナ間ではアクセスができる。MCPを通じてアクセスができる。
MCPでできること以外はできない。それ以外は全部コンテナの中に閉じてるっていう。
セキュリティレイヤー的な使い方をMCPに求めることもできるのかなみたいなことをちょっと読んでて思った。
なるほどね。今聞いて思ったけど、ローカルエージェントとホストエージェント…違うよな。
ホストエージェントとローカルか、他のエージェントみたいな分け方はもしかしたらありかもな。
コンテナの中にも1体ずつエージェントがいて、ホストはそれとやり取りをするだけとか。
いろいろ考えて思ったんだけど、結構開発体験がめちゃくちゃ良くならないとみんな使わないんじゃないかって気はしてるんだよな、単純に。
コンテナ的にまず思ったのはオーバーヘッドというか、遅いよなっていうのはちょっと…
それで言うとAppleがコンテナーって出したじゃん。
あったね。
あれ俺まだ触ってないんだよね。
触ってないな、どうなんだろうな。
あれ触ってみたいなって思いながら今日会社PCにドッカーを入れたわ。
敗北を感じたわ。
僕は別に遅いわけじゃないんだけど、やっぱローカルですぐ開発するよりはやっぱ遅いから。
また言語にもよるだろうな、NPMとかNode.jsとかあんま別にコンテナ使うまみって人間が開発してた時代は少なくともなかったから。
環境性もそんなにないし。
Pythonとか嬉しいのかな。
でもPythonもなんかみんな…
UVでね。
Python自体はそうだよね。
いやーあれなんか証券スタジオって思えないんだけど、まあいいや。
なんかさ、なんか拒否反応あるよねUV。
わからんけど。
なんか臭いものに蓋をしただけ感が若干あって、
なんか絶対話すれちゃうけど、なんか拒否反応が自分の中にある。
なんかね、わかんないけど、
PHP 5.1を触ってしまったまま、
その後のPHPを知らずに10年経ったPHPをディスるみたいな感覚なのかなっていう。
そうかもしれない。
でもさ、この…
特にさ、MacのこのPython関係がぶっ壊れてるのはさ、もうなんか終わっとるやん、なんか。
なんか、Pythonに対するヘッドホン。
なんか、そうね、わかるよ。
なんか無理にインストールしたいだけなのに、Pythonバージョンうんうんとか言って、
調べるとよくわかんないチップスばっかり出てきて、
それ安直にやっちゃうと環境がどんどん怖い。
取り返しがつかないみたいな。
そうそうそうそう、めっちゃわかる。
そういう経験をN階やってるから。
まあでもそれで言うとね、別にぶっちゃけなんか、
その、JavaScript界隈も似たようなもんだと思ってて、
その、なんかNPMなのかYARNなのかPNPMなのか何使えばいいのかパッと見てようわからんみたいなのはちょっと思ってる。
なんか。
そうか。
まあでも、だからそこはもう俺はダメだわ。
なんかバイアスかかってるわ。
うん。
こんな、あんま考えることないなって思って。
うん。
なんか。
だいぶ、だいぶ落ち着いたよ。
うん。
まあだいぶ、それで言うとなんかコンポーザーのオートロードとかも、
こうなんか他の界隈から見たら、
かけんな、何だこれ何なのか思って。
まあ確かに。
わからんけど。
うん。
なんかなんでこんな大事な仕組みをそこに依存してんのみたいなのあるかもしれんけど。
うんうん。
その点は結構PSRね。
PSRが仕様なんだ。
うん。
いやマジ、Goがやっぱり居心地良すぎてなあ。
ダメだなあ。
まあみんなが好きなゆえんの一つ。
うーん。
ねえ多分。
戦争がない。
全く。
うーん。
いやあ、いい思想だと思うよ。
うーん。
というか。
うん。
まだ話しすぎてる。
馬鹿ほど話しすぎてるけど。
まだ話しすぎてるかなあ。
うーん。
いやあ、でも、他はそうですね。
Pythonちゃんと触ってからディスる。
うん。
いやディスる気はないです。
あの、ちょい一旦なんでね。
使い道次第だと思います。
まあ、っていうのが出たよという話でした。
はい。
うん。
じゃあ、次。
うーん、はい。
Chrome for Developers Blogで
New Permission Prompt for Local Network Accessですね。
Chromeの新しいプロンプト
えー、まあタイトルの通りであるんですけど、
まあ、Chromeのウェブサイトがローカルネットワーク、
まあ、期日中で研究があったのは1.16で始まるIPとかローカルホストとかに
アクセスしようとした、する挙動をした時に
ユーザー側に確認プロンプトを表示するっていう変更が入りましたっていう話ですね。
うん。
あ、俺さっきのこっちじゃなかったかも、ごめん。
HTMLのやつはあれか、HTMLじゃなくてこっちがオプトインだわ。
こっちがオプトインで138から有効にできて
もう一個のやつは今月の末のリリースで多分有効になるよって書いてあったね。
今ベータに入ってるんで。
そうだね。
多分書いてあったから。
うんうん。
ああ、大変失礼しました。
こっちでした、オプトインは。
はい。
で、まあ今言ったのが大体全部ですね。
で、なんか理由としてはCSRF攻撃対策とか
まあこれはなるほどだと思ったけど
なんかローカルなフィンガープリントしとくのを防ぐみたいなことも書いてあって
まあこれはプライバシー文脈というか広告文脈かなと思ったんですけど
何が取れるんだろう?
まあいろいろ取れる時はあるんだなって思ったけど
はい、そういうののためらしいです。
はい。
なんか素直にいいんじゃないかと思ったけど
うん、どうなんでしょうか。
どうなんでしょう。
このコメントのシーンが気になる。
ああ、なんかまあOSとかでもこういうのよく出てくるし
まあChromeもなんか今もなんか出てくるよね、これ系のやつ。
ネットワーク。
ああ、そうなの?
うん、ローカルネットワークのなんかをやりますみたいな
たまに出てくると思うんだけど
いまいちその何きっかけで何をするために何が出してるのか
どうわからんなーみたいな場面が多くて
その明らかに何かサーバー立ち上げたとかでさ
そのOSのやつだと明らかに今サーバーが立ったなとかで
その聞かれるとまあまあまあこれだよねって分かるんだけど
たまに何気に何かよく分からないやつとかがあったりするから
まあそれで言うとさ、これもプロンプトどんな感じなの?
コネクトゥエニーデバイスオンユーアンドローカルネットワーク
コネクトゥエニーデバイスオンユーアンドローカルネットワーク
ああ、でもそうかローカル、そうだね、そこそこそこ地球の位置やっぱ
これを一般のユーザーが見てブロックを押せるのかな、どうなの?
いやそうなんだよね
よくわからん
よくわからんなーって思っちゃうから
もうちょっとその細かいなんかリュートで認可したいなと思うし
具体何をやってるかを見て、あれしたいなって思うんだけど
なるほどね
ドットローカルとかも弾くんだ
パブリックドメインスノプティックス
どうなんですかね、この記事の感じだと結構シンプルなプロンプトで終わらす感じ
まあリリースして様子見てって感じなのかな
これで確定ではないだろうから
あとはフィードバックコンティット、まあそうだね、フィードバック集めてって感じか
これ系の攻撃ってどれくらいあるんだろうな
なんか読んだ記事に1個あった気がするけど、ちょっと思い出す
なるほどです
こんな周辺がありますって感じですね
じゃあ、いいですね、次いきます
次はセキュリティのほうのGoogleドローグの記事なんですけど
プロンプトインジェクション攻撃の対策
Mitigating Prompt Injection Attacks with a Rare Defense Strategyっていう記事ですね
記事の内容としては、ジェミニに仕込んでるLMにまつわる攻撃を防ぐための
5つのレイヤーの解説をしてくれてる記事ですね
これすごく良くて、ぜひ紹介したいなって感じなんですけど
具体的にその5つの仕組み、レイヤーみたいなものを1個1個書いていて
詳しくは読んでほしいんですけど、さらっと5個紹介すると
まず1つ目が、わかりやすいところで言うと
最近度々出してるプロンプトインジェクションの話なんですけど
投げられたプロンプトが悪意のあるプロンプトかどうかを判定する
独自の機械学習モデルを実装して、まずはそれを食わせてます
っていうのが1枚目のレイヤーです
その次に赤字装置リインフォルスメントっていう風に書いてあるんだけど
このプロンプトに機械学習モデルを配せて
悪意のある判定はしなくて、突破した後にも
そのプロンプトを解釈する時のプロンプトに
赤字的な指示を追加して
敵対的な指示を無視する仕組みっていうのが入っているらしい
具体例が書いてなかったら想像するしかないんだけど
こういうことを指示してるようなものだったらアウトみたいな
そんな判定をしてるんじゃないかなという気がする
具体的なとか記事にもそんなに書いてなかったかな
概念図みたいなの書いてるんで
もしくはホワイトペーパーとかあったらそれに書いたかもしれないけど
そういう仕組みが2個目になります
3つ目がマークダウン・サニタイザー・サスピシャス・リアル・リダクション
AIのセキュリティ対策
っていうので
これ何のことかっていうのが実は
今日紹介する別の記事で答え合わせができるんですけど
一旦それはお楽しみということで
マークダウンを解釈のエッセイセナリーかな
する時にサニタイザーみたいなのが動くらしいんだけど
そのサニタイザーが動く時に
マークダウンをレンダリングとかして
例えば画像が埋まってた時とかに
そのURLをレンダリングしないようにするという仕組みが入っていて
これ何でかっていうとここでレンダリングしちゃうと
プロンプト経由で中まで入り込んだ時に
引っ張ってきた情報をURLにくっつけさせるみたいな
ことを通して外に情報を送信できることがあるんで
そもそも通信が発生しないように
サニタイザーをしてるよっていうのと
また処理の過程でURLが生成される場合には
Googleセーフブラウジング
Chromeとかに入ってる機能と一緒だと思うんですけど
URLがマリシアスなものは勝手に判定して
ブロックするっていうのが3つ目の走りです
4つ目にユーザーコンフォーメーションフレームワークで
これは防ぐっていうよりかは緩和って感じだと思うんだけど
投げられたプロンプトの結果
行おうとしてる操作とか指示みたいなものが
リスクが高いものであればユーザー確認を求める
っていう仕組みを入れてますよっていう
これがHuman in the LoopってHITLと呼ばれてるっていう風に書いてあって
初めて見たなって感じなんですけど
呼ばれてるらしくて
例えば例で上がったのはカレンダーのイベントを削除するみたいな
操作とかはリスクが高いから
ユーザー側に本当にこれ削除していいのっていうのを求めて
実際に実行しないようにするっていう仕組みが入ってるとのこと
最後は面白いなと思ったんだけど
Mind User Security Mitigation Notificationsっていうので
今まで話した4つのステップの
4つじゃないのかな
多分上3つとかかな
内部的な防御機構っていうのが動作した場合はユーザーに
こういう理由でブロックしたよとか
こういうのを検知したよっていうのを警告メッセージで表示して
似たような攻撃が来たときに警戒できるようにする
これどこまで警戒できんねんっていうのは
ちょっと疑問じゃなくはないんだが
ユーザー側に今入力されたプロンプトっていうのは
悪意があるものだよっていう警告するっていうのが
入ってますよっていうものが最後にありますって感じですね
Microsoft 365コパイロットの脆弱性
これキャプチャーがあって
だからジェミニで試そうと思ったら試せるのかな
なんかバンされるの怖いからやんないけど
多分
そうだね
In my behalf, who do you and your device use
caution with discontentみたいなのが表示されてる画像が
貼り付けられてましたって感じですね
これすごい中の話って感じで良かったなって思うのと
別の記事を後で答え合わせします
そっちとめっちゃ繋がっててちょっといいなって感じ
面白いね
画像URL経由で何かしらを持ち出すのも確かになと思ったのと
このクロスタイトルX的指向で結構面白いなと思った
でも中でマークダウンのレンダリングをしてるかどうかがわからんから
でもそれも不確定要素が多いな
外からプロンプトインチェクションみたいなのをしようと思った
そうね
でも正規の動作でいろんなことを試して挙動を見たりはできるのかな
ジェミニの場合とかだと
Google系のサービスをジェミニ系でいじるっていうのがどんどんできるようになってきてるから
その過程で何か起きてないのかとかは結構探索の余地はあるというか
推測ができたりするのかな
あと前に話したMCPの場合にプロンプトインジェクションできてもどこまでいけるのかみたいな話は
もう一個の記事の方でしっさが得られたんで
でもこういうのがバンバン出てくると
どんどんこの領域におけるセキュリティが
インハウスのセキュリティエンジニアの手から離れていくような
できることがあんまなくなってくるというか
よくわからんけどGoogleが頑張ってますそれ以上のことはできませんしか言えなくなってくるというか
つまらん世の中になりそうだなって
実際使う側もそうなんだろうね
ある意味SaaSとかを使うときもそうやって同じっちゃ同じな気もするかな
大事なデータ預けるけど信頼できるかどうかを僕らが評価するしかない
GitHubとか結構珍しいんだろうな
いろいろやる余地がある
あとは普通に近いうちに向き合わなきゃいけないのは
自分たちの事業でモデルを使うとなったときに
これを参考に同じ事業内容によるけど
同業機構を自分たちが考えできるって話はある
そのときに参考に
これはたぶん一例だと思うんだけど
それに備えて知識を蓄えておくっていうのが良さそうな気がしたな
話したくてしょうがないんでもう一個ついのやつ話そうかな
順番は別なんですけど
Geminiはこうやって守ってるって話に対して
落としたいわけじゃないんですけど
たまたまだと思って聞いてほしいんですけど
もう一個の記事がブリーピングコンピューターの記事で
Zeroclick AI Data Leak Flow Uncovered in Microsoft 365
なんて読むんだろ英語で365ところかな
Microsoft 365コパイロットのやつですね
タイトル通りMicrosoft 365のコパイロット
Googleで言うとこのGeminiにおいて
ZeroclickのAI経由でのデータ漏洩の脆弱性が発見されましたって話で
修正済みなんですけど発見されましたって話ですね
これ以上は研究者によって発見されて
CV振られて多分もう修正されてるんですけど
どういう脆弱性だったかっていうのが結構
今の話と次になっていて
攻撃者側がやるのは結構シンプルで
悪意のあるプロンプトっていうのを仕込んだメールを
ユーザーに送りつけるだけっていうのが攻撃ステップ
あとはメールを送って即成り立つんじゃなくて
メールを送られたユーザーがコパイロットで何か
メール画面でプロンプトを打ったら
その悪意のあるプロンプトっていうのが解釈されちゃって
攻撃が成立するっていう脆弱性ですね
多分んだけど裏側の仕組みとしては
例えばメールの画面でコパイロットで
こういうメール探してみたいなことを言ったときに
裏側でメールのバーって食ったタイミングで
その悪意のあるプロンプトを解釈しちゃって
攻撃が成立するみたいな話だと思う
原因としてはMS側も多分さっきのGeminiと一緒で
具体的なことはリビングコンピューターの記事に書いてなかったんだけど
そのプロンプトに悪意があるかどうかとか
いくつか防御機構があるんだけど
それを回避できちゃって攻撃が成立したっていう話
攻撃成立した後に
メールなんで何やりたいかというと
データ引っこ抜けないかって話なんだけど
そこもPOCというか
攻撃が成立することが確認されていて
あれですね 画像か
一部の画像形式においてはURLを埋め込むと
画像にリクエストが飛ぶんで
そこ経由でデータを取れたっていう話と
また仮にそれらがブロックされたとしても
MS TeamsとかシェアポイントにURLとかは
ブロックされないから
そこ経由で抜くこともできたっていうのがあったらしいって感じ
幸い多分悪用されてないんで
研究者が見つけて報告して直して
公開されたって感じなのかなと思います
攻撃手法の考察
なんでさっきのブログで言うと
多分本当に推測だけど似たような仕組みなんであれば
まずプロンプトに悪意があるかどうかの判定とか
あとは判定抜けちゃっても
それに悪意があったら無視するみたいな仕組みが動いてなかったり
3の仕組み 画像URLをレンダリングしないようにするとか
URLを悪意があるかどうか判定するとかが
動いてなかったんだろうなとか
あとは4番のユーザーコンファイメンションがあったら防げたのか
ちょっと分かんないなって感じだけど
結構普通に怖えって思ったのと
またどう修正したんだろうなっていうのは気になるし
また何かいたちごっこなんじゃないかなって気がするんですよね
回避できました回避できないしました
別の方法で回避できました
繰り返し何か始まるのかなってちょっとぼんやり思ったって感じですね
外側からでも一応攻撃はプロンプトに軸手ができたって話ですね
嫌だよね結構嫌だなって思ったんだよな
なんか技術的には可能だけどなかなか刺さらんよねっていう世界であってほしい気持ちがある
そういう願望があるわ
技術的には可能だけど?
技術的には可能だけど現実問題そうそう刺さらんよねみたいなこういうシナリオが刺さらんよねっていう世界であってほしい
そういう願望があった
どうなんだろうねこれはちょっと分かったんですが
どれくらいの角度で刺さるんだろうね
またこのプロンプトを見つけ出すの個人じゃないのかな会社だからめっちゃLLM詳しい人が集まって時間かけて見つけたのか
そんなん想定としては悪用する側も同じくらい詳しくなってくるわけだからどうせ
そんなにね
なんかプロンプト書いてないのかな
マークダウンなんか結構使い勝手いいのかなあんまLLMでマークダウンってあんま自分の中でひも付いてなかったけど
あれからレンダリングしちゃうのかなと思って
元ソースの見つけた会社の記事を読もう
いや面白いな
メール送って待つだけでいけるってのも結構やだな
メール送ってすりつくのはちょっとどうにかなるのかなせめて
Gmailもジェミニーが読めるわけじゃん今
同じことは原理上起きるかもしれない
いやーきついなー
なんかそのセキュリティとユーザビリティがトレードオフだよねをなんかめっちゃ体感してる気がする今
そうだね
革新的に便利になるものである
でもなんか割とそのなんていうか
ユーザビリティと両立するセキュリティはあると信じてきてたけど
なんかこれを見ちゃうとないかもなってちょっと思い
心が折れる感じがするな
本当にそれを思い求めようと思うとなんていうかもうNLMを作る側に回らなきゃいけないんだなっていう気持ちになるな
それこそできることがないというかさ
どうしたもんかなって
それか攻撃する側に回るかじゃない
ひたすら良くするために
確かにねそれもありだね
でも攻撃するためにはなんか
まあそうね
裏側も知らないといけない気もするけど
まあでもどんどん人間っぽい思考とかに寄ってくるし
まあでもなんか別にそのマークダウンをさ
レンダリングするよとかってなんか
LLM関係ないよね極論
まあそうだね
ただなんかその
まあただいやそんなこともないな
それは嘘だわ
まあでもマークダウンレンダリングすることによって
なんか唯一違うのはその
あのプロンプトを与えることによって
マークダウンをレンダリングしたときに
例えば画像とかでその
リクエストが送信される先が
AI技術とセキュリティの課題
プロンプトのあれに反応するかどうかで変わってくるっていう
そこの情報が取り出せるかどうかが多分大きくて
で別にそういう思想自体はさ
なんかある種クロスサイトリークス的な思想ではあるから
なんか経路が一個増えたっていうだけの話ではあるんだよな
なるほどね
一般的な話ではあるんだけど
ただそのなんていうか
生成されたマークダウンをそのままレンダリングしますよみたいな
まあだから極論信頼協会の話に落とせるっちゃ落とせるんだよな
極論信頼協会の話に落とせるっていうのがどういうことかというと
そのなんていうか要は
HTTPで外から送られてきたもの
一つも信用できないよね
っていうのと一緒で
そのなんていうかLLMが生成したものって何も信用できないよね
っていう前提に常に立たなきゃいけない
で
っていう中で例えばレンダリングするものにさ
CSPガチガチに固めておけばさ
なんかとかそういう考え方もありなのかもな
ちょっと思ったりするし
まあね
まあでもそれでいうと今回のやつとかと
MS TeamsのURLとかでやられちゃうときついんじゃない
そうだね結局CSPもなんかあってもバイパスの経路とか多分あるし
うん
いやだからそこはやっぱりベニーさんとのトレードオフなんだよな
そのMS Teamsとかを使えるのってその
わかんないけど例えば
ちなみにこのチームのURLを忘れたってちょっとから教えてって送ったら
回答させたいよねとか
それできなくしていいのかみたいなトレードオフが発生する
そうだね
いやーなかなかね厳しいな
自由度がな
ちょっと元ネタ読んでるけどその画像はあれだね
なんかマークダウンやっぱ解釈してレンダリングしちゃうんだね
で多分普通なんか何かのパターンはちゃんと削除するんだけど
それで削除しないパターンを見つけて
かつレンダリングさせることができたから
あとはそのURLをどういじるかみたいなとこが突破できたって感じ
しかもCSPのようなイメージSRCのフリッシュ入ってんだねこれ
書いてあったね元ネタの方に
そうだねそうだね
そうだよななんか入ってたよなーって思ったんだよな
なんかこれは厳しいな
でもなんかこうやってみるとステップ一発で全部抜けてるわけではないからさ
だからやっぱそれぞれにコツコツ防御策入れるしかないんだよね
それで言うとどっか一個防げてれば良かったはずで
ただそのさ最大の問題はその原理上なんか
どっか一個防ぐつったってさ
原理上その確実になんか防げる防ぐ手段が今ないわけだよね
画像表示する必要ある?あるか便利なのかな
なんか画像生成してとか言うもんな
別になんかさ
これに1年経ったら成熟するのかな
しないんじゃない?コロナと一緒だよ多分
そういうこともあるよねーでなんか多分
撲滅しないもんな
強制していくことになるんじゃない?わかんないなんか
これを綺麗に片付けられるその未来が正直ちょっと思い浮かばないな
今んどか見えないね
AIで何とかしてほしいね
ソースグラフの利点
そうね、そんな感じ
ちょっと次の記事でしたけど
今日も全部AIじゃん残り
超AI回だね
なんかもうさ
AIがHTTP喋るようになってさ
何も開発しなくていい世の中になんないかな
サーバーも?
前はHTTPじゃなくてそれだったらSAでエージェント同士がひたすら喋ってるだけの
世界になる
見る人によってなんか画面が全然違うみたいな
同じアプリケーション
ちょっと面白いな
ちょっと有名あるなそれ
アクセシビティの話とかもさちょっと
そうだね
エージェントがあなた向けに最適化するみたいなやつがある
結構嬉しいなそれ
いやー
いやー
どうなることやらやな本当にこの領域は
はい
まぁでもMSはやらかして2回目だから
なんか1回コパイロット経由で別の従業員のメール抜けるみたいなやつ
あったね貫通系のやつね
そうちょっと頑張ってほしいな
応援してます
応援してまーす
はーい
じゃあ次は
ソースグラフ×自作MCPサーバーによる社内コード検索連携の取り組み
メルカリエンジニアリングブログの記事です
うん
別にさらっとでよくって
でもソースグラフのMCPいいなってちょっと普通に思った
ソースグラフって触ったことある?
ないっす
なんかコードの検索ツールなんだけど
かなりオーガニゼーション横断で全部検索できて結構便利ではあるんだけど
個人的にあんまリポジトリまたきで検索する用事がなくて
自分ではあんま使ってないんだけど
あとクエリを覚えるのがめんどくさくって
なんで普通にゴーランドの検索とかで割と満足しちゃってたから
正直あんま使ってなかったんだけど
MCP系でプロモーターとして検索してくれるんだったら助かるなとは思うし
GitHubの限界があるんだね
そこにぶち当たってないからちょっと音形がまだ肌で勘違いだなって感じ
ブランチとかも含めて検索できるって多分書いてあったよね
それは確かにGitHubだとちょっと大変かも
なるほどね面白いね
結構いいなと思った
ソースコード見て何かする系の脆弱性検査ツールとかもこういうのかませると
GitHubの権限渡さなくても済むから楽だなと思った
言うても別にGitHubアップはパーミッション結構細かく切れるからそんなに困らないのか
リードだけ渡すってできんもんね
コンテンツリードだけ渡してけば
オルグアイドでリード渡して
でもレートリミットの
レートリミットはソースグラフと一緒なのかな
ソースグラフってインデックスするのかな
裏はどうなってんだろうね分かんないね
インデックスしてくれるんだったらGitHubの場合はレートリミットがあるから
メルカリぐらいの規模でGitHubアップでやろうと思うと
結構普通にぶつかりそうなんだなって
そういう記事では言及それはなかったと思うけど
そうなるとみんなパッと発行して手元にやってる
ちょっと気持ち悪いから
こういうのあったらそういう意味でも嬉しいかもしれない
ね
確かにね
いいなーって思いました
規模感に対して正しい投資をしてる感があっていいよね
先週話したカーソルのやつもそうだけど
ちゃんとやってる
すごい数のリポストやるにもね
これは辞めてた時点でも結構あったから
3倍4倍になってても全然驚かない
めっちゃいっぱいある
いいっすね
OSSにしてほしいな
この辺だったら作れって感じも
ぶっちゃけそんな感じがする
ぐらいに頼んだら作ってくれそう
確かに
ありがとうございます
1個ねさっき飛ばしていて
こっちもMCPネタっすね
あー
これは触れた方がいいんじゃないですか
待ってましたって感じだね
そうだね
リモートGithubのMCPサーバーが一般公開
リモートのGithubのMCPサーバーが一般公開
おめでとうございます
お疲れ様でした
もともとは公式のローカルサーバーがあって
それを使って
パッドで認証してっていうのをやればよかったんだけど
リモートのやつがあって
これ導入もかなり簡単っぽくて
URL入れて認証はポチポチってやればいいけど
パッドとかもサポートしてるけど
正直パッド使い意味ないんで
ポチポチってやって認証すればよさそうだし
またローカルと違って
サーバーのバージョン管理とかもしなくていいので
サプライチェーンみたいな話も結構
セキュリティ観点だと心配事が減るよねとか
っていう感じですね
なんか結構取り上げたのは認証
リモートMCPサーバーでこういうのやってくれると
認証助かるねって思ってて
別でこの場では取り上げてないんだけど
FigmaがMCPサーバー出したんですけど公式で
それとかはそれもリモートサーバーで
ただGithubと違って
リモートサーバーがローカルに立ち上がるんだけど
そのサーバーを立ち上げるのは
Figmaのデスクトップアプリで立ち上げる
認証はそのFigmaのデスクトップアプリの認証にひも付くから
MCPサーバーの定義JSONに
何かトークン発行して埋め込んだりしなくていいし
このGithubと一緒でサプライチェーンの
バージョン管理とかもしなくていい
厳密にデスクトップアプリのバージョンを
管理しなきゃいけないんだけど
認証と権限管理
そういう方がセキュリティカル目線だと
結構手放しでとは言わないけど
ローカルでNPXで引っ張ってくるようなものよりは
はるかに使ってねって言いやすいし
結構懸念はないわけじゃないんだけど
サプライチェーン周りに関しては嬉しいなと
一方で社内でこれ話して気づいたけど
ローカルのMCPサーバーの
でもこれ今気づいた 関係ねえわ
話してたのはローカルの場合は
PADしか選択しなかったから
発行する時点でPADの権限を絞れば
MCPサーバーの権限を絞るってできたんだけど
このサーバーの場合はオース認証しちゃうと
その人の権限の範疇で何でもできるから
実は権限が絞れないっていう話があるって話をしたんだけど
そこは本当に絞りたいんだったら
絞ったPADを使ってそっちを認証
使うように切り替えればいいなって今気づきました
でもめんどくせえよな
いちいちそんな
でもめちゃくちゃ最低も安全な世界線にするしかない気はしてるんだよな
もうGitHubとかに関して
GitHubに関してはそうだけど
AIが大暴れするという前提で
ブランチプロジェクションルールセットをちゃんとするとか
支援してるとか
大暴れしてるのがAIなのか人間なのか
分かんないの嫌だなって思ったわ
あー
そうだね
区別つかないね今は
これなんか区別つくようにしてくれたりするのかな
あー
なんかしてほしいけどな
うん確かにね
PADとかの場合は監査ログ見たら分かるんだけど
でもプリリック立った時にそれがPADかどうか分かんないから
オースも多分一緒なんだよな
確かに
いやーむずいな
それで言うとGitHub Appのオース認証であってほしかったな
それとかだと分かるんだよね
人はひも付くんだけど
なんかねGitHub Appのアイコンの右下にその
認証がひも付いてる人のアイコンが出て
プリリックとか一緒に立つから分かってる
なんかでもコミットレベルだったらさ
あのー
署名鍵をうまいことしたら
なんか見分けつくようにならないかな
うーん
GitHubでの署名問題
見分けつかないんじゃないかな
つかないかな
いやめんどくさいと思うな多分
いや多分原理上は
GitHub App作って
それのプライベートキー手元に置いて
APIでそのGitHub Appとして署名をするっていうのをやれば
いける原理上
であとは言っても
プライベートキー人の数だけ発行しないといけないし
違う違う言いたかったのは
サインドコミットの署名の鍵を
人間が操作するときと
AIが操作するときで変えられたら
コミットだけだったら見分けつくんじゃないって思った
でもさGitHubのコミットって
鍵が違ったときどういう意味になるんだろう
ベリーファイルドしか出ないから
そうだよねクリックしたら
今はどうしようもないと思う
そうだよね
アプローチは確かにありかもな
あれだよね
人間が触れる鍵と
AIが触れる鍵を厳密に分けるとか多分やらないといけなくて
直近の自分に
ちょっとプライベートが孤独感すぎて
ベリーファイルドコミットにたどり着けない
何でも大丈夫だよ
どのリポジトリ
自分のコミットがねえのかそもそも
仕事だったら無理
リノベートのコミット見るか
コミットじゃないベリーファイルド見るか
キーIDはあるから
一応開けば
このキーIDで区別
他の人から見たら分かんない
これを分かんないけど
例えばGitHubの鍵設定画面で区別して見れるようにとか
そういう世界ではあるかもしれないね
確かに区別つかないのは確かに
コミットとかはそもそもちょっと思ってるけど
電車ルールでも
コミットプレフィックスルールファイルで
マシンがやるときはこれにしてとか
指定した方がいいんじゃないかなと思ったりしてるけど
実効性持たせるのも難しいかもしれないけど
そこの区別はつけたいなと結構思うな
そんなこと言ってる間に
そもそも人がもうGitHubで動かない世界が来るのかもしれないけど
ワンチャンある
今のままだとね
今のペースだと
そんな感じの記事でした
AIモデルの導入
でもなんかまあまあいいですね
じゃあAIラッシュかつ今日の最後の記事読みますか
ちょっとライトめなんですけどね
お願いします
アンソロピック機密情報を扱う新しいAIモデルを発表
すでに米政府が導入
GDNETさんの記事ですね
タイトル通りではあります
機密情報を扱うためのクラウドコブ
ガブ
ガバネットのガブだと思うんですけど
っていうAIモデルを発表して
すでに米政府によって導入されてるっていうものがありますよと
国家安全保障に特化したAIモデルのようで
機密分子は防衛関連情報解釈可能ですとか
逆にそれぐらいしか書いてないんですよね
一応オープンAIもGPTガブみたいなのを発表して
そういう製品を提供してるらしいです
米政府がAI企業と組んで頑張ってる背景には
トランプ政権のAI政策みたいなのがあるよってところも
ちょっと様に入ってるって感じですね
なんかまあ
ちょっとこの情報だったらあんまわかんねえな
っていうのが正直な気持ちもありつつ
何がどう安全なんだろうっていうのは結構気になったなっていう
感じですかね
これ安全
これ違うな記事読み間違えてるの
安全なんじゃなくて
機密情報は解釈するのに特化してるって話か
多分
だから安全ではないんだな
安全ではないというか
他のモデルに比べて何かが安全というわけではないっぽいな
うん
AIによる仕事の変化
間違えました
はい
なるほどね
ユースケストッカーの学習をしてるってだけか
解散で
でもこれさなんか
サイバーセキュリティの解釈も強化されてるとか
あとなんかなんだっけ
ここで読んだか忘れたけど
ジェミニのセキュリティ強化版みたいな話もあるし
煮詰まってくるとこういう用途特化型のやつも出てくるのかな
ポコポコと
うん
AIの安全性みたいな部分もちょっと記事があるな
どうなんでしょうね
はい
はい
知り切れと思うな感じで申し訳ないが
まあでもこれもありますよって感じですね
うん
AI何個も1,2,3,4
半分以上AIだったら強化
AIポッドキャストになんか
ちょっと収拾しがいする
ルイージのポッドキャストも全部今AIポッドキャストになってるでしょ
ああそうかもしんない
切っても切り
AIと切って切り離せる
なんかエンジニアリング領域今ないんじゃないかな
まあ過渡期でもありますしね
うん
いやーでも
今日は個人的には楽しかったな
ディスコードのやつの面接のやついいな
あの我こそはという人は面接受けに来てください
DM待ってます
絶対しねえあの質問
これ聞いてきた人にしたらもう
いやでも逆に
いやでもむずいなやめよう
うん
でもなんかルイージの問題考えてみたいな
なんかいい試行実験だったな
いや結構そのセキュアバイデザイン本の思想
めっちゃ実践していきたいんだな個人的には
結構可能性を感じている
そうですか
一方でソフトエンジニアでは開発者開発チームではないので
現実こんなんできるようになるかどうか素振りできないという寂しさ
なんかはあるんですけど
でもなんかシンプルにその
なんか
仕様とか要件のレベルの話じゃないのってちょっと思っちゃうんだけどな
なんかその
何て言ったらいいんだろう
いやー
そうなんだけど結構その
そうなんだね
仕様要件から実装に
もしくは実装の手前に行った時にそっからちゃんと
仕様要件にフィードバックできるかみたいな大事な気がしてて
極端
僕らが働いてるような会社とかいう
わかんないちょっと
そういう人がいるかわかんないけど仮に
そういう人がいると仮定して話すけど
さっきのカートがマイナス1になるみたいな話って
ソフトエンジニアリングを知ってる人だったら
思いつく発想なんだけど
変な思考度を変えたことがない人にとって
現実の世界にそういう概念ってないじゃん
カートがマイナス1になるとか
それだったら
ユーシャンのPDMだったらすぐ思いつくかもしれないけど
もうちょっとなんかその
ソフトウェアが紐づくような概念
ソフトウェアだから出てくるような異常系みたいなものに
PDMが全部思いを発して
作り切れる可能性ってなんか
あんまり高くないっていう前提に立つと
仕様要件の
作り込んでもらう異常系も
現実的な現実世界のモデリングの範囲で
考えてもらうっていうのはやるべきなんだけど
そこからソフトエンジニアの手に当たったときに
ソフトウェアの世界において
そこでソフトウェアの世界に入ったからこそ
新しく生まれる異常系みたいなのが必ずあるはずで
それを洗い出して
その仕様プロダクトオーナーに対して
こういうふうになったかどうなんですかとか
これってこうなんですかみたいな対話を繰り返すっていうのは
結構地味なんだけど
めちゃくちゃ大事なんじゃないかなって気がする
だから本では
それこそドメイン知識の話とか
ドメインコンテキストの話がめちゃくちゃ出てきていて
結局カート
この数字ってどういう値なんですかとか
いくところまでいくとやっぱバリオオブジェクトとかになってくるよねとか
そういう話になるんですけど
っていう気がする
今言ったのは優は優しいで
実行はすごい難しい
実行というか実行するのは難しくないかもしれないけど
実行する文化とかを根付かせるのはすごく難しい
そこはすごいチャレンジングなんだろうなとは思うって感じかな
あと現実の仕様が
たまに仕様がバグってるじゃないけどさ
現実世界がバグってて
複雑性をどうすんねんみたいな話があると思ってて
実際の開発だと
そういうとこは個人的には腕が鳴るなと思うけど
いろいろ起きがちだよねと
プロダクトセキュリティね
しんどかったな
なんかいつの日かわかんないし
ちょっとピックしてないからわかんないけど
30%問題みたいなやつ話題になってたじゃないですか
知ってます?
AIの
わからん
なんかね
Googleだっけな
GoogleのAI開発の中の人か
元Googleの人かちょっと忘れちゃったんだけど
LMにめっちゃ強い人同士が話したみたいな
記事か何かなんだけど
いましてのAIの性能だと
多分7割しか代替できない
いろんなタスクを
コード書くのもそうだし
何か文章書かせるのもそうだし
だった時に最後の30%仕事が残るっていうのがあって
っていう記事があって
ちょっとこれは話しすると長くなっちゃうんで
あれですね
それを参照してる記事なんだけど
ちょっとアペンドです
おまけで
ノーショップページ
おまけ
書いとく
何だっけ何が言いたかったんだっけ
そう30%みたいなのが結構個人的にはかなり腹落ちしていて
何かが消えるってことはなくて
70%消える
70%が80%90%になることは
もしかしたらモデルの進化であるかもしれないけど
いまはそういうフェーズなんだなって思うと
さっき言ったそのために
をきちんと解釈して実装に落とすとか
そこで穴を突くみたいなのは
AIの支援を受けたり
最適化できるかもしれないけど
人間の仕事が残るんだろうなっていうのと
より鋭い尖った能力がないと生き残れないのかな
ってちょっとぼんやり思ったって感じです
このソースもそうだし
このソースを参照してるのは知り合いが実は書いてるんですけど
このカルタホールディングスの記事もすごいよかったんで
おすすめです
これ引用すればよかったな
先週分の記事だ
AI搭乗によりウェブに支援することはなくなるのかっていう
タイトルの記事がちょっとおまけにあったんで
とてもよかった
腹打ちした
そんな感じですか今日は
楽しんでいこう
この記事にもね楽しんでいきましょうって書いてあるよ
頑張ろうって僕も思いました
なんかでもさあ
まあいいや
なんかさあその
そのさ
AIで仕事がどうなるかなみたいなこと
心配してる余裕なくない今
ある?
ないです
ね
AIの影響への向き合い方
ないね
そうなんだよね
あとなんかどうにかなるんじゃねえかって思ってる部分あんだよな正直
なんか今例えばクラウドコードを
触る時間がなかったら
本当に置いておかれるのかって言われるとなんか
もう意外と大丈夫な気がしてる
自分の能力を持ってすれば
なんていうかなんか表現が難しいんだけど
なんかラストが流行った時にラストを触ってなかったら
なんかエンジニアとして退化したかというと別にそうじゃないというか
なんだろうな
なんか表現が難しいな
良いとこは思いつかないんだけど
だからまあ
こんな便利なんだウフフーとか
こんなのできちゃったんだウフフーぐらいの気持ちで
生きるのがちょうどいいのかなーって気はしたな
知らんけどね
元気出して頑張っていこう
来週も
はいじゃあ
今週はこんな感じで
また来週も頑張りましょう
みなさんおやすみなさい
おやすみなさい
