|
|
|
|
|
||
|
||
IPA情報セキュリティセミナー 講師派遣
2025-12-13
児童をして撮影送信させる不同意わいせつ罪・映像送信要求罪・性的姿態撮影罪・児童ポルノ製造罪について、上告棄却決定（最決R071201）
理由は10行くらい。
一審 東京地裁r061129
原審 東京高裁t070704
上告棄却 最決r071201
上告理由
目次
上告理由第１ 憲法違反～性的姿態撮影罪・映像送信要求罪の構成要件である「性器」「周辺部」の用語が不明確で、刑罰法規としての明確性を欠き、無効である（憲法21条、31条違反）（判示第2） ７
1 原判決 7
2 性的姿態撮影法上「性器」「周辺部」の定義が定まらないこと 8
3 16歳未満に対する映像送信要求罪（刑法182条3項2号）でも「性器」「周辺部」の定義が定まらないこと 9
4 医学書の「性器」の説明 9
5 国語辞典の「性器」の説明 10
広辞苑 10
明鏡国語辞典 10
新明解国語辞典 11
大辞泉 11
6 弁護人の主張する「性器」 11
①ある刑罰法規があいまい不明確のゆえに憲法三一条に違反するものと認めるべきかどうかは、通常の判断能力を有する一般人の理解において、具体的場合に当該行為がその適用を受けるものかどうかの判断を可能ならしめるような基準が読みとれるかどうかによつてこれを決定すべきである（最判s50.9.10） 11
② 国語辞典では「生殖器」と説明されている 13
③ 不同意わいせつ罪の接触部位との比較 15
④ 「性器」の説明は性的姿態撮影。映像送信要求罪の定義に置かれているから、性器・非性器の境界線は物理的形状を重視して、目で見て分かるという観点から決められるべきである。 18
⑤ 男性・女性の統一的な解釈 18
⑥ 児童ポルノ罪・映像送信要求・性的姿態撮影罪の「性器」は共通の概念であるべきである。 19
⑦ 小括 19
7 裁判例 19
①神戸地裁r7.3.12*5 19
②熊谷支部r7.4.15*6（控訴中） 20
８ まとめ 22
上告理由第２ 憲法違反～映像送信要求罪（182条3項2号）の規定は、「その他の姿態」の用語が不明確で、刑罰法規としての明確性を欠き、無効である（判示第2 r6.7.24起訴状） ２３
1 「その他の姿態」が無限定 23
2 第二号に掲げる行為については、当該行為をさせることがわいせつなものであるものに限る。）」の「わいせつ」が定義できないこと 26
3 原判決 28
5 まとめ 29
上告理由第３ 法令違反・判例違反～不同意わいせつ罪の成立範囲。送信させ保存する行為は「わいせつ行為」ではない（R6.7.24起訴状） ３１
1 原判決 31
２ わいせつの定義がないので議論しづらいが、馬渡（向井）解説*7・薄井論文*8の「手法」に沿って検討してみる 33
（１）送信させ・保存する行為の「性的な意味」とは 33
（２）撮影させる行為の「性的意味合い」の程度 35
馬渡（向井）解説 36
大塚仁ほか編・大コンメンタール刑法〔第3版〕(9)[亀山継夫＝河村博］67頁 37
薄井論文 39
（３）学説 40
①佐藤陽子 自己のわいせつな画像を撮影（ ・送信）させる行為の「わいせつな行為」性について 山口厚ら「実務と理論の架橋」 40
②木村光江「強制わいせつ罪における『性的意図』」判例時報 736号18頁。*9 42
③橋爪隆・研修８６０号３頁 42
（４）高裁判例・裁判例 43
①名古屋地岡崎支部h30.4.19*10 43
②大阪高裁H22.6.18*11（神戸地裁H21.12.10*12） 44
③大阪高裁r02.10.2*13（奈良地裁葛城支部R02.3.30*14） 44
④大阪高裁R2.10.27*15（奈良地裁葛城支部R2.2.27*16） 45
⑤大津地裁R5.3.1 48
⑥長崎地裁佐世保支部r6.2.21*17（強要） 50
⑦札幌高裁r5.1.19*18（札幌地裁R04.9.14*19 ） 51
（５）社会通念上の「撮影させる行為」の扱い＝強要罪の裁判例 51
3 判例違反～裸体を送信させ・記録する行為はわいせつ行為ではないという高裁判例。 55
①広島高裁岡山支部H22.12.15*53 56
②東京高裁H28.2.19*54 57
③広島高裁岡山支部h30.8.29*55 58
④大阪高裁r2.10.2（奈良地裁葛城支部R02.3.30） 59
⑤大阪高裁R2.10.27*56（奈良地裁葛城支部R2.2.27） 60
3 高裁レベルでは、撮影させた行為をわいせつと評価したものはあっても、送信させた行為をわいせつと評価した判決はないこと 60
（1）大阪高裁r03.7.14 61
（2）大阪高裁r04.1.20も 64
①当初訴因 65
②検察官意見書R2.12.1 65
③原判決の罪となるべき事実 66
（3）札幌高裁r5.1.19*61（札幌地裁R04.9.14*62 ） 66
広島高裁岡山支部H22.12.15*63（岡山地裁H22.8.13） 67
東京高裁H28.2.19*64（新潟地裁高田支部H27.8.25） 67
4 原判決 68
①佐藤陽子 自己のわいせつな画像を撮影（ ・送信）させる行為の「わいせつな行為」性について 山口厚ら「実務と理論の架橋」 69
5 まとめ 70
上告理由第４ 法令違反・判例違反～R6.7.24起訴状の公訴事実は、併合罪関係にある4罪を含み、単一性を欠くから、公訴棄却すべきである。 ７２
1 公訴事実は4罪を含む 72
2 4罪の重なり合い 74
（1）概観 74
※ 「姿態をとらせて」身分犯説 76
①上田哲「刑事関係 平成18.2.20小決 (最高裁判所判例解説 76
②山口裕之「最高裁刑事破棄判決等の実情（上）－平成18年度－」判例時報 第1980号 77
③東京高裁H21.10.14*68 79
④ 仙台高裁秋田支部h27.6.30*69（秋田地裁本荘支部h27.2.6*70） 81
（2） 不同意わいせつ罪の成立範囲は「撮影させ」までである。 81
広島高裁岡山支部H22.12.15（岡山地裁H22.8.13） 82
東京高裁H28.2.19（新潟地裁高田支部H27.8.25） 82
（3） 要求罪は、要求した時点で既遂となり、それ以前もそれ以降も児童ポルノ製造以外の他罪とは重ならない。 83
（4） 性的姿態撮影罪は、撮影した時点で既遂となり、その時点で一瞬不同意わいせつ罪・児童ポルノ罪と重なるが、それ以前もそれ以降も不同意わいせつ罪・児童ポルノ罪とは重ならない。映像送信要求罪とは接点がない。 85
（5）小括 86
3 一個の行為（54条1項）とは 86
大法廷s49.5.29**71 86
最高裁判例解説刑事篇昭和４９年度７７頁 昭和４６年（あ）第１５９０号業務上過失傷害、道路交通法違反被告事件昭和４９年５月２９日 高木典雄 86
4 裁判官の論稿は併合罪。 86
5 高裁判例によれば、児童に裸の画像を送らせる行為と、児童ポルノ製造行為とは2個の行為であって、牽連犯ではなく併合罪である。（判例違反） 87
広島高裁岡山支部h22.12.15（牽連犯否定） 88
東京高裁h28.2.19*72（新潟地裁高田支部H27.8.25） 88
名古屋高裁金沢支部h27.7.23*73（高岡支部事件） 89
名古屋高裁金沢支部h27.7.23*74（福井地裁事件） 90
6 「併合罪であるから、1個の行為として記載した公訴事実は、単一性を欠いて訴因不特定により、無効である。公訴棄却になる」という主張は不利益主張ではないこと 92
（1） 公訴の適法性の要素である、「訴因の単一性」の判断には、罪数処理を判断する必要があること 92
（2） 文献 95
①刑事控訴審の理論と実務第2版 Ｐ103 95
②大コンメンタール刑訴法3版Ｐ24（担当原田國男） 96
③佐藤文哉・最高裁判所判例解説 刑事篇（昭和53年度） 304頁 98
（３） 判例では、併合罪主張も主張として被告人に実質的に有利になる場合には不利益主張とはならない。 99
①不利益主張とは 99
② 本件でも併合罪主張による結果は被告人の利益であること 100
③ 被告人控訴事件について併合罪であることを前提理由として、破棄した最高裁判例 100
④ 併合罪主張を不利益主張としない高裁判例 107
⑤不利益主張となる場合 108
7 4罪の罪数処理について裁判例は混乱している。 109
（1） 4罪観念的競合説 109
松山地裁R6.9.24*81 109
東京地裁r6.10.5*82の判示第4の7 110
さいたま地裁熊谷支部R6.5.14*83 110
岡山地裁R6.9.25*84 110
岡山地裁r7.7.15*85 111
山中 純子性的グルーミングと面会要求等罪の新設 東海法学 第66号（2024） 112
（2）牽連犯説 113
大津地裁r6.3.4*86 113
東京地裁r6.11.29 113
広島高裁岡山支部h22.12.15（牽連犯否定） 114
東京高裁h28.2.19（牽連犯否定） 114
金沢支部h27.7.23（高岡の事件）（牽連犯否定） 115
金沢支部h27.7.23（福井の事件）（牽連犯否定） 116
（3）牽連犯になったり観念的競合になったり説 118
東京地裁r6.10.5*87 118
8 一罪説の実際上の不都合＝どの部分が何罪になるのかが判然としない。 119
9 まとめ 120
上告理由第５ 法令違反・判例違反～男湯の男児の裸画像は「性欲を興奮させ又は刺激するもの」に当たらない。（判示第4 R6.8.22追起訴状公訴事実第2（5項製造罪）） １２２
1 公訴事実・1審判決 122
2 「性欲を興奮させ又は刺激するもの」の解説 123
（１）立法者の説明 123
（２） 国会会議録H11.5.14 124
（３）医学写真 126
① 標準小児科学 第５版 126
②小児泌尿器科学書 127
③新女性医学大系18「思春期医学」 127
（４）「性欲を興奮させ又は刺激するもの」の判断方法～京都地裁h12.7.17*89*90 127
（５）警察庁生活安全局少年課 執務資料「児童買春、児童ポルノに係る行為等の処罰及び児童の保護等に関する法律」解説 128
３ 「性欲を興奮させ又は刺激するもの」の判断方法 129
（１）立法者 129
（２）京都地裁h12.7.17 131
（3）無罪事例（横浜地裁H28.7.20*91） 131
（4）公衆浴場の男子脱衣場における男児の存在は当然であり、一般人基準で「性欲を興奮させ又は刺激するもの」ではなく、社会的に許容されていること 136
（5）男湯の女児問題（大阪高裁h24.7.12） 138
（6）浴場の女児・男児問題を解消するために性的姿態撮影罪が創設された 139
4 児童ポルノ該当性は当該画像のみから判断される。 140
5 高裁判例（高松高裁h22.9.7*96 松山地裁h22,3,30*97） 142
松山地裁h22.3.30 142
高松高裁h22.9.7は 143
6 本件の画像は、いずれも、公衆浴場の男子脱衣場で男児が脱衣しているという普通の情景であること 143
7 まとめ 144
上告理由第６ 量刑不当 １４６
okumuraosaka 2025-12-13 21:15 読者になる
最終更新: 2025-12-13 21:15
児童をして撮影送信させる不同意わいせつ罪・映像送信要求罪・性的姿態撮影罪・児童ポルノ製造罪について、上告棄却決定（最決R071201）
最終更新: 2025-12-13 21:15
46
最終更新日：2025/12/12
JVNVU#91654258:
AzeoTech製DAQFactoryにおける複数の脆弱性 [2025/12/12 15:00]
JVNVU#91387382:
OpenPLC_V3におけるクロスサイトリクエストフォージェリの脆弱性 [2025/12/12 15:00]
JVNVU#96960925:
複数のGrassroots製品における境界外書き込みの脆弱性 [2025/12/12 15:00]
JVNVU#99514792:
Siemens製品に対するアップデート（2025年12月） [2025/12/12 10:30]
■ 2025.12.12
》 青森地震でNTT青森八戸ビルの鉄塔が損傷 「倒壊リスクは低いが補修に3週間」 (Business Network, 12/11)
また、水道管の破損によりビル内が浸水しており、「当社の社員もビルに立ち入れていない状況。ビル内の通信設備が損傷した場合、修理ができないため、一部サービスに影響が出る可能性がある。ただ、安全にビルへ入れるルートの確保を進めており、対応を急ぎたい」と石田氏は話した。
》 また古いアニメの公式サイトが“オンカジ誘導サイト”に ドロップキャッチか (ITmedia, 12/12)。温泉妖精ハコネちゃん。
》 ハウステンボス、大規模漏えいの可能性 顧客150万人の個人情報、役職員・取引先のマイナンバー情報など (ITmedia, 12/12)
》 AIバブルに身構える米個人投資家 (Wall Street Journal, 12/12)
》 オラクルに付きまとう「オープンAIの影」 (Wall Street Journal, 12/12)。単一障害点。
最大のサプライズは望ましくない類いのものだった。オラクルは9-11月期に過去最高の120億ドルを設備投資に費やした。これは市場予想の84億ドルをはるかに上回る額だった。同社はまた、2026年5月期通期の設備投資見通しを350億ドルから500億ドルに引き上げた。
年間500億ドルという設備投資は、他の大手テック企業の一部が支出している額と比べると少ないように見えるかもしれない。だがこれは、オラクルの26年5月期の予想売上高の75％に相当する。(中略)
言い換えれば、オラクルの今後数年間の成長の大部分はオープンAI頼みのままだ。これほどの金額を約束できる企業は他にほとんどないため、容易に分散することはできない。そして、オープンAIがその約束を完全に果たせるかどうかは全く確実ではない。
》 “DRAMパニック”はなぜ起きたか、価格はいつ落ち着くのか？ 狂騒の裏で起きていること (大原雄介 / ITmedia, 12/12)
現状発生しているのは、Spot価格の高騰だ。(中略)
Spot市場の高騰が、11月に入って突如発生したメモリの品薄・高騰の直接的な要因である。
ではなぜSpot市場が価格高騰しているかといえば、恐らくContract市場に異常が発生しているからだ。具体的に言えば、恐らくメモリメーカーに対してDDR5チップの生産能力を超える量のContractの要求が殺到。(中略) 遅延した納期を待ってなんぞいられないので、Spot市場でDDR5チップをあさるしかない。(中略)
ではなぜContract市場に異常が起きたのか？ あるいは、なぜサーバメーカーその他はContractを通常より増やさざるを得ないのか？ という話になるが、筆者は基本的にはPanic Buy、つまり“狼狽買い”と考えている。
(中略) 韓国Samsung及び韓国SK Hynixが米OpenAIと結んだ契約がきっかけではないか？というシナリオが現在は有力視されている。
ありそうなシナリオは「メモリトップ2社がHBMに傾斜生産を掛けた場合、自社分を調達できなくなる可能性がある」と感じたサーバメーカーなどが、DDR5のContractを本来の必要分より多めに発注。これはGPUメーカーのGDDR、スマートフォンメーカーのLPDDRなども同じで、結果各メーカーへのContractの要求が生産量を超え、今回の事態につながったというあたりが妥当かもしれない。
この状況がいつ終わるかというと、筆者の予想は2027年以降である。なぜかというと、恐らくContractの期間が1年程度が多い（もっと長いかもしれない）と考えられるからだ。
1四半期程度だったら、Crucialブランドを一時的に休眠状態にするという選択肢もあった。そうしなかったのは、つまり1四半期では収まらないくらい長期化すると予測したためと思われる。
chip がようやく順当に流れてくるようになったと思ったら、今度はメモリーか……。世の中ままならんのう。
恐らくは26年の決算くらいのタイミングで、損切りの形でそうした在庫を市場に放出を始めるだろう。ただ厄介なのは、放出されるのはサーバ向けのRegistered ECC DIMMということで、通常のPCでは利用ができない。
Registered ECC を食えるマザーボード流行らないかなあ。
この流れでコンシューマー向けも ECC ok という時代になってほしい。
そうはならんだろうけど。
関連: アイ・オー・データ、SSDやUSBメモリなど値上げ 最大54.8％増 (ITmedia, 12/11)
2025/12/12(金)金曜日ー。（色んなゼロデイがノコノコと。）
[雑談] いろいろ。
「React」に新たな脆弱性 ～「React2Shell」への対策は不十分、最新版への更新を - 窓の杜
「React」に新たな脆弱性 ～「React2Shell」への対策は不十分、最新版への更新を／DoSやサーバー関数のソースコード露出につながる可能性
UIライブラリ「React」（React.js）の開発チームは12月11日、「React Server Components」で新たな脆弱性が発見されたことを明らかにした。先日アナウンスされた「Re
https://forest.watch.impress.co.jp
Denial of Service and Source Code Exposure in React Server Components – React
Denial of Service and Source Code Exposure in React Server Components – React
The library for web and native user interfaces
https://react.dev
React2Shellによって実行されるマルウェアZnDoorについて | セキュリティナレッジ | NTTセキュリティ・ジャパン株式会社
React2Shellによって実行されるマルウェアZnDoorについて | セキュリティナレッジ | NTTセキュリティ・ジャパン株式会社
テクニカルブログ
React2Shellによって実行されるマルウェアZnDoorについて
https://jp.security.ntt
パスワード変更も意味がない、クラウドを侵害し続ける悪意ある「OAuthアプリ」の実態：セキュリティベンダーProofpointが公開 - ＠IT
パスワード変更も意味がない、クラウドを侵害し続ける悪意ある「OAuthアプリ」の実態
Proofpointは、悪意あるOAuthアプリケーションによる永続的クラウド侵害の実態を公開した。パスワード変更やMFA適用後も攻撃者のアクセスは継続し、4日間続いた実例も確認された。
https://atmarkit.itmedia.co.jp
あなた自身がマルウェア実行犯に？ コピー＆ペーストを悪用する新手のサイバー攻撃「ClickFix」の脅威と対策【読めば身に付くネットリテラシー】 - INTERNET Watch
あなた自身がマルウェア実行犯に？ コピー＆ペーストを悪用する新手のサイバー攻撃「ClickFix」の脅威と対策【読めば身に付くネットリテラシー】
キヤノンマーケティングジャパン株式会社が発表した「2025年上半期サイバーセキュリティレポート」によると、「ClickFix（クリックフィックス）」攻撃が急増しているそうです。セキュリティ製品「ES
https://internet.watch.impress.co.jp
LINE、年末年始に向けたセキュリティ強化を呼びかけ アカウント乗っ取り・詐欺被害に注意喚起 - ケータイ Watch
LINE、年末年始に向けたセキュリティ強化を呼びかけ アカウント乗っ取り・詐欺被害に注意喚起
LINEは、LINEアカウントの不正利用を目的とした詐欺行為が報告されているとして、ユーザーに注意を呼びかけている。これらの詐欺は、SMSやメールで不正なURLをクリックさせたり、個人情報を入力させ
https://k-tai.watch.impress.co.jp
ハウステンボス、大規模漏えいの可能性 顧客150万人の個人情報、役職員・取引先のマイナンバー情報など - ITmedia NEWS
ハウステンボス、大規模漏えいの可能性 顧客150万人の個人情報、役職員・取引先のマイナンバー情報など
顧客約149万9300人分の氏名や住所、役職員とその家族約3万7300人分の氏名やマイナンバー情報、健康診断結果、障がいに関する情報、取引先約9400人分の氏名やマイナンバー情報などが漏えいしたおそれ
https://www.itmedia.co.jp
警視庁の「デジポリス」装う偽アプリに注意 捜査名目でダウンロードさせる詐欺手口 - ITmedia NEWS
警視庁の「デジポリス」装う偽アプリに注意 捜査名目でダウンロードさせる詐欺手口
警視庁の防犯アプリ「デジポリス」を装った偽アプリが確認されているとして、警視庁生活安全部が公式Xで注意を呼び掛けている。警察官をかたり、「捜査目的」として現金などをだまし取るニセ警察詐欺において、偽ア
https://www.itmedia.co.jp
AIブラウザーに潜む落とし穴--ガートナーが企業に利用停止を求める理由 - ZDNET Japan
AIブラウザーに潜む落とし穴--ガートナーが企業に利用停止を求める理由
ガートナーは、企業に対してエージェント型ブラウザーの使用を当面ブロックするよう警告した。AIがワークフローを変革する可能性を持つ一方で、セキュリティよりも利便性が優先されるデフォルト設定が「重大なサイ
https://japan.zdnet.com
【衝撃】シンギュラリティは2045年じゃなかった！？専門家が語る「2025-2029年到来説」の真実｜むぎ屋@生成AI×仕事
【衝撃】シンギュラリティは2045年じゃなかった！？専門家が語る「2025-2029年到来説」の真実｜むぎ屋@生成AI×仕事
こんむぎわ〜♪ 今日もむぎ屋のnoteに来てくれて、本当にありがとうございます！(´∀`) 今日はですね、皆さんに絶対に知ってほしい、めちゃくちゃ重要な情報があるんです。 「シンギュラリティ」っ
https://note.com
OpenAI、「GPT-5.2」発表 「Gemini 3」の“コードレッド”後、性能を大幅強化 - ITmedia AI＋
「GPT-5.2」登場 「Gemini 3」の“コードレッド”後、性能を大幅強化
OpenAIは、Googleの「Gemini 3」に対抗し、最新フロンティアモデル「GPT-5.2」を発表した。知的労働タスクのベンチマークで人間を超える割合が70.9％に向上。ChatGPTの有料プ
https://www.itmedia.co.jp
OpenAIが「GPT-5.2」を緊急事態「コードレッド」発令からわずか1カ月足らずでリリース、猛追するGoogleへ反撃となるか - GIGAZINE
OpenAIが「GPT-5.2」を緊急事態「コードレッド」発令からわずか1カ月足らずでリリース、猛追するGoogleへ反撃となるか
OpenAIがChatGPT向けAIモデルの最新ファミリーであるGPT-5.2をリリースしました。このリリースは、サム・アルトマンCEOが2025年12月初めに社内向けに出した「コードレッド」宣言に基
https://gigazine.net
VPNは廃止しなければならないのか｜hayapi
VPNは廃止しなければならないのか｜hayapi
この記事は、corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#1 Advent Calendar 2025の11日目の記事です。
https://note.com
死にそうで死なない背水のセキュリティ対策
死にそうで死なない背水のセキュリティ対策
https://zenn.dev
ASCII.jp：Power Automateで“祝日を除く”平日だけフローを自動処理させるには？ (1/3)
Power Automateで“祝日を除く”平日だけフローを自動処理させるには？ (1/3)
Power Automateには、毎週の「決まった曜日／時間」にフローを自動実行できる「スケジュール済みクラウドフロー」機能があります。ただし、これだけでは「祝日の場合は実行しない」というコントロール
https://ascii.jp
“グエー 死んだンゴ…” 父も知らなかった「22歳の遺言」 “ぼっち”ではなかった息子の生きざまが起こした奇跡（FNNプライムオンライン） - Yahoo!ニュース
“グエー 死んだンゴ…” 父も知らなかった「22歳の遺言」 “ぼっち”ではなかった息子の生きざまが起こした奇跡（FNNプライムオンライン） - Yahoo!ニュース
今年10月12日…札幌の病院で、1人の青年が静かに息を引き取った。
中山奏琉（かなる）さん、享年22。
その早すぎる死に、父・和彦さんは…
父・中山和彦さん:
1日でも長く生きてほしいっていう思い
https://news.yahoo.co.jp
■ 2025.12.09: 晴
》 閉鎖予定だったクリエイター向け3D素材配布サイト、閉鎖を延期した前代未聞の理由とは (Internet Watch, 12/9)。ありがち。
》 DAZN、F1配信終了 26年からフジテレビが独占、11年ぶりに地上波復活 配信は「FOD」でも (ITmedia, 12/5)。しかし角田は今年で終了……。
動画配信サービス「FOD」でF1を初めてライブ配信。全24戦の全セッションを配信する。F1公式ストリーミングサービス「F1 TV」との連携も日本で初めて実現する。
FOD スタンダードは 1,320円/月 なので、DAZN の半額以下で見れるということですかね。
ふつうに DAZN を使っていた人には FOD 分が純増なわけですが。
2025年12月06日
■ Digital Omnibus, Scope and Relevance: Are We Fighting the Wrong Battle?
In a previous post on the leaked “Digital Omnibus” draft, I played with the idea hidden in noyb’s name: None of Your Business – in other words, irrelevant. My point was that the GDPR already contains, in plain sight, a principle that should be at the core of the debate but is almost never mentioned: Article 5(1)(c)’s demand that data be adequate, relevant and limited to what is necessary in relation to a purpose. The real question is not how much “personal data” the law can cover in the abstract, but which data are any controller entitled to take into account for a given decision.
Since then, the Digital Omnibus proposal has been published, and noyb has issued a long report criticising it. The public debate has largely been framed as a familiar clash: on one side, a Commission accused of “watering down” the GDPR by narrowing the definition of personal data and creating new exceptions for AI and research; on the other, civil-society actors defending a maximal scope for “personal data” and a strong version of data minimisation.
In this post I want to argue that this is the wrong axis of conflict. Both sides are fighting over how broad the law’s coverage should be, while largely ignoring what the law was actually designed to control. The Omnibus debate is being treated as a war over definitions, when it should be treated as an opportunity to recover the original focus of data protection: the fairness of decisions about individuals, and the prevention of their being made on the basis of irrelevant data.
To make that case, I will first say something about the “maximal scope” paradigm that dominates current criticism of the Omnibus. I will then turn to the research and AI provisions, explain why both the Commission and noyb mis-locate the risks, and finally suggest a different way of looking at scope – one that re-reads “processing of personal data” in line with its directive-era function.
1. The “Maximal Scope” Paradigm and Its Limits
1.1 How the Omnibus Debate Frames Article 4(1)
A central target of current criticism of the Digital Omnibus proposal is the suggested rewording of Article 4(1) GDPR, the definition of “personal data”. In noyb’s reading, the new text would introduce a strongly controller-relative element into identifiability: whether information is “personal data” would depend on the specific controller’s perspective, resources or reasonable efforts. Pseudonymised data held by actors who lack re-identification keys might therefore fall outside the definition for them, even if another actor could identify the same records.
For noyb, this is not just an unfortunate drafting choice but a constitutional problem. The reasoning, roughly, is as follows:
the Charter of Fundamental Rights protects the “protection of personal data”;
the Court of Justice has repeatedly read “personal data” and “processing” very broadly;
therefore, any legislative move that appears to reduce that scope is a direct threat to fundamental rights.
On this view, the definition of “personal data” in Directive 95/46/E.C., as interpreted in landmark CJEU judgments, has been effectively “constitutionalised” by Article 8 of the Charter. And what is “constitutionalised” is understood as the breadth of the definition: the more generously we interpret “any information relating to an identified or identifiable natural person”, the more robust the protection of Article 8 must be.
From this vantage point, the only safe strategy is to insist that almost any information that can, in some chain of events, be linked to an individual must be treated as “personal data”, and that almost any operation involving that information must be treated as “processing”. The Omnibus proposal is thereby cast as an attempt to introduce controller-relative “subjectivity” into what ought to remain an objective, all-encompassing definition – a move that would undermine legal certainty, fragment enforcement and invite a race to the bottom.
I will call this way of thinking the maximal scope paradigm: the belief that the primary way to protect fundamental rights is to push the conceptual reach of “personal data” and “processing” as far as possible and then defend that maximal line against any retreat. Different actors occupy this paradigm in different ways – NGOs like noyb, some authorities and parts of the academic debate – but what they share is the assumption that “more situations legally qualifying as processing of personal data” almost automatically means “more effective protection.”
1.2 The Original Target of Data Protection: Decisions, Not “Data as Such”
Historically, however, the normative focus of European data protection instruments has never been “data as such”. It has been the use of data in systems of decision-making: credit scoring, employment screening, social security adjudication, policing, risk assessment, and so on. The early data protection laws, as well as their international precursors, were motivated by concerns that automated or computer-supported decisions about individuals could be made in opaque ways, based on incomplete, irrelevant or biased information, compiled in powerful, centralised files.
This orientation is visible in two features that are often overlooked in current debates.
First, the concept of processing was originally tied to what one might call an informational pipeline: a systematic sequence of operations through which data are collected, stored, combined, analysed and used to support decisions or actions. It was this pipeline – and the risks it created for individuals subjected to it – that justified a set of procedural and substantive constraints. The inclusion of “collection”, “use”, “disclosure” and “erasure” in the definition was meant to capture the different stages of that pipeline, not to transform any isolated mention of a person’s name into “processing” in the full legal sense.
Secondly, the much-cited triad of “adequate, relevant and not excessive” was framed as a data quality principle for decision-making. Its function was to ensure that decisions affecting individuals are based on information that has a rational link to the purpose of the decision, that is sufficiently complete and accurate for that purpose, and that does not include extraneous or prejudicial details. The idea was not to minimise data in the abstract, but to constrain the informational basis of decisions so that they are fair, non-arbitrary and non-discriminatory.
If one keeps this decision-oriented perspective in view, the relation between scope and protection looks different. What matters is not primarily how many pieces of information fall under the label “personal data”, but which informational pipelines and which decision contexts are brought within the reach of data protection law. A conception of “processing” that indiscriminately covers everything from one-off journalistic mentions to complex, automated profiling systems may be rhetorically expansive, but it risks obscuring precisely those structural features – centralisation, automation, iterative use – that generated the need for a specific legal regime in the first place.
1.3 A Preview: Two Layers of Protection
From this angle, the maximal scope paradigm is problematic in two ways.
It is over-broad, in that it extends the full conceptual and doctrinal apparatus of “processing of personal data” to contexts where the characteristic risks of data protection law are only marginally present. Treating every isolated reference to an individual, every casual photograph, or every transient log entry as “processing” subject to the GDPR may be logically possible under a literal reading of “any information relating to…”, but it stretches the concept far beyond the original risk profile it was designed to address. In doing so, it invites either pervasive non-compliance in everyday life or the proliferation of exceptions and derogations, which in turn make the law more complex and less intelligible.
At the same time, it is under-protective where protection is most urgently needed. By focusing energy on defending the outer conceptual perimeter of “personal data”, it diverts attention from the internal structure of those processing operations that truly matter: large-scale profiling, scoring and decision-support systems. Here, the crucial questions are not whether some fragment of information can be said to “relate” to an individual in the abstract, but whether the overall pipeline of processing is structured in such a way that decisions about individuals are based on adequate and relevant data, subject to meaningful contestation, and constrained by clear prohibitions on certain kinds of inferences.
Put differently, insistence on an ever-expanding notion of “personal data” risks functioning as a substitute for the harder work of identifying, and regulating, those decision contexts that require heightened protection. It can make it politically easier to denounce any perceived narrowing of scope – such as controller-relative identifiability in Article 4(1) – without having to say very much about which kinds of processing the fundamental right to data protection actually targets, and why.
To get out of this dead end, we need to recall that data protection law has always worked on two layers at once:
a decision layer, which governs how data are used in concrete decisions about individuals, and where “adequate, relevant and limited to what is necessary” should be understood as a genuine relevance requirement; and
a flow layer, which governs how data can move between contexts – purpose limitation, restrictions on re-use and onward disclosure – in order to prevent future decisions from being made on data that have no rational link to their purpose.
The rest of this post will unpack this two-layer structure and show how it helps to reframe the Omnibus debates about scientific research, AI and personal data definitions.
2. Scientific Research and AI: Data Minimisation without Decision Context
2.1 How the Omnibus and noyb Frame Scientific Research
A second focal point of the Omnibus debate is the proposed new definition of “scientific research” in Article 4(38) and the accompanying changes to purpose limitation and information duties, notably Article 13(5). The Commission’s draft defines scientific research, in essence, as “any research” that “can also support innovation”, supplemented by a long list of criteria referring to growth of society’s “knowledge and wellbeing”, adherence to “ethical standards in the relevant research area”, and similar elements.
noyb’s report offers a sharp and, in many respects, justified critique of this approach. It points out that:
the core term “research” is left so broad that it could cover almost anything, from “sifting through a library” or “using Google Search” to watching rats in a laboratory;
the phrase “any research which can also support innovation” extends the scope to mere possibilities (“can”) and by-products (“also”), so that virtually any data-driven activity in the name of innovation could qualify;
the requirement that research must be able to “support innovation” risks excluding areas of academic work not aimed at innovation in the economic or technological sense; and
references to “growth of society’s general knowledge and wellbeing” and to compliance with “ethical standards” are so indeterminate that they effectively outsource the definition of a Charter-limiting concept to private or sectoral ethics codes.
On this basis, noyb argues that the proposed definition, combined with an expanded framework for research exemptions, amounts to a “blanket allowance of further processing for a broadly and ill-defined ‘research purpose’”, which would likely fail the Charter’s requirements of necessity and proportionality. The Commission appears, in this reading, to be sacrificing the Article 7 and 8 rights on the altar of an amorphous “innovation” agenda.
At first glance, this critique appears squarely aligned with a rights-protective stance. Yet its internal logic again rests on two familiar premises: first, that the core of data protection is data minimisation as a direct emanation of Articles 7 and 8 and Article 52(1), and second, that the main threat posed by an overbroad research definition is the erosion of this minimisation and of purpose limitation as such. The questions of which types of research, and which decision contexts, ought to fall under stricter scrutiny remain largely implicit.
2.2 Research without Decisions vs Research Feeding Decisions
A decision-oriented perspective – one that takes seriously the role of adequacy and relevance in decision-making – suggests a different way to cut the problem.
On the one hand, there are forms of research that do not themselves feed into concrete decisions about identifiable individuals. Classic statistical and scientific uses of data, where the outputs are aggregate patterns, coefficients or models describing populations, may raise important issues of ethics, distributive justice and epistemic bias. But in terms of data protection, their risk profile is largely mediated by what happens after research: whether and how the resulting insights are embedded into operational decision systems.
On the other hand, there are forms of research that are structurally wired into treatment decisions: credit risk models developed on customer databases, hiring algorithms trained on past applicants, insurance pricing models, fraud detection tools. Here, the line between “research” and “operation” is thin. The same structured datasets used to develop the models are used, or readily usable, to support consequential decisions about individuals.
In this second family, what matters for data protection is not that “research” in the abstract uses more data than strictly necessary, but that the resulting decision systems may operate on data that are not relevant to the decision purpose. The core risk is arbitrary or discriminatory treatment: music taste influencing credit limits, social media activity affecting hiring, neighbourhood proxies standing in for ethnicity in insurance pricing. These are precisely the kinds of problems the adequacy and relevance requirement was originally meant to prevent.
From this angle, the Omnibus proposal’s changes to Article 4(38) and 13(5) are problematic, but not primarily because they offend an abstract ideal of data minimisation. They are problematic because they:
blur the distinction between research that merely generates statistical insight and research that is structurally embedded in decision pipelines; and
loosen purpose limitation and transparency duties in a way that weakens what I will later call the flow layer: the set of rules that restrict how data can move between contexts in order to prevent their use in irrelevant or discriminatory decisions.
noyb’s critique rightly attacks the vagueness of the definition and the risk of “innovation” being used as a carte blanche for further processing. But by casting the issue mainly in terms of Charter-compliant data minimisation, it misses the opportunity to ask the decisive question: which research-generated datasets are likely to flow into decision contexts, and how should their re-use be constrained to prevent irrelevant or discriminatory decision-making? This is the perspective I developed in my earlier post on the Omnibus debate, where I argued that both the Commission and noyb tend to overlook the GDPR’s explicit relevance requirement in Article 5(1)(c).
2.3 AI and Special Categories: Two Activities Confused under Article 9(2)(k) and (5)
The same pattern recurs, in sharper form, in the Omnibus proposal for Article 9(2)(k) and (5), dealing with AI and special categories of data. The draft introduces a new derogation for “processing in the context of the development and operation of an AI system … or an AI model”, accompanied by a paragraph 5 that requires controllers to implement “appropriate organisational and technical measures” to avoid the processing of special categories in training, testing and validation, and to remove such data where identified, or at least to prevent them from influencing outputs or being disclosed if removal would require disproportionate effort. The proposed recital 33 expressly frames this as a derogation from the Article 9(1) prohibition “in order not to disproportionately hinder the development and operation of AI”.
noyb criticises this structure on familiar grounds. It argues that AI is precisely the kind of opaque, large-scale processing that the data protection principles were originally designed to constrain; carving out a new derogation for AI development and operation is therefore backward-looking and threatens to hollow out the very safeguards that were written with such systems in mind. It also points out the loose drafting (“in the context of”, “appropriate measures”, “disproportionate effort”) and the risk that the derogation becomes a general permission for AI developers to retain special categories so long as they can claim to have implemented some minimisation efforts.
Again, this line of attack is understandable, but it presupposes that “AI development” is a unitary activity and that the relevant Charter risk can be captured by the volume and sensitivity of data processed. The actual situation is more complex.
As I argued in that earlier blog post, the label “AI development” currently covers two fundamentally different activities:
Treatment AI, such as credit scoring, hiring and insurance models, trains on genuine systematic datasets: customer or candidate databases that are prototypical “personal data” in the sense of data protection law. Here, database-oriented requirements make structural sense: minimise unnecessary special categories in training sets, remove them where inappropriately included, protect the sensitive training data against disclosure or misuse.
Generative AI training on public web text, by contrast, operates on scattered fragments of already public information to extract statistical patterns. It does not create systematic individual records; the resulting models do not, in normal operation, contain addressable records of specific persons’ sensitive characteristics. The main risks lie not in disclosure of special categories about identified individuals, but in the amplification of biases and stereotypes in generated content.
For the second family, Article 9(5)’s requirements are simply mis-specified. Instructing controllers to “remove” special categories from a corpus of heterogeneous web pages assumes a database-like structure that does not exist: what exactly is to be removed – sentences, paragraphs, entire documents? The “where possible” qualifier acknowledges the impracticality without providing a coherent standard. The language about preventing “disclosure” of special categories presupposes a context in which disclosure means revealing specific individuals’ sensitive data from a controlled database, not producing new text in which health or religion are mentioned in the abstract.
By lumping these structurally different activities together under a single derogation, the Omnibus proposal repeats the conceptual conflation already visible in the personal data definition. At the same time, and more importantly from a decision-oriented viewpoint, it misplaces regulatory attention:
Generative AI training on scattered public text, which normatively should not be treated as personal data processing at all because it never constructs systematic datasets suitable for decisions about individuals, becomes the direct target of impractical, database-oriented requirements.
Treatment AI operation, where structured datasets are used to make consequential decisions about individuals, receives relatively little targeted attention. Article 88c recognises AI operation as a legitimate interest, but provides no mechanism to enforce the relevance requirement of Article 5(1)(c) in this context. Irrelevant characteristics such as music preferences, social media activity or religious affiliation may thus be factored into decisions under the banner of “legitimate interest”, subject only to an individual right to object.
In short, both the Omnibus proposal and much of its criticism, including noyb’s, focus on how much and what kind of data AI systems may process, while leaving largely untouched the question whether the data used in AI-supported decisions are relevant to the decision purpose and how to prevent cross-context re-use of data in ways that generate arbitrary or discriminatory outcomes. That is precisely the gap that a relevance-based reading of Article 5(1)(c) is meant to fill.
2.4 So What Should Happen to the Research and AI Exceptions?
At this point the obvious question is: if both the Commission and noyb are framing the problem in the wrong way, what would a better treatment of research and AI actually look like? It seems clear that one political driver of both the new research definition and the AI derogation in Article 9(2)(k) – and of the attempt to redefine personal data – is the fear that, under the current reading of “processing of personal data”, even web-scale AI training and other large-scale analytics are automatically sucked into the full GDPR regime.
My answer is essentially the same as in my earlier post on the leaked Omnibus draft, but extended to the new definition and AI proposals.
Keep the existing statistical/research framework for the learning phase.
Europe already has a coherent way to deal with large-scale analysis that does not itself feed into decisions about individuals: the combination of
the “compatibility” rule for statistical and scientific purposes in Article 5(1)(b) GDPR; and
the older Council of Europe framework on statistical processing, which allows restrictions of individual rights as long as no decisions or measures concerning individuals are taken on the basis of the statistical results.
AI training belongs here. Training a model on large datasets is, in substance, statistical processing. In this phase there is, by definition, no concrete decision purpose yet, so it makes little sense to apply a relevance test at the level of the model or its inputs. The adequacy and relevance requirement is a constraint on the informational basis of decisions, not on the structure of models in the abstract. The core protected interest is not offended simply because a learning algorithm has “seen” certain variables; it is offended when those variables are actually used as part of a decision pipeline about individuals.
Draw a hard line at the operational, decision-making phase.
Once a trained model is used to support credit decisions, hiring decisions, insurance pricing, fraud detection and so on, we are no longer in the realm of “mere statistics”. We are in the realm of treatment AI, where the adequacy and relevance requirement must bite: every category of data that actually feeds into the decision pipeline must have a rational link to the decision purpose.
This distinction is crucial. A model may internally contain parameters influenced by many features, including features that would be irrelevant if used explicitly at decision time. What matters for data protection is which data are in fact taken into account when deciding about a person – which variables are read, combined and acted upon in the operational system. The legal architecture should therefore be very simple:
learning / training = statistical or research processing, covered by existing rules for such purposes, on the strict condition that the outputs are not used directly to decide about individuals;
operation = decision-making, subject to full data-quality scrutiny, including a serious enforcement of “adequate, relevant and not excessive” under Article 5(1)(c) with respect to the inputs actually used in the decision.
No special AI derogation is needed – and a broad one would be harmful.
If we treat AI training as statistical processing and AI operation as ordinary (but highly consequential) decision-making, there is no need for a new, AI-specific derogation in Article 9(2)(k) or elsewhere. On the contrary, a blanket derogation “for AI development and operation” risks doing exactly what I criticised in my previous post: it invites controllers to invoke “AI” as a magic keyword to justify both phases at once, while never asking the simple question at the operational phase: are the data we actually use in these AI-supported decisions relevant to the decision purpose?
Special categories do not need an AI-only regime either.
For the learning phase, the right question is not “how can we purge every trace of special categories from web-scale training corpora?”, but “how do we make sure that training corpora used for statistical purposes are not casually re-purposed into decision systems where special categories – direct or inferred – would be irrelevant to the decision purpose?”.
For the operation phase, if relevance is properly enforced, the distinction between directly revealed and inferred sensitive data becomes less important: both are ruled out wherever they are “none of your business” in light of the decision purpose. The problem, as I argued in the earlier post, is that we are currently trying to slim down Article 9 without first building the enforcement muscle around relevance at the decision layer.
In other words, instead of inventing AI-specific exceptions and research-specific shortcuts, we should put AI training back where it belongs – under the existing statistical/research framework – and concentrate regulatory energy on AI operation, where the relevance requirement finally has to be taken seriously at the point where decisions are made.
3. Decision Governance and Flow Governance: Re-reading “Processing of Personal Data”
The discussion so far already suggests that data protection operates on two interlocking layers:
decision governance, where the law constrains how data are used to make or support decisions about individuals; and
flow governance, where the law constrains how data can move between contexts, in order to prevent future misuse in irrelevant or discriminatory decisions.
We can now make this structure more explicit and ask how the Omnibus proposals affect each layer.
3.1 Two Complementary Layers of Protection
From a functional perspective, EU data protection law operates on two distinct but interdependent layers.
First, there is direct governance of decisions. Whenever personal data are actually used to make or support decisions about individuals, data protection law requires that the informational basis of those decisions meets the traditional data-quality standard: the data must be adequate and relevant to the purpose of the decision and not excessive. In modern language, there must be a rational link between the data items used and the legitimate decision purpose. This is where the classic “adequate, relevant and not excessive” formula belongs: it is a constraint on how decisions are made, not an abstract call to minimise data.
Second, there is preventive governance of data flows. Purpose limitation, restrictions on further use and onward disclosure, and the construction of “data silos” are not mysterious relics of a bygone era of database regulation. They are ex ante tools designed to prevent future violations of adequacy and relevance. The empirical intuition is simple:
Once data start to flow into new contexts, the probability that they will be re-used in decisions for which they are not relevant rises sharply.
If a dataset collected for one clearly defined purpose can be repurposed, combined and traded without structural constraints, it is only a matter of time before some actor uses it as input for decisions to which the data have no rational connection – credit scoring based on music taste, insurance pricing based on social media activity, hiring decisions based on political affiliation, and so on.
Seen in this light, purpose limitation is not a decorative recital about fairness. It is the central legal mechanism through which the law tries to shape the future graph of data flows: to determine which data can realistically end up feeding which decision systems. The decision layer governs the content of decisions (adequacy and relevance); the flow layer governs the routes through which data can travel into decision contexts in the first place.
Any attempt to redraw the boundary of “personal data” therefore has two effects:
It changes which operations count as “processing” for the purpose of direct decision governance; and
It determines where the preventive flow-governance layer applies at all. Data that fall outside “personal data” are not just exempt from information duties; they are exempt from purpose limitation and onward-transfer constraints, even if they later feed into decision systems.
The risk of the Omnibus proposal on personal data definitions is best understood at this second level.
3.2 How a Relative Personal Data Definition Undermines Flow Governance
The Omnibus proposal does not invent the idea that personal-data status may depend on the means of a particular controller; it codifies the Court’s relative approach, especially as expressed in more recent case law. The core idea is that information counts as personal data for a controller only if that controller has means that are “reasonably likely to be used” to identify the individuals concerned. Pseudonymised datasets held by actors who lack re-identification keys might therefore fall outside the definition for them, even if another actor could identify the same records.
On its face, this move is presented as a technical solution to a real problem: without some relativisation of identifiability, any data that someone could link to a person risks being treated as personal data for everyone. But once we look at the two-layer structure, a different picture emerges.
C
2025-11-19
ページビューランキングTOP10（2025年10月）
ランキング
このサイトのタイトル毎に2025年10月のページビューを調べて、ランキングにしてみた。
1位 仮想マシンにCtrl+Alt+Delを送信する方法
2位 Windowsでファイルを16進数テキストに変換したり、16進数テキストをファイルに変換したりする方法
3位 仮想マシンから抜ける方法
4位 Windowsでbase64エンコード・デコードする方法
5位 certutilコマンドの非公開なオプションを表示する方法
6位 WinPcapのインストール時に聞かれる「Automatically start the WinPcap driver at boot time」で困った場合の対処法
7位 Linuxでbase64エンコード・デコードする方法
8位 wiresharkでTCP制御フラグを指定してパケットを表示する方法（Display Filter）
9位 エクスプローラの検索ボックスから「作成日時」や「更新日時」などで検索する方法
10位 WindowsでハードディスクのPHYSICALDRIVE番号などを調べる方法
このランキングはGoogle Analyticsの情報をもとに作成。
EijiYoshida 2025-11-19 18:31 読者になる
ランキング (235)
2025 / 11
We’re getting things ready
Loading your experience… This won’t take long.
2025-10-12
sora2および動画生成
sora2で10秒動画制作を続けている。30本制限になったけど、テイク数を少なくしつつ量産する感じに持ってきたので、毎日それなりの数を生産できている。
動画としての完成度を上げることはかなりできるようになってきたけど、問題はセリフかなぁ。
元のスクリプトを標準語の会話文として書いて、AIに関西弁をお任せするとイマイチ想定通りいかないことがある。細かく指定すると棒読みになる可能性が結構高い。どちらかと言えば前者の方が自然になる確率が高い。
その一方で、人物の動作とか背景とかは情報を適切に与えるとそれに答えてくれる。ただし漢字は別（笑）。セリフのときもそうだけど、日本語の読みが不自然になることがたまにある。例えば「特定班」のことを「とくていばん」と言うので「特定はん」と書いても「とくていばん」と言ってしまうとか。「怖いよね」というのを「ふいよね」と読んだりもする。ひらがなで指定してても間違えることもある。
そんな試行錯誤の中で、最も情報量が多く、かつ自然になるのは、関西弁の若い女性、というのが見えて来たので（笑）、最近の動画はもっぱらそのパターン。しかし、若い女性、とだけ指定していると服装がパターン化してきてしまうのと、若干の不自然さも出てきてしまうので、正直全く関心が無かった（笑）ファッションをいろいろ勉強しつつ、そのあたりも指定し始めている。使い方を見極めながらやっているので、どうしても同じような装いが続いてしまう（笑）。
本数たまってきたらどっかで連続的に公開していこうかなぁ。なおテーマは情報セキュリティの啓蒙啓発。なので情報量が命なんだよね（笑）。
さすがに長尺ものも欲しいので、他のプラットフォームも試してみようと思うものの、日本語対応がどうなの？というところがあるので、まだ試行中、というところ。
sonodam 2025-10-12 20:16 読者になる
もっと読む
コメントを書く
sora2および動画生成
2025 / 10
この広告は、90日以上更新していないブログに表示しています。
AI版押しかけ教師
AI迷惑電話
小説 (2)
2025 / 8
本当においしいものはバズりません毎日たくさんのブログを読んでいるはてなブログ編集部。なかでも読むのを楽しみにしているテーマのひとつに、おいしいご飯について書かれたブログがあります。特に、自分で作った料理について書かれたものに惹かれます。そんなブログを読者登録していると、購読リストが幸せな感じになってくるんですよね。リストにおいしいご飯が流れてくるだけでもうれしいですし、料理そのものを真似することはできなくても、今の時期においしいものはなにか知ることができます。その季節のおいしいものを思い出すこと…
独自ドメインで運営されている、こだわりブログの新着記事を掲載
こだわりブログ
この特集に載るには？
レッドオニオンとピーナッツのピリ辛サラダ
今回は、食卓にちょっと刺激がほしいときにオススメな簡単レシピをご紹介します。 レッドオニオンに刻んだピーナッツ、コチュジャンベースのドレッシングでパンチを効かせたサラダ。暑い日や、食欲がない時にも食べやすい一品です！ レッドオニオンとピーナッツのピリ…
チーズケー記
はてなブログPro
簡単レシピ
5月16日(金)秩父フライフィールドの河川情報
秩父フライフィールドご予約、注意事項等はこちら ５月１６日(金)秩父フライフィールドの河川情報です。 天候：曇 水量：3.0ｔ 水温：13.3 川色：澄み 朝からまずまずにお天候の日でした。 本日のご入場者はおりませんでした。 ５月１３日(火)の午後５時から浦山ダムの…
秩父漁業協同組合／秩父フライフィールド
はてなブログPro
整える期間
雑談用ストーリー [4] 1180
2025年01月12日(日) [晴れ]
＊ [IRC] dev.ircnet.ne.jp : 6667 / 6697 and 6679 提供開始しました
祝) IRCnetJPとして、2025年01月06日に日本国内にとってもとっても新しいIRCサーバーをリリースしました！！
こちらは、既存のIRCnet（日本国内では通称WIDE IRCといわれていた従来のネットワーク)に接続したものを提供しています。
前回同様、私個人ASのネットワーク上に設置されています。また、実験目的での提供となり、カナダに次ぐ2番目のサーバーとして日本に設置されました。インストールされているIRCdのバージョンは、irc2.12.0-preで、今の所ソースコードはGitHub上ではまだPrivateなものになります。IRCnet2においても数台このバージョンが適用され、動作確認がされているようです。既存のIRCnetとの相互接続性などの試験も十分に行われたことから、最新版のIRCdをインストールされたソフトウェアで、既存のネットワークに接続をして今後も開発をしていく、また、SASL対応の環境においてユーザーが困らないかテスト環境を提供するといった趣旨で設置されています。日本に設置を求められた経緯については、次のセクションで記載しますので、是非ご覧ください。
Server Name: dev.ircnet.ne.jp
IPv4: 103.167.46.70
IPv6: 2001:df6:a680:1014::7000
Port: 6667 / 6697 and 6679
※ irc.ircnet.ne.jp の DNSラウンドロビンには組み込みしておりません
IRCnet server info
IRCnet.com SASL
★ 日本に設置されることとなった経緯:
このサーバーは、12月28日頃、IRCnet全体で決まり、既存のIRCnetに日本からサーバーを提供することとなりました。当初開発サーバーは1台のにでよいという他国の意見がありましたが、日本を好意にしてくれている方々が、日本にも必要だと言ってくれたことから、日本にも準備することとなりました。日本にも設置する必要があると認められた理由は、日本独自の文字コードがあり、ISO-2022-JP という文字コードが利用されています。この文字コードに対応するため、これまで、日本のIRCサーバーは「JP Patch」というのを個別に適用してビルドしていました。
このパッチの適用が無い場合、一部の文字が壊れ、チャネルへのログインやメッセージの送信に失敗します。これは、ISO-2022-JP の文字コード由来の一部の文字に潜在的に 「,」「:」 が含まれており、チャネル名に「:」の文字が含まれると、サーバーは区切り文字が来たと判断し、正しいチャネルを作れない、正しいチャネルにJOINできない、メッセージを送れない、壊れたチャネル名が作成されてしまうと言う問題がありました。故に、日本とリンクされている海外のサーバーとの間でも問題が発生しました。そのため、日本国内に閉じたサーバーに限り正しく文字コード処理ができたという話があります。IRCでは、プロトコル上、チャネルとメッセージの間の区切りに、「:」(コロン)を使用します。
このあたりは、 1999年度WIDE報告書 第17部 IRCの運用技術と活用技術に記載がありますので、興味がある方は是非ご覧ください。私がIRCに関わったのは2002年ごろで、私が参加した当時は、irc2.10.xが動作しており、Pentium3なサーバー上で動いていました。ircdそのものが使用しているメモリは100Mも無かったように記憶しています。90年代から使われているプロトコルで当時は回線も数十kbps～数百キロbpsといった細い回線で使われているほどだったそうです。その当時からの実装のため、IRCは非常に軽量な実装となっています。その後、2.11へとアップグレードし少しずつ重たくなりましたが、現在でも数百MB以内に収まっています。IRCとは、Internet Relay Chatとよばれ、メッセージを中継するだけのとてもとてもシンプルな作りになっています。むしろいまはSSL処理の方が重たいのでは...。IRCの歴史については、
IRC Working Groupが解散されるまでの情報が毎年報告書として掲載されておりますので、こちらも気になる方はご覧ください。歴史の一部が分かるかと思います。
少し脱線てしまったので、話を戻します。今回の irc2.12.0-pre では、この「JP Patch」も取り込まれており、ISO-2022-JP に標準で対応されるようになりました。日本のメンテナが事実上不在となったことから私が、今まで使用されていた日本のパッチを投げることにより、新しいバージョンで取り込んでもらうに至りました。こういった背景から、日本人によるテストが必要なこと、日本で多く使われているIRCクライアントの対応の必要性があると言うことで、日本に設置することとなりました。
世界的に見ても、UTF-8に移行している中、日本は未だに ISO-2022-JP から移行できていませんし、今後も移行されることはおそらく無いでしょう。
私が考える大きな理由は、日本で提供されている日本語のクライアントに大きく依存しているためだと考えられます。また、その日本で慣れ親しんでかつ、一般的に利用されているクライアントの多くは開発が終了もしくは事実上メンテされていないことだと考えられます。では、TLS や SASL に対応し、かつ、ISO-2022-JP に対応した海外製のクライアントはほかにあるかというと、HexChat ぐらいしかみつけれませんでした（ほかにあったら教えてください）。そういう私も、Freenode に接続する際、クライアントがUTF-8に未対応のため、Tiarra を用いて文字コード変換を行い、慣れ親しんだクライアントで接続していたりします。
最近、新たにHexChatというのを試してみましたが、ISO-2022-JP にも対応していますが、NOTICEメッセージがきたら画面表示が壊れてみだれたり、なかなかUIになれれなかったりと、苦戦しており、こりゃー、移行がむりだなぁって気分になってしまいます。
今回、新たに用意したサーバーは、新バージョンでSASL対応の環境となるため、IRCクライアントを開発されてきた皆様、この環境を是非役立てていただければ幸いです。お願い申しあげます(切実)
以下についてはあくまでも超辛口個人的なコメントや愚痴で、気分を害するような記載があるので、注意願います。
----------- ここから -----------
特に日本人の多くはリテラシーが低く、また、多くの人は新しいものや変化、英語クライアントというだけで抵抗があったり、日本語で手取り足取り書いてあっても、手取り足取り教えてもらわないと使うことが出来ない人がおおいという感触を受けました。2000年代当時ゲームをしたい、連絡手段にIRCをつかいたいのにわからない。解説サイトがあっても面倒くさいから教えてくれ、それどころか「パソコンの使い方をおしえてくれという教えてクレくれ君」というのを多々見かけました。自分で調べて学ぼうという人が非常に少ないと感じられました。が故に、変化を嫌う、既存のままずっと使い続けるということもあるでしょう。
当時一番シェアを誇った、CHOCOAがISO-2022-JP以降対応していないこともあるでしょう。今まで困ってないし…というのもあるでしょう。これらから日本のIRCnetではUTF-8に行くのも難しく、クライアントの対応有無が混在することから、未だにIRCnetJPにおいては、ISO-2022-JPが標準になっており、今後もおそらく変わることは無いでしょう。無理矢理SASLに強行移行したら、ISO-2022-JPの問題はなくなり、全員UTF-8にいけると思いますが、おそらくそのタイミングで、IRC bouncersの多くが対応不可、また、新たなIRCクライアントを探して自分にあったクライアントを探し、英語の壁や日本語環境でうまく動くかわからない中、試行錯誤すると行った試練が待ち構えているでしょう。また、SASL認証するために登録をして、となると多くのIRCユーザーが離れてしまうと個人的には感じています。
すでに風前の灯火なので。いっそのこと入れ替えるか切り離して、サーバーを分けるという話も管理者の中で議論がありましたが、分断は崩壊を進めるだけになるので、阻止する方向で調整し、折り合いをつける必要がありました。ということで、日本で使われていたIRCクライアントの開発、アップデートが強く望まれます。正直私も行く当てが無くて困ってんだよー！！！(涙)
----------- ここまで -----------
こういう状況から日本の状況も配慮する必要があり、日本のサーバー直下にぶら下がった開発用JPサーバーが必要になったと言うことです。
私が見える範囲のチャンネルで、CTCP Versionをたたいて、どういうクライアントが多く使われているのか、暇なときに集計してみたいなと、思いました。
参考に、日本発日本クライアントで、UTF-8に対応しているのは、LimeChat2, Cottonぐらいで、CHOCOA, RainMaker, LimeChat1 は未対応です。
SASLに対応しているのは、Mac版のLimeChat2のみとなります。
SSL対応と記載があるのは、Windows版iでは、LimeChat2(SSLv3までかな?)、Cotton（対応バージョン未確認)です。時間があるとき調査します。
なお、数少ないUTF-8対応クライアントの一つである、Limechat2 Windos版について、 LimeChat 2.40の配信についても、つい先日ですが、バイナリの配布が停止してしまいました。
これは、 Vectorのホームページサービスが2024年12月20日終了による配布終了が起因です。。。公式の人にバイナリの復活が出来ないか、また当方でミラーをすることができるので、ミラー出来ないか打診してみようかと思います。（Windows版LimeChatで、SASL対応、TLS対応をしてほしい…）
★ IRCnetの利用状況:
現在、IRCnet全体のユーザー数は、執筆の時点で 17,000 程度です。
国別クライアント数(ユーザー数)においては、Netherlands: 3900, Finland: 3200, 日本: 1500 程度で3番目に利用されている国になります(Open serversのクライアント数除く)。
世界全体でもみても、日本はまだ上位3位に位置しています。まだまだ日本にユーザーがいることから、無視は出来ない存在だと思います（移行できないなら、切り離すという話も出ました…がなんとか阻止しました)
なお、全盛期、IRCnetJP(日本のクライアント数)では、接続数で2万以上ありました...
IRCの利用者人口は年々減っておりますが、また活気を取り戻したいなあ、これほどシンプルで素晴らしいプロトコルはないので、是非とも皆さん、新しい動きがありますので是非戻ってきてください。インターネット中年会や老人会といわれても仕方ありませんが、昔懐かしのチャンネルもまだ残っておりますので、是非もどってきてくださいませ。dh.ircnet.ne.jp を含め、日本のIRCサーバーはまだまだ生き残ります。というか私が引っ張っていきます。
日本の中のオペレーター内にあった蟠りもほぼ解消しております。これから新たなスタートに向けて勢いをつけて行きたいので、是非レガシーな懐かしい世界にもどってきてくださいませ。今回SSLの対応も入っていることから通信路の暗号化も実装が入りました。通信路を暗号化したい方は、是非TLSをご利用くださいませ。
さらに、IRCサーバーを設置させていただけるネットワークも是非募集中です。興味がありましたら国際間で調整しますので、是非お声がけください。
DDoS対策などのノウハウも必要に応じて技術提供いたします。
★ IRCといえば、TELNET クライアントが一番最強でしょ？:
IRCといえば、TELNETで接続出来るぐらい軽量であり、シンプルなプロトコルであると言うことが言えます。では、IRCnet2や、今回リリースした、dev.ircnet.ne.jp など、SASL認証が入ったネットワークではどのように接続するのでしょうか？また、TLSに対応した場合どのように接続するのでしょうか？それはとても簡単なことです。手で接続するときのサンプルを貼り付けておきますので是非ご参考にしてください。なお、SASL Plain認証による例となります。
SASLパスワードである、SASL Plain Base64は以下の方法で作成します。
PLAIN 認証では mechanism が PLAIN、argument が "ユーザID\0ユーザID\0パスワード" という文字列を Base64 エンコードした物になる。
以下はユーザ名 user、パスワード pass の場合の argument 文字列を作成する Perl スクリプト。
$ perl -MMIME::Base64 -e 'print encode_base64("user\0user\0pass");'
dXNlcgB1c2VyAHBhc3M=
(出展： SASL base64によるエンコード演算プログラム)
$ openssl s_client -connect dev.ircnet.ne.jp:6697
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = E5
verify return:1
depth=0 CN = dev.ircnet.ne.jp
verify return:1
---
Certificate chain
0 s:CN = dev.ircnet.ne.jp
i:C = US, O = Let's Encrypt, CN = E5
1 s:C = US, O = Let's Encrypt, CN = E5
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDgDCCAwagAwIBAgISA/quCPeNgRf1slSZe33yZY9FMAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
NTAeFw0yNTAxMDQyMjU4MjhaFw0yNTA0MDQyMjU4MjdaMBsxGTAXBgNVBAMTEGRl
di5pcmNuZXQubmUuanAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASBXLHJvou7
6Y94f1lt+/bcXPpn6VGAE7GP515BXHC0rdld42PRzf3IsG9ZxXBRKuwRduwtBqRJ
51/TWjfL+oCfo4ICETCCAg0wDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSZloGZjyx5
iX0fQ1jpuQ1ogjXEVjAfBgNVHSMEGDAWgBSfK1/PPCFPnQS37SssxMZwi9LXDTBV
BggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9lNS5vLmxlbmNyLm9y
ZzAiBggrBgEFBQcwAoYWaHR0cDovL2U1LmkubGVuY3Iub3JnLzAbBgNVHREEFDAS
ghBkZXYuaXJjbmV0Lm5lLmpwMBMGA1UdIAQMMAowCAYGZ4EMAQIBMIIBAwYKKwYB
BAHWeQIEAgSB9ASB8QDvAHUAzPsPaoVxCWX+lZtTzumyfCLphVwNl422qX5UwP5M
DbAAAAGUM8AlswAABAMARjBEAiBg5IYH82Y0AJUas19n9+8ExDWRPwayYtT9gfvA
MKWNbwIgXyPRcyIUDvSefA5RlJw1CfrMGOq+PJyMVRm5zcmW3OkAdgDgkrP8DB3I
52g2H95huZZNClJ4GYpy1nLEsE2lbW9UBAAAAZQzwCXNAAAEAwBHMEUCIHZH1YFd
kKnBJtWC7/BkHG55Cr/hoCmjDqrUz6Eot3dmAiEAqkNhkBR9A21oeHhyZ/1AilJy
LzkovRd+OHWN4MQI0OYwCgYIKoZIzj0EAwMDaAAwZQIwXDduNyxWjoLYrZV0nLl0
fnwPUTIJ2VXzTLxR3iWXoU1nrFXgX33P5mS9+M7SkoT5AjEA3aMK1Z+MmU5q0ALV
J2Xf1NAP4Y2KqoVQydVrqoQdncsZggwWpi44e6SJwo5KJCRm
-----END CERTIFICATE-----
subject=CN = dev.ircnet.ne.jp
issuer=C = US, O = Let's Encrypt, CN = E5
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2395 bytes and written 394 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 46A60731DA3425BF57E81CC83E8ABD79E91DD0D2218CD7326AF6DE134C5646F5
Session-ID-ctx:
Resumption PSK: E0C3ECD28DA503688DAB2327F18A5E9EC7B7C7C3A07B2FA417A73F5780653E303A15D344FD1CE482B403D63910C3CD90
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 6b f1 a1 2c e9 6f 56 63-ce 00 9b 88 1f 16 c6 a2 k..,.oVc........
0010 - 52 b5 47 b0 35 44 cc 3b-de 32 57 59 08 92 2d f8 R.G.5D.;.2WY..-.
0020 - 0f b0 da da 9c 5c 1e 73-56 c2 f1 c2 f4 be 35 46 .....\.sV.....5F
0030 - 11 dd b0 3d 64 c9 1c 0c-85 6c ec ba f3 20 05 08 ...=d....l... ..
0040 - 6d 42 e6 65 a3 66 28 73-5c 23 ac da e0 52 1e 39 mB.e.f(s\#...R.9
0050 - 57 3a db 82 81 06 d4 b8-85 ad 50 cd 42 c8 d9 94 W:........P.B...
0060 - d6 89 04 8f 24 9c 91 20-de 47 e6 4b 14 dd b8 a1 ....$.. .G.K....
0070 - 23 bc 26 76 99 39 0f 99-d6 70 aa ab dd 77 aa f9 #.&v.9...p...w..
0080 - 09 1d 9a ef 8d 1b 99 db-9d 8f 3a 97 89 d6 db ad ..........:.....
0090 - 62 07 27 30 71 4d b3 ae-19 e7 8a 74 07 8a b1 d8 b.'0qM.....t....
00a0 - 10 18 e0 53 27 68 5d 75-80 01 c6 a7 c0 d8 59 79 ...S'h]u......Yy
00b0 - 9a 04 c8 a9 af fe 9f f7-32 7d 40 68 55 7c 28 f0 ........2}@hU|(.
00c0 - 67 5f 6a b9 0b 95 8c 0f-3c 14 41 ee 3c ac 6f 20 g_j.....<.A.<.o
00d0 - d9 74 1d d1 5c ed b7 41-18 01 6a 7b 1d 4f c4 87 .t..\..A..j{.O..
00e0 - 04 52 f0 3f 36 6f c8 68-ca bc a3 72 04 80 36 11 .R.?6o.h...r..6.
Start Time: 1736755741
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: A06D178561B14439775672D22209A1E52A16D6A86246CDD5C4D3C4674A32F950
Session-ID-ctx:
Resumption PSK: C740D49409010B867FC4E8583F8773FE550E1BF1FBA222B54C5E031F9D7458FD9F0D5C9A94519745B0D4E527E9925838
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 6b f1 a1 2c e9 6f 56 63-ce 00 9b 88 1f 16 c6 a2 k..,.oVc........
0010 - d6 78 1a 4c cd 24 d9 2c-a3 ff 90 db 7e ec 46 56 .x.L.$.,....~.FV
0020 - 27 7c b3 84 ee 0b 08 de-e1 3c 8b 7a 52 24 97 89 '|.......<.zR$..
0030 - f9 70 a7 a3 1d b0 2e 88-62 b5 83 db 33 88 8a fc .p......b...3...
0040 - ac ef de 9b ba fa c6 d4-42 26 1c c6 e9 c5 e0 78 ........B&.....x
0050 - d8 18 f5 8a 29 c8 bf 83-10 bd e1 e0 4b f2 bb e0 ....).......K...
0060 - 87 68 90 7b 7b fc 3a 07-83 f5 fb 5d 7e 4e 5b 64 .h.{{.:....]~N[d
0070 - 11 4a 0d d8 a0 8c 33 d8-9b d8 34 c0 6d e0 b4 77 .J....3...4.m..w
0080 - 7d 22 42 41 dd 1f 25 3a-29 11 53 34 d7 57 cb 97 }"BA..%:).S4.W..
0090 - 3c a3 e4 ee 11 8b 81 1d-29 ef a3 a3 42 3b 69 60 <.......)...B;i`
00a0 - 86 12 22 f0 65 7b 1a 39-f7 f8 b7 5e db 62 0e 21 ..".e{.9...^.b.!
00b0 - ee dd 68 53 f0 0f cc 20-71 0c e9 04 8a c8 ba e8 ..hS... q.......
00c0 - 4a 78 24 a3 c7 91 55 a2-16 44 c0 ea b5 e1 70 4f Jx$...U..D....pO
00d0 - 43 3b 5b 9b a6 b9 22 17-69 de 44 14 3a 5c 08 71 C;[...".i.D.:\.q
00e0 - 4c 73 e7 9d 5e 95 48 62-32 a0 d8 1e 72 85 0b 12 Ls..^.Hb2...r...
Start Time: 1736755741
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
:dev.ircnet.ne.jp 020 * :Please wait while we process your connection.
CAP LS 302
:dev.ircnet.ne.jp CAP * LS :extended-join ircnet.com/extended-join multi-prefix sasl
NICK tomocha_dev4
USER tomocha 0 * :tomocha
CAP REQ :extended-join multi-prefix sasl
:dev.ircnet.ne.jp CAP tomocha_dev4 ACK :extended-join multi-prefix sasl
AUTHENTICATE PLAIN
AUTHENTICATE +
AUTHENTICATE <encode_base64("user\0user\0pass");>
:dev.ircnet.ne.jp 900 tomocha_dev4 tomocha_dev4!tomocha@tomocha.users.ircnet.com tomocha :You are now logged in as tomocha.
:dev.ircnet.ne.jp 903 tomocha_dev4 :SASL authentication successful
CAP END
:dev.ircnet.ne.jp 001 tomocha_dev4 :Welcome to the Internet Relay Network tomocha_dev4!~tomocha@tomocha.users.ircnet.com
:dev.ircnet.ne.jp 002 tomocha_dev4 :Your host is dev.ircnet.ne.jp, running version 2.12.0-pre(3a7b5ff)
:dev.ircnet.ne.jp 003 tomocha_dev4 :This server was created Sun Jan 5 2025 at 07:55:02 JST
:dev.ircnet.ne.jp 004 tomocha_dev4 dev.ircnet.ne.jp 2.12.0-pre(3a7b5ff) aoOirw abeiIklmnoOpqrRstv
:dev.ircnet.ne.jp 005 tomocha_dev4 RFC2812 PREFIX=(ov)@+ CHANTYPES=#&!+ MODES=3 CHANLIMIT=#&!+:42 NICKLEN=15 TOPICLEN=255 KICKLEN=255 MAXLIST=beIR:64 CHANNELLEN=50 IDCHAN=!:5 CHANMODES=beIR,k,l,imnpstaqr :are supported by this server
:dev.ircnet.ne.jp 005 tomocha_dev4 PENALTY FNC WHOX EXCEPTS=e INVEX=I CASEMAPPING=ascii NETWORK=IRCnet :are supported by this server
:dev.ircnet.ne.jp 042 tomocha_dev4 392DAAAQK :your unique ID
:dev.ircnet.ne.jp 251 tomocha_dev4 :There are 17352 users and 2 services on 32 servers
:dev.ircnet.ne.jp 252 tomocha_dev4 75 :operators online
:dev.ircnet.ne.jp 254 tomocha_dev4 10145 :channels formed
:dev.ircnet.ne.jp 255 tomocha_dev4 :I have 35 users, 1 services and 1 servers
:dev.ircnet.ne.jp 265 tomocha_dev4 35 37 :Current local users 35, max 37
:dev.ircnet.ne.jp 266 tomocha_dev4 17352 19763 :Current global users 17352, max 19763
:dev.ircnet.ne.jp 375 tomocha_dev4 :- dev.ircnet.ne.jp Message of the Day -
:dev.ircnet.ne.jp 372 tomocha_dev4 :- 5/1/2025 20:00
:dev.ircnet.ne.jp 372 tomocha_dev4 :- *************************************************************
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Server: dev.ircnet.ne.jp
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Location: Tokyo, Japan
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Admins: tomocha
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Disclaimer
:dev.ircnet.ne.jp 372 tomocha_dev4 :- This is an irc 2.12.0 development server. To connect you
:dev.ircnet.ne.jp 372 tomocha_dev4 :- need to authenticate with SASL: https://sasl.ircnet.com
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- This server is running for AS45679 experimental purposes
:dev.ircnet.ne.jp 372 tomocha_dev4 :- and stability is not assured.
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- *************************************************************
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Website: https://www.ircnet.com
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Server/Channel list: https://www.ircnet.info
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Webchat: https://ircnet.chat
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- *************************************************************
:dev.ircnet.ne.jp 376 tomocha_dev4 :End of MOTD command.
:dev.ircnet.ne.jp NOTICE tomocha_dev4 :Your connection is secure (SSL/TLS).
:dev.ircnet.ne.jp NOTICE tomocha_dev4 :Due to an administrative decision, your connection is cloaked.
JOIN #arege
:tomocha_dev4!~tomocha@tomocha.users.ircnet.com JOIN #arege * :tomocha
:dev.ircnet.ne.jp 353 tomocha_dev4 @ #arege :tomocha_dev4 ...(snip)
:dev.ircnet.ne.jp 366 tomocha_dev4 #arege :End of NAMES list.
quit
ERROR :Closing Link: tomocha_dev4[~tomocha@tomocha.users.ircnet.com] ("")
closed
★ 参考リンク:
IRCnet.com
ircnet.info
IRCnet-JP 情報提供サイト
WikiPedia: Internet Relay Chat
WikiPedia: Wikipedia:チャット
IRCv3 Specifications
RFC7194 : Default Port for Internet Relay Chat (IRC) via TLS/SSL
Liber.chat - Using SASL
IRCv3 - IRCv3.2 SASL Authentication
SASL base64によるエンコード演算プログラム
[ コメントを読む(0) | コメントする ]
＊ [IRC] IRCNET2.com の ircnet2.ircnet.ne.jp のサーバーをリリースしました
ずいぶん前のネタになりますが、日本のIRC管理者は、Tomocha だって海外から宣言されて、 IRCnet2という網で、新しい実装をした実験網だから日本でも提供してほしいといわれたので、提供することにしました。
サーバー名は、 ircnet2.ircnet.ne.jpというホスト名で提供することになりました。本文にも記載しているとおり、個人AS、個人所有の設備で運用しているものであり、実験・研究・自ASのネットワーク品質のモニタリングのため、品質は保証いたしませんが、最大限の安定稼働を出来るよう努めさせていただく予定です。
サーバー情報
Server Name: ircnet2.ircnet.ne.jp
IPv4: 103.167.46.69
IPv6: 2001:df6:a680:1014::6900
Port: 6667 / 6697 and 6679
IRCNET2
IRCNET2 - What's SASL and how it works?
IRCNET2 - Server List
IRCnet2では、構築当初 irc2.11.3 (2024/12/13 release)のRCバージョンで動いており、ircnet2用(後にirc2.12.0で取り込まれる内容)のパッチ適用し、SASL認証、TLS接続などの実装が入っております。
基本的には、既存のIRCnetとは独立していますが、ゆくゆくは既存のIRCnet網と統合するか、廃止するかという前提での運用のようです。
そんなわけで、日本時間の2024年8月28日夜23時頃メッセージが来て、0時頃にはサーバの準備が始まり、海外との国際リンクの構築を行い、朝の5時にはリリースしているという頭のおかしい状況が出来ました(祝）
提供に至った経緯としては、自ASは実験・検証での使用を主としており、サービスを設置していないこと、品質のモニタリングをするにあたってもサービスが無いため正確なモニタリングがしにくいこと、IRCというプロトコルの特性上、常時TCPコネクションを張り続けるといいとてもインフラを管理する側からすれば嫌な実装で、メンテナンスしにくい実装です。これらの特徴から、ネットワークの安定性が一目瞭然でわかりやすく、ネットワークの品質モニタリングもかねて提供するに至りました。また、irc2.11.2より、14年間開発が停止しており、政権交代ならず世代交代、枯れたプロトコルから今時の実装として、認証・認可、またSSL/TLS対応などを行っています。このあたりは、 IRCv3 Specifications準拠に伴う内容となります。このサーバーは、世界と接続された日本国内にある唯一オープンなサーバーであり、実験的リソースの供給という公共・社会性から判断しました。ここからは完全な個人的な思いなのですが、WIDE ProjectのIRC Working Groupから始まり、20年以上日本のサーバーの管理者の一人として運用に関わっています。また、当時研究してきたものが廃れて日本または世界から消えていくのは忍びなかったことなどがあります。そんななか20年以上面倒を見ていたところ、海外より相談があったことから、じゃあ、日本でももう一回ちゃんとやるか！って気持ちになり、取り組み始めたのが現在です。これらの成果は今後、日本のIRCnetに生かされるはずで、それにより、20年以上生活した憩いの場を失うのを阻止しようという思いもあります。でも人口は減っていく悲しさ...
★ 接続方法:
IRCnet2に接続するには、最初に アカウント登録をする必要があります。
その上で、SASL対応のクライアントで、ircnet2.ircnet.ne.jp を設定すればよいでしょう。また、既存の CHOHOAはSSLそのものが未対応、Windows版の LimeChatでは、TLS1.2以降に未対応のため、IRCサーバーには接続出来ません。また、SASL認証にも対応していないため、事実上HexChatかmIRCあたりになります。
対応クライアント一覧は、 IRCnet2 How to configure SASLを参照の上接続ください。
Mac版のLimeChatはGitHubに公開されているソースコードベースに、SASL Plain認証のみ使用可能となっています。
なお、 サーバー一覧にサーバーリストもあり、実際に接続されているサーバー一覧、ユーザー数、IRCdのVersion、設置されている国などの一覧表があります。
そのほか、 Tiarraについては、PerlのSSLライブラリを使用している
(参照： Tiarra over SSL without stone) ことから、そのままSSL/TLSで対応出来ますが、今後、実装が変わっていく可能性が高いことから、SASLの実装をしてほしいとご本人に聞いてみたところ、SASL対応するコードを追加する予定はなさそうなので、雄志によるパッチのリクエストを私は希望します。 :)
なお、 Tiarra - ChangeLogや、 doc-srcをみても、SSL対応の記載が無く、 tiarra/main/Tiarra/Socket/Connect.pm
を見たところ、以下の記載があり、commit logで確認することが出来ました。
* check ssl module before connect.
* fix bug tiarra entering busy-loop after verification error.
* handle ssl-configuration failure.
現時点では、IRC Bouncers で、SASL対応しているクライアントは見つけれておりませんので、ご存じの方は教えてください。
★ ネットワーク運用のこぼれ話:
運用開始して数日後、10Gbpsを超えるDDoSを受けているらしいです。
直接流れ込むトラフィックもあり、モニタリングしていると、数時間毎に5分間のDDoSを観測されるなどとてもとても楽しい状況を楽しんでおります。
この自宅にある個人ASは10Gbpsの専用線を含むアップリングが複数本あり、そのほか、1Gbpsになりますが、NGN閉域接続のよる回線などがあります。ルータについては、Cisco ASR や 各種ソフトウェアルータなど複合的に組み合わせ、冗長化構成を取っており、リージョン間でも同様の仕組みを構築しています。その辺の普通の一般的なAS運用と同じレベルでの運用を目指しておりますが、電気代高騰に伴うコスト増のため、半分はハードウェア、半分はソフトウェア(仮想化基板上)で実装していました。
その中で、10Gbpsを超えるDDoSが流入し、一部のパケットが仮想化基盤へ流れ込み、その結果ppsに負けてしまい、vDS含む仮装基板が破綻しました。帯域では無くパケットの数で負けました。なお、ハードウェアで構成されたネットワーク部分については、余裕でした。
自宅の構成は、インターフェースはすべて10G以上で構成されているので帯域的には戦えるのですが、それ以前のボトルネックにぶち当たる羽目に。元々、普段トラフィックがないので通常は仮想化することによる集約メリットがあるのですが、DDoSが流れ込むと仮装基板が破綻することから、一部のサービスを仮想化するという事を辞め、機能ごとに、オンプレに回帰する方向に向かっています。
もちろんナレッジをためたいのは山々ですが、DDoSを耐えるためのオーバースペックともいえる最新CPUの搭載したサーバーを何台も用意しチャレンジする、とか、SR-IOVやNICをまるまるVMに渡すなど、いくつかの方法は考えられるのですが、結局、その分システム全体が大きく、また複雑になります。自宅で運用するには金銭面だけではなく、運用コストも含めると、全くもってコストメリットがでない状態になります。また、DDoSに耐えれる仮想化基盤を作るのが目的では無く、リソースの集約のための仮想化基盤のため、リソースの集約が出来ないような代物については、オンプレでホストごと潰すというのが一番手っ取り早くてコストが安いものです。ネットワーク機器の仮想化は日常的にDDoSが来る事を想定すると向かないということが頭ではわかっていたものの、ここまで性能が出ないのかというのを目の当たりにしました。また、ホストの組み合わせ方によっては巻き添えを喰らうvmもでてくることから、結局組み合わせなどを考えて最適な配置をする必要が出てきて、結果物理サーバーの台数が必要になってしまいます。
また、トランジットを受けている一部の上位でも悲鳴が上がり、協議の結果、BGP flowspecによるネットワーク保護、RTBH、特定IPに対して、事前フィルタを上位で設定するなど、いくつか調整を行い、DDoSパケットを落とす仕組みが入っています。
そのほか、IRCでは、C&Cサーバー *1 などが設置され悪用されることも多いと言われていますが、IRCnetにはそういうのが居ないことを願いたいものです。今回、そのためユーザーを認証するという概念が取り込まれています。セキュリティー系の人からすれば、IRCってC&Cサーバーの温床でしょ？っていう方も居るぐらいIRC=C&Cのプラットフォームと思われているケースもあります。
ガチ運用できて落としても怒られないASって最高ですね。面白い。商用でこういうサービスをぶち込む勇気のある事業者がほとんどおらず、WIDE ProjectがIRCの提供を終了するとなったとき、引取先や協力してくれる事業者やASが見つからなかったのもそういう背景がありました。だったら、おうちで持ってみたらどうか？って思い始め、さらに品質モニタリングもしちまえっていうのが今回の私のテーマです。とりあえず、対外線などを100Gになればとりあえず頑張れるのですがなかなか頑張れる気がしませんね。
そんなわけで、省電力で10G喰えてソフトウェアルータに向く箱、IRCサーバーに向く箱などを探していたというのもあり、先日の 2024/05/06 MINISFORM MS-01検証などをやってたというのが実は関連していたりしました。個人的には見送りましたけど....
面白そうだからオンプレだけじゃなくて、クラウドやVPSにおいてどうなるかもためしてみたいなぁ。
*1:
C&Cサーバー：
「コマンド&コントロール（C&C）サーバ」とは、ボットネットや感染コンピュータのネットワークに対し、不正なコマンドを遠隔で頻繁に送信するために利用されるサーバのこと。この用語は、もともと、司令官が目的遂行のために、部隊へ直接指令（com >
mand）を送り、制御（control）するといった軍事的な概念から派生したものである。C&Cサーバは、「Internet Relay Chat（IRC）」や>正規のWebサイト、ダイナミックDNSサービスを利用することで知られている。
(出展: TrendMicro: コマンド&コントロール（C&C）サーバ)
[ コメントを読む(0) | コメントする ]
Diary for 3 day(s)
ブログを開設した年のグループに入りましょう
はてなブログには、同じ話題でつながる「グループ」があります。まずはブログを開設した年のグループに入りましょう。同時期に始めたブログとつながることができます。
「2025年開設ブログ」のグループ
「字幕職人の朝は早い……」にコメントを書く
2024
northADの日記
読者になる
ripjyr's blog
読者になる
読者になる
おきらくにっき
読者になる
登 大遊 (Daiyuu Nobori) の個人日記
読者になる
うさぎ文学日記
読者になる
情報てとりす。
読者になる
R'lyeh ノ記
読者になる
TOTOROの自堕落 日記
読者になる
蠅蠅蚊蚊蚊金鳥ル。
読者になる
teracc’s blog
読者になる
motonの日記
読者になる
9DOの日記
読者になる
たぬきん貧乏日記 〜No Worry, No Hurry. Eat Curry!〜
読者になる
luminのコードメモ
読者になる
SecuDiary
読者になる
Luffyのメモ
読者になる
ヴァルカンの気まぐれ日記
読者になる
CVSSとその限界
Vuls祭り#8資料 2023-09-15
CSPを無意味にする残念なServiceWorker
Shibuya.XSS techtalk #12資料 2023年7月25日
Bluesky
hasegawa.bsky.social
ただただし t@tdtds.jp プログラマ、Webアクセス解析士を経て、現在はセキュリティエンジニア兼エンジニアリングマネージャ。
学生時代からフリーソフトウェア開発に関わりはじめ、かれこれ30年。RubyではWebアプリケーションを中心に開発。tDiaryプロジェクト創始者。
妻1人、猫2匹。
▼ ▶
2021
2021 / 12
2021 / 9
▼ ▶
2020
2020 / 12
2020 / 5
▼ ▶
2019
2019 / 12
2019 / 7
2019 / 6
▼ ▶
2018
2018 / 12
2018 / 11
2018 / 10
2018 / 8
2018 / 3
2018 / 1
▼ ▶
2017
2017 / 12
2017 / 10
2017 / 5
2017 / 3
2017 / 2
2017 / 1
▼ ▶
2016
2016 / 12
2016 / 8
2016 / 7
2016 / 6
2016 / 4
2016 / 2
2016 / 1
▼ ▶
2015
2015 / 12
2015 / 10
2015 / 9
2015 / 8
2015 / 6
2015 / 5
2015 / 4
2015 / 3
2015 / 2
2015 / 1
▼ ▶
2014
2014 / 12
2014 / 7
2014 / 5
2014 / 4
▼ ▶
2013
2013 / 12
2013 / 9
2013 / 6
2013 / 5
2013 / 4
2013 / 3
2013 / 2
2013 / 1
▼ ▶
2012
2012 / 12
2012 / 11
2012 / 10
2012 / 9
2012 / 8
2012 / 7
2012 / 6
2012 / 5
2012 / 4
2012 / 3
2012 / 2
2012 / 1
▼ ▶
2011
2011 / 12
2011 / 11
2011 / 10
2011 / 9
2011 / 8
2011 / 7
2011 / 6
2011 / 5
2011 / 4
2011 / 3
2011 / 2
2011 / 1
▼ ▶
2010
2010 / 12
2010 / 11
2010 / 10
2010 / 9
2010 / 7
2010 / 2
2010 / 1
▼ ▶
▼ ▶
▼ ▶
2007
2007 / 12
2007 / 11
2007 / 10
2007 / 9
2007 / 8
2007 / 7
2007 / 6
2007 / 5
2007 / 4
2007 / 3
2007 / 2
2007 / 1
▼ ▶
2006
2006 / 12
2006 / 11
2006 / 10
2006 / 9
2006 / 8
2006 / 7
2006 / 6
2006 / 5
2006 / 4
2006 / 3
2006 / 2
2006 / 1
▼ ▶
2005
2005 / 12
2005 / 11
2005 / 10
2005 / 9
2005 / 8
2005 / 7
2005 / 6
2005 / 5
2005 / 4
2005 / 3
2005 / 2
2005 / 1
▼ ▶
2004
2004 / 12
2004 / 11
2004 / 10
2004 / 9
2004 / 8
2004 / 7
2004 / 6
2004 / 5
2004 / 4
2004 / 3
▼ ▶
2003
2003 / 10
▼ ▶
1000
1000 / 1
▼ ▶
0
0 / 1
▼ ▶
2022
2022 / 1
▼ ▶
2021
2021 / 7
2021 / 6
▼ ▶
2020
2020 / 6
2020 / 5
2020 / 4
2020 / 3
2020 / 2
▼ ▶
2019
2019 / 2
▼ ▶
2017
2017 / 7
2017 / 5
▼ ▶
2016
2016 / 10
2016 / 8
2016 / 7
2016 / 4
2016 / 3
2016 / 2
▼ ▶
2015
2015 / 10
2015 / 8
2015 / 4
2015 / 2
▼ ▶
2014
2014 / 8
2014 / 6
2014 / 3
▼ ▶
2013
2013 / 12
2013 / 9
2013 / 8
2013 / 7
2013 / 6
2013 / 5
▼ ▶
2012
2012 / 1
▼ ▶
2011
2011 / 12
2011 / 11
2011 / 9
2011 / 8
2011 / 7
2011 / 6
2011 / 5
2011 / 4
2011 / 3
▼ ▶
2010
2010 / 8
2010 / 7
2010 / 6
2010 / 5
2010 / 4
▼ ▶
2009
2009 / 12
2009 / 11
2009 / 10
2009 / 9
2009 / 8
2009 / 7
2009 / 6
2009 / 5
2009 / 4
2009 / 3
2009 / 2
2009 / 1
▼ ▶
2008
2008 / 12
2008 / 11
2008 / 10
2008 / 9
2008 / 8
2008 / 7
2008 / 6
2008 / 5
2008 / 4
2008 / 3
2008 / 2
2008 / 1
▼ ▶
2007
2007 / 12
2007 / 11
2007 / 10
2007 / 9
2007 / 8
2007 / 7
2007 / 6
2007 / 5
2007 / 4
2007 / 3
2007 / 2
2007 / 1
▼ ▶
2006
2006 / 12
2006 / 11
2006 / 10
2006 / 9
2006 / 8
2006 / 7
2006 / 6
2006 / 5
2006 / 4
2006 / 3
2006 / 2
2006 / 1
▼ ▶
2005
2005 / 12
2005 / 11
2005 / 10
2005 / 9
2005 / 8
2005 / 7
2005 / 6
2005 / 5
2005 / 4
2005 / 3
2005 / 2
2005 / 1
▼ ▶
2004
2004 / 12
2004 / 11
2004 / 10
2004 / 9
2004 / 8
2004 / 7
2004 / 6
2004 / 5
2004 / 4
2004 / 3
2004 / 2
2004 / 1
▼ ▶
2003
2003 / 12
2003 / 11
2003 / 10
2003 / 9
▼ ▶
0
0 / 1
▼ ▶
2020
2020 / 6
▼ ▶
2018
2018 / 12
▼ ▶
2017
2017 / 12
2017 / 3
2017 / 2
2017 / 1
▼ ▶
2016
2016 / 12
2016 / 11
2016 / 1
▼ ▶
2014
2014 / 6
▼ ▶
2013
2013 / 12
2013 / 1
▼ ▶
2012
2012 / 12
2012 / 10
2012 / 9
2012 / 6
2012 / 5
2012 / 1
▼ ▶
2011
2011 / 12
2011 / 8
2011 / 6
2011 / 5
2011 / 4
2011 / 3
2011 / 2
2011 / 1
▼ ▶
2010
2010 / 12
2010 / 11
2010 / 10
2010 / 9
2010 / 8
2010 / 7
2010 / 6
2010 / 5
2010 / 4
2010 / 3
2010 / 2
2010 / 1
▼ ▶
2009
2009 / 12
2009 / 11
2009 / 10
2009 / 9
2009 / 8
2009 / 7
2009 / 6
2009 / 5
2009 / 4
2009 / 3
2009 / 2
2009 / 1
▼ ▶
2008
2008 / 12
2008 / 11
2008 / 10
2008 / 9
2008 / 8
2008 / 7
2008 / 6
2008 / 5
2008 / 4
2008 / 3
▼ ▶
2007
2007 / 10
2007 / 9
2007 / 8
2007 / 7
2007 / 6
2007 / 5
2007 / 4
2007 / 3
2007 / 2
2007 / 1
▼ ▶
2006
2006 / 12
2006 / 11
2006 / 10
2006 / 9
2006 / 6
2006 / 5
2006 / 1
▼ ▶
2005
2005 / 12
2005 / 10
2005 / 9
2005 / 8
2005 / 7
2005 / 6
2005 / 5
2005 / 4
2005 / 3
2005 / 2
higaitaisaku.com
This domain not actively for sale, but will consider reasonable offers
ACCEPTING OFFERS
Domain owner will consider reasonable offers
Make Offer
Contact Domain Owner
For more information about this domain
Contact Owner More Details
Why purchase this domain with Epik?
Secure & Instant Domain Delivery
The domain you are buying is delivered upon purchase.
Buyer Protection Program
Buy with confidence. Your purchase is secured by Epik.
All-inclusive.
No-nonsense
Free WHOIS privacy, free forwarding, 24/7 Support are all standard.
We accept
Share it
Facebook
Twitter
LinkedIn
Currency:
Language:
English
Spanish
Portuguese
French
German
Chinese
Russian
Tagalog
Thai
Italian
Turkey
Epik ® is a registered trademark of Epik Inc. Copyright © 2022 by Epik Inc. All rights reserved.
Whois Privacy services provided by Anonymize.com
HOME
LOG
Wiki
QX UG
BAD's
GEM's
HOME
annex1
TORON
SBM
BAD's
SITE's
HOME
annex2
BeChic
REVIEW
BAD's
BBS
お笑いパソコン日誌
Take You To The Pilot
Text by Terry Minamino
Music by IKO-IKO
不動産情報
2007/12/9 PM 1:05
＠ 今日の今年の回顧・2007年はチョー豊饒
まだ三週間残ってるつーのに、早漏気味の回顧である。若いときはチロー気味で顰蹙をかったこともあるくらいだが、年々ソーロー傾向が高まりつつある。これも老化現象の一つであろうか。なんの話だモゴモゴ。
さて諸君。今年はここ十年間でも、いや、ひょっとすると歴史上もっとも良い一年であったかもしれない。素晴らしいことにショートパンツが若い女性の間で流行ったんである。それも、ケチくさく詐欺まがいのキュロットもどきのショートパンツではなく、写真のようにきっぱりと潔いどうだこのヤロー的ショートパンツ、古いいい方だとホットパンツ、が流行ったのである。すんばらしいではないか。街にはショートパンツ姿の女のがわしわしいたし、テレビでもがんがんタレントが見せてくれた。ちなみに上の写真は私の脚フェチ＆ホットパンツ好き＆ピンヒール好みを察知したキャバクラ嬢が、そんなに好きならと同伴の時に着てくれた時のものである。いやはや眼福頓服ぷっぷくぷう、カミサマありがとー。ま、ちょっと高くついたけどな。うはは。
Permalink | BBS
不動産情報
2007/11/26 PM 9:49
＠ 今日のヨタ・ソフトバンクの広告に隠された暗喩を読む
ソフトバンクモバイルのテレビコマーシャルには二つの路線がある。スターがケータイで話しながら歩くだけの古典的なイメージアップ戦略ものと、謎の家族が謎の生活をしているという（まあこっちも新奇とはいいがたいのだけど）ものの二つだ。それについて、私はある発見をしたのでここに記しておく。なお、これは半年ぐらい抱えてるネタなので、すでにどなたかが同じ話を書かれている可能性も高いが、もしもカブってたらゴメンね。あと、あくまでネタなんで、そこんところもよろしく。
先日、スターが歩く路線の方に、キティちゃんが登場した。それを見た私は、次はミッキーマウスが出てくると思った。理由は二つある。一つは、ディズニーがソフトバンクから回線を借りて日本のケータイ業界に進出してくるというニュースがあったからだ。ただよく考えるまでもなく、その場合ディズニーは自分でミッキーを使いたいだろうから、この読みは浅すぎた。実際、登場したのはディズニーキャラではなくスヌーピーだったわけだ。
さて、もう一つの理由が本題である。私はミッキーだと考えたのと同時に、男のアニメキャラが使われると考えた。まあこっちは誰にでも予想がついただろう。ただし、絶対日本のアニメからは使われないと考えた方はいるだろうか？ それが予想できたのは、もう一つの路線の方にヒントがあったからだ。
考えても見て欲しい。変な家族篇に登場する男は、犬と黒人とイルカである。一方、女はすべて日本人なのだ（実は違うというオチはナシという方向で）。やや微妙な話になってきたので書き方には注意が必要であろうが、そういうことなんである。だからアメリカ製の男のキャラクタが使われたのである。間違いない（死語）。
ところでこれはいったいなんの暗喩であるのか。あえてオチまでは書かないことにしよう。各自自分で考えてくだされ。ただ、下手するとソフトバンク側は誰もこの事実に気がついてないという恐れもある。その場合は代理店とかディレクターとか、そこらあたりに悪意を持った犯人がいることになるが。みゅう。
Permalink | BBS
以前の記事へ
2021-12-31
2021/5/4 エベレスティング
読者になる
http:
読者になる
2006|01|03|
2015|09|10|11|
2016|01|04|
2021/04/05 島根県松江市における大規模火災にかかる災害救助法の適用について
はてなブログ アカデミー
法人プラン
意外かもしれないが、初デスクトップ。今回はサイコムというところで注文した。自作という選択肢もあったが、自分の不器用さをよく承知しているので(最近では液漏れで止まった時計を修理しようと分解して、再起不能にした)、BTOに。スペックは、
それに比較対象がThinkPad T460s (Core i7 6600U) 2 core 4 threadだからねえ
追記
サイコムから返事来た。送料着払いでボード２枚を返却したら、ボードぶんの代金を返金するとのこと。やさしい。
高田馬場
杉並区
瑞穂町
目白
飯田橋
西東京市
中野区
豊島区
八丈町
〓
Copyright © 2005-
Theme
Light
Dark
High contrast
2019-07-26
はてなダイアリーからはてなブログへの自動移行が完了し、はてなダイアリーでの記事の公開が終了しました
本日、2019年7月26日、はてなダイアリーからはてなブログへのデータの自動移行及び、移行先のブログへのリダイレクトなど移行に関する工程が完了いたしました。
これまではてなダイアリーをご利用いただき誠にありがとうございました。
つきましては、ご自身のダイアリーからデータの移行が正常に行われているか、はてなブログへのリダイレクトが行われるかなどご確認ください。もし、ご不明な点などございましたら、2019年9月1日までに下記のお問い合わせ窓口までご連絡ください。
https://www.hatena.ne.jp/faq/q/diary
なお、すべての記事を削除しているダイアリー、一部のはてなダイアリーについては引き続きはてなダイアリーが表示されておりますが、今後徐々に閲覧できなくなる予定です。
どうぞよろしくお願いいたします。
移行に関する注意事項
はてなブックマークについては、徐々に移行が行われていきます
移行完了までに数ヶ月かかる可能性もございますが、何卒ご了承ください
本日記にて告知いたしました通り、自動移行によらずはてなブログへの移行を行っていたブログについても、リダイレクト処理を行っています
リダイレクトを希望されない場合は、お問い合わせ窓口までご連絡ください
よくある質問
はてなダイアリーでは、メインアカウントでログイン中に非公開のサブアカウントのダイアリーが閲覧できるなど、サブアカウントに関する機能を提供していましたが、はてなブログでは提供していません。ブログごとに閲覧権限の設定をお願いします
hatenadiary 2019-07-26 15:30
はてなダイアリーからはてなブログへの自動移行が完了し、はてなダイアリーでの記事の公開が終了しました
Tweet
もっと読む
コメントを書く
はてなダイアリーからはてなブログへの自動移行が完了し、はてなダイアリーでの記事の公開が終了しました
コメント
2017-12-06
■ [Joke] ローカルネットワークに対するクロスオリジンの攻撃からシステムを守る簡単な方法
インターネット上に公開されているわなサイトを経由して社内イントラネットなどのローカルネットワークへXSSやCSRFなどのクロスオリジンでの攻撃を仕掛けようという試みは古くから存在します。現実にこれらが行われたという話は聞いたことはありませんが、理論上は可能であるという話をよく聞きます。対策としてまず検討すべきは、社内システムであっても通常のシステム同様に脆弱性を生まないようセキュアなものにするということです。それらが難しい場合には、少しの手間でローカルネットワークに対するクロスオリジンでの攻撃を低減させることができます。
フィドラでクロスオリジンからの攻撃を低減させる手順
Fiddler を起動し「Rules」メニューから「Customize Rules...」をクリックします。エディターが立ち上がってルール用のFiddlerScriptの編集画面が出てきますので、以下を追記します。
function isLocalServer(host:String):Boolean {
// TODO: 環境に合わせてここを修正して下さい
const localServers = ["server-name-1", "server-name-2"];
var re = /^([￥d]{1,3})￥.([￥d]{1,3})￥.([￥d]{1,3})￥.([￥d]{1,3})$/;
var m = re.exec(host);
var i;
// プライベートIPアドレスのホストはローカルのサーバーとみなす
if (m !== null) {
m[1] = m[1]|0;
m[2] = m[2]|0;
m[3] = m[3]|0;
m[4] = m[4]|0;
if (m[1] > 255 || m[2] > 255 || m[3] > 255 || m[4] > 255) return false;
if (m[1] === 10) return true;
if (m[1] === 172 && (m[2] >= 16 && m[2] <= 31)) return true;
if (m[1] === 192 && m[2] === 168) return true;
}
// ローカルサーバーの一覧に存在するかチェック
for (i = 0; i < localServers.length; i++) {
if (host.Equals(localServers[i]) ){
return true;
}
}
return false;
}
class Handlers
{
// 省略
static function OnBeforeRequest(oSession: Session) {
// 省略
// ターゲットがローカルサーバー
if (isLocalServer(oSession.hostname)) {
var from = oSession.oRequest.headers["origin"];
if (from !== "") {
from = from.replace(/^https?:￥/￥//,"");
} else {
var m = /￥/￥/([^￥/]+)￥//.exec(oSession.oRequest.headers["Referer"]);
if (m !== null) {
from = m[1].replace( /^[^@]+@/,"");
}
}
// 呼び出し元がローカルサーバーではない
if (!isLocalServer(from)) {
FiddlerApplication.Log.LogFormat("Blocked {0} from {1}", oSession.fullUrl, from);
oSession.utilCreateResponseAndBypassServer();
oSession.oResponse.headers.Add("Content-Type", "text/plain");
oSession.oResponse.headers.HTTPResponseCode = 404 ;
oSession.oResponse.headers.HTTPResponseStatus = "404 Not Found";
}
}
}
}
たったこれだけで、外部のわなサイトを経由したクロスオリジンの攻撃からローカルシステムをある程度守れます。
まとめ
やっていることは、通常は社外の公開サーバーをRefererやOriginとして社内に対してリクエストが発行されることはないので、それを検知した場合に404応答を返しているだけです。ただし、もちろんのことながら、ReferrerやOriginがつかない状況も頻繁に発生するので、そういった場合にはこの方法では攻撃を防ぐことはできません。繰り返しになりますが、社内システムであっても社外のシステム同様にきちんと脆弱性への根本的な対策を行っておくべきでしょう。
ツイートする
コメント
2017-11-06
■[SECURITY][Event] サイボウズ バグハンター合宿に行ってきた
先週の11月3日-4日に開催されたサイボウズ バグハンター合宿に参加してきた。
サイボウズ バグハンター合宿 - connpass
3年前は個人戦だったけれど今回はチーム戦ということに加え、クソつまらない脆弱性を多数報告した場合は評価が下がる採点方式だったので、最初はチームの足を引っ張らないようホームラン級のバグを探そうとしたけれど、最近すっかり技術的なことをやっていないのでなかなかそういうバグも見つけることができず、ゼロよりマシだろうということで結局わりとくだらないバグをいくつか報告した次第。とはいえ、他の人はあまりやらないだろうなという「クロスオリジンでの情報漏えい」みたいな自分としては好きなタイプのバグをひとつ見つけて報告することができたので、その点は満足。結果的にチーム順位は最下位、個人順位ではかろうじて10位に入るという感じでした(下から数えた方が早い)。Masato Kinugawaさん強すぎ。
いろんな攻撃手法に関して、以前なら自分の技として適切な場面でそれを取り出して使えることが多かったけれど、だんだんと手を動かす時間が減るにつれ他の人の攻撃例を見て「ああ、そうか。そこでその攻撃手法が使えたんだ！」みたいな感覚になっていってたんだけど、さらに今回は「なにそれ。そんな攻撃方法あったのか」みたいに全く知らない技がいくつもあったりして、すっかり時代においていかれた感を味わってきた。
実際にサイトを検証するのは、CTFと違って「問題のための問題」みたいなのではなく、実際に生きて動いてるWebサイトなのでどれだけ不合理で不自然なかたちであっても脆弱性が存在すればそれは現実のものなわけだし、あるいは特定の挙動についてあるサービスではサービスの提供方針として脆弱性として認定されるものが他のサービスでは脆弱性とは認定されないというような運用指針に寄るものがあったり、そういう点でリアルな世界なので学びも大きいし超楽しかった。
次回が開催されるのかはわからないけれど、もし開催されるのであれば次は事前にちゃんと予習復習をして、もうちょっと人権をちゃんと確保したい。
ツイートする
コメント
2017-04-24
■ [SECURITY] podcast 第1回 セキュリティの『アレ』
@ntsujiさん、@MasafumiNegishiさん、mtakeshiさんのポッドキャスト「セキュリティの『アレ』」の収録にお邪魔してきました！
第1回 動画のアレからポッドキャストのアレに帰ってきたよ！スペシャル « podcast - セキュリティの『アレ』
http://tsujileaks.com/media/are_170423.mp3
人に聞かせるために話すっていうよりは、辻さん根岸さんに解説してもらいながら3人との会話を自分自身が楽しむみたいな感じでした。ゆるゆるグデグデな感じですけどよろしくお願いします！
ツイートする
コメント
2016-12-16
■[SECURITY] 安全な脆弱性の作り方
この記事は 「脆弱性"&’<<>￥ Advent Calendar 2016」16日目の記事です。具体的な脆弱性の話でなくてすみません。いろいろコードを書いていると、安全に脆弱性を発生させたくなるときがあります。って書くとさっぱり意味がわからないと思いますが、セキュリティの講義のための演習環境とかそういうやつです。
受講生自身の手でWebアプリケーションの脆弱性を探してもらうような演習では、検査対象となる脆弱性を含むWebアプリケーションを用意する必要があります。こういった「脆弱なWebアプリケーション」は例えば Broken Web Applications Project のようなものを代表にいく
URL変更のお知らせ
このページのURLを変更しました。お気に入り・ブックマーク・更新アンテナ等へ登録されている方は登録の変更をお願い致します。
del.icio.us・はてなブックマーク等のソーシャルブックマーク経由、日記・プログ・個人ニュースサイト等の紹介記事から訪れた方で、もし、リンク切れ状態であるなら ニュース過去ログ & ネタ・まとめ系特集記事、雑学・考察系リンク集 を参照してください。
2010-02-02
atword.jp
このドメインを購入
ドメイン atword.jp は 299 USDで売り出し中です!
検索検索
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
ナビゲーションを切り替え
投稿日: 5月 17, 2016 投稿者: admin
カテゴリー: Money
投稿日: 5月 1, 20165月 17, 2016 投稿者: admin
カテゴリー: Money
投稿日: 4月 24, 20165月 24, 2016 投稿者: admin
カテゴリー: Uncategorized
2016.02.15
当サイト「やまもといちろうブログ」は、LINEブログにお引越しをしました
すでにご案内のとおり、ここニフティ「ココログ」で長らく運営しておりました「やまもといちろうブログ」は、知らない間にスマホ向けブログページに無断で広告が貼られていて私には広告収入の分配がなかったという理由でLINEブログに移籍することになりました。
やまもといちろうブログ（LINEブログ）
http://lineblog.me/yamamotoichiro/
もっとも、いままで無料で長く続けさせていただいていたということや、ココログ立ち上げの経緯も考えますと、感情的には断腸の思いもあるわけですけれども、そこは是々非々での判断ということで…。スタッフの皆様にも長らくお世話になりましたので、改めて、ここで深く御礼申し上げたいと存じます。
» Continue reading
2016.02.15 | Permalink
Tweet
«今日は『こころに効く本読みガイド』＆フジテレビ系『真夜中のニャーゴ』
当サイト「やまもといちろうブログ」は、LINEブログにお引越しをしました
このブログへのアクセスは現在停止しています。
ぐるなびHOME | お店のブログ
Android Extra Field Vulnerability Spotted in the Wild
It has been 20 days since the Extra Field vulnerability (also known as Chinese Master Keys) ...
Posted by dgoddard on Jul 30, 2013
ladysmokerの日記 [全5905件]
2012.10.18
未だ蔓延る放射脳
[ セキュリティ雑記 ]
人にはそれぞれの動かしがたい価値観や基準などがあり、だからこそお互いの差異を知った上での距離感や信頼感がないまぜになった上での人付き合いになる。
ある人には許容出来るものが別の人には容認しがたいというのはこれで、全部頭の上に書いてあるわけではない上に新しい事態に直面して初めて判断するということもある。
この判断は無論正しかったり間違っていたりするわけで、その繰り返しでほんの僅かずつ経験値にもなるんだが経験値といってもそれが正負両方なのも当然ある。
最初に書いた「動かしがたい」も実はその瞬間瞬間、時には相手にもよるし事態にもよるのというのが良くも悪くも人間らしいということかもしれない。
しかし例えば科学技術とか軍事という分野は「怖い怖いいやいや」で済むかというと「好ましくはないが容認せざるを得ない」脳内の感情を自分で宥める事も時には必要になる。
自分にとって好ましいものだけで社会は成立運用されていず国家となると尚更で、1億3千万弱がこの水準の生活を維持するには多大な「個人的には好ましくないもの」も存在する。
昨日Twitterでひとしきり騒ぎがあった。
【驚異の】「放射能はウイルスやアレルゲンに変異する（キリッ」【新説】
一見おちゃらけたような題名だが、こうでも書かないとこの1年半営々と放射脳を説得しまた傍から見るものにも充分納得できるだけの意見を発信し続けたにも関わらず未だこういう認識なのかという無念や脱力感のみに押し流されてしまうのは私にはよく判る。
やってきた者だけがこの題名を付けられるというのなら纏めた方も当然こうした題名をつけていいと思ってもいる。
この騒ぎの大元といっていい放射脳と言われる脳内アレルギーは発災から1年半を過ぎこれだけ情報が数字としてまた何よりもその地にいる方々が自ら証を立てていることから目を背け続けている。
どんなデマを飛ばしても自分達の気分がそれで休まるのならいいという極めて病的な衝動と理由だけでこの1年半彼らはやってきたわけだが、それらが時間が立ちまた数字や経緯経過によってデマの根拠さえも覆され始めるとこの纏めの最初の発言者のようにどこから突っ込んでいいか判らないほどの錯乱を示す。
もうひとつ言うのなら「勝手に移り住んで勝手に脳内アレルギーになる」自体は勝手だがまとめコメントにもあるようにそれを正当化しようとするとこのような事態に陥る。
日本ではどこに住もうとそれは自由で移った以上はその先で楽しく生活すりゃいいものを勝手に移住したのまで人のせい何かのせい、果ては金寄越せは通らない。
また私もじかに病院で見たが癌患者へのインチキ健康食品、なんちゃらキノコの押し売りと同じで、元々ある程度信用のあったもの(EM菌)を勝手に放射能に効く的なデマを飛ばして高価に売りつけるなどの被害も発生している。
もう一度言うがゼロベクレルはこの宇宙にも地球上にも存在しない。
目指すのは無駄だ。
この当たり前の事実くらいはせめて理解しろと思うけれどね。
mixiチェック
最終更新日 2012.10.18 09:03:51
コメント(0) | コメントを書く
■[資][Ubuntu] 日本語ディレクトリ名を英語名に変換
■[資][Ubuntu] 標準ディレクトリの設定
Copyright © 1995 - 2010 Pangeia Informática LTDA. Todos os direitos reservados.
Powered by Ruby version 1.8.7-p352
2011年5月12日
■ 「優しく, 美しく, 気高い数学書」 2011年5月12日 08:13
数学書房さんから出版される『この数学書がおもしろい 増補新版』という書籍に文章を書きましたのでアナウンスします。
この本は「約50名の執筆者が数学書について自由に書く」というもので、 数学に興味を持っている方なら、どなたにも参考になると思います。 編集部によれば、出版は近日中ということですが、正確な日付はまだわからないそうです。
各執筆者は一人およそ4ページずつ書きます。 結城は「優しく, 美しく, 気高い数学書」というタイトルで書きました（このタイトル…なにこれすごい）。
以上、簡単ですがご紹介でした。よろしくお願いします。
『この数学書がおもしろい 増補新版』
数学書房編集部編
ISBN 978-4-903342-64-1
数学書房（5/12現在、まだ本書の情報はないようです）
feedback | top
<前の日
ツイートする
旧Blog（ここ）について
質問の答えを書く
諸所の事情で
http://blog.moooi.jp/
こちらにて更新を再開しています。
[ツッコミを入れる]
2009-05
2009年1月13日
Xplico
だそうです。
トラフィックから色々なものを抽出して、アーカイブできるようですね。
閲覧したWebサイトやFTPアクセス、メールなどなど。
IRCやMSNなどのチャットプロトコルにも対応予定のようです。
今後に期待といった感じですかね。
公式サイト
2009年1月 (2)
鵜飼氏は，WinnyやMicrosoft製品，組込み機器などのセキュリティ・ホールを多数発見していることで知られるセキュリティの専門家。2003年から2007年7月まで米国に在住し，米eEye Digital SecurityのSenior Software Engineerを務める。2007年7月に帰国しフォティーンフォティ技術研究所を設立，取締役副社長最高技術責任者に就任。米国から執筆していたITpro Watcher「Security from USA」は，帰国にともない「Security from KAGURAZAKA」に改題した。
過去記事
>> 一覧
ethereal 日本語化 (325)
総務省地方公共団体コード一覧表
総務省: 地方公共団体における情報セキュリティポリシー（情報セキュリティ対策に関する基本方針）等の策定状況
Yahoo! - 06/02/08 09:43:35
ethereal 日本語化
Google - 06/02/08 09:43:22