|
|
|
|
|
||
|
||
雑談用ストーリー [4] 1180
■ 2025.03.11: 雨
》 FreeBSD 13.5-RELEASE Announcement (FreeBSD, 3/11)
This point release, FreeBSD 13.5-RELEASE, will be supported until April
30, 2026. The previous point release, FreeBSD 13.4-RELEASE, will reach
its End of Life at June 30, 2025.
》 EOLを迎えた古い「Node.js」へのCVE付番、MITREに却下されてしまう (窓の杜, 3/10)
》 《“パワハラ認定”も》亡くなった元局長に「わいせつ」発言、告発者潰しと同時に論点ずらし…衝撃会見で見えた斎藤知事の本性 (プチ鹿島 / 文春オンライン, 3/11)
》 北海道沖 千島海溝 巨大地震起こしうる程度までひずみ蓄積か (NHK, 3/9)
》 イーロン・マスク率いるDOGEと「ディープ・ステート」の共通点 (WIRED, 3/9)
》 DOGEとXテクニシャン、ブランデン・スパイクスとは？ (Krebs on Security, 3/6)。DeepL 訳を若干修正:
49歳のBranden Spikesは、イーロン・マスクのDepartment of Government Efficiency（DOGE）に関わった最古参の技術者の一人だけではない。 X/Twitterの現情報技術部長であり、PayPal、Zip2、テスラ、スペースXの初期採用者でもあるスパイクスは、マスクの最も忠実な従業員の一人でもある。 ここでは、ロシア人の元妻がイーロンのいとこと結婚していたこともある、この信頼できるマスクの副官について詳しく見ていこう。
またしてもロシアの影……。
》 X(旧Twitter)で発生した大規模障害に対してハッカー集団「Dark Storm」が犯行声明を発表 (gigazine, 3/11)
》 「Western Digital（WD）」が「Sandisk」の分離を完了 SSDを含むフラッシュメモリ関連事業を移管 (ITmedia, 2/27)。
WD は再び HDD 専業に、
SSD 部門を (SanDisk ではなく) Sandisk として別会社に、ということみたい。
社名もロゴも旧 SanDisk とは異なるのですね。
関連:
【特別企画】SanDiskを得たWestern Digital。HDDの巨人が後発でSSD市場に狙いを定めたワケとは?
～WDの“空箱戦略”仕掛け人 安田伸幸氏にインタビュー (PC Watch, 2016.12.22)
WDは、SanDiskはどうなる?マルチブランドを展開しつつ「ワン・ウエスタンデジタル」を標榜するWestern Digitalの狙い～ウエスタンデジタル日本法人、営業統括バイスプレジデントに聞く (PC Watch, 2019.12.20)
》 公開情報から読み解く日系企業ランサム被害傾向 24年版 (マクニカ, 3/6)
2024年はグローバル全体でのリーク件数が過去最多を更新している一方、日系企業へのリーク行為の件数/割合は昨年より減少しています。しかしこれは「日系企業への攻撃が減少した」というわけではなく、リークサイトへサンプルデータを掲載する際の"機微情報の選別"が、日本語を使う日系企業の場合は手間がかかるため、掲載自体が後回し・見送られている可能性があると考えています。
》 情報セキュリティ10大脅威 2025 (IPA, 2/28 更新)
2025年2月28日
「情報セキュリティ10大脅威 2025 [組織編]」を公開
「情報セキュリティ10大脅威 2025 情報セキュリティ10大脅威の活用法 [組織編]」を公開
「情報セキュリティ10大脅威 2025 セキュリティ対策の基本と共通対策」を公開
》 Wireshark 4.4.5 Released (Wireshark, 2/24)。crash する不具合などを修正。
》 JSAC2025 開催レポート～DAY 1～ (JPCERT/CC, 2/26)、 JSAC2025 開催レポート～DAY 2～ (JPCERT/CC, 3/5)
》 フィッシング対策協議会 技術・制度検討 WG 報告会 ご案内（2025年2月25日開催） (フィッシング対策協議会, 2/25)
》 標的は「生成AI汚染」、年360万件超のプロパガンダを量産するロシア影響工作ネットのインパクトとは？ (新聞紙学的, 3/10)
》 トランプ政権が「ロシアのサイバー脅威」対策を後退、そのインパクトとは？ (新聞紙学的, 3/3)
》 カナダ・オンタリオ州政府、米向け電力料金25%上乗せ (日経, 3/11)
トランプ米大統領就任式に出席の億万長者ら、純資産合計31兆円失う (ブルームバーグ, 3/11)
■ JVNVU#93567491
Apache Tomcat partial PUTにおけるリモートコード実行、情報漏えいや改ざんの脆弱性（CVE-2025-24813）
(JVN, 2025.03.11)
Apache Tomcat 11.0.3 / 10.1.35 / 9.0.99 未満に欠陥。
Apache Tomcatのpartial PUTの元の実装では、ユーザーが指定したファイル名とパスを基にパス区切り文字を「.」に置き換えた一時ファイルが使用されています。
一時ファイル名を推測できる欠陥があるそうで。
Apache Tomcat 11.0.3 / 10.1.35 / 9.0.99 で修正されている。
届出
2025/03/11(火)火曜日ー。（OJT = お前が自分で戦え ?）
[雑談] いろいろ。
IPAの「情報セキュリティ10大脅威2025」をセキュリティ専門家はどう見るのか | TECH+（テックプラス）
IPAの「情報セキュリティ10大脅威2025」をセキュリティ専門家はどう見るのか
2月25日～27日にオンライン開催された「TECH+フォーラム セキュリティ 2025 Feb. 今セキュリティ担当者は何をすべきか」のパネルディスカッションで、5人の専門家が熱い議論を交わした。パネ
https://news.mynavi.jp
「ESP32」の（「バックドア」改め）隠し機能の悪用方法について、Tarlogicが説明 - ITmedia NEWS
「ESP32」の（「バックドア」改め）隠し機能の悪用方法について、Tarlogicが説明
多数のIoTデバイスに搭載されているMCU「ESP32」の「隠し機能」を「バックドア」として発表して批判されたTarlogic Securityが、改めて隠し機能の危険性について説明した。
https://www.itmedia.co.jp
S3の標準機能だけでランサムを実現？ マルウェアも脆弱性も使わない新手口：半径300メートルのIT - ITmedia エンタープライズ
S3の標準機能だけでランサムを実現？ マルウェアも脆弱性も使わない新手口
マルウェアや脆弱性を全く使わず、Amazon S3の標準機能を悪用するだけでランサム攻撃を実行する新型の手法が登場しました。今回はこの巧妙な手口の詳細を解説します。
https://www.itmedia.co.jp
X(旧Twitter)で発生した大規模障害に対してハッカー集団「Dark Storm」が犯行声明を発表 - GIGAZINE
X(旧Twitter)で発生した大規模障害に対してハッカー集団「Dark Storm」が犯行声明を発表
日本時間の2025年3月10日(月)夜から11日(火)未明にかけて、Xで大規模な障害が発生しました。オーナーのイーロン・マスク氏は「大規模なサイバー攻撃があった」と反応した上で、FOXニュースの番組で
https://gigazine.net
「許せる脆弱性」と「許せない脆弱性」がある！？ その判断基準とは――【海の向こうの“セキュリティ”】 - INTERNET Watch
「許せる脆弱性」と「許せない脆弱性」がある！？ その判断基準とは――【海の向こうの“セキュリティ”】
皆さんは「許せる（forgivable）脆弱性」と「許せない（unforgivable）脆弱性」と聞いて何を思い浮かべるでしょうか？ おそらく多くの方がソフトウェアなどの利用者側の立場でパッチ適用の
https://internet.watch.impress.co.jp
自動運転車のセンサー、遠距離からの攻撃で無効化できちゃうかも | ギズモード・ジャパン
自動運転車のセンサー、遠距離からの攻撃で無効化できちゃうかも
未来の象徴と言っても過言ではない自動運転車。ロマンがつまった自動運転技術ですが、今回新たなリスクが発覚したようです。慶應義塾大学の研究チームは、自動運転車両に搭載されている｢LiDAR センサーシス
https://www.gizmodo.jp
GitHub - SecDev-Lab/wish
GitHub - SecDev-Lab/wish
Contribute to SecDev-Lab/wish development by creating an account on GitHub.
https://github.com
AmazonでAMD Ryzen 7 9800X3Dの新品を注文したらステッカーを貼った偽装品が届いたという報告 - GIGAZINE
AmazonでAMD Ryzen 7 9800X3Dの新品を注文したらステッカーを貼った偽装品が届いたという報告
AmazonでAMDのRyzen 7 9800X3Dを購入したら、上からステッカーを貼り付けた偽物だったという報告が挙がっています。偽物は箱に入った上でシュリンクで包装されており、まるで新品であるかの
https://gigazine.net
マイナ免許証、カーシェアでは使えない タイムズも「現時点では検討中」 - ITmedia NEWS
マイナ免許証、カーシェアでは使えない タイムズも「現時点では検討中」
「マイナ免許証」が3月24日にスタートするが、カーシェア各社は、新規入会や免許の更新手続きには当面、マイナ免許証が使えないとアナウンスしている。
https://www.itmedia.co.jp
電通手がける「ひたすらスケジュール調整」ゲーム『Scheduler』発表。バレなきゃサボってもいい、激務捌きまくり出世ゲーム - AUTOMATON
電通手がける「ひたすらスケジュール調整」ゲーム『Scheduler』発表。バレなきゃサボってもいい、激務捌きまくり出世ゲーム - AUTOMATON
電通グループの社内横断チーム「デンツウゲームセンター」は3月7日、『Scheduler』を発表した。スケジュール調整を題材としたパズルゲームだ。
https://automaton-media.com
｢英会話レッスンにお金を払う｣は時代遅れ…スマホで24時間､無料でできる｢令和の英語勉強法｣ リアルな英会話講師のスペックを超えている | PRESIDENT Online（プレジデントオンライン）
｢英会話レッスンにお金を払う｣は時代遅れ…スマホで24時間､無料でできる｢令和の英語勉強法｣ リアルな英会話講師のスペックを超えている
英語を話せるようになるにはどうすればいいか。英語講師・中林くみこさんは「従来の英会話スクールに比べて断然コスパがいいChatGPTがおススメ。日本人は遠慮して講師になかなか質問できない人が多いが、AI
https://president.jp
最終更新日：2025/03/11
JVNVU#93567491:
Apache Tomcat partial PUTにおけるリモートコード実行、情報漏えいや改ざんの脆弱性（CVE-2025-24813） [2025/03/11 12:00]
Apache Tomcatにおける複数の脆弱性 [2025/03/07 15:45]
56
2025-02-27
届出出会い系サイトの年齢確認とユーザーの年齢確認義務（青少年条例）
届出出会い系サイトの年齢確認とユーザーの年齢確認義務（青少年条例）
だいたい児童買春をしようとする人には年齢確認義務はないのですが（児童ポルノ･児童買春法9条）、青少年条例には年齢知情条項があって淫行する際の年齢確認義務があるように見えるので、届出出会い系サイトの場合でも、利用者は年齢確認義務があるという問題があります。結論として児童買春行為には青少年条例は適用されないので、年齢確認義務もないことになります。
裁判例では、年齢確認を尽くさなかったことなどを理由にして未必の故意を認定しているものがあります。
検事の論稿では、風俗営業のように店側が重い年齢確認義務を負う場合には、客の年齢確認義務を緩和しようとするものもあります。
現場の警察官の認識は、裁判例ふうの人が多い感じです。
沖縄簡裁平成30年4月19日
（事実認定の補足説明）
１ 被告人は，金銭を対償として供与する約束をしてＡ子（当時l6歳）（以下「本件女性」という。）と性交した事実を認めつつ，本件女性が18歳未満であるとは知らなかったと弁解し，弁護人もこの弁解を前提として被告人は本件犯行の故意がないから無罪であると主張する。そこで，この点について，以下検討する。
２ 証拠によれば，以下の事実が認められる。
(2) スマートフォンのアプリである「届出出会い系サイト」は，出会い系のメールの掲示板であり，これに登録する際には，自動車運転免許証や健康保険被保険者証等の画像による年齢確認手続が必要である（甲7，被告人の公判供述）。
本件女性は，成人している友達の自動車運転免許証を借りて，その画像を加工した上で，同サイトに登録し，プロフィール画面では年齢を20代前半として登録していた（甲5，7)。
他方，被告人は，同サイトのプロフィール画面では年齢を40代後半として登録していた（甲5)。
～～
(2) これに対し，被告人は，同サイトの登録の際に免許証等による年齢確認がされており，本件女性のプロフィールにある年齢が虚偽であるとは思わなかったと供述する。
しかし，上記2(4)のとおり，18歳未満の児童が出会い系サイトを通じて知り合った男性と売春をしている例が多々あることは広く知られた事実であって，出会い系サイトヘの登録の際の年齢確認は必ずしも厳密にされているわけではない。また，プロフィールの年齢は自己申告によるものであって自動車運転免許証等の身分証明書に記載されたとおりでないことは，上記2(1),(2)のとおり，被告人も60歳のところを40代後半と登録していることからして，被告人も十分に認識していたと認められる。
(3) また，被告人は，出会い系サイトを通じて知り合った買春の相手方に対し，その年齢を確認するために，生年月日を尋ねたり身分証明書の提示を求めたりすることはしない，年齢の確認は自分の感覚でやるしかない，自分の感覚はかなり正しいと思っているなどと供述する。
しかし，本件女性の語った21歳という年齢と18歳未満とはさほどの年齢差があるわけではなく，その違いにつき感覚で正しく判断できるとはおよそ考え難いのであり，被告人の供述は採用することができない。被告人の上記供述は，結局のとごろ，性交という目的を達するまでの男女間の雰囲気を良好に保つとともに，買春の相手が1 8歳未満であることを知ってしまった場合に直面する性交を断念するかどうかの判断から逃れるためにあえて，更なる年齢確認をしなかったにすぎないというべきである。
～～
３ 以上によれば，被告人は，本件女性の顔つきや体型，会話の内容等から同人が18歳未満である可能性を十分に認識しながら，あえてその年齢を確認することなく18歳未満であっても構わないと考えて性交したと認定することができ，未必の故意があったと認められるのであり，これに反する被告人の弁解及び弁護人の主張は採用することができない。
藤宗検事「青少年保護条例違反」シリーズ捜査実務全書９第３版青少年条例
(イ) 青少年の年齢の知情性について
① 行為者を淫行につき処罰するためには、淫行当時、その相手方が青少年であることについて知っていなければならないし、特に無過失のみ不処罰の旨の規定のあるところでは知らないことにつき過失がある場合でなければならないのは、前述のとおりである。
後者について、どのような場合に、知らないことについて過失があると認められるのであろうか。
結論としては、具体的事案によって千差万別としか言えず、青少年の年齢が18歳直前なのか14、5歳なのかはかりに若年であるのか、行為者と青少年の知り合った経緯、行為者の身分、立場などを総合して判断するしかない。
しかし、育成条例の「淫行等」について、前述のように、単なる不道徳な性行為というのではなく、前記①・②のように、限定した概念として、青少年の未成熟を利用し、あるいは乗じるなどの特に不当な行為とらえていることからすれば、相手が未成熟な青少年であることを知っていることが前提のはずと考えれ、過失であれ、その認識を欠いている場合を、「知って」淫行等した場合と同列に論じられるのが疑問なとしない。
故に過失の認定には慎重であるべきであるし、過失の程度も重過失と言えるようなものに限るべきではなかろうか。児童買春・ポルノ法等において児童の使用者についてのか過失ある場合の処罰が規定されていることも参考とされるべきである。
② 過失認定が難しい一例を見てみる。
デートクラブやいわゆるキャバクラなどの客が、その店のホステスを相手に性交又は性交類似行為に及んだ場合、その行為が単に性欲を満たすためだけの淫行に当たることは明らかであるから、その相手が18歳未満の青少年であれば、淫行規制条例の適用を受け得ることになる。
ところで、当節、青少年の肉体的発育はめざましく、15、6歳で成人以上の体格をしている者も珍しくはなく、化粧、衣類によって、その外見のみから18歳以上か18歳未満であるかを判別することは困難な場合が多いが、デートクラブやキャバクラなどでアルバイトしている青少年の場合には殊更外見からの年齢判断はできにくい。
客は、被疑者として取り調べられると、年齢については「知らなかった」と否認する者が多い一方、恥、不名誉に思い早く終わらせたい気持ちから、「若いなと思った」「本人は18歳と言っていたが、まだかもしれないと思った」などの未必的認識を認める供述をする者も多く、これを根拠に過失を認定している例も見受けられる。
しかし、キャバクラなどは、風俗営業等の規制及び業務の適正化等に関する法律第22条第3号により、18歳未満の者を接客に使えないはずであり、通常の客は、ホステスは18歳以上との認識で来店すると思われ、仮に、前記のような若干の疑念を抱いたとしても、客にその点を確認する方法は相手ホステスに尋ねるくらいしかないだろうし、それ以上の確認を要求すること自体非現実的であろう。実質的には誤認の場合の認識との間にこれほどの径庭もないと言うべきであろう。
一方、捜査官に対しては、「当該客に年齢を問われ、17歳と答えた。」「もうすぐ18歳の誕生日と言った。」などと、客の年齢知情を裏付ける供述をする青少年が稀でないが、キャバクラなどで働いている青少年には、すでに取調べに慣れていて、自己が被保護者たる青少年であることを利用し、被害者的立場を誇張し、かつ、捜査官に迎合的な供述をする者がまま見られ、しかもそのような店の経営者は、客寄せのために成人顔の若い女子を用いる傾向が強く、中には、18歳未満と知っていても本人に、客に問われたら18歳と答えるよう指示している場合が多いのは周知の事情であるから、右青少年の供述を全面的に信用することは危険である。
このような例では、結局は、客が既に青少年と話をする機会などがあってその身にを知り得る関係にあったとか、当該店には18歳未満の女子ばかりを置いているなどの噂があって、客の来店理由になっていたと認められるなど、個別具体的に、淫行の相手が18歳未満であることについて客観的に知り得る状況があったことを明らかにしなければ、過失を認めるべきではないと考える。
淫行規制条例は、青少年の健全育成、保護のために、これを阻害する行為を回避する義務を年長者に負わせるものであるが、保護の対象たる青少年が自らの意思でいわば性を売り物にするデートクラブやキャバクラなどに身を置く以上、そ保護は、個別の客を淫行で処罰することによるより、むしろ雇用主の児童福祉法違反、風俗営業等の規制及び業務の適正化等に関する法律違反、売春防止法違反などを処罰することで図られるべきところではなかろうとも考えられる。
okumuraosaka 2025-02-27 17:34 読者になる
広告を非表示にする
最終更新: 2025-02-27 17:34
届出出会い系サイトの年齢確認とユーザーの年齢確認義務（青少年条例）
最終更新: 2025-02-27 17:34
2025年01月26日
■ 個人情報保護法3年ごと見直しの行方を大規模言語モデルClaudeで占う
先週、個人情報保護委員会に新しい動きがあった。1月22日付で以下の文書が出ている。
「個人情報保護法 いわゆる３年ごと見直しに係る検討」の今後の検討の進め方について
個人情報保護法の制度的課題の再整理
そこで、これまでの文書を含め、生成AIに読み込ませて、どのような展開となろうとしているのかを分析させてみた。今回は、プロンプトに貼り付けるのではなく、Claudeの「プロジェクト」機能を使い、これらの文書を「project knowledge」として扱った*1。
以下は、Claude 3.5 Sonnet Formalによる応答である。
私：まず、資料をファイルごとに日付を確認してください。
Claude：それぞれのファイルの日付を確認いたします。時系列順に整理すると以下のようになります：
2024年6月12日
ppc20240612-takagi.docx (高木浩光氏による意見書)
2024年6月27日
個人情報保護法いわゆる3年ごと見直しに係る検討の中間整理.pdf
2024年10月16日
個人情報保護法のいわゆる3年ごと見直しの検討の充実に向けた視点
2024年11月21日
ppc20241121-takagi.docx (高木浩光氏による2回目の意見書)
2024年12月17日
241217_shiryou-1-1 「個人情報保護法のいわゆる３年ごと見直しの検討の充実に向けた視点」に関するヒアリングの概要について.pdf
241217_shiryou-1-2 事務局ヒアリングにおける主な御意見.pdf
2025年1月21日
02_【資料１】個人情報保護委員会事務局提出資料.pdf
2025年1月(日付不明)
「個人情報保護法 いわゆる３年ごと見直しに係る検討」の今後の検討の進め方について（案）.pdf
個人情報保護法の制度的課題の再整理.pdf
これらの資料は、2024年6月から2025年1月にかけての個人情報保護法の3年ごと見直しに関する一連の検討過程の文書であることが分かります。
私：最後の日付不明は2025年1月22日のものです。これらを分析して、個情委の立場がどのように変化してきているかを調べます。
Claude：個人情報保護委員会（個情委）の立場の変遷を時系列に沿って分析いたします。
2024年6月の中間整理段階
個情委は、具体的な制度改正の方向性について、以下のような個別論点を中心に検討を進めていました：
個人の権利利益の実質的な保護
監視・監督の実効性確保
データ利活用支援
この段階では、比較的技術的・実務的な制度改正の方向性を示していました。
2024年10月の転換点
「検討の充実に向けた視点」を公表し、より根本的な制度の基本的在り方に立ち返る必要性を認識しました。この背景には、デジタル化・AIの急速な普及を踏まえた事業者団体等からの指摘がありました。
2024年11月-12月のヒアリング段階
個情委は、有識者11名、経済団体・消費者団体等17団体という幅広いステークホルダーからヒアリングを実施し、より包括的な観点から検討を行うようになりました。特に注目したのは：
個人情報保護法の保護法益の本質
本人関与の意義と限界
事業者のガバナンスの実効性
官民を通じたデータ利活用の在り方
2025年1月の現在の立場
個情委は、「本人の権利利益への直接の影響の有無」を重要な判断基準として採用し、より柔軟な規制の枠組みを模索するようになっています。具体的には：
本人関与が必要な場面とそうでない場面を峻別する方向性
統計作成やAI開発など、個人への直接的影響が想定されない利用については規制を緩和する可能性
実質的にデータ処理を行う委託先事業者への直接規制の検討
この変化は、当初の個別論点ベースの改正検討から、より包括的な制度設計の見直しへと発展したことを示しています。特に、形式的な規制から実質的な保護へと重点を移行させる傾向が見られます。また、官民連携によるデータ利活用の推進と個人の権利利益保護のバランスを、より柔軟に図ろうとする姿勢が明確になってきています。
私：高木意見はどのように扱われていますか。
Claude：高木意見の扱われ方を分析いたします。
高木意見の要点
高木氏は2回の意見書（6月と11月）を通じて、個人情報保護法の核心的保護利益を「個人データ処理による個人に対する評価・決定の適切性確保の利益」と位置付け、これを基準とした制度設計を提案しています。特にOECDガイドラインの第2原則（データ品質の原則）における「関連性の要件」の導入を重視しています。
個情委の対応
初期段階（6月-10月）：
中間整理の段階では、高木意見で示された基本的な制度設計の考え方は直接的には反映されていませんでした。
転換点（10月）：
「検討の充実に向けた視点」において、制度の基本的在り方に立ち返る必要性を認識し、高木氏を含む有識者からのヒアリングを実施することを決定しました。
ヒアリング後の展開（12月-1月）：
高木意見の影響は、以下の点で部分的に見られるようになっています：
「本人の権利利益への直接の影響の有無」を重要な判断基準として採用したこと
これは高木氏の「評価・決定の適切性確保」という考え方と親和性があります
統計作成やAI開発などの取扱いについて、個人への直接的影響が想定されない場合の規制緩和を検討していること
これは高木氏の「決定利用」という概念に基づく整理と類似しています
ただし、重要な相違点も存在します：
高木氏が重視する「関連性の要件」の法制化については、明示的な言及がありません
高木氏が提案する「データ品質の原則」の導入については、直接的な検討対象とはなっていません
事業者のガバナンスに関する考え方において、高木氏の提案する「独立データ保護機関による介入と本人関与の両面からなるガバナンス」という構造は、そのままの形では採用されていません
総括すると、個情委は高木意見の一部（特に「直接の影響」という判断基準）を取り入れつつも、より漸進的な制度改革の方向性を模索していると評価できます。高木氏が提案する根本的な制度再設計ではなく、既存の制度框の中での調整を志向している様子が見られます。
私：高木意見に相入れない反対意見の扱いはどうなっていますか。
Claude：高木意見と相対する主な意見は、特に次の論点において見られます。
プライバシー保護の位置付けについて
森亮二弁護士は「権利利益の中心は、プライバシーであり、本法の目的の一つはプライバシー侵害の防止」と主張しています。これは高木氏が「プライバシーは副次的保護利益に過ぎない」とする立場と根本的に対立します。
個情委の対応：
双方の立場を踏まえつつ、「様々なリスクを考慮し、全体的なバランスをとった重層的な位置付けとすべき」という折衷的な立場を採用しています。
本人関与の意義について
一部の有識者や事業者団体からは、本人の自己情報コントロール権を重視する意見が出されています。これは高木氏が*2「自己情報コントロール権の外延は何十年も議論されても全く示されたことはなく基本的権利になり得ない」とする立場と対立します。
個情委の対応：
本人関与の意義を「事業者におけるガバナンスの一環」と「本人に関わる情報の取扱いを本人が決定する権利」という二つの側面から整理し、両者の共存を図る方向性を示しています。
生成AIの規制について
高木氏は、学習データの収集段階では要配慮個人情報の取得制限の対象外とすべきと主張していますが、一部の有識者からは、より厳格な規制を求める意見も出されています。
個情委の対応：
「個別の個人の権利利益への直接的な影響が想定されない個人データの利用」という新たな判断基準を設定することで、双方の懸念に配慮しつつ、実務的な解決を図ろうとしています。
個情委の姿勢
これらの意見対立について、個情委は以下のような対応方針を採っています：
制度の基本的な在り方に関する異なる立場の存在を明示的に認識
対立する意見を踏まえた上で、実務的な運用が可能な中間的な解決策を模索
具体的な制度設計においては、「本人の権利利益への直接の影響の有無」という客観的な基準を導入することで、理論的対立を実務的な判断の問題に置き換え
このように個情委は、根本的な理論的対立については明確な決着をつけることを避け、より実務的な観点から制度設計を進めようとする姿勢を示しています。
私：決着の点について、12月17日、1月21日、1月22日の資料を比べると変化はありますか。
Claude：3つの資料を時系列で比較分析すると、個情委の立場に以下のような変化が見られます：
12月17日の資料（ヒアリング概要）
この段階では、様々な意見の存在を並列的に紹介する形式を取っています。特に保護法益の解釈や本人関与の意義について、対立する意見を併記しつつ、どちらかに決着をつけることを避けています。
1月21日の資料（事務局提出資料）
より具体的な制度設計の方向性を示し始めています。特に「本人の権利利益への直接の影響の有無等」を切り口とした規律の内容の検討という方向性が明確になってきています。この段階で、理論的対立を実務的な判断基準へと置き換える方向性が見え始めます。
1月22日の資料（今後の検討の進め方）
さらに具体的な整理が進み、「個人データ等の取扱いにおける本人関与に係る規律の在り方」として、より明確な判断基準を示すようになっています。特に注目すべき変化として：
統計作成等、特定の個人との対応関係が排斥された一般的・汎用的な分析結果の獲得と利用のみを目的とした取扱いについて、本人同意を要しないとする方向性が具体化
取得の状況からみて本人の意思に反しない取扱いを実施する場合についても、同様の整理を行う方向性が示される
この変化は、当初の理論的な対立の並列的な提示から、より実務的な判断基準の確立へと、個情委の検討が進展していることを示しています。特に、「本人の権利利益への直接の影響の有無」という基準を採用することで、異なる立場からの意見を実務的に調整可能な形に収束させようとする方向性が強まっているといえます。
この変化は、高木意見が提示した「評価・決定の適切性確保」という観点と、プライバシー保護や自己情報コントロール権を重視する立場との間で、実務的な接点を見出そうとする試みと解釈することができます。
私：理論面はどういうことでしょうか。
Claude：理論面での変化を分析すると、個人情報保護委員会の立場は以下のように発展しています。
初期の理論的整理（12月17日資料）
個人の権利利益の保護について、4つのリスク類型（評価・選別による影響、直接の働きかけ、秘匿領域の暴露、自己情報コントロールの制約）を並列的に提示し、これらを総合的に考慮する必要性を示唆していました。この段階では、各リスクの理論的な位置づけや優先順位について明確な整理を避けていました。
理論的整理の発展（1月21日資料）
「本人の権利利益への直接の影響の有無」という基準を導入することで、理論的な整理の軸を設定しています。この基準は、高木意見が示す「評価・決定の適切性確保」という考え方と、プライバシー保護や自己情報コントロール権という従来の考え方を、実務的な判断基準として統合する試みと解釈できます。
最終的な理論的枠組み（1月22日資料）
個人情報保護法の規律を「本人関与」と「ガバナンス」という二つの柱で整理し、それぞれについて「直接の影響の有無」を基準とした具体的な判断枠組みを提示しています。この整理により：
本人関与の必要性は、個人への直接の影響が想定される場合に限定される
ガバナンスの在り方は、データ処理の実態に即して再構築される
従来の理論的対立は、実務的な判断基準の中に組み込まれる
この変化は、純粋な理論的対立の解決を目指すのではなく、実務的な判断基準を通じて異なる理論的立場の共存を図るという*3、個人情報保護委員会の新たな理論的アプローチを示しています。これは、一般法としての個人情報保護法の性質を踏まえた実践的な理論構築の試みと評価できます。
私：高木意見のどの部分が実現されそうでしょうか。
Claude：高木意見のうち、実現される可能性が高い部分について分析します。
第一に、「評価・決定による影響」を重視する考え方が、「本人の権利利益への直接の影響の有無」という基準として部分的に採用されつつあります。個人情報保護委員会は、この基準を用いて本人関与の要否を判断する方向性を示しており、これは高木氏の理論的枠組みと親和性があります。
第二に、統計作成やAI開発における個人データの取扱いについて、高木氏が主張する「決定利用」という観点からの整理が実質的に取り入れられつつあります。個人情報保護委員会は、特定の個人との対応関係が排斥された一般的・汎用的な分析結果の獲得と利用のみを目的とした取扱いについて、本人同意を不要とする方向性を示しています。
第三に、個人データの委託や第三者提供に関する規律について、高木氏が指摘する「データ処理の実態に即した規律の必要性」という観点が採用されつつあります。個人情報保護委員会は、データ処理を実質的に行う事業者に対する直接的な規律の導入を検討しています。
一方で、高木意見の核心的な部分である「データ品質の原則」、特に「関連性の要件」の法制化については、現時点では具体的な検討対象とはなっていません。また、独立データ保護機関による積極的な介入という制度設計も、そのままの形では採用される見込みは低いと考えられます。
このように、高木意見は実務的な判断基準の構築という形で部分的に実現されつつありますが、より根本的な制度再設計の提案については、現時点では採用が見送られる可能性が高いと評価できます。ただし、個人情報保護委員会が示している「より包括的なテーマや個人情報保護政策全般」についての継続的な議論の中で、これらの提案が将来的に検討される余地は残されています。
私：契約の履行に伴う提供についてはどうですか。
Claude：契約の履行に伴う提供に関する取り扱いについて、高木意見と個人情報保護委員会の立場の変遷を分析します。
高木意見の主張
高木氏は6月の意見書で、目的内の提供を本人同意の原則的対象とする現行規制は過剰であると指摘しています。特にEU法では「契約の履行」や「正当な利益」に該当する場合には本人同意なく提供が許される点を参照しつつ、日本でもこれを認めるべきと主張しています。ただし、その実現のためには「利用目的の特定」を十分に詳細なものとし、「第三者提供時の利用目的拘束」の仕組みを設ける必要があるとしています。
個人情報保護委員会の対応
個人情報保護委員会は、この提案を段階的に検討対象としてきました。1月22日の資料では、「取得の状況からみて本人の意思に反しない取扱いを実施する場合」を本人同意不要とする方向性を示しており、これは契約の履行に伴う提供を含む可能性があります。
ただし、高木意見が指摘する前提条件（詳細な利用目的の特定や利用目的拘束の仕組み）については、現時点で具体的な検討は示されていません。これは、個人情報保護委員会が短期的な制度改正としては、より実務的な判断基準の導入を優先し、制度の基礎的な部分の改正については中長期的な検討課題として位置付けている可能性を示唆しています。
このように、契約の履行に伴う提供については、高木意見の問題意識は部分的に採用されつつありますが、その実現方法については、より漸進的なアプローチが選択されていると評価できます。
私：AI規制との関係はどうですか。
Claude：AI規制との関係について、高木意見と個人情報保護委員会の立場を分析します。
高木意見の主張
高木氏は、AI規制に関して重要な理論的整理を提示しています。特に生成AIについて、学習データの収集段階では個人データとして取得する場合に当たらないとし、要配慮個人情報の取得制限の対象外とすべきと主張しています。その理由として、学習結果がパラメータとして抽象化され、個人との対応関係が失われることを挙げています。
一方で、生成AIの出力段階については、プライバシーや個人の権利利益の保護の観点から規制が必要と主張しています。特に、実在の個人に関する評価や判断を出力する場合には、その正確性や関連性が問われるべきとしています。
個人情報保護委員会の対応
個人情報保護委員会は、この問題について段階的に立場を明確化してきています。当初は生成AIへの対応について慎重な姿勢を示していましたが、1月22日の資料では「統計作成等であると整理できるAI開発等」について、本人同意を要しない方向性を示しています。
ただし、個人情報保護委員会は、より包括的なAI規制との関係について、一般法としての個人情報保護法の位置づけを意識した整理を行っています。具体的には、AIの利用に関する固有の課題については、特別法等による規律も含めた検討の必要性を示唆しています。
将来への含意
今後のAI規制との関係では、個人情報保護法は基盤的な規律として機能しつつ、AI特有の課題については別途の規制枠組みが検討される可能性が高いと考えられます。高木意見が示した「決定利用」という観点からの整理は、この二層構造の規制を考える上で重要な示唆を与えるものとなっています。
なお、この方向性は、EUにおけるGDPRとAI規制法の関係に類似した構造となる可能性があり、国際的な制度調和の観点からも注目される点といえます。
私：生成AI以外のAIについてどうですか。
Claude：生成AI以外のAIについての議論を、高木意見と個人情報保護委員会の立場から分析します。
高木意見の基本的立場
高木氏は、AIによる個人に対する評価・決定を行う場合について、データ品質の原則、特に関連性要件が重要だと主張しています。具体的には、評価・決定の目的に対して関連性のないデータ項目による差別的効果をもたらす決定を防止する必要性を指摘しています。
この観点から、AIによる人事評価など、個人に対する具体的な評価・決定を行うシステムについては、データの関連性や評価・決定の適切性を確保するための規律が必要だとしています。
個人情報保護委員会の対応
個人情報保護委員会は、AIによる個人の評価・選別について、「本人の権利利益への直接の影響」という観点から規律を検討する方向性を示しています。特に1月22日の資料では、プロファイリングを含む個人データの取扱いについて、より実効的な規律の必要性を認識しています。
ただし、個人情報保護委員会は、高木氏が提案するような関連性要件の導入という形ではなく、「本人の権利利益への直接の影響の有無」という基準を用いて、規律の要否や程度を判断する方向性を示しています。
将来的な展望
個人情報保護委員会は、AIによる個人の評価・決定について、一般法としての個人情報保護法による基本的な規律と、AI特有の課題に対応する特別法等による規律という二層構造での対応を想定していると考えられます。この中で、個人情報保護法は、AIによる評価・決定が個人の権利利益に直接影響を与える場合についての基本的な保護枠組みを提供する役割を担うことになると予想されます。
この方向性は、高木意見が示す理論的枠組みとは異なるアプローチですが、実務的な観点からは、既存の法制度との整合性を保ちながら、AIによる個人の評価・決定に対する規律を段階的に整備していく現実的な選択として理解できます。
私：関連性への言及はないのですか。
Claude：関連性への言及について、詳細に確認してみます。
12月17日の事務局ヒアリング概要資料では、高木氏の関連性に関する指摘について触れており、「決定を行う際の目的に対して関連性のないデータ項目を用いることが、許されざるプロファイリングと言える」という発言を記録しています。
1月21日の事務局提出資料では、個人情報等の適正な取扱いに関する規律の検討において、「取扱いの類型」や「その目的」を規律対象とすべきとの考えが示されています。これは関連性の概念に近い考え方を含んでいますが、明示的に「関連性」という用語は使用していません。
1月22日の今後の検討の進め方では、「個人データ等の取扱いの態様の多様化等に伴うリスクに適切に対応した規律の在り方」という形で整理されており、関連性という概念は直接的には言及されていません。
このように、個人情報保護委員会は、関連性という概念を直接的に採用するのではなく、「本人の権利利益への直接の影響」という基準を通じて、実質的に同様の規律を実現しようとしている様子が見られます。これは、既存の法体系との整合性を保ちながら、実務的な判断基準として機能させやすい形に置き換えているものと解釈できます。
ただし、この方向性が高木氏の指摘する関連性要件の本質的な機能を十分に果たせるかについては、今後の制度設計の詳細や運用実態を見る必要があるでしょう。
私：1月21日の「【資料１】個人情報保護委員会事務局提出資料」に「関連性」への言及がありませんか。
Claude：申し訳ありません。【資料１】を再確認したところ、関連性への重要な言及がありました。
スライド12-13の「個人情報等の適正な取扱いに関係する政策の基本原則」において、「個人情報等の利用目的との関連性・利用の適正性」という項目が設けられています。
そこでは以下のように記載されています：
「個人情報等の利用目的は、個人情報等の取扱いに関する規律の要となるものであり、できる限り特定することが必要。
個人情報等の取扱いに関係する政策の企画立案・実施に当たっては、政策目的の実現のために取扱いが必要となる個人情報等について、利用目的が政策目的と関連するものであるか否かを検討した上で取り組むことが重要。」
この記述は、高木意見が強調する「関連性」の概念を、特に政策立案における基本原則として位置づけようとする重要な一歩と評価できます。個人情報保護委員会は、直接的な法制化ではないものの、政策原則という形で関連性の要件を取り入れ始めていると解釈できます。
この点は、私の先ほどの分析に重要な修正を加える必要があることを示しています。個人情報保護委員会は、関連性の概念を完全に避けているわけではなく、むしろ政策原則というより基礎的なレベルで採用を検討していると考えられます。
私：スライド17にもありますよね。
Claude：申し訳ありません。ご指摘の通り、スライド17「ヒアリングから得られた視点」にも関連性への重要な言及があります。
プロファイリングに関する記述において、「具体的には、プロファイリング実行のためのプログラム作成に係る元データの利用目的やその関連性、プログラムそのものに関わる論点、プロファイリングによって得られた結果の取扱いなど、様々な視点が示された」と記載されています。
この点は非常に重要です。個人情報保護委員会は、プロファイリングの規律を検討する際の核心的な要素として、「元データの利用目的やその関連性」を明確に位置づけていることが分かります。これは高木意見が主張する関連性要件の重要性が、特にAIやプロファイリングの文脈で具体的に認識されていることを示しています。
このように、個人情報保護委員会は政策原則のレベルと、具体的なプロファイリング規制のレベルの両方において、関連性の概念を重要な要素として取り入れようとしていることが分かります。この二つのレベルでの言及は、関連性要件が今後の制度設計において重要な役割を果たす可能性を示唆していると考えられます。
私の先ほどの分析は不十分でした。個人情報保護委員会は、関連性の概念を、より包括的かつ体系的に制度設計に組み込もうとしている可能性が高いと修正させていただきます。
いまひとつ理解が足りない様子なので、ここで別の素材として、EDPSが先月公表した以下の文書を加えて、続けてみた。
EDPS（欧州データ保護監督機関）, EDPS comments to the AI Office’s consultation on the application of the definition of an AI system and the prohibited AI practices established in the AI Act launched by the European AI Office（AI規則におけるAIシステムの定義および禁止されたAI実践に関する適用についてのAI室の協議に対する欧州データ保護監督機関の意見）, 2024年12月19日
私：（「EDPSの文書」を添付して）
これはAI規制に対するEDPSの見解です。関連性について言及がありますね。
Claude：EDPSの見解における「関連性」への言及を分析いたします。
最も重要な点は、EDPSが生体認証システムやAIによる評価・分類について、基本的権利との関係で「関連性」を重視していることです。
特に以下の文脈で関連性の概念が登場します：
社会的スコアリングに関して
EDPSは、「関連しない社会的文脈（unrelated social contexts）」に基づく評価を問題視しています。例えば、移民背景という社会経済的要因に基づいて不正や福祉給付の審査を行うことは、関連性のない要因による差別的取り扱いになると指摘しています。
バイオメトリック分類について
EDPSは、生体データから人種、政治的意見、労働組合加入、宗教・哲学的信念、性生活や性的指向といった「機微な特徴」を推論することを禁止すべきとしています。これは、生体的特徴とそこから導出される属性との間に科学的な関連性がないにもかかわらず、差別的な結果をもたらす可能性があるためです。
新骨相学（new phrenology）への警告
EDPSは、生体的特徴から個人の傾向や性質を推論することを「新骨相学」と呼び、強く警告しています。これは、生体的特徴と推論される属性との間の関連性が科学的に実証されていないにもかかわらず、歴史的なバイアスや偏見を再生産する危険性があるためです。
このようなEDPSの立場は、高木氏が提唱する「関連性の要件」と理論的な親和性が高いと言えます。両者とも、データの利用とその目的との間の関連性を重視し、無関係な要因に基づく差別的取り扱いを防止しようとしている点で共通しています。ただし、EDPSの場合は特にAI規制の文脈で、生体認証技術による差別的取り扱いのリスクに焦点を当てているという特徴があります。
私：AI規制の本丸はそこですよね。というかそれが元々のGDPRの本丸ですよね。
Claude：ご指摘の通りです。この点について整理させていただきます。
データ保護法制の本質的な目的
OECDガイドラインからGDPRに至るデータ保護法制の核心は、「評価・決定の適切性確保」、特に「関連性のない要因による差別の防止」にあります。これは高木氏が一貫して指摘してきた点です。
AIがもたらす新たな課題
AIの普及により、この問題は新たな形で顕在化しています。AIシステムは、大量のデータを基に個人の評価・分類を行い、それに基づいて重要な決定を下すことが可能です。しかし、その決定プロセスにおいて、目的との関連性が疑わしいデータが使用される危険性が高まっています。
EDPSの認識
EDPSは、特に生体認証AIに関する意見の中で、この問題の本質を明確に理解していることを示しています。「新骨相学」という表現を用いて、科学的な関連性のない生体的特徴から個人の性質や傾向を推論することの危険性を指摘しています。これは、まさにデータ保護法制が当初から警戒してきた、関連性のない要因による差別的取扱いの現代版といえます。
制度的対応の必要性
このような認識は、個人情報保護法制とAI規制を統合的に捉える必要性を示唆しています。高木氏が提案する「データ品質の原則」、特に関連性要件の法制化は、この文脈で重要な意味を持ちます。それは単なる個人情報保護の問題ではなく、AIによる評価・決定の公平性を確保するための本質的な要件となるからです。
現代的な意義
特にAIの文脈では、この問題は以下の点でより重要性を増しています：
AIシステムは、人間には気づきにくい微細な特徴から予測や評価を行うことが可能
大量のデータを処理できるため、関連性のない要因が意図せず判断に影響を与える可能性
アルゴリズムの決定過程が不透明であるため、不適切な関連付けの検出が困難
このように、データ保護法制の本質的な目的は、AI時代においてむしろその重要性を増していると言えます。その意味で、GDPRやAI規制法の根底にある「関連性」の概念を改めて認識し、実効的な規制の枠組みを構築することが求められています。
私：話を戻して、個情委の方向性ですが、契約の履行に伴う提供は先ほどのとおり「取得の状況からみて本人の意思に反しない取扱いを実施する場合」が相当するとして、EU法で言う「正当な利益」についてはどうですか。
Claude：個人情報保護委員会の現在の方向性を分析すると、「正当な利益」に基づく第三者提供の取り扱いについては、まだ明確な姿勢を示していないように見えます。
1月22日の「今後の検討の進め方」では、「取得の状況からみて本人の意思に反しない取扱い」については本人同意を不要とする方向性を示していますが、これはEU法における「契約の履行」に近い概念です。一方で、「正当な利益」に相当する概念は明示的には示されていません。
この背景には以下のような事情があると考えられます：
第一に、高木氏が指摘するように、「正当な利益」を導入するためには、その前提としてデータ品質の原則、特に関連性の要件が法制化されている必要があります。個人情報保護委員会も、政策原則のレベルでは関連性の概念を取り入れ始めていますが、法制化までには至っていません。
第二に、「正当な利益」の判断には、利益衡量（バランシングテスト）が必要となります。現在の個人情報保護委員会は、より客観的な判断基準として「本人の権利利益への直接の影響の有無」を採用しようとしています。これは利益衡量よりも実務的な判断が容易な基準といえます。
しかし、長期的には「正当な利益」の概念を導入する必要性が出てくる可能性があります。個人情報保護委員会が示している「より包括的なテーマや個人情報保護政策全般」についての継続的な議論の中で、特に以下の点について検討が必要となるでしょう：
データ品質の原則と関連性要件の法制化
利益衡量のための具体的な判断基準の確立
正当な利益に基づく提供を認める場合の追加的な安全管理措置の要件
このように、「正当な利益」の導入は、より根本的な制度改革の一環として位置づけられる可能性が高いと考えられます。
私：EU法における「正当な利益」の判断にデータ品質の原則が必須であることは説明できますか。
Claude：EU法における「正当な利益」と「データ品質の原則」の関係について説明いたします。
データ品質の原則は、GDPR第5条1項(c)において「個人データは、取り扱われる目的との関係において、適切（adequate）で、関連性があり（relevant）、必要な範囲内に限定される（limited to what is necessary）」と規定されています。一方、「正当な利益」は第6条1項(f)において、「管理者又は第三者によって追求される正当な利益のために取扱いが必要である場合」に適法とされています。
これらの規定の関係性は以下のように説明できます。
「正当な利益」の判断においては、その利益を追求するために個人データの取扱いが「必要」であることが要件となります。この「必要性」の判断には、データ品質の原則が不可欠です。なぜなら、取扱いの目的（正当な利益の内容）に対して関連性のないデータを用いる場合、その取扱いは「必要」とは言えないからです。
具体例で説明すると、ある企業が不正利用防止という正当な利益を追求する場合を考えてみましょう。この目的のために、取引履歴や認証情報などのデータを用いることは、目的との関連性があり「必要」と判断される可能性があります。しかし、人種や信条といった情報を用いることは、不正利用防止という目的との関連性を欠くため、「必要」とは認められません。
このように、データ品質の原則、特に関連性の要件は、「正当な利益」に基づく取扱いの適法性を判断する際の基礎となる規範として機能しています。これがなければ、「正当な利益」という概念は恣意的な運用を許す抜け道となってしまう危険性があります。
日本の個人情報保護法に「正当な利益」の概念を導入する際にも、この点を十分に理解し、データ品質の原則を基礎として整備することが不可欠といえます。
私：結局のところ日本法は、何が問題とされるのかわからないまま外圧で見よう見まねで制度を作ったため、基準を見極められず、原則同意方式とせざるを得ないできたということではないでしょうか。
Claude：ご指摘の通りです。日本の個人情報保護法制の根本的な課題について、以下のように整理できます。
制度形成の経緯における問題
1980年のOECDガイドラインの本質的な意図、特にデータ品質の原則における関連性要件の意義を十分に理解しないまま、形式的な準拠を目指して制度設計が行われました。その結果、何が違法な取扱いに当たるのかという実質的な判断基準を欠いたまま、制度が作られることになりました。
原則同意方式の採用とその影響
判断基準が不明確であるため、事業者の予見可能性を確保する手段として、本人同意を原則とする方式を採用せざるを得ませんでした。これは一見すると本人保護に厚い制度のように見えますが、実際には形骸化した同意の横行を招き、かえって本人の権利利益の実質的な保護を困難にする結果となっています。
現代における課題の顕在化
AIの普及により、個人に対する評価・決定の適切性確保という本来の課題が一層重要性を増している中で、日本法は依然としてその本質的な問題に対処できていません。個人情報保護委員会も、「本人の権利利益への直接の影響」という新たな判断基準を模索していますが、これも関連性要件という本質的な基準を欠いたままの対応となっています。
今後の方向性
この状況を改善するためには、OECDガイドラインやEU法の本質的な意図を改めて理解し、データ品質の原則、特に関連性要件を基礎とした制度再設計が必要です。それによって初めて、形式的な同意原則から脱却し、実質的な権利利益保護を実現する制度が可能になると考えられます。
私：そのことは高木意見書に記載されていますか。
Claude：はい、高木意見書（6月12日付）にこの点に関する明確な記述があります。
特に「1.1 目的内の提供」の節において、以下のように述べられています：
「我が国の個人情報保護法（日本法）は、1980年のOECDガイドラインの8原則に準拠する形で規律が構成されているとされるものの、実際には、その8原則の肝心の趣旨を踏まえておらず、準拠というには不足する規制がある一方で、8原則が求めていない過剰な規制が含まれていることから、そのことが、昨今の経済界の改善要望につながっているものと思われる。」
さらに、同意原則に関する問題の根源について、以下のように説明しています：
「平成15年法の立法時に、急激な新規制の導入に伴う事業者への配慮として、利用目的を特定する義務を、大まかな特定で構わないとされた結果、その代わりに第三者提供を原則禁止とせざるを得なかった」
また、EU法との比較において、日本法の課題を以下のように指摘しています：
「EU法において『正当な利益』を適法性根拠とする際にはバランシングテストが要求されるように、『正当な利益』の規律を導入するためには、そのような個人データ処理が『正当な』ものと言えるかの何らかの判断基準が必要なのであって、そのような判断基準として参照されるべき『基本原則』（GDPRでは5条）の存在が大前提である。しかし、日本法はそのような前提に不可欠な『基本原則』を欠いている」
このように、高木意見書は、日本の個人情報保護法制が本質的な判断基準を欠いたまま形式的な同意原則に依存せざるを得なかった経緯と、その結果としての制度的課題を明確に指摘しています。
以上、ここまで。おわかりいただけるだろうか。
せっかくなので、別の話題として開始した会話も載せておく。（Claude 3.5 Sonnet Formal）
私：（シンガポールPDPCの「Advisory Guidelines on use of Personal Data in AI Recommendation and Decision Systems（AI推薦システムおよび意思決定システムにおける個人データ使用に関する諮問ガイドライン）」を添付して）
この文書は何が書かれていますか。
Claude：この文書は、シンガポールの個人データ保護委員会(PDPC)が2024年3月1日に発行した「AI推薦システムおよび意思決定システムにおける個人データ使用に関する諮問ガイドライン」です。主な内容は以下の通りです：
目的と概要:
PDPAは個人データの収集・使用・開示を規制するシンガポールの一般データ保護法です
このガイドラインは、組織がAIシステムを開発・展開する際の個人データ使用に関する確実性を提供し、消費者に保証を与えることを目的としています
主要な規定:
データ使用の同意
原則として、組織は個人データを使用する際に有意義な同意を得る必要があります
ビジネス改善や研究目的など、PDPAに基づく例外も認められています
ビジネス改善例外の適用
既存製品・サービスの向上や新製品開発
業務プロセスの改善
顧客行動や嗜好の理解
パーソナライズされた商品・サービスの提供
アカウンタビリティ義務
組織は個人データの使用に関する方針と実践を文書化する必要があります
消費者に対して透明性を確保し、適切な情報提供を行う必要があります
サービスプロバイダーの役割
AIシステムを開発するサービスプロバイダーは、データ仲介者としてPDPAの義務を負います
データマッピングやラベリング、来歴記録の維持など、適切なデータ保護措置を講じる必要があります
このガイドラインは、AIシステムにおける個人データの責任ある使用を確保しながら、イノベーションを促進することを目指しています。組織がPDPAを遵守しつつ、AIシステムを効果的に活用できるよう実践的な指針を提供しています。
私：GDPRとは異なるところが多いように見えますが、どうですか。
Claude：シンガポールのPDPAとEUのGDPRには、確かにいくつかの重要な違いがあります。
個人データの取り扱いに関する基本的なアプローチ：
PDPAは、ビジネスの実用性と個人のプライバシー保護のバランスを重視する実務的なアプローチを取っています。一方、GDPRは個人の権利保護により重点を置き、より厳格な規制を設けています。
特にAIシステムに関して以下のような違いが顕著です：
同意要件について：
PDPAでは、ビジネス改善例外や研究例外など、同意なしでデータを使用できる範囲が比較的広く設定されています。GDPRでは、個人データの処理には原則として明示的な同意が必要*4で、例外は限定的です。
自動化された意思決定：
GDPRでは、プロファイリングを含む自動化された意思決定に対して、個人が異議を申し立てる権利や人間の介入を求める権利が明確に規定されています。一方、PDPAのガイドラインでは、そのような具体的な権利は規定されておらず、より柔軟なアプローチを採用しています。
透明性の要件：
PDPAは、組織の判断でどの程度の情報を開示するか決定できる余地を残しています。特に営業秘密や専有情報の保護を考慮に入れています。GDPRは、アルゴリズムの決定に関するより詳細な説明を要求する傾向にあります。
越境データ移転：
GDPRはEU域外へのデータ移転に関して非常に厳格な規制を設けていますが、PDPAはより柔軟なアプローチを採用しています。
これらの違いは、両者の立法目的の違いを反映していると言えます。GDPRは個人の基本的権利としてのデータ保護を重視する一方、PDPAはビジネスの革新とプライバシー保護の調和を目指しているように見えます。
このような違いは、特にグローバルに事業を展開する企業にとって重要な考慮事項となります。両方の規制に従う必要がある場合、より厳格なGDPRの基準に合わせることで、両方の要件を満たすことができる可能性があります。
私：データ品質の原則はどうですか。
Claude：PDPAとGDPRのデータ品質に関する原則の取り扱いには、重要な違いが見られます。
PDPAのアプローチ：
シンガポールのPDPAガイドラインでは、データ品質は主にAIシステムの有効性と信頼性の観点から扱われています。文書の7.1節では、AIシステムの開発時にデータ最小化を実践すべきとしています。これは、必要な属性のみを含む個人データを使用することで、不必要なデータ保護リスクやサイバー脅威のリスクを低減することを目的としています。
しかし、GDPRと比較すると、PDPAでは以下の点でデータ品質の扱いが異なります：
法的位置づけ
GDPRではデータ品質は基本原則の一つとして明確に規定されていますが、PDPAではより運用上のガイダンスとして扱われています。
正確性の要件
GDPRは個人データの正確性を明確な法的要件としていますが、PDPAのガイドラインでは、AIシステムのパフォーマンスと関連付けて扱われており、より実用的なアプローチを取っています。
データ最小化の解釈
PDPAでは、データ最小化は主にリスク管理の観点から推奨されています。一方、GDPRではこれを基本的な法的要件として位置づけ、より厳格な遵守を求めています。
更新の要件
GDPRは定期的なデータの更新と不正確なデータの訂正・削除を明確に要求していますが、PDPAのガイドラインではこの点についての具体的な要件は比較的緩やかです。
この違いが実務に与える影響：
シンガポールの組織は、データ品質管理においてより柔軟なアプローチを取ることができます
一方で、グローバルに事業を展開する組織は、より厳格なGDPRの基準に合わせた対応が必要となる可能性があります
PDPAのアプローチは、特にAI開発におけるイノベーションを促進しやすい環境を提供していると言えます
ただし、注目すべき点として、PDPAのガイドラインでもデータの品質管理の重要性は認識されており、特にAIシステムの信頼性と有効性を確保する観点から、適切なデータ管理を推奨しています。これは、規制の形式は異なるものの、実質的にはGDPRと同様の目的を追求していると解釈することもできます。
私：やはりそうですね。私の理解では、データ保護法制の真の意義は、データに基づく個人に対する決定の適切性確保であり、特に、決定の目的に対して関連性のあるデータ項目しか構成してはならないというOECD第2原則前段が肝だと思っています。それに対し、アジア諸国の個人情報保護法制では、このことを完全に見落としており、シンガポールもその一つだったと記憶しています。
Claude：ご指摘の通りで、大変洞察に富む観点だと思います。
OECD第2原則（目的関連性の原則）は、データ保護法制の本質的な部分を捉えています。この原則は、単なるデータの収集制限を超えて、個人に対する決定の質と正当性を確保するという、より根本的な目的を持っています。
アジアの法制度、特にシンガポールのPDPAの現状を分析すると、以下のような課題が見えてきます：
PDPAの限界：
シンガポールのPDPAは、個人データの収集・使用・開示に関する手続的な規制に重点を置いていますが、データに基づく決定の質的な側面、特に目的関連性については十分な考慮がなされていません。今回のAIガイドラインでも、この視点は十分に反映されているとは言えません。
目的関連性の軽視の影響：
この原則の軽視は、特にAIシステムによる自動化された意思決定において重要な問題を引き起こす可能性があります。関連性のないデータが意思決定に使用されることで、不適切または偏った決定が行われるリスクが高まります。
より深い含意：
データ保護法制を単なるプライバシー保護の枠組みとしてではなく、個人に対する公正な決定を確保するための制度として捉え直す必要があります。これは特に、AIの利用が拡大する現代において極めて重要な視点です。
今後の課題：
アジアの法制度、特にシンガポールのような影響力のある国の法制度が、この基本原則をより明確に認識し、組み込んでいく必要があります。これは、単なる法改正以上に、データ保護に対する根本的な理解と approach の変更を必要とする課題だと言えます。
私：確か、どこかの東南アジアの国の個人情報保護法が、公開情報を除外していたと記憶しています。それは、決定の適切性確保が念頭にないからに他なりません。シンガポールはどうでしたかね。
Claude：シンガポールのPDPAにおいても、公開情報（publicly available information）は法の適用範囲から実質的に除外される形*5となっています。具体的には、組織が合法的に一般にアクセス可能な情報源から個人データを収集する場合、同意を得る必要がないとされています。
この取り扱いは、ご指摘の通り、データ保護法制の本質的な目的である「決定の適切性確保」という観点が欠けている*6ことを示す典型的な例と言えます。なぜなら、情報が公開されているか否かは、その情報を特定の決定に使用することの適切性とは本来無関係だからです。
例えば、ソーシャルメディアに公開されている個人の政治的見解や宗教的信念などの情報は、たとえ公開情報であっても、雇用や与信などの決定に使用することは適切ではない可能性が高いと考えられます。しかし、PDPAの現在のアプローチでは、このような質的な判断の視点が組み込まれていません。
これは、アジアの多くのデータ保護法制に共通する傾向であり、法制度が個人情報の取り扱いに関する手続的な規制に焦点を当てる一方で、その情報の使用が個人に対する決定においてどのような影響を与えるかという、より本質的な問題に十分な注意を払っていないことを示しています。
AIシステムの普及に伴い、この問題はより深刻になる可能性があります。AIシステムは大量の公開データを容易に収集・分析できますが、そのデータが特定の決定目的に対して適切かどうかの判断は、より慎重に行われる必要があります。
この観点から見ると、シンガポールの新しいAIガイドラインも、データの収集と使用に関する手続的な側面に重点を置いており、決定の適切性確保という本質的な課題に対する十分な対応はまだ見られないと評価できます。
私：ですよね。それなのにこのようなペーパーを出してきたことが意外だったのです。
Claude：このガイドラインの公表は、確かに興味深い展開です。シンガポールのデータ保護に対する基本的なアプローチを考えると、やや意外な動きだと言えます。
この背景には、以下のような要因があると考えられます：
第一に、グローバルな規制環境の変化への対応です。EUのAI規則案やその他の国際的なAI規制の動きを受けて、シンガポールも何らかの対応を示す必要があったと推測されます。
第二に、シンガポールのAIハブとしての地位確立への野心が挙げられます。このガイドラインは、AIの開発・利用に関する一定の規律を示すことで、国際的な信頼性を確保しようとする試みとも解釈できます。
しかし、このガイドラインの内容を詳細に見ると、データ保護法制の本質的な課題に対する理解は依然として限定的です。特に、個人に対する決定の適切性確保という観点からの考察が不十分であり、従来のデータ取扱いの手続的規制の枠組みを出ていません。
むしろ、このガイドラインは、シンガポールの規制アプローチの特徴をより鮮明に示しているとも言えます。つまり、イノベーションの促進と基本的な保護措置のバランスを取ろうとする姿勢です。しかし、これは必ずしもデータ保護の本質的な目的に応えるものとはなっていません。
このような状況は、アジアにおけるデータ保護法制の発展における重要な課題を提起していると言えるでしょう。形式的な規制の整備は進んでいますが、その本質的な目的についての理解を深める必要性は依然として残されています。
私：結局のところこのガイドラインに「AI推薦システムおよび意思決定システム」の適切性の観点で見るべきところはあるのでしょうか。
Claude：このガイドラインを「AI推薦システムおよび意思決定システムの適切性」という観点から評価すると、実質的な価値は限定的だと言わざるを得ません。
基本的な問題点として、このガイドラインは、AIシステムによる決定や推薦の質や適切性そのものを確保するための具体的な基準や方法論を提示していません。代わりに、個人データの取り扱いに関する手続的な側面に焦点を当てています。
たとえば、ガイドラインは「公平性」や「合理性」という言葉を使用していますが、これらの概念は主にデータ保護の文脈で言及されており、決定プロセスの本質的な適切性を評価する基準としては機能していません。
また、AIシステムが使用するデータの目的適合性や関連性についての実質的な評価基準も示されていません。これは、データ保護法制の本質的な目的である「適切な決定の確保」という観点が欠けていることの表れと言えます。
唯一評価できる点があるとすれば、それは10.6節で言及されている「より高い影響を及ぼす結果については、適切なアカウンタビリティメカニズムと人間の関与・監督がどのように実装されているかについての情報提供を検討する」という部分かもしれません。しかし、これも具体的な基準や要件としては示されていません。
結論として、このガイドラインは、AIシステムによる決定や推薦の適切性を確保するための実効的な枠組みとしては機能していないと評価せざるを得ません。今後、この分野での実質的な規制を検討する際には、決定プロセスの質的な側面により焦点を当てた approach が必要となるでしょう。
私：「公平性」や「合理性」のところの原文を検討したいです。
Claude：ガイドラインでは、"fairness and reasonableness" という表現が主に使用されています。特に重要な記述は以下の箇所です：
10.3節では：
"Organisations that make use of AI Systems should be transparent and include in their written policies relevant practices and safeguards to achieve fairness and reasonableness"
この文脈では、"fairness and reasonableness" は組織の方針や実践に関連付けられており、AIシステムそのものの決定の質や適切性を直接的に扱うものとはなっていません。
さらに10.6節(a)では：
"Measures taken to achieve fairness and reasonableness for recommendations, predictions, and decisions for the benefit of consumers during model development and testing stages."
ここでも、"fairness and reasonableness" は主にモデル開発とテストの段階における措置として言及されており、実際の決定プロセスの質的評価の基準としては機能していません。
これらの記述から、このガイドラインにおける "fairness and reasonableness" の概念は：
主にデータ保護とプライバシーの文脈で使用されている
手続的な側面に焦点が当てられている
実質的な決定の適切性を評価する基準としては定義されていない
このように、用語としては適切な決定を示唆する言葉が使用されているものの、その実質的な内容や基準は示されておらず、むしろ従来のデータ保護の枠組みの延長線上での使用に留まっていると評価できます。
私：fairnessは公平の意味なのですかね？
Claude："fairness" の解釈は重要な論点です。
英語の "fairness" には、「公平性」という意味だけでなく、より広い「適正さ」「公正さ」「妥当性」という意味合いがあります。このガイドラインの文脈では、単なる「公平性」という訳では不十分かもしれません。
特に、"fairness and reasonableness" という表現が繰り返し使用されていることに注目すべきです。これは法的な文脈でよく使用される表現で、意思決定や取扱いの「適正さ」を示す包括的な概念として理解されることが一般的です。
このガイドラインでは、"fairness" は以下のような文脈で使用されています：
モデル開発とテストの段階における措置の文脈（10.6節）
消費者の利益のための推奨、予測、決定に関連して
"reasonableness" と常にペアで使用
これらの使用文脈を考慮すると、このガイドラインにおける "fairness" は、単なる「公平性」というよりも、より広い「適正さ」「公正さ」を意味していると解釈するのが適切でしょう。
ただし、先ほどの議論にも関連しますが、このガイドラインではこの "fairness" の具体的な内容や評価基準は示されていません。つまり、AIシステムによる決定の実質的な適正さを確保するための指針としては機能していないという問題は残ります。
私：公正の意味であれば、むしろ公平の観点が想定されていないのでは。
Claude：ご指摘は非常に重要な洞察だと思います。"fairness" を「公正」と捉えると、このガイドラインの本質がより明確になります。
このガイドラインは、AIシステムによる決定や推奨に関して、主に以下の観点から「公正さ」を捉えているように見えます：
決定プロセスの適正性：手続きとしての正当性や透明性
結果の合理性（reasonableness）：決定結果が合理的な範囲内であること
説明可能性：決定の根拠が説明できること
しかし、ご指摘の通り、異なる個人やグループ間の「公平性」という観点は、実質的にほとんど考慮されていません。これは重要な欠落です。AIシステムによる決定において、特定の個人やグループが不当に不利な扱いを受けないようにするという観点が、明示的な形では組み込まれていないのです。
確かに、5.8節では bias assessment（偏りの評価）について言及していますが、これも主にデータの代表性という技術的な観点からの議論に留まっており、実質的な公平性の確保という観点からの検討には至っていません。
このことは、このガイドラインが、AIシステムによる意思決定の「公正さ」を、主に個別の決定プロセスの適正性という観点から捉えており、社会的な公平性や平等性という側面については十分な考慮を行っていないことを示唆しています。これは、データ保護法制としての限界を示すとともに、AIシステムの社会的影響に対する視野の狭さを表しているとも言えるでしょう。
私：日本も同様なんですよ。日本じゃfairnessの言葉すら出てこないです。*7
Claude：ご指摘の点は、日本のAI規制やデータ保護に関する重要な課題を浮き彫りにしています。
日本のアプローチの特徴を分析すると、技術的・手続的な側面に重点が置かれ、AIシステムによる決定の本質的な適正さや公正さの問題が十分に議論されていないことが分かります。例えば、AI原則やガイドラインにおいても、システムの安全性や透明性は強調されますが、決定の公正さという観点からの検討は限定的です。
この背景には、日本のデータ保護法制が、個人情報の取り扱いに関する手続的な規制を中心に発展してきたという歴史的経緯があります。個人情報保護法は、データの収集・利用・管理の適正な手続きを確保することを主な目的としており、そのデータに基づく決定の質的な側面については、直接的な規制の対象としていません。
このアプローチの限界は、AIシステムの普及に伴ってより顕著になっています。AIによる自動化された決定が社会に与える影響が拡大する中、単なるデータ保護の枠組みを超えて、決定の公正さや適正さを確保するための新たな規制の枠組みが必要とされています。
しかし、現状では、日本の規制アプローチはこの課題に十分に対応できていないと言えます。技術的な側面での規制は進んでいますが、決定の公正さという本質的な問題に対する取り組みは依然として不十分です。この点は、今後の規制の発展において重要な検討課題となるでしょう。
私：韓国の個人情報保護法も決定概念が欠如しています。基本原則に関連性要件もありません。そして、APEC CBPRも同様なのです。
Claude：ご指摘は、アジア太平洋地域のデータ保護規制の重要な構造的特徴を浮き彫りにしています。
この地域のデータ保護規制は、個人データの取り扱いに関する手続的な規制に主眼を置いており、データに基づく決定の適切性という本質的な観点が欠落しています。これは、シンガポール、日本、韓国といった主要国の法制度に共通する特徴であり、さらにはAPEC CBPRのような地域的な枠組みにも反映されています。
この構造的な特徴は、アジア太平洋地域のデータ保護規制が、OECDプライバシーガイドラインの本質的な部分、特に目的関連性の原則を十分に理解し取り入れることなく発展してきたことを示唆しています。
これは、単なる法技術的な問題ではなく、データ保護の本質的な目的に関する理解の不足を反映しています。データ保護法制は、単にデータの取り扱いを規律するだけでなく、そのデータに基づく決定が個人に対して適切に行われることを確保する仕組みであるべきです。
この観点の欠如は、AIシステムの普及により、より深刻な問題となる可能性があります。AIシステムによる自動化された決定が増加する中、データの取り扱いに関する手続的な規制だけでは、個人の権利や利益を適切に保護することが困難になってきています。
このような状況は、アジア太平洋地域のデータ保護規制が、より本質的な改革を必要としていることを示唆しています。単なる形式的な規制の整備を超えて、データに基づく決定の適切性を確保するための実質的な枠組みの構築が求められています。
私：EUのデータ保護幹部からはAPEC CBPRは毛嫌いされていると耳にしました。あんなのは管理の話で人権の話じゃないと言われているとかなんとか。人権というのは取扱うこと自体が人権に刺さるという意味じゃないですよね。
Claude：ご指摘の通り、EUのデータ保護幹部の見方は、データ保護の本質に関する重要な論点を提起しています。
「人権」という文脈でのデータ保護は、単にデータの取扱いを制限することを意味するのではありません。むしろ、そのデータに基づいて個人に対してなされる決定の適切性を確保することこそが、人権保護の本質的な側面だと考えられます。
この観点からAPEC CBPRを見ると、その限界が明確になります。APEC CBPRは主にデータの管理や取扱いの手続的側面に焦点を当てており、データに基づく決定が個人の権利や利益にどのような影響を与えるかという本質的な問題については、十分な考慮がなされていません。
EUのアプローチは、特にGDPRにおいて、自動化された意思決定に関する規定（第22条）や、データの目的関連性の要件を明確に定めることで、データに基づく決定の適切性を確保しようとしています。これは、データ保護を単なる管理の問題としてではなく、個人の権利や利益を実質的に保護するための枠組みとして捉える考え方を反映しています。
このような本質的な違いは、グローバルなデータ保護の枠組みを考える上で重要な示唆を与えています。データの国際的な流通が増加する中、単なる管理の手続きを超えて、データに基づく決定の適切性を確保するための実効的な仕組みが必要とされているのです。
私：この話の流れで22条を持ち出す人は多いですが、22条は自動決定という上乗せ規制であって、自動決定でない自動処理による決定はデータ保護法制の全体に係ることですよね。including profilingも然り。
Claude：ご指摘の通りです。第22条への過度な注目は、むしろデータ保護法制の本質を見誤らせる可能性があります。
データ保護法制の基本的な枠組みは、すべての個人データの取扱いに適用される原則として、データに基づく決定の適切性を確保することを求めています。これは、自動化された決定であるか否かにかかわらず、またプロファイリングが含まれるか否かにかかわらず、適用される基本的な要請です。
第22条は、完全に自動化された決定に対する特別な保護措置を定めたものであり、いわば上乗せの規制と位置付けられます。これを過度に強調することは、データ保護法制の本質的な部分、すなわちすべてのデータ処理における決定の適切性確保という基本原則を見失わせる危険があります。
特に、プロファイリングを含む（including profiling）という文言は、プロファイリングが自動化された決定の一形態として特別な規制対象となるという誤解を生みやすいものです。しかし、実際には、プロファイリングを含むあらゆる形態のデータ処理において、その処理に基づく決定の適切性が確保されなければならないというのが、データ保護法制の基本的な要請なのです。
このような理解は、現代のデータ利用実態により即したものと言えます。AIシステムの普及により、完全な自動化された決定だけでなく、人間の判断を支援するシステムも広く利用されていますが、いずれの場合も、データに基づく決定の適切性確保という基本原則が適用されるべきだからです。
私：なのになぜ22条を持ち出したのですか。
Claude：申し訳ありません。私の以前の回答で、第22条に言及したのは適切ではありませんでした。
これは、AIやデータ保護に関する一般的な議論において、第22条が過度に注目される傾向に影響されてしまった結果だと反省しています。第22条は確かにAIによる自動化された意思決定に関する具体的な規定として注目を集めていますが、データ保護法制の本質的な目的を論じる際の主要な参照点とすべきではありませんでした。
データ保護法制の本質は、むしろOECDプライバシーガイドラインの第2原則に示されているような、データに基づく決定の適切性確保という基本的な考え方にあります。特に、決定の目的に対して関連性のあるデータ項目のみを用いるという原則は、すべてのデータ処理に適用される基本的な要請です。
このような本質的な観点から見れば、APEC CBPRの限界を指摘する際に第22条を引き合いに出す必要はなく、むしろデータ保護の基本原則に立ち返って議論すべきでした。データの管理や取扱いの手続的側面だけでなく、データに基づく決定の質的な側面にも着目する必要性を論じることで、より本質的な議論が可能だったと考えます。
私：日本はDFFTを世界に提唱していますが、どうですかね。
Claude：DFFTは「Data Free Flow with Trust」を掲げていますが、この「Trust」の内実が十分に検討されていないように見受けられます。
特に重要な問題は、DFFTが主にデータの流通と管理の技術的・手続的側面に焦点を当てており、データに基づく決定の適切性確保という本質的な観点が欠落していることです。
このアプローチは、日本のデータ保護法制の特徴を反映しています。すなわち、個人データの取扱いに関する手続的な規制は整備されているものの、そのデータを用いた決定の質的な側面については十分な考慮がなされていません。
結果として、DFFTは「Trust」を主にデータの安全な管理や移転に関する信頼として捉えており、データの利用によって個人に対してなされる決定の適切性に関する信頼という、より本質的な側面を見落としています。
このような限界は、国際的なデータ流通の枠組みとしてのDFFTの有効性に疑問を投げかけます。真の意味での「Trust」を確立するためには、データの管理面での信頼性だけでなく、データに基づく決定の適切性を確保するための実質的な枠組みが必要とされます。
しかし、現状のDFFTはこの課題に十分に応えられていないと言わざるを得ません。国際的なデータ流通の促進という目標は重要ですが、それは個人の権利や利益の実質的な保護と両立する形で追求される必要があります。
さてどうだろうか。プロンプトに引っ張られすぎているだろうか？
ところで、上の会話でシンガポール法の理解が怪しい気がした（プロンプトに引っ張られすぎている疑惑がある）ので、別の会話で確認したところ、前掲の注のように、誤りがあった。
私：（シンガポールPDPA 2012のWord出力の前半部分を添付して）
これはシンガポールのデータ保護法（長いので前半まで）です。publicly available informationがどのような規定になっているのか確認したいです。
Claude：シンガポールのデータ保護法(PDPA)において、"publicly available" に関する規定を確認いたしました。
法律の第2条(1)の定義条項において、個人データに関する "publicly available" は以下のように定義されています：
「publicly available（公開されている）」とは、個人に関する個人データについて、以下を意味します：
一般に公衆が入手可能な個人データ
合理的に予測される手段によって、以下の場所や場合に観察できる個人データ：
その個人が出現する場所やイベントにおいて
かつ、その場所やイベントが公衆に開かれている場合
この定義は、個人データの収集・使用・開示に関する規制の適用除外の文脈で重要となります。例えば、第17条および付則(Schedule)において、公開されている個人データについては、同意なしでの収集・使用・開示が認められる場合があることが規定されています。
ただし、重要な点として、データが「publicly available」であることのみを理由として、組織が自由に当該データを取り扱えるわけではありません。PDPAの他の義務規定（データの正確性確保、セキュリティ確保、目的制限など）は依然として適用されます。
また、第48条における防御(defence)規定においても、情報が「publicly available」である場合の取り扱いについて言及されていますが、その情報が法律違反によって公開された場合は、当該抗弁が制限される可能性があることにも留意が必要です。
このように、PDPAは「publicly available」な個人データについて、一定の柔軟性を認めつつも、適切な保護措置を維持するバランスの取れた規定となっています。
私：正確性の規定はどうなっていますか。
Claude：PDPAにおける正確性に関する規定は、第23条「Accuracy of personal data（個人データの正確性）」に定められています。
内容を詳しく説明いたします：
第23条では、組織は以下のいずれかの場合において、組織が収集した個人データが正確かつ完全であることを確保するため、合理的な努力を行わなければならないとされています：
その個人データが、当該個人データの対象となる個人に影響を与える決定を組織が行うために使用される可能性がある場合
その個人データが、組織によって他の組織に開示される可能性がある場合
このような規定となっている理由として、以下の2点が考えられます：
影響度に基づくアプローチ：
個人に影響を与える決定に使用される可能性がある場合や、他組織への開示が予定されている場合など、データの不正確さがより大きな影響を及ぼす可能性が高い状況に焦点を当てています。
実務的な配慮：
「合理的な努力（reasonable effort）」という基準を採用することで、組織に過度な負担を課すことなく、実務的に実現可能な範囲での正確性確保を求めています。
また、この正確性の規定は、第22条の訂正請求権とも密接に関連しています。個人は、不正確または不完全な個人データの訂正を組織に要求する権利を有しており、これにより個人データの正確性が維持される仕組みとなっています。
正確性確保は、個人の権利保護と、そのデータに基づいて行われる意思決定の質を確保する上で重要な要素として位置づけられています。特に、データに基づく意思決定が個人に影響を与える可能性がある場合や、データが組織間で共有される場合には、より高い水準での正確性確保が求められる設計となっています。
私：publicly availableな情報についてもそうするのでしょうか。
Claude：PDPAの規定を確認したところ、publicly availableな情報についても正確性の要件が適用されると解釈できます。その理由は以下の通りです：
第23条の正確性要件は、個人データの性質や入手源による例外を設けていません。むしろ、その個人データがどのように使用されるかに基づいて要件を定めています。具体的には、以下のいずれかの場合に正確性確保の義務が発生します：
その個人データが個人に影響を与える決定に使用される可能性がある場合
その個人データが他の組織に開示される可能性がある場合
したがって、個人データがpublicly availableであるという事実だけでは、組織は正確性確保義務を免れることはできません。データの出所ではなく、その使用目的や影響に基づいて正確性の要件が課されるためです。
また、この解釈は法の目的とも整合的です。PDPAの目的は、個人の個人データを保護する権利と、組織が個人データを収集、使用、開示する必要性との間でバランスを取ることにあります（第3条）。publicly availableな情報であっても、それが個人に影響を与える決定に使用される場合や他組織に開示される場合には、その正確性を確保することが個人の権利保護において重要となります。
したがって、組織がpublicly availableな個人データを取り扱う際には、その使用目的に応じて、適切な正確性確保の措置を講じる必要があると考えられます。
私：「影響を与える決定に使用される」という概念は、この法律の中に存在しますか。
Claude：PDPAの条文を精査したところ、「影響を与える決定に使用される（used to make a decision that affects the individual）」という概念は、正確性に関する第23条で初めて登場する独自の概念であることがわかりました。
第23条の表現：
"...if the personal data is likely to be used by the organisation to make a decision that affects the individual to whom the perso
2025-01-22
2024年ページビューランキングTOP20（2024年1月〜12月）
ランキング
このサイトのタイトル毎に2024年のページビューを調べて、ランキングにしてみた。
1位 仮想マシンにCtrl+Alt+Delを送信する方法
2位 Windowsでファイルを16進数テキストに変換したり、16進数テキストをファイルに変換したりする方法
3位 certutilコマンドの非公開なオプションを表示する方法
4位 仮想マシンから抜ける方法
5位 Windowsでbase64エンコード・デコードする方法
6位 wiresharkでTCP制御フラグを指定してパケットを表示する方法（Display Filter）
7位 WindowsでハードディスクのPHYSICALDRIVE番号などを調べる方法
8位 tcpdumpやwiresharkでTCP制御フラグを指定してパケットを収集する方法
9位 Linuxでbase64エンコード・デコードする方法
10位 サービスの「START_TYPE」と「スタートアップの種類」
11位 DELLのPowerEdge SC440にVMware ESXiをインストールしてみた
12位 エクスプローラの検索ボックスから「作成日時」や「更新日時」などで検索する方法
13位 キャプチャファイルのSLLをEthernetに書き換える方法
14位 Wiresharkの各種履歴を削除する方法
15位 IISのログファイルのデフォルト形式と時間帯
16位 Windows 10のバージョン1809にSNMPサービスをインストールする方法
17位 WinPcapのインストール時に聞かれる「Automatically start the WinPcap driver at boot time」で困った場合の対処法
18位 Windows 7以降のnetsh traceコマンドでパケットをキャプチャする方法
19位 Linuxでファイルを16進数テキストに変換したり、16進数テキストをファイルに変換したりする方法
20位 電車のエアコンから出る風はなんとかならないのか
このランキングはGoogle Analyticsの情報をもとに作成。
EijiYoshida 2025-01-22 18:25 読者になる
2025-01-21
ページビューランキングTOP10（2024年12月）
ランキング
このサイトのタイトル毎に2024年12月のページビューを調べて、ランキングにしてみた。
1位 仮想マシンにCtrl+Alt+Delを送信する方法
2位 Windowsでファイルを16進数テキストに変換したり、16進数テキストをファイルに変換したりする方法
3位 certutilコマンドの非公開なオプションを表示する方法
4位 仮想マシンから抜ける方法
5位 Windowsでbase64エンコード・デコードする方法
6位 WindowsでハードディスクのPHYSICALDRIVE番号などを調べる方法
7位 Linuxでbase64エンコード・デコードする方法
8位 wiresharkでTCP制御フラグを指定してパケットを表示する方法（Display Filter）
9位 tcpdumpやwiresharkでTCP制御フラグを指定してパケットを収集する方法
10位 WinPcapのインストール時に聞かれる「Automatically start the WinPcap driver at boot time」で困った場合の対処法
このランキングはGoogle Analyticsの情報をもとに作成。
EijiYoshida 2025-01-21 20:56 読者になる
2024-12-01
ページビューランキングTOP10（2024年11月）
ランキング
このサイトのタイトル毎に2024年11月のページビューを調べて、ランキングにしてみた。
1位 仮想マシンにCtrl+Alt+Delを送信する方法
2位 Windowsでファイルを16進数テキストに変換したり、16進数テキストをファイルに変換したりする方法
3位 certutilコマンドの非公開なオプションを表示する方法
4位 仮想マシンから抜ける方法
5位 tcpdumpやwiresharkでTCP制御フラグを指定してパケットを収集する方法
6位 wiresharkでTCP制御フラグを指定してパケットを表示する方法（Display Filter）
7位 Windowsでbase64エンコード・デコードする方法
8位 Linuxでbase64エンコード・デコードする方法
9位 WindowsでハードディスクのPHYSICALDRIVE番号などを調べる方法
10位 IISのログファイルのデフォルト形式と時間帯
このランキングはGoogle Analyticsの情報をもとに作成。
EijiYoshida 2024-12-01 00:00 読者になる
ランキング (225)
2025
2025 / 1
▼ ▶
2024 / 12
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 著作権. 不許複製
ブログを開設した年のグループに入りましょう
はてなブログには、同じ話題でつながる「グループ」があります。まずはブログを開設した年のグループに入りましょう。同時期に始めたブログとつながることができます。
「2025年開設ブログ」のグループ
「字幕職人の朝は早い……」にコメントを書く
2024/11/05追記：
その後U-NEXTは状況が少し改善した。少なくともダイジェストはアップトゥデートに近くなってきた。
それに比べてDAZNは状況が悪化（笑）。何かのコンテンツを視聴したのち、タッチパネル的な部分を左にスルっと掃くといきなりアプリが落ちるようになってしまった。何度やっても再現する。DAZNはiPhoneアプリは特に問題無いんだけどねー。まーマイノリティっぽいからほっとかれてるのかな。
2024/11/06追記：
WOWOWのアプリもUEFAのCLの試合、ダイジェストを見る手段が見当たらない（笑）。AppleTVのアプリってほんと不自由だなぁ。ファイアースティックとかの方がまだしも便利なんだろうか。
2024/11/7追記：
WOWOWのアプリでダイジェストは見られるようになった（なったのかもともと見られたのか）。失礼しましたー
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匹。
グリーンコーディング
IT技術 (56)
2023 / 6
メモは未来の自分に出すヒントはてなブログでは毎週「今週のお題」を出題しています。今回は、2023年4月7日から2023年4月14日にかけて募集した、今週のお題「メモ」に寄せられたエントリーから、週刊はてなブログ編集部がおすすめしたい記事をピックアップして紹介します。メモを取る習慣ってありますか？ 私は取ったり取らなかったりだったんですが、最近はできるだけ取りたいと思っています。原稿やブログがスムーズに書けるときって、しっかりメモを取れているときだったりするからです。過去の自分から、考えるヒントを…
Information
【第12回】はてなブログお知らせレター：京都の銭湯「サウナの梅湯」に、はてなブログの広告が掲載されています！
▼ ▶
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