示現舎の全国電話帳アプリについて＋警告

住所でポン（公開電話帳サイト）で有名？になった人が公開している、
全国電話帳 https://play.google.com/store/apps/details?id=info.jigensha.hellopage というアプリは、複数の人が電話帳を送信していると確認しているようだ。

インストールされている人は直ちに削除をおすすめする。

（追記：個人的なまとめ http://causeless.seesaa.net/article/296187376.html でまとめてみた）

ただ、法的に問題があるのかは疑問におもう。作者は最低限周辺法を調べて問題ない、とTwしていて、個人情報保護法や高木先生のような存在を知らないとも思えない。

まずスラドのコメント
http://yro.slashdot.jp/comments.pl?sid=578428&cid=2227099
が指摘していたように、住所でポン！が、単純なNTTの電話帳由来であり、追加情報を加えていない場合、公開しても問題はないと考えられる。

http://www.meti.go.jp/policy/it_policy/privacy/kaisei-guideline.pdf

個人情報データベース等が、以下の要件のすべてに該当する場合は、その個人情報データベース等を構成する個人情報によって識別される特定の個人の数は、上記の「特定の個人の数」には算入しない。

�@個人情報データベース等の全部又は一部が他人の作成によるものであること。
�A氏名、住所・居所、電話番号のみが掲載された個人情報データベース等（例えば、電話帳やカーナビゲーション）であること、又は、不特定かつ多数の者に販売することを目的として発行され、かつ、不特定かつ多数の者により随時に購入することができる又はできた個人情報データベース等（例えば、自治体職員録、弁護士会名簿等）であること。
�B事業者自らが、その個人情報データベース等を事業の用に供するに当たり、新たに個人情報を加えることで特定の個人を増やしたり、他の個人情報を付加したりして、個人情報データベース等そのものを編集・加工していないこと。

の通り、
NTTの提供する電話帳は一般公開の意図で取得された単純なデータベースで、NTTとの契約者が公開を許可した情報に何ら付加情報を加えていないので、ソートやファイル分割は機械的な処理であって、情報が追加されているとはいえず、検索出来る内容も公開されている情報だけで、サーバー内にある秘密情報（たとえば趣味や職業）で検索しているわけでないため、公開されているウェブページからは、ただの電話帳テーブル以上の情報が得られない。

つまり、個人情報取扱事業者にあたらず、公開や電話帳アプリから検索といった利用自体は違法ではない。電話帳や名簿業が問題なく行われていることからもこれは明らか。

次に、全国電話帳アプリは、複数の人が電話帳を送信していると確認しているようだ。
この情報がどのように利用されるかは明示されていないが、電話帳取得権限の警告文でもって、利用者はアプリに収集を許可している。
アプリによって端末内で生成された電話帳データベースを、「ユーザが生成した電話帳」とみなし、それをアプリ提供者に送信・提供している解釈すれば、つまり、全国電話帳アプリが複数データベース横断検索をしているだけなら、法に反しない可能性がある。

ウイルス作成罪側で対処できるかについても、「意図せず」をどこまで広く解釈するかになるが、LINEのように電話帳を公開するアプリや広告ライブラリが（問題視されているといえど）容認されている以上、収集自体を法に問うことも難しいとおもわれる。これは判例が出るまでわからないのではなかろうか？

どこから違法になりうるか

これら情報をマージして公開した場合、個人情報取り扱い事業者となって公開に問題が発生する。しかし、現在のザル法（ザル政令）では、マージしていない個人の電話帳そのものの無断公開は法に問えないと思われる。
たとえば、利用者毎に個別のデータベースとして、とある個人が作成した電話帳、として公開された場合、法に問えない可能性がありそうだ。（よっぽど問題に思えるが）
もしこれが直ちに違法と為るならば、名簿を複数所持しているであろうほとんどの事業者は、マージ可能であるという理由で対象になってしまうが、そんな理由で立件されたという話は聞かない。

これが通れば、公開されたデータをマージして利用する側は個人情報保護法の対象になるが、提供する側の個別のデータは対象外になりうる。

結局のところ、名簿業者が行なっているであろう、データを自分で収集せず購入するなどして多数かき集めて販売し、抽出・マージしての利用は購入した側でご自由に、というスタンスの事業は、個人情報取扱事業に含まれないという抜け穴を明確にしている。

政令を改正するにしても、単にマージ可能なデータを持つ場合合算で5000人、などとしてしまったりすると、小企業や個人事業主（電話帳の一冊くらい持っているだろうから、プラス１人の顧客情報で規制対象になる）にものすごいコスト負担を強いることになってしまう。

続きを読む

SHA-3に選出されたKaccakのスポンジ関数方式

大学の講義で暗号論をかじったくらいの知識で解説してみる。

SHA-3コンペで選出されたKaccakは、旧来の構造とは異なるスポンジ関数という考え方で構築されている。

古い設計のハッシュ関数は、入力圧縮関数、内部状態バッファ、撹拌関数で構成されていた。（丸めやパディングのような雑多な処理は略す）
入力圧縮関数は、撹拌関数の呼び出し回数を減らすため、また前処理として大きな入力ブロックを内部状態サイズ以下に不可逆に縮めるために使われ、
可能な限り撹拌関数の対象となる内部状態サイズ＝必要レジスタ数を小さくして、その分撹拌関数一回あたりの複雑性を高めることで安全性を担保しようとした。

http://sponge.noekeon.org/
一方スポンジ関数方式では、大きな内部状態＝スポンジを用い、複雑な圧縮関数を不要にする。入力は単に、内部状態の一部（例えばKeccakでは1600bit中の1024bit）にXORするような方法で行われる。最後に出力圧縮関数を使う場合もあるが、keccakのように単純な切り出しで十分と考えられているようだ。
この場合、バッファサイズの大きさが増えるが、撹拌関数の複雑性・計算量を無理に増やす必要はないようだ。
非線形な圧縮関数を用いず、撹拌関数と内部状態の余裕分に安全性を担保してもらう形になる。

昔はハードウェアレジスタがとても高価だったため、内部状態を小さくすることは至上命題だったかもしれない。
現在では、ASICや高速な一次キャッシュが十分安価になっているので、内部状態を小さくする利点よりも、高速かつ単純な撹拌関数を利用する利点の方が勝ったということと思われる。非線形性をワード内rotとワード置換のみで実現している点などが評価されたか。

メリット

内部状態の大きさはが出力可能なハッシュサイズを決定するので、内部状態のサイズを切り詰めていた旧来の方式では、内部状態のサイズ自体を変更しなければならず、圧縮・撹拌関数の計算式が出力サイズによって異なった。SHA-256とSHA-512は内部が違う上、計算コストが急激に増えた。

スポンジ関数方式なら将来必要になった時に、同じ撹拌関数を用いて、入出力するブロックサイズを任意に変更できる。例えばkaccakなら仕様上1024bitまでのブロックサイズでそのまま利用でき、出力ビット数もブロックサイズ以上にできる。実質的に計算量は変わらず、原理的には安全性の検証をブロックサイズ毎に行う必要が無く、単純に算出できるものと思われる。
またkeccakは5x5xWord長という可変サイズの内部状態に対してほぼ同じ関数を使える。（rijndaelからAESの256bitブロック固定のように最終的に64bitword固定で規格化されると思うけど。）

もうひとつ利点があり、撹拌関数を都度取り出すことでストリーム暗号に仕立てることが、ほぼ同じ実装だけでIO増加以外の性能劣化なしに可能になる。出力ブロックに対して内部状態が十分大きいなら、内部状態の全体の逆算は困難で、安全である可能性が高い。
独立した暗号化と鍵精製関数を使うよりも、スポンジ関数にsalt+パスワード＋padを入力し、残りは入力ブロックの替りにカウンタを入れて出力ブロックをCTRモード暗号として扱う、といった単純な実装で安全に利用できる可能性がある。SHA-3で規格化されることは無いだろうが、ハッシュと暗号化を統合できるかもしれない。

デメリット
素人に思いつくのはせいぜい必要レジスタ数で実装コストが増えることくらいか。
構造が単純な分懐石も検証もしやすいかもしれない。一般に非線形置換・rotで十分安全と考えられているようなので、単純に性能を犠牲にラウンド数を増やされるかも、程度に思う。

トレードオフ
撹拌関数のラウンド数の他、スポンジ関数の内部状態レジスタにどの程度余裕をもたせるか（一回に出し入れする入出力サイズと、手を加えない残り自由度。図のrとc）で性能が変わる。
余裕を減らしてブロックサイズを大きくすれば計算速度は早くなるが、衝突が発生しやすくなる。（内部状態を推定・制御しやすくなる）

ブロックサイズ1024bit＋576bitで1600bitのバッファ、出力サイズ576bitで、2^-288の衝突耐性がデフォルトのようだ
http://keccak.noekeon.org/tune.html
ブロックを減らせば第二原像の算出可能性が下がるが、撹拌関数の呼び出しが増えるのでrに反比例して性能が下がる。

SHA-3規格化時点でこれも数通りに固定されると思うしそれを使えば安全だろうけれど、自由度が大きいぶん、実装が下手なパラメータを許容するとかやらかしそう。

広告・ユーザ追跡ブロック用公開hostsファイル

https://hostsaway.appspot.com/
広告やユーザ追跡をブロックするため、hostsファイルを生成する広告判定・hosts編集ウェブアプリを公開しているのだが、基本的にアクティブユーザは自分一人だ。

hostsファイルの編集は、個人個人の判断で行なってほしいものだが、単にAdawayに追加する広告ブロックhostsファイルが欲しいのであれば、広告のウザさに依らず、網羅的なものとして、
https://hostsaway.appspot.com/userhosts/b697db559506405f
を管理しているので試していただきたい。（当然無保証だが）

日本国内の広告やユーザ追跡サーバを登録しているので、AdAwayにデフォルトで入っている、hosts-file.netとwww.ismeh.comを有効にすることをおすすめする（それ以外のデフォルトhostsはアグレッシブすぎるので自分は使っていない）

出来るなら、自分に合ったブロックファイルを作成して、真っ当な広告掲載に対しては見てやってほしいとも思うのだが、そういう取捨選択できるAPIが無い以上、一律にブロックされるのは仕方が無いのも事実だ。

以下、愚痴のようなもの。

編集作業のサンプルとして、ログインすることなく誰でも編集できる（今はロックしたので、できた）hostsファイルも公開していたのだが、それを広告ブロック用として利用しているらしきアクセスログを先日複数件発見してしまった。

つまり、悪意ある誰かがログインすることなく、リテラシの低いユーザ（失礼）の端末でyahoo.co.jpをブロックするように設定できる状態だった。
（OpenIDでログインしていればそんなことはありえない。念のため）

hostsファイルなんてマニアックなものを使おうと思う人間がそんな筈は……という甘えだったわけだ。
現在では以前の公開URLを削除して編集不可にした。これでadawayなどに登録しようと思う人はいないはずだし安全。

hostsファイル、アプリ、ブラウザ拡張機能、userscript、userstyle、etc. etc.
とにかく、自分の端末が信頼して実行するコードに、信頼出来ない人間の手が入る事は絶対に避けるべき、というのは、リテラシとして当然のことだと思うのだが

Facebookの広告に関する日本版WSJの記事（タイトル・色々加筆修正）

『フェイスブック、個人データの試験販売を開始』(追記：2012-10-03朝時点でタイトルが『フェイスブック、会員情報の活用拡大を試験的に開始』と訂正されている。)

http://jp.wsj.com/IT/node_522784
というセンセーショナルなタイトルの記事。某氏がツッコミを入れていたので英語版を読んでみた。

http://online.wsj.com/article/SB10000872396390443862604578029450918199258.html
実際には、Facebook Exchange （追記：）及びCustom Audienceと呼ばれる方式及び広告効果測定 http://www.facebook.com/notes/facebook-and-privacy/relevant-ads-that-protect-your-privacy/457827624267125）に関する技術面を省いた一般向けの記事のようだ。

英語版だとdatalogixについて、datalogix自信が幅広く個人情報収集を行なっていることを指摘しつつ、微妙な表現でFacebookとは直接のデータ授受ではなくユーザ特定のために（追記：生データでなくハッシュ値でのみ）連携していること（おそらくFBX追跡用のクッキーのこと）を示唆している。Facebookの個人情報の扱いについては最後の方にも、"In the process, neither side swaps personal information, these companies say."と明記されている。

リターゲティング広告と効果測定自体は原理的にFBの個人情報データへのアクセス無しに実現できるので特に矛盾したことは書いてなさそう。（追跡は必要だが、個人情報と紐つけたり売ったりする必要はない、寧ろFacebookはユーザの評価額という情報を広告主から教えてもらえる立場）

一方、日本語版は『フェイスブックは、個々のユーザーのデータは小売り会社には売っておらず、ましてや小売り会社にデータを直接閲覧させてはいないと強調している。』とタイトルの『個人データの試験販売』が明確に矛盾している。もちろん英語版とも違う。
つまりタイトル側が事実ならFBが嘘をついている事になるが……流石にまずいだろ。

（追記）
個人データそのものではなく、個人データのハッシュ値を受取、あるいは提供、ならFBの記載と合う。

Custom Audienceでは、ハッシュのみ受け取るといえ、FBは元データとハッシュのペアを管理しているので、元データに復元して紐付けは技術的には可能。
datalogixはハッシュだけで比較すれば元データ無しにマッチ率を計算できるが、生データを別ソースから入手していたり、マッチしたデータを統計処理せずそのまま返してしまうと、同じく復元可能。（なにか秘密計算アルゴリズムを使っていれば別だけれど、技術的に保証可能な方法があれば論文公開しているだろう）
という意味で、技術的な担保ではなく、自主規制的な側面が強いと思われる。しかし、FB側が明確にやっていないと言っている以上、根拠無くデータを渡しているというのはやはり不味い。