List of Management [text.Baldanders.info]

Signal への攻撃手口（ソーシャルエンジニアリング）と防御策

2026-04-28T04:12:54+00:00

今朝，Bluesky と Mastodon の TL に Signal による長いスレッドが上がっていた。 Bluesky のポストは以下から始まるスレッドである（Mastodon のほうも内容は同じ，多分）。

A response to recent reporting in Germany, in service of clarity and accountability: First, it’s important to be precise when it comes to critical infrastructure like Signal. Signal was not “hacked” — in that our encryption, infrastructure, & the integrity of the app’s code was not compromised. 1/
— Signal (@signal.org) April 28, 2026 at 5:53 AM

ちょっと何言ってるか分からなかったので Kagi Assistant と GitHub Copilot に手伝ってもらいながら調べてみた。

もとになってる報道

Signal に対する攻撃，特に phishing を含むソーシャルエンジニアリングについては以前から言われていて，ドイツ BSI (Bundesamt für Sicherheit in der Informationstechnik) も Signal の利用ガイドラインを公開しているほどだ。

にもかかわらずってことなんだろうなぁ。

Signal による声明の直接のトリガーとなっているのは先週のドイツでの一連の報道のようだ。発端は DER SPIEGEL の報道：

Julia Klöckner ist Opfer des Signal-Hacks - DER SPIEGEL

これは有料記事だが，他メディアでもいくつかあった。

この中では Tagesschau の一連の記事が良さげなので Kagi Assistant に要約してもらった。

ドイツの政界や重要機関を標的としたSignalでの大規模なフィッシング攻撃は，国家が関与するスパイ工作の疑いへと発展しています。

被害の規模と対象:
- ドイツ連邦議会のほぼすべての会派の議員が標的となり，ユリア・クレックナー連邦議会議長や，フーベルツ建設相，プリーン家族相といった現職閣僚の被害も確認されています。
- 政治家だけでなく，ジャーナリスト，軍関係者，さらにはNATO関係者も攻撃対象に含まれています。
攻撃の手法:
- 攻撃者は「Signalサポート」を装い，偽のセキュリティ警告でユーザーに接触します。
- ユーザーを騙してPINコードを聞き出しアカウントを完全に奪取するか，あるいはQRコードをスキャンさせて攻撃者のデバイスを連携（同期）させることで，チャット内容や連絡先，過去45日分のファイルを盗み見ます。
当局の捜査と背後関係:
- ドイツ連邦検察庁は，本件を「諜報員活動（スパイ容疑）」として正式に捜査を開始しました。
- ドイツ治安当局（BfVおよびBSI）は，このキャンペーンが「国家主導のサイバー攻撃者」によるものであり，現在も勢いを増していると警告しています。
- オランダの諜報機関や米国のFBIは，この攻撃の背後にロシアの諜報機関が関与していると特定しています。
Signal側の見解:
- Signalは，アプリの暗号化やインフラ自体が突破されたわけではなく，あくまでユーザーを欺くソーシャルエンジニアリングによる攻撃であると強調しています。

大体合ってるかなぁ。ドイツ語はよく分からないので自信がない。

GitHub Copilot が各メディアの報道の違いを表にまとめてくれるというのでやってもらった。

媒体	位置づけ	主なポイント	閲覧性
DER SPIEGEL	初報の可能性が高い	政治家アカウント被害の最初期報道。見出しで「Signal-Hack」と表現	本文はSPIEGEL+（有料）
Tagesschau	検証・整理記事	「最初にSPIEGELが報じた」と明記。ハックではなくフィッシングという整理が明確	無料で読みやすい
taz	補強報道	被害対象，政府見解，手口（偽Signal Support）を具体化。SPIEGEL初報への言及あり	無料
ZEIT	続報	政府・当局側の見方（ロシア関与の可能性）を短く整理	一部制限あり（記事により差）

Signal による声明

というわけで Signal による SNS での声明に戻る。これについても Kagi Assistant に要約してもらった。

攻撃の性質: Signalの暗号化やインフラ自体が「ハッキング」されたわけではありません。実際には，攻撃者が「Signalサポート」を装い，ソーシャルエンジニアリングを用いてユーザーから認証情報を聞き出す巧妙なフィッシング詐欺が発生しています。
手口の詳細: 攻撃者は盗んだ情報でアカウントを乗っ取り，登録電話番号を変更します。被害者には「再登録が必要」と信じ込ませて新しいアカウントを作らせることで，乗っ取りに気づかせないようにします。その後，乗っ取ったアカウントを使って被害者の連絡先にさらなる攻撃を仕掛けます。
Signal側の対応: 今後数週間で，こうした攻撃を阻止するための新機能を導入予定です。
ユーザーへの推奨事項:
- Signalサポートがメッセージリクエストを送ったり，認証コードやPINを尋ねたりすることはないため，警戒を怠らないこと。
- 保護を強化するため，設定から「登録ロック」を有効にすること。

んー。これは大体合ってるはず。

「登録ロック」はアプリの設定の「アカウント」セクションにある項目で，電話番号を変更する際に PIN 入力を要求するらしい。

Signal アカウント設定より

PIN をばらしちゃったらダメだけどね。ちなみに Signal の PIN は英字も含めることができる。

Phishing はシステム侵入の手口としてはありふれていて，しかも人間の行動が関与するから完全には防ぎづらい。故に多層防衛をしていかないと「蟻の一穴」から簡単に class break してしまうことになる。

GitHub Copilot はこうまとめてくれた。

本件は，セキュアな暗号技術がそのまま利用者体験の安全を保証するわけではないことを示した事例である。攻撃者は最も弱い層，すなわち人間の心理と手続きを狙う。ゆえに防御も，暗号強度だけでなく，認証情報を渡さない運用，異常時の確認手順，設定レベルの予防策を組み合わせて成立するのである。

全く以ってそのとおり！

余談だが…

最初の SNS のポストの内容を元に Kagi Assistant と GitHub Copilot に元ネタとなるドイツ報道を調べてもらった。 Kagi Assistant のほうは自前の検索サービスがあり，一発で Tagesschau の記事を引き当てたので問題なかったが， GitHub Copilot はだいぶ難儀していた。

まず DuckDuckGo で調べようとして bot 判定され拒否られる。そこで Bing に切り替えたのだがノイズが多すぎて見つからなかったようだ（「検索エンジンが使いづらい」と愚痴ってた。 AI も愚痴るのかw）。まぁ， Google を使わなかっただけ偉いと言っておこう（笑）

そんで検索サービスを彷徨うのは一旦諦めて Bluesky の該当スレッドを API 経由で取得し，そこからようやく「Julia Klöckner（独連邦議会議長の人）」というキーワードを引き当てた。これを使って Bing で絞り込みをかけた結果，意味のある検索結果を得られたという流れだった。

この GitHub Copilot による一連の作業をチャット上で眺めながら，人間みたいなことをするんだなぁ，と妙なところで感心してしまった。そんでもって，ネット上の調べ物は Kagi Assistant のもんやねぇ，と思う。

そもそも調べ物をするのに検索窓を叩いて調べるとかせんやろ，いまどきは。ノイズに塗れた Web で，かつ主要検索サービスがメタクソ化する状況で「行きたい場所」に到達するには，結局 AI を使わなきゃ無理なのよ。特に今回みたいな漠然とした内容で知らない言語圏の情報を探す場合は。

つまり，もはや AI に認知してもらえないサイトやページは存在しないのと同じで，安易に拒否してるだけでは大海に取り残された某島の生物のようになってしまうだろう。

参考

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

原書のタイトルが “Beyond Fear: Thinking Sensibly About Security in an Uncertain World” なのに対して日本語タイトルがどうしようもなくヘボいが中身は名著。とりあえず読んどきなはれ。ゼロ年代当時 9.11 およびその後の米国のセキュリティ政策と深く関連している内容なので，そのへんを加味して読むとよい。

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

「ChatGPT は安全か？」

2026-03-07T11:47:23+00:00

前回の記事のあとにこれだと「またぞろ政治の話か」と思われそうだが，今回は純粋にリスク・マネージメントの話。 Proton のブログより。

Is ChatGPT safe to use? Here’s what you should know. | Proton

ChatGPT に限らないが生成 AI サービスの大半はユーザが入力したデータやプロンプトをサービスプロバイダ側が入手できる。実際にサービスプロバイダの多くはユーザの入力（データもプロンプトも）を保持して学習に使ってるし，インシデントの際は（政府を含む）第三者にそれを開示している。また広告・分析会社に情報を売っていた例もあるし ChatGPT との会話内容が Google 検索に拾われてしまった例もあったそうな。

そうしたリスクを改めて思い起こさせたのが前回紹介した事例で，これによって400万人以上のユーザが ChatGPT を止めると宣言しているらしい¹。

件の記事では ChatGPT に対して「個人のプライバシー」「ビジネスリスク」「透明性の欠如」の3つのリスクを挙げている。詳しい内容は（結構ボリュームがあるので）ここでは割愛する。

Even though ChatGPT can be helpful, you should never treat it like a secure vault for sensitive information. Avoid entering anything that could harm you, your company, or others if it were stored, reviewed, or accidentally exposed:

via Is ChatGPT safe to use? Here’s what you should know.

それでも ChatGPT を使いたいならどうすりゃいいの？ということで，入力してはいけないものとして以下を挙げている。

via Is ChatGPT safe to use? Here’s what you should know.

具体的にはこんな感じ：

パスワードと認証データ： アカウントのパスワード，二要素認証（2FA）コード，バックアップ認証コード，プライベートAPIキーなど
政府発行の識別番号： 社会保障番号，国民ID，パスポート，運転免許証，納税者番号など
金融および銀行情報： クレジットカードまたはデビットカードの番号，IBAN，オンラインバンキングの認証情報，投資口座のログイン情報，ビットコインウォレットの秘密鍵など
機密性の高い個人データ： あなたやあなたの家族を特定または追跡するために使用される可能性のある情報。自宅の住所や電話番号，生年月日，プライベートな写真や文書など
健康情報： 医療報告書，診断記録，保険番号，患者ID，またはあなたの身元に結びついた詳細な健康履歴など
機密性の高い業務データや企業データ： 独自のソースコード，社内戦略文書，機密契約書，顧客データベース，クライアント詳細情報，財務予測，未公開レポート，NDAなど
法的情報および秘匿特権のある情報： 弁護士と依頼人間の通信，訴訟戦略，証拠書類，秘密の和解交渉など

いや，まぁ， AI サービスでなくても当たり前なんだけどね，これ。こういう情報をうっかり漏らしてしまうというのは，やっぱ生成 AI サービスはデータ構造が分かりにくい（というか構造がない）というのが根底にあるんじゃないだろうか，と思ったり。

さらに ChatGPT を安全に利用するために以下の習慣を身につけると良いとある。

保存，レビュー，または公に公開されたくない機密情報の（AIとの）共有は避ける
個人を特定できる情報を削除するか，プレースホルダーや架空の例に置き換える
機密情報や個人情報を含まないファイルのみをアップロードする
AIチャットは，他の人に見られる可能性のあるメールやサポートチケットのように扱う
プライバシー設定を確認し，チャット履歴，メモリ，AIトレーニングなどの設定は無効にする
不要になった会話を削除し，アカウントに関連付けられた個人情報の量を減らす

もちろん生成 AI サービスを乗換える手もある。

(明らかに宣伝だがw) Proton の Lumo はユーザデータを「ゼロアクセス暗号化」することを売りにしていて，履歴を一切保存しないゴーストモードもあるらしい²。

私が常用している Kagi Assistant は匿名性を売りにしている。また「ユーザデータは負債である」というポリシーを持っていて，できるだけユーザデータをサービス側に保存しないようにしているそうな³。

いっそのこと SaaS など使わずオンプレミスで AI 環境を構築するという手もある。企業・組織はこのほうがいいかも知れない。軍事関係もね（笑）

（Grok や Google は元から悪いが）今回の騒動で Anthropic や OpenAI といった大手のサービスはセキュリティやプライバシーのリスク観点からは旗色が悪くなったように思う。各サービスにおける運用のポリシーや透明性を見極めて，賢く使うのがいいと思う。所詮は道具なんだから。

ブックマーク

参考

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

ハッキング思考　強者はいかにしてルールを歪めるのか、それを正すにはどうしたらいいのか: ブルース・シュナイアー (著), 高橋聡 (翻訳); 日経BP 2023-10-12 (Release 2023-10-12); Kindle版; B0CK19L1HC (ASIN); 評価

Kindle 版が出てた！

reviewed by Spiegel on 2023-11-21 (powered by PA-APIv5)

2026-03-07 時点。 ↩︎
Lumo に対する PrivacySpy のスコアはないが Proton VPS については 8.1 (10点満点) と評価されている。データ侵害が発生した場合のユーザへの対応がイマイチらしい。まぁ，高スコアではあるので Lumo もこのくらいならいいんだけど。 ↩︎
Kagi Assistant に対する PrivacySpy のスコアはないが Kagi 検索サービスについては 7.5 と評価されている。一般的なセキュリティ・ポリシーが曖昧なのと，法執行機関の要請への対応が明記されてない点がマイナス要素らしい。 ↩︎

「プロンプトウェア・キルチェーン」

2026-02-17T01:25:14+00:00

“Promptware Kill Chain” をどう訳していいか分からなかったので，とりあえずそのままカタカナで「プロンプトウェア・キルチェーン」としてしまった¹。きっとそのうち偉い人が適切な訳語を考えてくれるだろう。英単語をカタカナに伸ばしただけなんてダサいし，それによって言葉の意味が消失するのは拙いと思う²。けど，私は英語不得手だからなぁ…

（内容は同じ）

この記事は Oleg Brodt, Elad Feldman, Bruce Schneier, Ben Nassi による共著で，斜め読みするに以下の（同じ著者による）論文の解説になっているようだ。

[2601.09625] The Promptware Kill Chain: How Prompt Injections Gradually Evolved Into a Multistep Malware Delivery Mechanism

論文の要旨は以下の通り：

Prompt injection was initially framed as the large language model (LLM) analogue of SQL injection. However, over the past three years, attacks labeled as prompt injection have evolved from isolated input-manipulation exploits into multistep attack mechanisms that resemble malware. In this paper, we argue that prompt injections evolved into promptware, a new class of malware execution mechanism triggered through prompts engineered to exploit an application’s LLM. […] By moving the conversation from prompt injection to a promptware kill chain, our work provides analytical clarity, enables structured risk assessment, and lays a foundation for systematic security engineering of LLM-based systems.

via The Promptware Kill Chain: How Prompt Injections Gradually Evolved Into a Multistep Malware Delivery Mechanism

つまり，プロンプト・インジェクションやジャイルブレイクといった個々の事象にフォーカスするのではなくマルウェアに類似した多段階の攻撃メカニズムを「プロンプトウェア」と定義し，理解に必要な語彙やフレームワークを政策立案者やセキュリティ専門家に提供することが目的のようだ。なので，既に AI システムを導入している（あるいはこれから導入する）企業・組織のセキュリティ担当者は，論文のほうを読んでおくといいかもしれない。

プロンプトウェアには以下の7つの段階がある。

Initial Access (初期アクセス) : プロンプト・インジェクション等（悪意のあるペイロードが AI システムに侵入）
Privilege Escalation (権限昇格) : ジャイルブレイク等（安全トレーニングやポリシーのガードレールの回避）
Reconnaissance (偵察) : 資産，接続されているサービス，および能力に関する情報を明らかにさせる
Persistence (永続化) : 長期記憶に自身を埋め込む，またはエージェントが依存するデータベースを汚染
Command and Control (C2; 指揮統制) : 攻撃者がその挙動を変更できる制御可能なトロイの木馬へと進化
Lateral Movement (水平展開) : 他のユーザ，デバイス，またはシステムへと拡散。マルウェア拡散の高速道路を作り出す
Actions on Objective (目的の実行)

via The Promptware Kill Chain - Schneier on Security

こうやって見るとプロンプト・インジェクションなどは一連の攻撃の取っ掛かりに過ぎないことが分かる。最終段階では仕込まれたマルウェアが発火して攻撃者の目的が実行される。

The goal of promptware is not just to make a chatbot say something offensive; it is often to achieve tangible malicious outcomes through data exfiltration, financial fraud, or even physical world impact.

via The Promptware Kill Chain - Schneier on Security

実際に AI エージェントによって攻撃者のウォレットに暗号資産が送金された事例とかあるらしい。他にも

といった論文がある。

根本的な問題は LLM 自体のアーキテクチャにあると言う。

Unlike traditional computing systems that strictly separate executable code from user data, LLMs process all input—whether it is a system command, a user’s email, or a retrieved document—as a single, undifferentiated sequence of tokens. There is no architectural boundary to enforce a distinction between trusted instructions and untrusted data. Consequently, a malicious instruction embedded in a seemingly harmless document is processed with the same authority as a system command.

via The Promptware Kill Chain - Schneier on Security

つまり LLM はコマンドとデータを区別できず全てを一連のトークン列として処理するため，容易に悪意を忍ばせることができる。

初期アクセス（プロンプト・インジェクション等）を防ぐことが難しいなら，後続のステップで防ぐしかない。権限昇格の制限，偵察の制約，永続化の防止，C2の妨害，エージェントが実行を許可されるアクションの制限といった対策で多層防衛を構築する必要がある。

某マスク氏率いる xAI について

One source said, “Safety is a dead org at xAI,” while the other said that Musk is “actively is trying to make the model more unhinged because safety means censorship, in a sense, to him.”

via Is safety ‘dead’ at xAI? | TechCrunch

みたいな話もあるようだが，そんな牧歌的な段階はとうに過ぎてるということだろう。他の大手 AI サービス・プロバイダはどうなんだろうねぇ。

そういえば先日公開された「AIによる民主主義の巻き返しは可能か」で “Rewiring Democracy” に関して

実際、やはり情報セキュリティ分野の専門家であるベン・ロスキーが本書について、「AIを民主主義のために利用する上で最大の障壁はセキュリティだが、その話が第27章になるまで出てこない」「セキュリティなくして信頼は成立しないのに、著者らは今日のAI開発において、セキュリティは後付けの考慮事項だと言わんばかりだ」と不満げに書いているのを読んで思い至ったのですが…

AIによる民主主義の巻き返しは可能か – WirelessWire & Schrödinger'sより

という指摘があったが，複数のレイヤできっちり仕事をされる Bruce Schneier 先生マジすげーなと思ったのであった。

参考

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

ハッキング思考　強者はいかにしてルールを歪めるのか、それを正すにはどうしたらいいのか: ブルース・シュナイアー (著), 高橋聡 (翻訳); 日経BP 2023-10-12 (Release 2023-10-12); Kindle版; B0CK19L1HC (ASIN); 評価

Kindle 版が出てた！

reviewed by Spiegel on 2023-11-21 (powered by PA-APIv5)

“kill chain” は元々軍事用語で，敵軍の構造を破壊（切断する）することで自軍を守る先制処置の考え方らしい。これをサイバーセキュリティの分野に持ち込んだのが “Cyber Kill Chain” なんだそうで，攻撃の段階構造を理解し，各段階に対してそれぞれ有効な対策をとることで自システムを多層防御するフレームワークを指すとのこと。故に “Promptware Kill Chain” は本文で紹介するプロンプトウェアの7段階を理解し，各段階それぞれに対して有効な対策をとるべき，という意図なのだろう。 ↩︎
“enshittification” を「メタクソ化」と訳した p2ptk.org の中の人は天才だと思う。 ↩︎

諸々の雑感（2025-11-26 の戯れ言）

2025-11-26T05:58:25+00:00

Orion ブラウザがバージョン 1.0 に到達

Orion 1.0 ✴︎ Browse Beyond | Kagi Blog

Orion ブラウザは WebKit ベースの Web ブラウザで，ゼロテレメトリ，ユーザのプライバシー優先の設計を謳っている。

A lean, native codebase without ad‑tech bloat.

Optimized startup, tab switching, and page rendering.

A UI that gets out of your way and gives you more screen real estate for content.

Zero Telemetry: We don’t collect usage data. No analytics, no identifiers, no tracking.

No ad or tracking technology baked in: Orion is not funded by ads, so there is no incentive to follow you around the web.

Built‑in protections: Strong content blocking and privacy defaults from the first launch.

via Orion 1.0 ✴︎ Browse Beyond

生成 AI への態度も明確で¹

We are not against AI, and we are conscious of its limitations. We already integrate with AI‑powered services wherever it makes functional sense and will continue to expand those capabilities.

We are against rushing insecure, always‑on agents into the browser core. Your browser should be a secure gateway, not an unvetted co‑pilot wired into everything you do.

via Orion 1.0 ✴︎ Browse Beyond

とした上で，実装としては

Orion ships with no built‑in AI code in its core.

We focus on providing a clean, predictable environment, especially for enterprises and privacy‑conscious professionals.

Orion is designed to connect seamlessly to the AI tools you choose – soon including Kagi’s intelligent features – while keeping a clear separation between your browser and any external AI agents.

via Orion 1.0 ✴︎ Browse Beyond

ということだそうだ。

個人的には Web ブラウザのコア機能として AI を組み込むのは時期尚早だと思っているので，上述の実装方針には共感する。とはいえ AI 機能自体は便利に使っていて，たとえば Firfox 組み込みの AI 機能は使ってないけど “Kagi Search for Firefox” (表示ページの内容を要約してくれる) や “Kagi Translate” といった拡張機能はかなり積極的に使っている（お金払ってるんだから使わにゃ損）。

Orion ブラウザは現在 macOS, iOS/iPadOS 版が提供されていて Linux 版はアルファ版がある。 Windows 版は開発中とのこと。私は外出用の MacBook Air には既に入れているのだが macOS の機能は殆ど使ってないからなぁ。

Linux 版のアルファが取れる日をお待ちしています。

Firefox 145 で追加されたプライバシー保護関連機能

Firefox expands fingerprint protections: advancing towards a more private web

記事を読んでもちょっと何言ってるか分からないのだが（自画自賛？）

Firefox’s new protections are a balance of disrupting fingerprinters while maintaining web usability. More aggressive fingerprinting blocking might sound better, but is guaranteed to break legitimate website features. For instance, calendar, scheduling, and conferencing tools legitimately need your real time zone. Firefox’s approach is to target the most leaky fingerprinting vectors (the tricks and scripts used by trackers) while preserving functionality many sites need to work normally. The end result is a set of layered defenses that significantly reduce tracking without downgrading your browsing experience.

via Firefox expands fingerprint protections

と書かれている。 Firefox を使ってる人は，この機会に「プライバシーとセキュリティ」の設定を見直してみるといいかもしれない。

Firefox のこういうところは悪くないと思うのだが，イマイチ信用しきれんのだよなぁ。

𝕏 プロファイルの所在地をボカしてみる

最初は NHK の 𝕏 アカウントが US になってるという話を聞いて，これこそ「ちょっと何言ってるか分からない」だったが，どうもプロファイルに表示されるようになった「アカウントの所在地」の話らしい。

プロファイルより

ちっ。私は日本在住か。いや，合ってるけど。

これに端を発して，なかなかに愉快なことになってるようだ。

Elon Musk’s Worthless, Poisoned Hall of Mirrors - The Atlantic

あまり真面目に読む気がなかったので Kagi Assistant に要約させたのだが

機能の説明：「このアカウントについて」はアカウント作成国やユーザー名の変更履歴などを表示する新機能です。
発見された事実：アメリカの愛国者を名乗る多くのプロMAGAアカウントが、実際にはナイジェリア、ロシア、インド、タイなど外国を拠点にしていることが明らかになりました。
表示の問題：ただし、この機能には誤表示や不正確なラベル付けも確認されており、すべての情報が信頼できるわけではありません。
著者の主張：筆者は、X（旧Twitter）がエンゲージメントと利益を優先することで、政治的分断や偽情報を増幅し、プラットフォームを「価値のない、毒された万華鏡」のような状態に変えていると論じています。
結論：この事例は、真実や安全性よりも利益を優先するソーシャルメディア全体に共通するより大きな問題の一端であると結ばれています。

これで合ってる？

間違いや不正確な情報を元にどれだけ騒ぎ立てても1ミリも説得力がないと思うのだが，やっぱ 𝕏 は碌でもないということは分かる。

𝕏 のリージョン・チェックがどうなってるか知らないが（壊れてるようにしか見えないけど），表示を緩和させることはできるらしい（完全に隠すことはできない）。

How To Hide Your Country Location on X (Twitter) by Switching to Region – Hackread – Cybersecurity News, Data Breaches, Tech, AI, Crypto and More

これによると「設定とプライバシー」から「プライバシーと安全」を選択し，更に「アカウントについて」を選択すると以下の画面が表示される。

プロファイルより

ここで「地域/大陸を使用する」を選択すると

プロファイルより

おおっ。所在地が “East Asia & Pacific” になった。まぁ，大陸レベルで誤魔化したい場合（あるいは大陸を跨いで間違えてる場合）は，これでもダメだろうけど。

なんでこんなこと始めたのかね。意味のない情報だよな。 GitHub みたいに時差を表示してくれるんならまだ分かるけど。あれか。米国とそれ以外を区別しようとしてるのかな？かの国は「アメリカ・ファースト」らしいし。でもそれで間違った情報をばらまいてるならしょうがないな（笑）

ちなみに私の 𝕏 アカウントは認証されてません。お金を払ってない（払う気がない）ので。

KeePassXC 2.7.9 が ANSSI のセキュリティビザを取得

KeePassXC 2.7.11 がリリースされた。

KeePassXC 2.7.11 released – KeePassXC

この中で， Windows 版 KeePassXC 2.7.9 がフランスの国立情報システムセキュリティー庁（Agence Nationale de la Sécurité des Systèmes d’Information; ANSSI）の第一級セキュリティ認証（Certification de Sécurité de Premier Niveau; CSPN）に合格し，セキュリティビザを取得したと書かれている。

via KeePassXC Security Audits and Certifications – KeePassXC

このセキュリティビザ取得により KeePassXC は，今後3年間 ANSSI の後援を受けられるそうな。

ANSSI はフランスにおいて暗号製品の政府調達にも関わってるセクションらしい。以下のドキュメントにフランスの暗号関連の認証・調達に関する解説が載っている。

「暗号利用環境に関する動向調査」報告書（2015年度） | 情報セキュリティ | IPA 独立行政法人情報処理推進機構

また，セキュリティビザに関しては以下をどうぞ。

Security VISA | ANSSI

ブックマーク

Linux その288 - KeePassXC 2.7.11 リリース・KeePassXC をインストールするには - kledgeb

この件については拙文「「LLM は詭弁家である」」も参考にどうぞ。 ↩︎

GitHub「変更不可リリース（Immutable Releases）」について

2025-11-11T03:59:41+00:00

気づくのが遅れたが，先日 GitHub が「変更不可リリース¹（Immutable Releases）」機能を正式リリースしたらしい。

私のリポジトリでこれを採用するかどうかは分からないが，覚え書きとして記しておく。

リポジトリに対して「変更不可リリース」を設定すると以下の機能が有効になる。

変更できないリリースを有効にすると、次の保護が適用されます。

Git タグは移動または削除できません。変更できないリリースが発行されると、関連付けられている Git タグは特定のコミットにロックされ、変更または削除することはできません。

リリースアセットを変更または削除することはできません:リリースにアタッチされているすべてのファイル (バイナリやアーカイブなど) は、変更または削除から保護されます。

さらに、変更不可リリースを作成すると、リリース構成証明が自動的に生成されます。これは、リリースタグ、コミット SHA、およびリリースアセットを含むリリースに関する、暗号で検証可能なレコードです。コンシューマーはこの構成証明を使用して、使用しているリリースと成果物が、公開された GitHub リリースと完全に一致することを確認できます。

変更不可リリース - GitHub ドキュメントより

さらに

不変リリースには、リポジトリの復活攻撃に対する保護が含まれます。リポジトリを削除し、同じ名前の新しいリポジトリを作成した場合でも、元のリポジトリの変更できないリリースに関連付けられたタグを再利用することはできません。

変更不可リリース - GitHub ドキュメントより

なんだそうだ。リポジトリを移動したらどうなるんだろう？

「変更不可リリース」を有効にする前のリリースバージョンにはこれらの機能は適用されない。逆に「変更不可リリース」有効状態でリリースしたバージョンについては「変更不可リリース」設定を解除した後も機能が残り続ける。

Once enabled:

All new releases are immutable (i.e., assets are locked and tags are protected).

Existing releases remain mutable unless you republish them.

Disabling immutability doesn’t affect releases created while it was enabled. They remain immutable.

via Immutable releases are now generally available

「変更不可リリース」はリポジトリ単位で設定できる。リポジトリの “Settings” を開き “General” 項目の “Releases” にあるチェック項目 “Enable release immutability” をチェックする。

via Repository Settings

Organization の場合は Settings で「変更不可リリース」のポリシーを設定できる。 “Code, planning, and automation” の “Repository” → “General” 項目を開き “Releases” を “All repositories” または “Selected repositories” に設定する。

via Organization Settings

“All repositories” を選択すると Organization 内の全リポジトリに「変更不可リリース」が適用される。 “Selected repositories” を選択すると適用するリポジトリを選択できる。

via Selected repositories

まぁ Go のパッケージに関しては， Go のエコシステムの中で運用する限り，リポジトリのバージョンタグは実質的に immutable なんだよな。

Go はどのようにしてサプライチェーン攻撃を低減しているか

それでも GitHub のリリースページでバイナリを配布している場合は「変更不可リリース」機能は有用なので，導入を検討してもいいかもしれない。

参考図書

初めてのGo言語第2版 ―他言語プログラマーのためのイディオマティックGo実践ガイド: Jon Bodner (著), 武舎広幸 (翻訳); オライリー・ジャパン 2025-08-05 (Release 2025-08-05); 単行本（ソフトカバー）; 4814401191 (ASIN), 9784814401192 (EAN), 4814401191 (ISBN); 評価

第2版。 Generics の説明が大幅に改訂されたらしい。練習問題も追加されている。

reviewed by Spiegel on 2025-11-02 (powered by PA-APIv5)

GitHub の公式ドキュメントで「変更不可リリース」「不変リリース」「変更できないリリース」など訳語が混在しているが，この記事では「変更不可リリース」としておく。これって生成 AI に翻訳させてるのかね。用語の統一くらいしておけよ。 ↩︎

自転車も早めにライトを点けよう，という噺

2025-10-24T03:57:39+00:00

トワイライト・オン運動？

Bluesky の TL を眺めてたら

夕暮れ時・夜間の交通事故防止警視庁

という Web ページがあるそうでその中で「トワイライト・オン運動」なるものが紹介されていた。

トワイライト・オン運動より

これを見て「10月に16時半点灯は早過ぎんだろ！」と一瞬思ったが，私の住んでる松江と東京ではだいぶ経度が違うので，日の入り時刻も違うか，と思い直した。国立天文台暦計算室で東京の日の出入りを調べてみると，10月下旬の日の入り時刻が 17:00〜16:47 だそうで，それなら16時半点灯は妥当なんだろう。ちなみに昨日の松江の日の入り時刻は 17:23 で東京より30分近く遅い。日の出も同じくらい遅いけど。

日没（宍道湖嫁ヶ島） | Flickr

自転車の夜間点灯に関するルール

私は自転車乗りなので，自転車の夜間点灯のルールについて改めて調べてみる。

まず「車両等」の点灯については道路交通法の第五十二条に定められている。

（車両等の灯火）
第五十二条　車両等は、夜間（日没時から日出時までの時間をいう。以下この条及び第六十三条の九第二項において同じ。）、道路にあるときは、政令で定めるところにより、前照灯、車幅灯、尾灯その他の灯火をつけなければならない。政令で定める場合においては、夜間以外の時間にあつても、同様とする。

道路交通法 | e-Gov 法令検索より

ところで，この第五十二条の二項に

２　車両等が、夜間（前項後段の場合を含む。）、他の車両等と行き違う場合又は他の車両等の直後を進行する場合において、他の車両等の交通を妨げるおそれがあるときは、車両等の運転者は、政令で定めるところにより、灯火を消し、灯火の光度を減ずる等灯火を操作しなければならない。

道路交通法 | e-Gov 法令検索より

とかあるけど，運転手側の視認優先で歩行者や自転車を平気でハイビームで照らしやがるのはいいのかね？あれで照らされると目の前が白飛びして何も見えなくなるんだけど。歩行者は事故って4ねってことかね。

それはともかく「政令で定めるところにより」については道路交通法施行令の第十八条に定められていて

（道路にある場合の灯火）
第十八条　車両等は、法第五十二条第一項前段の規定により、夜間、道路を通行するとき（高速自動車国道及び自動車専用道路においては前方二百メートル、その他の道路においては前方五十メートルまで明りように見える程度に照明が行われているトンネルを通行する場合を除く。）は、次の各号に掲げる区分に従い、それぞれ当該各号に定める灯火をつけなければならない。

道路交通法施行令 | e-Gov 法令検索より

さらに自転車を含む軽車両については

五　軽車両　公安委員会が定める灯火

道路交通法施行令 | e-Gov 法令検索より

とある。要するに，自転車に関しては各都道府県の定めるルールに従ってね，ということだ。

さらにさらに「政令で定める場合においては、夜間以外の時間にあつても」の部分は道路交通法施行令の第十九条に定められていて

（夜間以外の時間で灯火をつけなければならない場合）
第十九条　法第五十二条第一項後段の政令で定める場合は、トンネルの中、濃霧がかかつている場所その他の場所で、視界が高速自動車国道及び自動車専用道路においては二百メートル、その他の道路においては五十メートル以下であるような暗い場所を通行する場合及び当該場所に停車し、又は駐車している場合とする。

道路交通法施行令 | e-Gov 法令検索より

とある。これは，まぁ，当然だね。

さて，各自治体が定める具体的なルールについてはそれぞれ住んでるところを調べてもらいたいが，島根県に関しては島根県道路交通法施行細則に定められている¹。

(軽車両の灯火)

第9条　令第18条第1項第5号の規定により、軽車両(そり及び牛馬を除く。以下この条において同じ。)がつけなければならない灯火は、次に掲げるものとする。

(1)　灯火の色が白色又は淡黄色で、夜間、前方10メートルの距離にある交通上の障害物を確認することができる光度を有する前照灯

(2)　灯火の色が橙色又は赤色で、夜間、後方100メートルの距離から点灯を確認することができる光度を有する尾灯

2　軽車両が夜間後方100メートルの距離から道路運送車両の保安基準(昭和26年運輸省令第67号)第32条第2項の規定による自動車の前照灯で照射した場合に、その反射光を照射位置から確認できる橙色又は赤色の反射器材1個(後面の幅が0.5メートル以上の軽車両にあっては、その両端に各1個)以上を備えているときは、前項第2号に定める尾灯をつけることを要しない。

(平13公委規則1・平19公委規則11・令6公委規則9・一部改正)

島根県道路交通法施行細則より

「夜間、前方10メートルの距離にある交通上の障害物を確認することができる光度」となると（周囲の環境にもよるが）最低でも400ルーメン，できれば800ルーメン以上は欲しいところである。ちなみに私は最大800ルーメンの前照灯を使用している。私が持ってる前照灯は充電式なのだが，充電しながら点灯できることに最近気がついた。つまりモバイルバッテリに繋ぎながら点灯できるわけだ。バッテリ残量が心配で夜間はできるだけ走らないようにしているが，これでちょっと安心。

最後に罰則について。

当然無灯火運転には罰則がある。

第百二十条　次の各号のいずれかに該当する者は、五万円以下の罰金に処する。

[…]

五　第五十条（交差点等への進入禁止）又は第五十二条（車両等の灯火）第一項の規定の違反となるような行為をした者

道路交通法 | e-Gov 法令検索より

気ぃつけなはれや！そこな高校生（まぁ私は他所様の子供を叱る義理も熱意もないけど）。

点灯タイミング

私は自動車を持ってないので知らなかったのだが，2020年以降の新車に関しては（周囲の明るさを検知して自動点灯する）オートライト機能が義務化されているらしい。このおかげかどうか，日没30分前あたりからライトを点けている自動車が増えてきたように思う。曇りとか雨の日とかはもっと早く点けている感じ。

なので私は，周囲の車の様子を見て自分もライトを点けるようにしている。ちなみにハブダイナモ（車軸に付いてるやつ）方式だと大抵オートライト機能が付いてる。充電池式のタイプにもオートライト機能が付いてるものがある。

光に闇が混じる合 (あわい) の時間に点く灯りは周囲への存在アピールになる。

人々が闇夜に持つランタンは「相手を見張る道具」であると同時に「自分自身を見張らせる」道具でもあった。

『テスラ―発明的想像力の謎』陰影礼賛より

最後は少しシュールに，自転車も早めにライトを点けようというお噺でした。これでこっぽし。

ブックマーク

参考

テスラ―発明的想像力の謎: 新戸雅章 (著); 工学社 2002-02-01; 単行本; 4875932685 (ASIN), 9784875932680 (EAN), 4875932685 (ISBN), 9784875932680 (ISBN); 評価

正直，伝記本とは言いがたいが，読み物としては面白い。

reviewed by Spiegel on 2015-09-13 (powered by PA-APIv5)

島根県道路交通法施行細則については検索サービスが用意されていて，これを使えとある。できれば PDF で欲しいけど，まぁいいか。 ↩︎

NIST SP 800-63-4 最終版がリリース

2025-08-28T08:34:43+00:00

以前「誰が「パスワードは複雑なものにしろ」と言ったのか」でちょろんと紹介した NIST SP 800-63-4 の最終版が2025年7月に公開されたようだ。見落としてたよ。

これは以前の NIST SP 800-63-3 を置き換える内容となっている。 NIST のブログ記事によると，主な変更点は以下の通りらしい。

Updates to context setting for risk management, reframed risk management processes, and new expectations for greater cross-functional engagement.

New recommended continuous evaluation metrics.

Expanded fraud requirements and recommendations for identity proofing processes.

Restructured identity proofing controls to better define roles and types of identity proofing.

Added controls for addressing injection attacks and forged media (e.g., “deep fakes”).

Integration of syncable authenticators (e.g., synced passkeys).

Representation of subscriber-controlled wallets in the federation model.

via Let’s get Digital! Updated Digital Identity Guidelines are Here!

とりあえずこの記事ではリンクのみ指示しておく。そのうち詳しく話す機会があるかもしれない。

ブックマーク

参考図書

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

社会における「信頼」とは。

reviewed by Spiegel on 2015-11-28 (powered by PA-APIv5)

Integrity が問われる時代

2025-06-28T10:48:41+00:00

セキュリティの3要件をご存知だろうか。すなわち

機密性 (Confidentiality)
完全性 (Integrity)
可用性 (Availability)

である。このうち機密性は言わずもがなで，可用性についても Web 2.0 以降から重要視されるようになった。一方で完全性についてはこれまで機密性を担保するための（データ破壊や改竄を防ぐ）要件として考えられることが多かったように思う。

ここで我らが Bruce Schneier 先生が以下のエッセイを公開された。

The Age of Integrity - Schneier on Security

この記事ではまず，これまでの狭義の「完全性（Integrity）」を拡張する。

More broadly, integrity refers to ensuring that data is correct and accurate from the point it is collected, through all the ways it is used, modified, transformed, and eventually deleted. Integrity-related incidents include malicious actions, but also inadvertent mistakes.

via The Age of Integrity

つまり，利用からはじめ変更・変換そして削除に至るまで，データのライフサイクル全体で「整合性¹（Integrity）」を担保していくわけだ。こうした「整合性」の問題は，これからの AI 時代に特に重要になっていくという。

Integrity has always been important, but as we start using massive amounts of data to both train and operate AI systems, data integrity will become more critical than ever.

Most of the attacks against AI systems are integrity attacks. Affixing small stickers on road signs to fool AI driving systems is an integrity violation. Prompt injection attacks are another integrity violation. In both cases, the AI model can’t distinguish between legitimate data and malicious input: visual in the first case, text instructions in the second. Even worse, the AI model can’t distinguish between legitimate data and malicious commands.

Any attacks that manipulate the training data, the model, the input, the output, or the feedback from the interaction back into the model is an integrity violation. If you’re building an AI system, integrity is your biggest security problem. And it’s one we’re going to need to think about, talk about, and figure out how to solve.

via The Age of Integrity

さらに Bruce Schneier さんは “confidentiality” に対する “confidential” や “availability” に対する “available” のように “integrity” に対しても “integrous” という言葉を普及させてはどうかと提案している。ただし辞書にはない単語らしいけど（笑）

There are deep questions here, deep as the internet. Back in the 1960s, the internet was designed to answer a basic security question: Can we build an available network in a world of availability failures? More recently, we turned to the question of privacy: Can we build a confidential network in a world of confidentiality failures? I propose that the current version of this question needs to be this: Can we build an integrous network in a world of integrity failures?

via The Age of Integrity

（強調は私がやりました）

AI だけでなく，近年 Web 3.0 などと言われる分散型・非中央集権型・インテリジェンスなネットワークにおいても「整合性」の問題は重要な課題と言える。

We need research into integrous system design.

via The Age of Integrity

こうした議論についても今後注目していく必要があるかな。

ブックマーク

参考

ハッキング思考　強者はいかにしてルールを歪めるのか、それを正すにはどうしたらいいのか: ブルース・シュナイアー (著), 高橋聡 (翻訳); 日経BP 2023-10-12 (Release 2023-10-12); Kindle版; B0CK19L1HC (ASIN); 評価

Kindle 版が出てた！

reviewed by Spiegel on 2023-11-21 (powered by PA-APIv5)

広義の “Integrity” の場合は「完全性」と訳すより「整合性」のほうが日本語的にピッタリくる？ Google 翻訳や Kagi 翻訳では「整合性」と訳していた。 ↩︎

Bluesky における新しい認証方法

2025-04-22T10:11:22+00:00

また Bluesky が面白いことを始めたらしい。

A New Form of Verification on Bluesky - Bluesky

この記事について Kagi Assistant に要約してもらった。 LLM の言うことだから鵜呑みにしないで原文をチェックしてね。

Blueskyは2025年4月21日に新しい認証の仕組みを発表しました。主なポイントは以下の通りです。

青いチェックマークによる認証の導入

これまでのドメインをユーザー名に設定する認証（ドメインハンドル）に加え、公式で著名なアカウントに対して青いチェックマークを表示する新しい認証レイヤーを導入。

Blueskyが積極的に認証を行い、青いチェックを付与する。

Trusted Verifiers（信頼された認証機関）機能

独立した組織が直接アカウントを認証できる仕組み。

Trusted Verifiersは波型の青いチェックマークで表示される。

例としてニューヨーク・タイムズが自社のジャーナリストに直接認証を付与可能。

Blueskyのモデレーションチームが認証の真偽を確認する。

認証の詳細表示と設定

認証マークをタップすると、どの組織が認証したかが見られる。

ユーザーは設定で認証表示をオフにすることも可能。

認証の申請について

現時点では直接の認証申請は受け付けていない。

今後、安定化した段階で申請フォームを公開予定。

自己認証の推奨

公式組織や個人は引き続きドメインをユーザー名に設定する自己認証を推奨。

この新しい認証システムは、信頼性を高め、ユーザーが誰と交流しているかをより明確にすることを目的としています¹。

A New Form of Verification on Bluesky - Bluesky ↩︎

元記事を見るに Bluesky 自身が個々人のユーザアカウントを認証（verification）するのではなく，企業・組織アカウントを verifier として Bluesky が認証した上で，認証された verifier が麾下のユーザアカウントを認証するという仕組みのようだ（つまり不特定のユーザを認証することは想定していない？）。

via A New Form of Verification on Bluesky

X.509 な証明書管理の仕組み（hierarchical な信用モデル）とちょっと似てるかもね¹。ユーザアカウントの認証については verifier に丸投げではなく

Bluesky’s moderation team reviews each verification to ensure authenticity.

via A New Form of Verification on Bluesky

と Bluesky も監査を行う感じだろうか。

SNS ユーザのアイデンティティを客観的に評価するのは難しい。というか多分無理。

昔（ゼロ年代）はリアルのユーザと SNS アカウントを（実名を強制するなどして）強引に紐づけようとして，多くの批判にさらされ失敗した。旧 Twitter はサービス提供者がアイデンティティを認証しバッヂを付与することでユーザ間の差別化を図ろうとしたが，そこから二転三転し，現在の 𝕏 のバッヂは単に有料ユーザであることを示しているに過ぎずアイデンティティについて何も担保しない。

Bluesky による今回の認証方法が上手く回るかどうかは（面白そうではあるが）分からない。 Verifier に対する認証・監査は簡単じゃないと思うし，恣意的な判断が入る余地もある。それでも…

昨年末に「Bluesky 上で起きたなりすましとサイバースクワッティング」という話を書いたが，少なくともこうしたなりすましが抑制されることを期待したい。

ブックマーク

Xそっくりの青い認証マーク導入をBlueskyが発表するも、一部で批判の声が上がる理由とは【やじうまWatch】 - INTERNET Watch

参考図書

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

社会における「信頼」とは。

reviewed by Spiegel on 2015-11-28 (powered by PA-APIv5)

Bluesky は分散システムとして設計されているので，認証を Bluesky が中央集権的に行うのは拙いという判断なのだろう。でも hierarchical な認証システムを分散環境に入れ込むのは微妙かもしれない。 ↩︎

米国の危殆化と CVE Foundation に関するブックマーク

2025-04-17T10:47:32+00:00

政治的な話をこのブログでするつもりはないが CVE Foundation 発足の経緯については覚え書きとして記しておこう。

以後，随時ブックマークを追加していく予定。

今回の件に教訓があるとすれば，国際的なシステムがひとつの国家にロックインされることがいかに危険かということかな。大国でもちょっとしたことで危殆化する可能性があるということやね。

参考文献

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

ハッキング思考　強者はいかにしてルールを歪めるのか、それを正すにはどうしたらいいのか: ブルース・シュナイアー (著), 高橋聡 (翻訳); 日経BP 2023-10-12 (Release 2023-10-12); Kindle版; B0CK19L1HC (ASIN); 評価

Kindle 版が出てた！