まず、平成27年改正と令和2年改正で、「〇〇情報取扱事業者」という用語が増えた。全部で4つになった。これが令和3年改正で、用語定義が一箇所に集められ、見通しが良くなった。そこを抜粋すると以下である。 （定義） 第16条 この章及び第8章において「個人情報データベース等」とは、個人情報を含む情報の集合物であって、次に掲げるもの（……）をいう。 一　特定の個人情報を電子計算機を用いて検索することができるように体系的に構成したもの 二　前号に掲げるもののほか、特定の個人情報を容易に検索することができるように体系的に構成したものとして政令で定めるもの 2　この章及び第6章から第8章までにおいて「個人情報取扱事業者」とは、個人情報データベース等を事業の用に供している者をいう。ただし、次に掲げる者を除く。 （略） 5　この章、第6章及び第7章において「仮名加工情報取扱事業者」とは、仮名加工情報を含む情

少ないサンプル数のデータから、そのバラつきが有意な変化を示すものなのかどうか、直感的に把握するために棒グラフは適している。その場合、波線省略をしてはいけない。面積や高さの比によって把握するからだ。 「増加傾向はまぎれもない真実」と思った人達は、まさに、波線省略されたNHKの棒グラフ（下の図）を見たからこそ、「増加傾向」を直感的に感じたのじゃないのか。 「波線だって入っている」「読み手のリテラシーで理解するべきものだ」と言うような人たちが、自分自身の直感が狂わされていることに気づかない。 他に、NHKの制作現場の関係者をうかがわせる人（高校講座の情報Aの制作関係者？）からのコメントもあった。 身内がつるし上げられてるので、今日は（も？）こっちも大人げないモードで。 おお、高校講座がはてぶに載る日が来るなんて。 bm自身は地理には直接関わってないけど、ちょっとびっくり。 情報Aもどうぞよろしく

■ 「個人情報」定義の弊害、とうとう地方公共団体にまで 現行個人情報保護法の「個人情報」の定義に不備があることを、これまでずっと書き続けてきた。「どの個人かが（住所氏名等により）特定されてさえいなければ個人情報ではない」（のだから何をやってもよい）とする考え方がまかり通ってしまいかねないという危機についてだ。 2003年からはRFIDタグ、2008年からはケータイIDによる名寄せの問題を中心に訴えてきたが、当時、新聞記者から説明を求められるたび、最後には「被害は出ているのでしょうか」と、問われたものだった。当時は悪用事例（不適切な事例）が見つかっておらず（表沙汰になるものがなく）、これが問題であるという認識は記者の胸中にまでしか届かなかった。 それが、昨年夏から急展開。スマホアプリの端末IDを用いた不適切事案が続々と出現し、それぞれそれがなぜ一線を越えているか説明に追われる日々になった。ス

■ spモードはなぜIPアドレスに頼らざるを得なかったか spモードの事故 NTT docomoのスマホ向け独自サービス「spモード」が、今月20日に大規模な事故を起こして、重大事態となっている。 スマホ向けネット接続が不具合 ドコモ 別人のアドレス表示, MSN産経ニュース, 2011年12月20日 ドコモのspモードで不具合、他人のメールアドレスが設定される恐れ, 日経IT Pro, 2011年12月21日 ドコモの「spモード」でトラブル、関連サービスが一時停止, ケータイ Watch, 2011年12月21日 ドコモ、spモード障害で「ネットワーク基盤高度化対策本部」設置, ケータイ Watch, 2011年12月26日 ドコモ 約1万9000人に影響, NHKニュース, 2011年12月27日 ドコモの“メアド置き換え”不具合、影響数や新事象が明らかに, ケータイ Watch,

■ Wi-FiのMACアドレスはもはや住所と考えるしかない 目次 まえがき これまでの経緯 2つのMACアドレスで自宅の場所を特定される場合 SSIDに「_nomap」でオプトアウト？ PlaceEngineはどうなった？ まえがき 先週、以下の件が話題になった。 Greater choice for wireless access point owners, Official Google Blog, 2011年11月14日 Removing your Wi-Fi network from Google's map, CNET News, 2011年11月14日 グーグル、Wi-Fiネットワークの位置情報収集で対応策を公開, CNET Japan, 2011年11月16日 Google's WiFi Opt-Out Process Makes Users Navigate Technic

■ ケータイ脳が大手SI屋にまで侵蝕、SI屋のセキュリティ部隊は自社の統率を 昨年示していた、 やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合, 2009年8月2日の日記 日本の携帯電話事業者の一部は、「フルブラウザ」にさえ契約者固有ID送信機能を持たせて、蛸壺の維持を謀ろうとしているが、iPhoneのような国際的デファクト標準には通用しないのであって、今後も、他のスマートフォンの普及とともに、蛸壺的手法は通用しなくなっていくであろう。 そのときに、蛸壺の中の開発者らが、このニコニコ動画の事例と同様のミスをする可能性が高い。「IPアドレス帯域」による制限が通用しない機器では、アプリケーションの内容によっては特に危険な脆弱性となるので、関係者はこのことに注意が必要である。 の懸念が、今や、さらに拡大し、ケータイ業者のみならず、一般のシステムインテグレータの思考

■ ユニークIDがあれば認証ができるという幻想 2008年のNTTドコモによるiモードID送信開始以降、ケータイWebの世界に「かんたんログイン」なるエセ認証方式が急速に広がり、その実態は「はてなのかんたんログインがオッピロゲだった件」のように惨憺たるものになっている。こうした欠陥サイトはかなりあると考えられ、すべてを調べて廻ることはできないが、いくつかのメジャーどころのサイトについては、IPAの脆弱性届出窓口に通報して、対策を促す作業をやっている。 各サイトの「かんたんログイン」に欠陥があるかどうかは、実際に他人のIDでなりすましログインしてテストすることは許されない（不正アクセス禁止法違反になる）ので、自分用のアカウントを作成して（会員登録して）、自分のIDについてテストするのであるが、誰でも会員登録できるわけでないサイトがかなりあるようで、そういったサイトはどうしたらよいのか。以下は

そもそもこのサービスにとってCAPTCHAが何の意味をなすのか疑問*1だが、それはともかく、この部分のHTMLソースを見ると、画像のURLに答えが書かれている。（図2の「gifcat/call.php?SID=948545」） これでは何の意味もない。 これの目的がもし、他サイトからのリンクで検索させられる事態を防ぐためであるなら、画像なんか表示せず、直接INPUTフィールドに値を埋め込むようにしておけばいい話だ。*2 <input name="attestationkey" value="948545" type="hidden"> ちなみに、図2で示される画像のURLに直接アクセスしてみると、図3のように、リロードする毎に（同じ番号の）違う画像が現れる。何回か繰り返してみると、1つの数字あたり4種ほどの画像が用意されているだけだとわかる。 背景のノイズのようなものも、動的に生成されてい

写真中のミニモニタ上部中央に表示しているグラフは、5月28日の時点では図2のようになっていた。黄色の線（真ん中の線）を見ると、5月12日正午ごろから14日正午ごろにかけて明らかな異常ピークが見られる。 青の線（下の線）は、1回の巡回で観測されたキーから、キーにソースノード（当該ファイルの提供元を意味するIPアドレスとポート番号）として記されたノードの数を計数したもので、1回の巡回は20分〜30分程度である。この値は、おおよその瞬間アクティブノード数を表しているかのようにも思えるが、一巡する時間内に全ノードを巡りきれているとは限らないので、そうとは言えない*2。 この青の線は、毎日深夜にピークがあり、平日の昼間には小さい値となって、土日や祝日には昼間でも値があまり小さくならないという、安定した傾向が見られる。 黄色の線は、青の線が示すノードについて過去24時間以内に存在した数を求めた値であり

■ Firefox 3.5でSSLの確認方法が「緑なら会社名」「青ならドメイン名」と単純化される 今年中には正式版がリリースされると目されているFirefox 3.5だが、現時点でリリースされている3.5b4のベータバージョンで確認したところ、browser.identity.ssl_domain_display の初期設定値が「1」となるようだ。つまり、たとえば、楽天のログイン画面に移行すると、アドレスバー*1が図1のようになる。 これにより、パスワードやクレジットカード番号などを入力する前に、今訪れているサイトが本物であるかどうかを、アドレスバーに表示されるドメイン名で確認できるようになる。 この機能はFirefox 3.0でも実装されていたが、初期設定ではオフにされていた。従来は図2のように、青くなるだけでドメイン名は表示されず、クリックしてドメイン名を確認する必要があった（URL中

■ 「NoScript」をやめて「RequestPolicy」にした セキュリティ屋が、Firefoxユーザに「NoScript」の使用を推奨することがしばしばあるが、私は賛同しない。 JPCERT/CC、技術メモ「安全なWebブラウザの使い方」を公開, INTERNET Watch, 2008年11月4日 *1 技術メモ − 安全なWebブラウザの使い方, JPCERT/CC, 2008年11月4日 IV. 各 Web ブラウザに共通する設定上の注意事項 1. スクリプト等の実行を制限する JavaScript 等のスクリプトや（略）は（略）Ajax に代表されるインタラクティブなインターフェースが実現できるなど、高い利便性が得られます。反面、PC 上の重要なファイルを削除・変更するなど、悪意を持った処理が行われる可能性もあります。従って無制限にスクリプト等を実行できるようにしておくのは

■ Windows Mobileの「オーナー情報」設定に注意 RFID付き米国旅券の情報を遠隔地から収集する試み, スラッシュドット, 2009年2月7日 米国籍パスポート(所有者)が接近すると爆発する爆弾（略） とあるように、無線で近くの人のIDが読めてしまうことの危険性は、米国ではテロの現実性もあって、かねてより話題になっている。 ところで、一昨年、はじめてWindows Mobile機を買った際に気になったものの、小ネタだったので放置していた件があるのだが、やっぱり書いておく。 Windows Mobile搭載機器（スマートフォンなど）を買ったとき、最初にやることといえば、いろいろな設定を試してみることだろう。最初に目につくのは「オーナー情報」（図1）の設定。ここに名前と連絡先を書いておくと、電源を入れたときに表示されるようにできる。

■ Googleドキュメントの「招待メール」の危険 ことの始まり 先々週の話。1月23日に次の記事が出ていた。 『Google Docs』の設定にご用心：知らないうちに書き換えも？, WIRED VISION, 2009年1月23日 この記事の趣旨は、「Googleスプレッドシート」の共有設定の画面の説明文「Let people edit without signing in」が誤解を招くために、誤って、誰にでも閲覧や編集を許す設定にしてしまいかねないという話である。この画面は、日本語表示では図1の表記となっている。 WIRED VISIONの記事の言い分では、「people」が上の招待メール送信先の人々のことを指すように読めて、下の「プライバシー」設定も変更しないといけないように誤解してしまうという。 そもそも、この機能の意図されている動作はどういうものか。私も試しているうちに一時混乱し

■ 旧はてなブックマークで社内情報が漏洩していた可能性 昨年11月上旬に、はてなブックマークでプライベートアドレスが登録されていることが話題になっていた。 はてなブックマーク - はてなブックマーク - http://192.168. たとえば次などがそれだ。 http://b.hatena.ne.jp/entrylist?sort=eid&url=http://192.168.0.1/ http://b.hatena.ne.jp/entrylist?sort=eid&url=http://192.168.0.2/ http://b.hatena.ne.jp/entrylist?sort=eid&url=http://192.168.0.3/ http://b.hatena.ne.jp/entrylist?sort=eid&url=http://192.168.0.4/ http://b.

■ Nyzillaをリリースすべきか迷う 29日補足: 以下について「u-aizu.ac.jpは国立大学ではない」といった指摘を受けた。「ある国立大学」とは図1のことではないのだが、最初の段落が長過ぎて読み難かったようなので、改段落を2つ挿入して段落を3つに分割する修正を施した。 大学や会社で稼働するWinny ある国立大学の事務系部局のものと思われるドメイン名のIPアドレスが、2006年からずっとWinnyネットワーク上に観測されている。これは何なのかと以前から気になっていた。[改段落挿入29日] 最近はどうなっているのかと、2009年1月20日〜24日の期間に「WinnyWalker」で観測されたWinnyノードの全部について、IPアドレスをDNSで逆引きしてドメイン名を集計してみたところ、他にも大学のドメイン名上で稼働しているWinnyノードがいくつか見つかった。[改段落挿入29日]

■ Amazonジャパンはほしい物リスト問題を放置、9か月経った今も改善せず 昨日のINTERNET Watchの記事「やじうまWatchで振り返る2008年」で、Amazon.co.jpの「ほしい物リスト」問題（「ほしい物リスト」=「Wish List」）の件が取り上げられた。「日米文化摩擦」という観点が挙げられているが、これは単にそういう問題というわけではなかった。米国でも過去に同様の懸念が指摘された経緯があり、米国版 Amazon.com では既にシステムが改善されてデフォルトで非公開になっていたのに対し、日本版 Amazon.co.jp では改善が行われていなかったのだ。 このことについては、3月12日の日記「Amazonで私の情報は私の意志に反してどう表示されていたか」で触れた後、説明が足りなかったので続編を書くつもりだったが、忙しくて結局書かなかった。改めて現在の状況を確認して

■ SSLを要するモバイル環境でのパスワードマネージャの使い方に注意 Basic認証の話 この日記にSSLを導入した*1。基本的には自分用（編集時の安全を確保する）のもので、FirefoxとSafari（Mac OS版のSafari）からしか使えない*2*3。これにより、外出先の公衆無線LANからでも日記を編集できるようになった。 これまでは、自宅のコンピュータでしかログインしないようにして、http:// のままBasic認証を使っていた。パスワードが生のまま送信されるが、自宅の通信環境はまあ信頼できるので、（その先の通信路上で盗聴されるリスクがあるにしても）リスクは受容できると考えてきた。しかし、外出先で公衆無線LANを使うとなると、そのリスクは受容できない。6日の日記「公衆無線LANで使うと危ないiPod touchアプリに注意」にも書いたように、公衆無線LAN内の通信は簡単に傍受さ

■ 楽天CERTに対するブラウザの脆弱性修正を阻害しない意思確認 楽天は比較的早い時期からコンピュータセキュリティに真剣に取り組んできた希有な存在だと認識している。昨年には、企業内CSIRTを正式に組織し、組織名を「Rakuten-CERT」とした。*1 楽天、社内に「CSIRT」を設置, ITmediaエグゼクティブ, 2007年12月6日 「楽天ad4U」の「脆弱性を突いてブラウザの閲覧履歴を調べるという禁じ手」の問題（前回の日記参照）は、その手法自体が直接人々のプライバシーを侵害するか否かという問題ではない。実際、「楽天ad4U」について言えば、閲覧履歴の有無は参照するけれども履歴自体の送信はしないように作られており、開発元はこれを「プライバシー保護にも優れています」と宣伝している。 しかし、この問題の根本は、10月の日経の記事にも書いたように、この手法が広く使われるようになって、こ

■ 楽天ad4Uの隠しリンクを露出させるユーザスタイルシート 脆弱性を突いてブラウザの閲覧履歴を調べるという禁じ手に手を出した、掟破りの（自称「次世代」）行動ターゲティング広告「楽天ad4U」について、amachangの「IEのinnerHTMLやappendChildで要素が挿入された瞬間を取得する方法」を参考に、その隠しリンクを露出させるユーザスタイルシートを作ってみた。（Internet Explorer用。） #ad4u_list { display: expression(function() { if (!this.__mark) { this.__mark = true; // alert(this.innerHTML); var o = '<div style="overflow:scroll; border:dashed 4px red;">'; o = o + this