カフェ席に持ち込んだ図書のRFID読み込んで主題ごとに違うドリンク勧めるとか、読むの長くなりそうなページ数なら普通より固めの氷使うとか、同じ作者の読んでるやつ同士を近くの座席に案内するとか、逆に飲みもんの残量と減りペースをコースターとかの重量センサで測って次のおすすめ図書推薦するとか、タブー破り気取ってんならいろいろできることあるやろ。

今のままじゃ技術に使われとるだけやぞ。

Permalink | 記事への反応(0) | 18:45

2013-05-29

■

たとえば、これからはマイナンバー制度になっていく。

住民基本台帳カードならぬ　マイナンバーカードが出来るだろう。　そこにRFIDをもう１チップ追加して、電子印影を記録できるようにして

控えなどに、それを押すことによって、　人間が見て　契約できていることを確認する。という方法もある。

電子化だけでは本人がOKしたことを確認しきれない。サインか印影は必要だ。

マイナンバーカードと暗証番号の今の制度なら、サインだけでなく　暗証番号が正しかった時に、電子印影を記録というのは　機械としてはいらないけど　役所の担当官がチェックするにはわかりやすいGUIだろう。

UXやUIの問題だ。

ちゃんと細かいところまで　専門家が考えて作れば　判子は残せる。

判子は文化だ。だが、　アナログは無理なんだ。RFIDなり、電子印影なりに対応してくれ。

認印の代わりはサインでいいだろう。　だが、重要なもののは電子印影だろう。

だがそのためには、マイナンバーカードに、ユーザーが操作できる個人情報とは違うエリアが必要だ。そこは技術論と政治論と、システム UIというかシステム UXの問題だ。専門家が必要だ。

進化しよう。

Permalink | 記事への反応(0) | 16:01

2012-07-24

■http://anond.hatelabo.jp/20120724214247

少なくとも犯罪者は全員RFID内蔵にすべきだよな。

Permalink | 記事への反応(0) | 21:56

2011-12-26

■指輪にIDを掘り込むべき

入浴中も睡眠中もけっして外さない指輪に、ID番号を掘り込んでおいて、

インターネット上にそのIDと医療情報を関連付けておけば

津波で薬や処方箋がながされてしまっても、その患者がどの薬を使っていたのかわかる。

身内の連絡先なども関連付けておけば、ボケや痴呆や記憶喪失になった時でも

専門機関がその個人を特定することが出来る。

そのIDがなんのIDかわからないといけないので、

管理サイトのドメイン名も掘り込んでおけばいい。

あるいは、専用のサイトを設けずとも、極小サイズのQRコードを掘り込むのでもいい。

（デジカメのマクロ撮影で拡大するなり、顕微鏡の類が必要かもしれないけど）

電子カルテのIDを刻んでおくというのでも良い。

緊急時の生命維持に必要な最低限の情報を指輪に刻み込んでおくというのを徹底しよう。

・指紋だと、個人情報流出になりやすい。

・生体認証は読取デバイスやインフラ整備が高価。

・皮下埋め込みのRFIDは、逆に知らぬ間に盗まれやすそうだし、異物に抵抗がある人も多そう

Permalink | 記事への反応(5) | 20:16

2011-11-16

■Google Location ServerからのWi-Fi 情報削除とかのまとめ

Google、WiFi AP位置情報データベースからのオプトアウト方法を公表。SSIDの改名を求める -- Engadget Japanese

Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN 機器の設定から " Jitaku_AP_nomap " に変更することになります。

ブコメには「Googleが勝手に盗んだのにこっちがオプトアウトしなきゃいかんとは何事だ」というものが多いが、それらは問題を根本的に誤解している。

(もしかすると総務省、ストリートビュー車の無線LAN傍受でGoogleに指導。再発防止策と日本語で周知を要求 -- Engadget Japaneseの件と混同している人がいるのかもしれない。これはビーコン信号ではなく通信内容そのものを傍受していたという話で、基本的には別件である――但し、法解釈によっては同じ問題ともなり得るし、根底に共通している部分はある。これは論点がズレるので、ここでは完全に別件として扱う)

Googleだけの問題ではない

そもそもの問題は、Wi-Fiの仕様において、Wi-Fi 機器のMACアドレスが強制タレ流しになっていることにある。これは例えばSSID ステルスの設定でも止めることはできない。

高木浩光＠自宅の日記 - 無線LANのステルス機能ではPlaceEngineに登録されるのを阻止できない (※同記事脚注4も必読)

つまり、あくまでGoogleは垂れ流されている情報を集めたに過ぎないということである。垂れ流されているものなら勝手に集めてもいいのかという論点はあり得るが、その点についてはGoogleだけを責めても全く意味がない。誰であれ収集は可能だからだ。「しかし、他の誰がそんなことをするのか？」との反駁には「はい、PlaceEngineがしています」が答えになる。仕組みは全く同じだ。PlaceEngineは、Googleのような巨大企業でなくてもこの技術を商用レベルにまで持って行けるということを既に証明している。

つまり、この問題は「GoogleのDB から削除してもらう」だけでは全く解決しない。

(追記: どうもこの節の表現は誤解を招いたようだ。「できるからやってもいい、Googleは悪くない」という意味ではない。その議論があること、今後も必要なことは承知の上で、そもそも「できる」こと自体が根本的な問題であり、しかも各国の現行法において確実に違法な行為ではないということが重要だ。何度でも言うが、Googleを憎んでも問題は全く解決しない。あくまでここでは問題の本質を理解することと、現実的で効果的な解決方法について考えたい――もちろん、GoogleやAppleやMSなどを相手取って世界中で訴訟を起こす、というのも一つの手だろう。今のところ強制力を持ちたいなら勝訴の判例を作るしかないし、勝訴すれば抑止力を備えた最強の解決手段になる。どうぞ。)

考え得る対応策

ひろみちゅ先生のご意見(2007年版)より。

高木浩光＠自宅の日記 - PlaceEngineの落とし所について考えてみる

(a) 「申し出のあったMACアドレスは削除し、今後も登録しないようにする」という対応
技術的にはすぐにでも対応可能。ただし、本人以外の手によって無差別に大量のアクセスポイントを削除するという妨害行為を防止できないかもしれない。
PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して、そのような手段が用意されていることを周知しなくては問題は解決したといえず、十分な周知は困難と思われる。
新たなアクセスポイントを購入するごとに削除手続きをする必要があることについて納得しない者が、「私のものは登録するな」という主張で争ってきたら対応できない。

(b) 「SSID ステルス設定にしているアクセスポイントは、登録拒否の意思があるとみなして、登録しない仕組みとし、また、既に登録されているものは次回検出時に自動的に削除されるようにする」という対応
技術的には容易に可能。しかし、そのような仕様であることを周知しなくてはならない。PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して周知しなくては問題は解決したといえない。
このようなルールが万人に受け入れられるものかどうか不明。

(c) 「暗号化設定されているアクセスポイントは登録せず、他は削除する」という対応
暗号化していないアクセスポイントは特定の相手方に対してのものではないとみなすことで、電波法59条の問題をクリアできるかもしれない。
しかし、これを採用すると登録アクセスポイント数が減ってしまい、位置の測定制度が低下する。

(d) 所有者の同意を得たアクセスポイントしか登録せず、他は削除する」という対応
法的には最も安全な対応。技術的にも、MACアドレスリストを提出してもらうことで対応可能。
実質的には公衆無線LANだけしか登録できなくなり、登録数はごくわずかとなってしまう。

まず、ブコメで要求されているような「オプトイン」の仕組みは(d)だが、これは実現性に乏しいと考えられる。どうやってオプトインするんだという問題もあるわけだが、そもそも「誰でも収集できる」のだから、個別にオプトインなど根本的に不可能であるし、無意味でもある。例えGoogleが独自にオプトイン方法を用意したとしても本質的な問題は全く解決しないばかりか、ユーザに「Googleでオプトインしなければ安心」という誤解を与えかねないという懸念もある。

(b)や(c)についてはサービスプロバイダ側の設計の問題であり、ユーザは関与することができない。

今回Googleが提案した方法は、(a)の改良型(あるいは(a)～(c)のハイブリッド)というべきものである。再掲。

Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN 機器の設定から " Jitaku_AP_nomap " に変更することになります。

オプトアウトという意味では、(b)のSSID ステルス法も同様である。それよりも_nomapが優れているのは、これが「うちのAPをマッピングしないでくれ」という明確な意思表示となるからだ。

SSID ステルスや暗号化をオプトアウトフラグとして扱うかどうかは単に実装に期待するしかないが、_nomapがデファクトになれば、万一オプトアウトが実装されずにマッピングされた際「俺は一般的に合意されている方法でマッピング拒否の意思表示をしていたぞ！」と法的に主張できる可能性がある。Wi-Fiの規格に変更を加えるものでもなく、この用途以外に意味を持たないことから、デファクトとして広まりやすいだろう。確かにSSID変更が困難なケースは考え得るが、しかしこれ以上に簡単な代案は私には考えられない。

これで解決？

解決しない。

ここに挙げたどの方法を採ろうとも、原理的に「サービスプロバイダのマナー」程度にしかなりようがないからだ。オプトインですら、である。robots.txtを無視するクローラを根絶することができないことにも似ている。そしてそれは、Googleの責任ではないし、Googleに責を負わせても全く意味がない。

最初に述べた通り、そもそもの問題は「Wi-Fi 機器がMACアドレスをタレ流しにしている」ことであり、これはWi-Fiの仕様改訂で対応しないとどうしようもない。また、対応したとして、新方式へ完全に置き換わるまでには気が遠くなるほどの長い時間が必要だろう。WEPすら未だに根絶できないというのに。

また、Wi-FiはMACアドレスをタレ流しているぞ、これは防げないぞ、という啓蒙ももっと必要だろう。一般ユーザには何のことやらさっぱりわからないと思うが、それでも啓蒙しないよりはマシである。

一つ付け加えるなら、個人的には、デファクトとなり得るオプトアウト方法を提示したGoogleさんはもうちょっと褒められてもいいと思う。これはAppleやPlaceEngineが今までしてこなかったことだ。

おまけ

ちなみに、Google Location Serverでは既に「2つ以上のMACアドレスがDBとマッチしないと位置情報を返さない」などの様々な対策を実施済のようである。これにより、もしMACアドレスやSSIDが漏れたとしても、その所在地をこんな方法で正確に掴むことは困難になっている。PlaceEngineは知らない。

もう一つ。この問題は、Wi-Fiだけに起こりうる問題ではない。ひろみちゅ先生は本来この問題をRFIDの普及によって起こりうる問題として予測していたそうである。この辺りもっと知りたい方はgoogle:高木浩光 PlaceEngineとかして勝手に読んでください。

追記

PlaceEngineより、Googleの提唱する_nomap方式のオプトアウトに準拠する旨のリリースが出た。

http://www.placeengine.com/

PlaceEngine データベースにおける無線LAN アクセスポイント(AP)情報の取り扱いについて
Google社から、Google Location Service のWi-Fi 位置情報データベースから無線LAN アクセスポイント情報を削除するためのオプトアウト方法（SSIDに"_nomap"文字列を追記する方法）が公開されました。
PlaceEngine サービスにおいても、Google社のオプトアウト方法に準拠する形でPlaceEngine位置推定データベースから該当するAP 情報を削除する運用を実施する予定です。具体的な実施時期や運用方法については、別途お知らせします。
また、PlaceEngine サービスにおいては、以前より、主にモバイルルーターなどに対応するため、オプトアウト(削除)したいMACアドレスをサポート窓口へ送付して頂く方法などをとっておりましたが、こちらについても引き続き運用していきます。（「位置推定の改善」をご参照ください）

これこそがまさにGoogleの狙った効果だ。素早くデファクトになり得る。すると次の段階として、Wi-Fi 機器の製造者が設定画面に「☑位置情報サービスからオプトアウトする(SSID末尾に_nomapを付加する)」のような項目を用意することが標準化する、などといった流れに進むことも期待できそうだ。これには一層の啓蒙活動が必要になるが、十分に現実的な範囲だ。