2012年10月12日

平文パスワードの復号を必要としない生体認証について

前エントリの続き。プラス、平文パスワードを復号できる必要性が、某氏に理解してもらえなかったようなので。

一般に、OSサポートの無いサードパーティの認証ソフトウェアは、平文のパスワードを何らかの方法で復号する必要がある。(追記:もし平文パスワード無しにログインできるなら、OSの認証機構それ自体が脆弱であり、考慮する意味が無い。)
つまり「暗号化されたパスワード」という、総当りで簡単に平文を得られる可能性の高いデータを保持する必要があり、十分なパディングなど総当り耐性を高める適切な暗号化を施す必要がある。
暗号専用ハードウェアなどに保存されていたり、十分なDRMで見つからないよう保護されているならともかく、windowsレジストリなどの他のユーザからアクセス出来る場所に置くなんて論外だ。そのうえ、件の認証ソフトウェアは暗号化方式が酷かった。(恐らく56bit鍵だが直ぐ分かったということなので、秘密鍵をDRM無しにハードコードしていたのだろう。もしくはIV固定で選択平文で解けて鍵不要だったとか)

平文パスワードを必要としない指紋認証にするには、OSのサポートが必要になる。

認証ハードウェアにカーネルレベルのサポートがあれば、話は簡単。カーネル内の情報がユーザーランドから読み書き出来るなら、そもそも安全なOSでは無いので考慮する必要はない。カーネルは認証ハードウェアに直接アクセスして、ユーザーを識別出来る。
OSSならサードパーティベンダはカーネルドライバを提供してユーザにカーネルをリビルドしてもらえばよい。

プロプライエタリなユーザー認証機構をもつカーネルでサードパーティ認証を実装するには、Oauthと同じ仕組みが必要になる、と言えばWebの人にわかってもらえるだろう。
例えばTwitter=OS、twitterfeed=生体認証ソフトウェア、エンドユーザはそのまま人間に対応する。(無関係だけど今twitterfeedがうまく動かない……)

(追記、認証制御できる特権を持たないという意味で、)ユーザーランドで動く認証ソフトウェアは、OSサポートが無い限り、ユーザのパスワードを(暗号化して)保存して、複合した平文パスワードをOSに渡すしか無いが、OSサポートがあれば、ユーザを生体認証してアクセストークンを渡せば済む
この場合はアクセストークンを正しく暗号化して保護する必要はあるが、トークンが漏れてもパスワードは漏れない
またカーネルが異常なトークン利用や、脆弱なトークン保護機構を検出した際に、生体認証ソフトウェアを個別に失効させる事もできる。


前エントリ http://causeless.seesaa.net/article/296998112.html と合わせて、
OSサポートのないサードパーティの生体認証では少なくとも平文パスワードを復号できる必要があり、ハードウェア対ダンパ性か強固な暗号化の無い場合脆弱になる。OSサポート=カーネルレベルで実装するべき。
ということ。

ラベル:暗号論 生体認証
posted by ko-zu at 08:22| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

指紋認証の脆弱性に関するメモ

UPEK Protector Suiteなる指紋認証が、あまりにも馬鹿馬鹿しい実装だったらしいので解説しておく。
http://blog.crackpassword.com/2012/08/upek-fingerprint-readers-a-huge-security-hole/

生体認証は
・生体データが本当に生体から得られているかチェック(例えば偽造指紋スタンプではなく生きた指かどうか)
・生体データから得られる鍵が十分な長さを持つ(他の人と一致しない)
・認証プログラム自体が保護されている(ブルートフォース対策)
ことの組回せで成り立っている。
正しく実装すれば、生体データから鍵を作り、秘密データを復号することで、秘密データを安全に復元できる。

このうち生体データには、ノイズ以外にも体調・成長による変化といったゆらぎがある為、十分大きな鍵を作ることは難しい。
普及レベルに実用的な生体認証は小さい鍵しか得られないため、一般にブルートフォース攻撃に脆弱になる。

ブルートフォースから保護するためには、認証プログラムを安全なOS環境で実行し、時間辺りの認証回数を制限したり、一定回数失敗したら秘密情報を破棄する必要がある。
たとえば、銀行ATMは秘密鍵として使える情報量の少ない静脈認証が使われているが、静脈を銀行の監視カメラの下で偽造するのは難しく、ブルートフォースは不可能なので問題はない。

逆に言えば、認証プログラム自体を改ざんしたりして、ブルートフォース対策を迂回できる場合、(十分な長さを持たない)生体データを予想することで、比較的簡単に秘密情報にアクセスできてしまう。認証プログラムが一般のPC上で動いている場合、他のユーザのように一定のアクセス権を持つ第三者からも、完全に保護することはとてもむずかしい。

高価なアプライアンスでは、独立したハードウェアに認証システム全体を取り込み、ハードウェアの耐タンパ性で認証プログラムとデータを保護することで、生体情報の鍵データの小ささをカバーしている。これが本来の生体認証と言われるもの。

問題が指摘されている指紋認証は、ソフトウェア、しかもWindowsレジストリに秘密データを保存していたため、簡単に暗号化された秘密情報にアクセスでき(ブルートフォース対策を回避する必要が無い)、しかも指紋から得られる鍵情報がとても小さいため簡単に鍵を推定できるようだ。
さらに酷いことに暗号化されたと言っても、常に一定の固定鍵だったようだ。
http://www.zdnet.com/enterprises-most-vulnerable-to-fingerprint-reader-attacks-researcher-says-7000005575/


大雑把に言って、レジストリにアクセス可能なソフトウェアをインストールしてしまうと、パスワードを平文で得られる。
悪意あるソフトウェアを起動した瞬間にパスワードが漏れることになるため、記事の参照しているブログでは、指紋ログイン機能を停止することを推奨している。

(追記)
生体認証の安全性と、平文パスワードを復号する必要のない生体認証を実現する条件について、次のエントリに書いた
http://causeless.seesaa.net/article/297035731.html

(追記)
Lenovoの http://support.lenovo.com/en_US/downloads/detail.page?DocID=DS031505
が対策パッチかもしれない from http://b.hatena.ne.jp/airj12/20121012#bookmark-115103634


ラベル:生体認証 暗号論
posted by ko-zu at 00:12| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年10月11日

広告ブロックHostsファイルを自分用にカスタマイズする方法

と言うタイトルの自作ウェブアプリ宣伝。
https://hostsaway.appspot.com/

広告やユーザー情報収集用サーバをブロックするために、有志製作のhostsファイルが公開されていることが多いが、自分で編集するのは面倒な人に。
既に作成済みのhostsファイルを自分専用hostsファイルに一括で追加できるように対応した。

追加したいhosts (127.0.0.1 blackhostname形式)やadawayがエクスポートするホワイトリスト (white hostname 形式)を
https://hostsaway.appspot.com/edithosts
の手動ホスト追加テキストエリアにコピペするして更新をクリック。

HostsAway5.png
#コメント行なども対応していて、localhostやアンダーバー入りなど不正なドメインはフィルタされるので特に問題なく利用できると思われる。

あまりたくさん追加すると重くなるのでほどほどに。1000ドメインでAPIリミットが掛かる筈。まだユーザへの警告等を実装してないのでお気をつけてどうぞ。

あとは見たいホストをブラックリストを削除するなり、追加でブロックしたいホストをブックマークレットなどで判定・追加するなり。

個々のホストの追加方法やアカウント作成の解説は以前のエントリ参照
http://causeless.seesaa.net/article/293849729.html
posted by ko-zu at 22:33| Comment(0) | TrackBack(0) | 広告・ユーザ追跡 | このブログの読者になる | 更新情報をチェックする

通信記録やPC上のデータは確実な証拠にはならない

PC遠隔操作による脅迫事件について、崎山伸夫氏と小倉秀夫氏の昨日辺りから続く(とても不毛に見える)議論を見ていた。

現在、PCに遠隔操作用に、アンチウイルスソフトウェアで検出できないウイルス類を送り込むことは不可能ではなく、実際に今回の件で実行できてしまった。
同時に、Web・PCに関する一定の知識を持っている人にとって、PCにウイルス等が感染し、第三者が遠隔操作してその後隠蔽のために削除された、という偽の記録を作ることはむしろ簡単である。

これは既に、PC上のデータには確実な証拠能力は無いことを意味する。弱い状況証拠として採用されることは有りうるだろうが、不確実な状況証拠だけでは有罪になり得ない。
同様に、PC上のデータが証拠能力を持たないのであれば、PCが利用しているIPアドレスとの通信記録も確実な証拠能力を持つわけではなくなる。つまり、PCを誰が制御していたかの証明にならない。

これがもし電話番号だったら、警察・裁判所も冷静に対応できたかもしれない。
例えば、置引きされた携帯電話から脅迫電話がかけられるということは有りうることであり、通話記録それ自体は確実な証拠と言えない
脅迫電話の録音テープと本人の声紋の一致、凶器準備、利害関係の確認といった他のより確実な物的・状況証拠を積み上げる必要があるのは明らかだ。

今回の事件を脅迫電話にたとえるならば、家に鍵がかかっていない長閑な田舎の固定電話を用い、不法侵入した第三者が役所に脅迫電話をかけ、録音テープのような他の物的証拠なく何も知らない家主を突然逮捕した、ということだ。逮捕理由は電話機に残る通話記録を隠される可能性があるため。そして受話器からは他人の指紋が見つかった。

今回の事件で警察が捜査を逮捕時点で捜査を打ち切った場合、釈放される事なく有罪にされた可能性がある。警察が調べないほうが有罪になる確率が上がるというのは、あってはならない状況だ。裁判所がまともであればいいが、今回の逮捕状を出したのは裁判所だ。少なくとも対応した裁判所に本件について適切な判断力があったとは考えにくい。最高裁判所なら、罷免に投票できるが、今回の件で逮捕状を許可した裁判官の名が明かされることはないだろう。


今後同様の事件が起きた場合、例えば爆破予告なら、必要な火器など凶器準備の証拠を集める必要がある。
PCのデータやIPアドレスの記録など電磁的記録の証拠能力がほぼゼロである以上、購入履歴など直接的な証拠となりうる第三者のデータなり物的証拠なりが必須で、それまでは継続監視するなど、逮捕以外の方法で安全を確保するしか無い。

国外などへ逃亡の恐れがあったり、凶器を処分される恐れが高い案件であれば、逮捕は必要だろうが、大義名分である証拠処分の容易性を証明するのは警察側の責任だ。
そもそも証拠能力のないPC上のデータを消される可能性について、逮捕の必要性を論ずること自体的はずれに過ぎる。


現在、インターネット上の何かいうこと=データの複製はタダだ。「今日誰かを○します」という書き込みはいくらでもできる。警察が全てまともに取り合うならば、dDoSになることは明らかだ。

警察は「嘘を嘘と見抜ける能力」を育てて、ネット上の通信を全て本気にして近視眼的に逮捕勾留するのではなく、本当に本人が犯罪予告している緊急な案件を見分ける力を育てなければならないのではないだろうか?
今回の件は、せいぜい利用された可能性のあるPCを差し押さえして被疑者を監視をすればいい案件だったように思われる。

逮捕に必要な、証拠隠滅や逃亡の恐れを証明する必要性があるのは逮捕する警察の仕事だ。
逮捕した上、自白を強要したあとで、証拠がなくなりました、なんて論外。別件逮捕と同根。

posted by ko-zu at 22:09| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年10月09日

Android/Xperia Acroへのカーネルモジュール導入についてメモ

Linuxではカーネルの機能がモジュール化されていて、コンパイルオプションで自由にオンオフできる(静的リンク)。さらに、カーネルが起動した後でも、同じモジュールをカーネルに導入できる(動的リンク)

Linuxでは、*.koというファイルが動的リンク可能なカーネルモジュール(kernel objectファイル)になる。
動的リンクされるカーネルモジュールは再起動すれば消えるので、ちょっとやそっとでは文鎮化することが無いので安心できる。(システムファイルやハードウェアを壊すようなバグを含んでなければ)
同じバージョン・同じCPU向けのモジュールなら基本的に互換性があるので、依存関係をしっかり解決すれば、Androidメーカーの作ったカーネルにOSの基幹機能を安全に追加できる。

カーネルバージョンや端末指定で.koファイルが配布されている場合、suシェルからinsmodコマンドでロードしてシステムが壊れないか確認した後で、init.dなどの起動スクリプトで自動導入するようにすればほとんどリスクなく利用できる。
CWMなどを使えば、自動インストールも簡単。

hw_setup.shなど、起動時にrootで実行されるスクリプトにbusybox insmod hogehoge.koと入れておけば、起動時に導入されるし、アプリによってはroot権限取得してインストールしてくれるものもある。


結局自分のAcroは
http://thjap.org/android/xperia-series/2011-xperia/291.html
を参考に、
etc/init.dの 99complite  (sqlite最適化)と 09disablevsync (vsync無効化)を削除して適用

ondemand2がかなり効果があるようで、ロック中の電力消費がかなり減っている。
384MHzでも音楽再生には問題ないようだ。Bluetoothが瞬断しやすくなったかもしれないので少し増やすといいかもしれない。

Android2.3.4のXperia Acroでは、CIFSでWindowsファイル共有をマウントするために、
cifs.ko slow-work.ko(これはandroid独自?) nls_utf8.ko
が必要だった。

cifs.koはWindows共有をファイルシステムとしてマウントする機能そのもの、nls_utf8.koは、windowsのファイル名エンコーディングを、AndroidOS内部エンコーディングに変換するための機能を提供している。

試していないが同様に、USB-OTGでUSBメモリをマウントするには、usb-storage.ko が必要。ファイルシステムがNTFSなら、ntfs.ko、ext4ならext4.ko。

CIFSマウントが実用的とわかってNexus7購入を決断してしまった。
posted by ko-zu at 22:05| Comment(0) | TrackBack(0) | Android | このブログの読者になる | 更新情報をチェックする

Android/Linuxでのファイルシステム文字コードの扱いのメモ


ファイルシステム上のエンコード
最近のファイルシステムはユニコードで決め打ちされているので考慮する必要はない。FATなどの古いファイルシステムでのみ問題になる。(厳密にはUCS-2でUTF-16非対応だったりするけど。)
FAT32ショートファイル名ならShift_JISなど(正確にはcp932)。ロングファイル名(8.3形式でない名前)は後付け規格なので問題ない。

OSの内部エンコード
基本的にUTF-8。

Linuxネイティブソフトウェアのエンコード
ソフトウェアが解釈できるエンコードはソフトによる。ASCIIしか表示できないアプリもあれば、UTF-8を解釈できたり、EUC-JPのままだったりする古いアプリもある。

Androidアプリのエンコード
Java自体ユニコードに対応しているので、HTTPなどで外から取得したバイナリを下手に変換しない限り考慮する必要は無い。

マウントオプション
vfatマウントについては、
http://archive.linux.or.jp/JF/JFdocs/kernel-docs-2.6/filesystems/vfat.txt
がわかりやすい。

XperiaAcroのマウントオプションは(noatimeに上書きしているけどfatは意味ないはず)
/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,noatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
Xperiaデフォルトの文字コード関連オプションは、codepage=cp437,iocharset=iso-8859-1,utf8なので、ショートファイル名には1バイト文字、ロングファイル名とOS内部とのIOはUTF-8変換がなされる。
もし接続したSDメモリなどのショートファイルに日本語文字が含まれてしまっていて、正しく読み書きできない場合は、codepage=cp932にすれば解決するはず。

USB-OTGでFATファイルシステムをマウントする場合、マウントオプションでcodepage=cp437,utf8を指定すれば、windowsマシンに持って行っても文字化けしたりアクセスできなくなることは無いはず。

だけど、デザイアさんが四苦八苦していた。有償版StickMountが発行するマウントオプションが知りたい。
もしかしたら、nexus7はSDメモリ非対応なのでFAT用のnls_cp437が入っていないのかも。nls_cp437.koとnls_utf8.koをいれればどうにかなるかも?

なおCIFSで日本語の読み書きにはiocharset=utf8にする必要があった。
ウィンドウズファイル共有自体はUTF-16で決め打ちなので、SMBプロトコルとOS内部間でUTF-16/UTF-8変換が必要で、nls_utf8.koも同時に必要だった。



posted by ko-zu at 19:54| Comment(0) | TrackBack(0) | Android | このブログの読者になる | 更新情報をチェックする

2012年10月08日

Android端末から自宅NASをマウントしてみた

root化済みAndroid端末にCIFSのカーネルモジュール導入して自宅のNAS(samba3/fedora)をマウントしてみた。

WiFi環境は11nで、SMBユーザライブラリでの接続は上下ともに実効500〜800KB/s程度出る(ワイヤレートで10Mbpsくらいでてるのかな)
転送速度の律速は恐らく端末でのWifiのAES暗号処理速度。ノートPC(古いVAIO)では最大15MB/sほど出ていた。

マウントオプションは iocharset=utf8 (utf-8だと思って小一時間ハマった。)だけで日本語の処理も問題無さそう。
linuxのioバッファがcifsも共用かわからないけれど、念のためSD Speed Increseで4096KBに拡大してある。

動画
300kbps〜100kbps程度にトランスコードして保存してあるニコ動をMX動画プレーヤで再生。
1000ファイル50フォルダほどあるせいでリスト作成に時間がかかるものの、一旦作成されてしまえば問題なく再生可能。
動画をタップしてからの再生までの反応はSDと区別がつかない程度。

画像
1ページあたり100KB程度(かなり低画質。拡大には耐えない)に圧縮したZIP自炊コミックも問題なく読める。
連続移動すると引っ掛かりを感じるが、(古い端末なので)SD内でもJPEG展開速度で律速されるのであまり変わらない感じ。
ページあたり1M程度の圧縮前画像を読もうとするとさすがに厳しい。というか展開処理でほぼ固まる。

音声
問題なし。そもほとんど128kbpsだし。


普段使いには十分。いい加減容量がやばくなりつつあったので、SDメモリからあまり見なくなったコンテンツをNASに移動中。
ついでにパーティション空けるのが面倒でやっていなかった、Link2SDを導入。本体のスペースが空いてGoogle日本語入力やデザイアさん紹介のアプリもサクサクとインストール出来るように。

今のところCIFS managerを使っているが、MountManager買うか検討してい見る。
ラベル:android NAS CIFS
posted by ko-zu at 18:50| Comment(0) | TrackBack(0) | Android | このブログの読者になる | 更新情報をチェックする

ダウンしたt.coを回避してリンク先を見る方法

twitterの短縮URLを提供しているt.coのドメインが死んでたようで、世界中で問題になっていたようだ。

Webブラウザでtwitterを見ている人は、t.coがダウンしても回避する方法がある。
ブラウザのアドオン・拡張機能のGreaseMonkey(firefox)やTemperMonkey(GoogleChrome)を用いると、javascriptを好きなページに挿入できるのだが、
下記ページの拙作スクリプトをインストールすれば、twitter公式ページのt.coをスキップして直接リンク先を辿れるようになる。
http://userscripts.org/scripts/show/149312

ぜひお試しを![PR]

posted by ko-zu at 15:11| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2012年10月07日

全国電話帳アプリのアドレス帳漏洩と、住所でポン!について個人的まとめ

各社報道も出揃ったようなので自分の理解をまとめてみる。

現状の報道
http://www3.nhk.or.jp/news/html/20121006/t10015569881000.html
http://www.jiji.com/jc/c?g=soc_30&k=2012100700067
http://www.tokyo-np.co.jp/article/national/news/CK2012100702000096.html
http://mainichi.jp/select/news/20121007k0000m040072000c.html
などなど。

@tottoriloop氏の提供する『全国電話帳』アプリは、ユーザーの電話帳70万件以上を公開状態に置いていたとして捜査されている。
この問題は、複数の法律にまたがったややこしい問題を含んでいる。

問題視された点は
・全国電話帳アプリがユーザ端末内のアドレス帳をアップロードした点
・作者のサーバでは、ユーザがアップロードしたデータが誰でも閲覧・検索可能になっていた点
・上記の点が正確にユーザーに伝わっていない点

また直接は関係ないが、同一作者の
・「住所でポン!」というサイトでの電話帳情報公開
も関連して語っている人が居る。


@ アドレス帳のアップロード
これは、不正指令電磁的記録の供用、所謂コンピュータウイルスの悪用として、問題視されている。

高木先生の解説などが詳しいが、法令の定義上、『ユーザーが意図しない事』を実行するプログラム全般がウイルスとみなされる。

アプリ解説には、
過去のハローページとタウンページに掲載された約3800万件の情報をもとにデータベースを作成しています。加えて、アプリ利用者のアドレス帳、GPSの情報も利用します
とあり、この一文によって、作者はユーザーの同意を得て、ユーザーの意図通りアップロードしたもの、と考えて居るようだ。
これは http://causeless.seesaa.net/article/296089367.html に書いた。

これは作者が意図してグレーゾーン、それもかなり黒い側ギリギリを狙って書かれたアプリ説明と思う。
もし自分なら、
全てのアプリ利用者のアドレス帳を対象に検索することができ、そのためにサーバーに各利用者のアドレス帳をアップロードします。
のように明記し、アプリ起動時にも同様の警告を行なって利用の可否をユーザーに尋ねるよう、実装するだろう。グレーゾーンに踏み込む必要など無い。


A サーバー上での公開
これは個人情報保護法について問題視されている。
個人情報保護法には例外規定があり、総務省のガイドラインには
http://www.meti.go.jp/policy/it_policy/privacy/kaisei-guideline.pdf
個人情報データベース等が、以下の要件のすべてに該当する場合は、その個人情報データベース等を構成する個人情報によって識別される特定の個人の数は、上記の「特定の個人の数」には算入しない。

@個人情報データベース等の全部又は一部が他人の作成によるものであること。
A氏名、住所・居所、電話番号のみが掲載された個人情報データベース等(例えば、電話帳やカーナビゲーション)であること、又は、不特定かつ多数の者に販売することを目的として発行され、かつ、不特定かつ多数の者により随時に購入することができる又はできた個人情報データベース等(例えば、自治体職員録、弁護士会名簿等)であること。
B事業者自らが、その個人情報データベース等を事業の用に供するに当たり、新たに個人情報を加えることで特定の個人を増やしたり、他の個人情報を付加したりして、個人情報データベース等そのものを編集・加工していないこと。
とある。 不正指令電磁的記録として問題がなかった場合、アプリがユーザーの意図通りアドレス帳データベースを作成することは、作者側にとってみれば、ユーザーから他人が作成したデータベースを受け取るだけになる。複数のデータベースを持っていても、加工・編集しなければガイドラインの3に当たらない。(NTTの電話帳と名刺一枚を持っているからと言って個人情報取扱い業務にあたらない)
つまり、個人情報保護法の対象外になる可能性がある。

アプリの説明文にある通り、誰でもユーザのアドレス帳からの検索をするためには、何らかの形でユーザーのアドレス帳を誰でもアクセス出来る状態=公開状態に置く必要がある。
したがって、「アプリ利用者が論理的に考えれば、何処かで公開されることに同意したとみなせ、不正指令電磁的記録に当たらない。」作者が法廷に立たされれば、そう反論するのが予想される。これも意図的にギリギリの説明を悪用して、ユーザーの誤解を引き起こそうという考えが透けて見える。


B説明は十分か

各社の報道、たとえばNHKには、
セキュリティ会社「ネットエージェント」の杉浦隆幸社長は、「電話帳を利用すると記載していたとしても、目的などを十分に説明しておらず問題だ。スマートフォンの情報を収集するアプリは少しずつ増えており、注意が必要だ」と話しています。
とあり、説明が不十分だったと問題視している。

カレログ、the Movieといった過去に問題となったアプリは、全く記載なく、あるいはユーザ以外の第三者が端末に導入することを推奨して、データ漏洩を引き起こすため問題視されていた。

しかし、全国電話帳アプリの説明は、論理的に考えるば、アップロードと公開アクセスが推論でき、第三者の端末に勝手に導入することを推奨していないので、この説明が不十分であるということは、もっと直接でわかりやすい記載を要求することになる。

ところが、既にFacebookやLINEのように、電話帳をアップロードするアプリは多数あり、個々アプリの機能説明において、アップロードについて説明がどの程度直接的かは怪しい

どの程度直接的な説明なら利用者の同意とみなせるかは、非常に難しい問題と考えられ、特定商取引法表示のような法で決まった表示規定が無い現状、事例ごとに裁判で個別に判断するしか無い。
全国電話帳アプリは黒に近いグレーゾーンで、"問題視"されるのは当然だが、違法だと断言してしまうと、他のアプリも黒であるという事になりかねない。

各社報道は、(捜査中なので当然だが)問題点・懸念として指摘し、違法と断言しているわけではない。
もちろん情報を収集される側のユーザとしては、黒であるほうが望ましい。


ついでに、
C住所でポンとの連携について。

@saronpasu氏が
https://twitter.com/saronpasu/status/254454228813242368
で、全国電話帳で収集した個人情報が、住所でぽんに利用されている、と指摘していた。
これは自分は確認できていない。

住所でポンは、作者の説明や乗っているデータから考えるに、NTTの電話帳を機械的に一般公開しているサイトで。それ自体は例外規定によって個人情報保護法の対象ではない。(=NTTが電話帳を公開できる理由)
しかし、複数のデータベースから名寄せしてデータ新たなデータベースを作って利用・公開する場合、例外規定ガイドラインの3に反するので、個人情報保護法対象となり、公開ができなくなる。

作者の過去ツイートをおうと、その点は考慮して公開しているようだ。


結論として、
・自衛として、アプリ説明や利用規約をしっかり読むこと
・わかりやすい定式化された説明の表示義務の法制化を急ぐこと
が非常に重要だ。
前者は多くの報道で指摘されているが、後者は指摘されている様子がない。

意地悪な言い方をすれば、ユーザデータを収集して利用する営利企業にとってみれば、表示義務が強くなると収集に支障をきたしたりコスト増を招くので、ユーザに自衛してもらうほうが好ましい。

現状、アプリに限らず迂遠な説明・利用規約でユーザ情報を収集しようとすることが多いと考えている。
わかりやすい説明の迅速な義務化を切に願う。

https://twitter.com/cause_less/status/254560614360424452





追記。
「情報に詳しい通りすがり」さんのコメントに対して、
http://causeless.seesaa.net/article/297244474.html
にエントリとして返答を書きました。

追記。
一週間経過し連絡らしきものが無いため削除しました。
http://megalodon.jp/2012-1021-0148-04/causeless.seesaa.net/article/296187376.html
posted by ko-zu at 15:06| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年10月06日

全国電話帳アプリは不正指令電磁的記録供用に当たるか

https://twitter.com/HiromitsuTakagi/status/254538144169476096
高木先生が違法と断言した全国電話帳アプリ
https://play.google.com/store/apps/details?id=info.jigensha.hellopage

不正指令電磁的記録供用についてと思われるので検討してみる。

アプリ説明には、『不正指令電磁的記録供用』を回避する事を意図したと思われる文言がある。
https://play.google.com/store/apps/details?id=info.jigensha.hellopage より

過去のハローページとタウンページに掲載された約3800万件の情報をもとにデータベースを作成しています。加えて、アプリ利用者のアドレス帳、GPSの情報も利用します。
zenkokudenwa.png


裁判になれば、アプリ作者の(@tottoriloopとは別?)は恐らく、こう主張するだろう。

アプリ利用者のアドレス帳を検索対象として用いるためには、アプリ利用者のアドレス帳をどこかにアップロードするなり、アプリがP2P型の公開サーバとして振る舞う必要がある。つまり、アプリがアドレス帳を外部に送信することは、論理的にみて当然の前提。
アプリをインストールした利用者は、アプリ説明と権限を確認してインストールしているため、同意を得た送信であり、不正指令電磁的記録に当たらない。

カレログの場合は本人の意思と無関係に第三者がインストールした場合(その第三者が)問題視された。
The Movieの場合、全く記載のない情報送信が問題視された。
しかし、このアプリは利用法が示されているため、問題ではない。

といった感じの主張が容易に想像される。
消費者保護の観点から、これは明らかにユーザーを惑わせるための婉曲な表現と言えるだろうが、長くユーザーにわかりづらい規約は一般に存在し、100%有罪と言うのは難しいのではないだろうか?

逆にこの件が明確に有罪となってくれるならば、ユーザー情報収集や利用を隠そうとする意図が見え見えの、婉曲・迂遠な利用規約を掲げる事業者の訴訟リスクは大幅に高まるので、(被害にあった人には悪いが、)追跡される側のユーザーとしては非常に喜ばしい。

posted by ko-zu at 21:31| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする
×

この広告は90日以上新しい記事の投稿がないブログに表示されております。