<前の日記(2008年07月19日) 次の日記(2008年07月26日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1752   昨日: 2734

2008年07月22日

「日本のインターネットが終了する日」あとがき

10日の日記「日本のインターネットが終了する日」には、書ききれなかったことがある。また、頂いた反応を踏まえて追記しておきたいこともある。

青少年は結局どうすればいいのか

はてなブックマークのコメントに、「本当に知らなければいけない人には理解されないかと思うとね・・・哀しくなってくる」という声があった。リンク元のどこだったかには、「肝心の子供たちにはどう説明したらいいんだ」というような声もあったと思う。

契約者固有IDの送信を止める設定をしてしまえば、モバゲータウンや魔法のiらんどなどが使えなくなってしまう。設定をアクセス先毎に変更しながら使うという方法もあり得るが、子供たちにそれをさせるのは無理な話だろう。保護者としては、確実に安全に使える設定を施した上で電話を子供に渡したいはずだ。「住所氏名は入れちゃ駄目」というのは、これまでも子供たちに教え諭す必要があったかもしれないが、どんな物販サイトにも入れちゃ駄目となると、「子供は物販サイトを使っちゃ駄目なの?それでいいの?」という問題が生じる。

結論としては、「青少年はフィルタリングを施して使えばいい(ホワイトリスト型の)」ということになる。

つまり、キャリア認定の公式サイトや、EMA(モバイルコンテンツ審査・運用監視機構)等に認定された健全なコミュニティサイト等にしかアクセスできない状態にして使えばいい。そこには契約者固有IDを不適切な用途で使用したり、横流しするようなサイトはないはず……とすることが可能だからだ。

その意味では、認定されたサイトが、取得した契約者固有IDをどのように取り扱うのかが気になるところである。EMAに健全サイトと認定されるくらいの真っ当な運営会社であれば、入手した契約者固有IDの取り扱いもきっと良識的な使い方しかしないだろうとは思う。だけども、良識に頼るというのは危ない。健全サイトの認定基準で、契約者固有IDの取扱い方針についても明確に定めておくべきではないだろうか。

その点、EMAの「コミュニティサイト運用管理体制認定基準」がどうなっているかというと、「携帯端末を特定する個体識別番号等を取得しなければならない」*1という要件は示されているものの、その番号を個人情報として扱い、個人情報保護法に則って管理する(あるいは、住所氏名等の個人情報とけっして結びつけないようにする)ことといった要件は見当たらない。*2

ともあれ、そうしたことが整備されて、認定機関による健全サイトの育成がうまくいくようになれば、全サイトにIDが送信されてしまうケータイWebであっても、健全サイトにしかアクセス不能にして使えば、安全に利用することができるようになる。

類似の仕組みは過去にも検討されていた

じつは、これに似たやり方は、2002年に総務省の研究会で検討されていた過去がある。

10日の日記の冒頭で示したように、旧郵政省が2000年から始めた「次世代移動体通信システム上のビジネスモデルに関する研究会」で、「ユーザIDに係る取扱いルールを早急に確立する必要がある 」といった結論を出していたが、それがその後どうなっていたかというと、2001年に別の研究会「モバイルコンテンツビジネスの環境整備の方策に関する研究会」を始めて、その報告書で、コンテンツプロバイダの審査・監査機関を設けて、契約者固有ID利用のルール化するという結論を出し、「「モバイルコンテンツ評価システムの構築に向けた総務省デザイン」に関する意見募集」というバブリックコメント募集をしていた。(詳細は、2007年6月30日の日記「「ガラパゴス携帯のパラダイス鎖国」をWebの技術面から見る」にも書いた。)

これがその後どうなったのかは知らない。調べた限りでは立ち消えになったように見える。立ち消えになった原因も知らないが、パブリックコメントの提出意見には否定的な意見が出ていたことがわかる。

現在でも星の数ほどあり、今後も増え続けるサイトを評価機関が監視し続けることができるのか、実効性に疑問がある。逆に、実効性を持たせるとすれば、表現行為に対する大きな萎縮効果が懸念され、看過できない。(略)

さらに、委員会の委員の構成、委員会・評価機関の運営方法をみると、本評価システムの中立性に疑問がある。

インターネットが全世界において爆発的に普及した理由のひとつは、「規制がないこと」である。本評価システムに対してその設立動機は理解するものの、実体はモバイルインターネットコンテンツの制作、流通の円滑化をむしろ阻害してしまうことを懸念する。

よって、本評価システムの導入には慎重であるべきと考える。

意見書 日本テレビ放送網株式会社, 2002年1月10日

たしかに私にも無理のある構想だったように思える。それから6年が経過した2008年、青少年ネット規制の逆風が吹き荒れる中、対象を青少年向けフィルタリングのホワイトリストに絞ったことで、コスト負担の問題も解決するようで、類似の方策が息を吹き返したという感じだ。

しかし、審査の対象が絞られているだけに、登録されるサイトは限定的なものにならざるを得ないだろう。こういうやり方でやる以上、それはやむを得ないのではないか。

それでは不自由すぎるというのであれば、PCで通常のインターネットを使えばいい。iPhoneでもいい。(ただし、PCまで固有ID全サイト送信が強制されてしまう日が来ない間の話だが。)

契約者固有ID取得時代の事故対策と責任

Webサイト運営者側の立場からすると、契約者固有IDを取得することは、従来になかったリスクを抱えることになる。

これまで、個人情報を漏洩させる事故を起こしても、単に住所と氏名だけからなる名簿を漏らした場合では、たいした実害がない(「住所氏名単体は元々公開された情報である」という主張もある)として、損害賠償訴訟を起こされてもさしたる金額を請求されなくて済む傾向があったように思う。

これが、住所氏名と契約者固有IDを含むデータを流出させてしまった場合には、被害者に具体的な損害が生ずるようになる。被害者は、どこのサイトに行っても住所氏名がバレてしまうという事態になるので、携帯電話の契約者固有IDを変更する必要に迫られ、改番手続きないし契約の解除と再契約などが必要になる。携帯電話会社によっては手数料を請求するところもある。また、契約者固有IDと住所氏名の漏洩は、任意サイトにおける過去のアクセス記録についてもそれが誰のものだったかバレてしまうという被害をもたらすので、被害者の精神的苦痛は大きいと判断される可能性がある。原状回復のために被害者にかかる作業の負担もあり、それらの損害を、漏洩させた企業に賠償請求することができるようになると思われる。なにしろ、被害の発生原因が漏洩させた企業にあることは明白だ。

サイト運営者としては、契約者固有IDを取得する場合には、住所氏名情報と隔離して、照合可能な状態で記録や保管をしないよう、セキュリティ対策をとる必要に迫られると思う。

Windows MobileのIEでどうやって契約者固有IDを送信しているか

10日の日記では、イー・モバイルでも、音声通話サービスの開始と同時に始まった「EMnet」を契約していれば、「x-em-uid」に契約者固有IDが載せられて送信されることを書いた。Windows Mobile付属のInternet Explorerでアクセスしても送信される。

これがどうやって実現されているかというと、イー・モバイル内のプロキシサーバを通しているからである。

EMnetを契約している場合、「接続方法」として「EMnet」と「emb」のどちらかから選べるようになっている(図1左)。「EMnet」を選択して「編集」ボタンを押し、「プロキシの設定」タブのところを見ると、デフォルトで「wm.internal.emnet.ne.jp:8080」というプロキシサーバが設定されている(図1中央および右)。

図1: イー・モバイルにおけるWindows Mobileのインターネット接続設定

wm.internal.emnet.ne.jp のプロキシサーバは、端末から接続されたとき、何らかの方法で、端末の何らかのIDを安全に識別できるようになっているのだろう。それに対応する契約者固有IDを、HTTPリクエストヘッダに挿入するようになっていると思われる。

一方、接続方法として「emb」を選んだ場合には、プロキシサーバは使用しない設定になっており、「x-em-uid」が送信されることはない。各社の携帯電話で広く普及してる「NAVITIME」のサービスを利用しようとしても、「emb」で接続したときには、「ご利用いただけません」という画面が出る(図2)。契約者固有IDが送信されず、課金関係の処理ができないからだろう。

図2: 「emb」接続ではNAVITIMEが利用できない様子

で、iPhoneって契約者固有IDは出力されるの?」という声があったが、ソフトバンクモバイルがこれと同様の手段を用意すれば、iPhoneでも契約者固有IDの全サイト送信は実現可能と思われる。*3

イー・モバイルに契約者固有ID送信は不必要なんだが

10日の日記で、次のことを書いた。

たしかに、携帯電話のWebでは、Webサイト側で、IPアドレスで書き込み者を区別することができないという問題がある。通常のインターネットのWeb ならば、アクセス元IPアドレスと時刻の情報でISPに開示請求すれば契約者を突き止めることができるが、携帯電話のWebでは、アクセスが携帯電話会社のゲートウェイを介して来るため、ゲートウェイが匿名化Proxyのようになってしまっている。(略)

その理由からも、HTTPのリクエストヘッダに何らかの識別情報を送信する必要性があるのはわかる。ProxyサーバがX-Forwarded-Forヘッダを付加して中継するのと同様に。

しかし、イー・モバイルにはこの事情は当てはまらない。なぜなら、イー・モバイルでは、インターネット接続をした上でサービスを動かしているのだから、接続する都度、IPv4のIPアドレスが個別に割り当てられるからだ。PCの通常のインターネット同様に対処できる。

ちなみに、イー・モバイルでインターネット接続したとき、IPアドレス(アクセス先のWebサーバから見える)が具体的にどうなるかというと、「emb」のときと「EMnet」のときで次のようになる。

1回目2回目
embEM119-72-20-XXX.pool.e-mobile.ne.jpEM60-254-240-XX.pool.e-mobile.ne.jp
EMnet プロキシありEM117-55-1-236.emobile.ad.jpEM117-55-1-231.emobile.ad.jp
EMnet プロキシなしeM60-254-209-99.emobile.ad.jpeM60-254-209-99.emobile.ad.jp

「emb」で接続したときは、接続毎に大幅に異なるIPアドレスが割り当てられ、「e-mobile.ne.jp」というドメイン名が付けられている。

一方、「EMnet」で接続したときは、デフォルト設定では、プロキシサーバのIPアドレスでWebサイト側に届く。このアドレスは「emobile.ad.jp」のドメイン名になっており、区別されている。複数台のプロキシサーバが適当に割り当てられるようだ。このアドレスは、イー・モバイルの「技術情報」のページによると、現時点では「117.55.1.224/27」の範囲となっているそうだ。

そして、「EMnet」でプロキシサーバを外したときはというと、何度か接続を試しても毎回「eM60-254-209-99.emobile.ad.jp」というアドレスになった。NAT経由になっているのだろうか*4。「eM60-254-209」でGoogle検索してみると、たくさんヒットし、いずれも「-99」となっている。端末に割り当てられているはずのローカルアドレスを「vxIPConfig」を使って調べてみたところ、「10.128.XXX.XXX」というプライベートアドレスになっていた。

EMnetは何のために必要だったのだろうか。

NAVITIMEは、EMnetのプロキシ経由でないと使えないようになっている。しかし、普通のWindows Mobile機器なんだから、ケータイ流にやらなくても、NAVITIMEは作ることができたはずだ。Skypeのように、一回ログインすれば、ユーザIDとパスワードを覚えておくように作ることもできたはずで、そうしていれば契約者固有IDを必要としない。

その点、先日「イー・モバイルのEMONSTERシリーズに最適化」と発表された、音楽配信サービス「mora win」では、普通に「emb」接続で利用できる。ユーザ名とパスワードでログインして使うようになっている。

日本のケータイサイト開発者の技術力が後退していく

一般的には、Webアプリケーションの開発に携わる技術者は、セッション管理の概念を把握しておく必要がある。セッション管理は、セッションIDをcookieに覚えさせることでアクセス元のブラウザを識別し、アクセス元のブラウザ毎にWebアプリケーションの状態を記憶して使用するというものである。セッションIDは、予測困難なその場限りの乱数として生成されなければならない。これが、Webアプリケーションのスタンダードだ。

こうした概念は、ソフトウェア技術あるいはネットワーク技術を基礎から学んだことのない者には、いささか理解が難しいことかもしれない。

一方、ケータイWebで、ケータイが送信してくる契約者固有IDの概念は、誰でも理解できる単純なものだ。そのIDがそのまま閲覧者に対応する。IDをそのまま使って処理すればよく、セッション管理は使わなくてもよくなる。文系の行政官にも理解できる。cookieがどんなものか解らない人でも理解できる。

ここ数年、「初めてプログラムを書きました」というレベルの開発者が、こぞってケータイサイト開発をやらされているように見受けられる。ユーザの識別手段として契約者固有IDによる方法しか考えたこともないような人たちが。

はてなブックマークには連日、契約者固有IDの取得方法や使い方の解説記事にたくさんの無言ブックマークが付く。「こんな安直なやり方がまかり通ってはいかん」と思うけども、もう止めようがない。

NAVITIMEのイー・モバイル版では、Skypeのように契約者固有IDに依存せずに作ることはできたはずなのに、NAVITIMEはそれをやらなかった。もはや、日本のケータイ開発者の間では、契約者固有IDに頼って設計することが当たり前のものとして受け入れられてしまっていて、それより高度っぽい方法は考えもしないようになっているのではないか。*5

日本でだけ技術力が後退していく。

この調子で後退していけば、結局、「PCの世界にも共通の固有IDを」という流れになってしまうのではないか。議員立法で押し付けられるまでもなく、後退した開発者らの手によって。

IDと氏名の収集は既にあからさまに横行している

今年2月のこと。「今日すべきこと -世界初!今日すべきこと検索エンジン-」というサイトのブックマークがホッテントリにあがっていた。

あなたの今日すべきことを検索してくれる
世界初のライフハック検索エンジンです。
名前を入れて検索してみてください。

とある。正直、なんでこんなたいしたことのないサイトがこれほどまでに注目を浴びているのか疑問だった。サイトには「フジテレビ「めざましテレビ」で紹介されました!」と書かれている。おそらく、おびただしい数のアクセスがあり、氏名が入力されたことであろう。携帯電話から。

このサイトは、なぜか、ケータイの端末IDを送信させている。NTTドコモの携帯電話からアクセスすると、HTMLは次のように書かれていて、送信ボタンを押すと、図3のように「携帯電話情報を送信しますか?」と出る。

<form action="./" method="POST" utn>

図3:サイトが端末IDを収集しようとしている様子

端末IDがなぜ必要なのか理解できない。このサイトの機能を実現するのに端末IDを必要とする用途がない。

これをやっているということは、auやソフトバンクモバイルについても契約者固有IDを記録しているのだろう。auやソフトバンクモバイルでは、確認なしに自動送信される。(このサイトは、iモードIDの利用はまだ始めていないようだ。)

既にこのサイトに氏名を送信してしまった人は、何の目的で端末IDを収集しているのか、サイト運営者に問い質してみてはどうだろう。はたして納得のいく説明が得られるだろうか?

問題だとわかっている現場が声をあげない

こういうやり方の危なさは、現場のケータイサイト開発者が一番わかっているはずだ。しかし彼らは表立って声をあげない。せいぜい、2ちゃんねるでヤバいと書き込むくらいで、真正面からの批判をしない。

契約者固有ID全サイト送信の危険性を訴えると、しばしばこう言われる。「ケータイWeb使わなけりゃいいじゃん」と。そう、ケータイサイトの開発者自身が、「自分自身はケータイは全然使っていない」と公言することがたびたびある。自分は安全なところにいるので気にならないというわけだ。

儲かるんだからしょうがない。IT弱者から搾取して。

(力尽きたのでここまで。続く予定。)

*1 ところで、「個体識別番号」という用語がなんだか嫌な感じだ。この言葉って、ワンクリック不当請求業者らが使い始めたものだと記憶しているのだが、私の記憶違いだろうか。彼らは「『固体』識別番号」とよく誤記していたものだ。初期のころは、ありもしないランダムな番号を表示して脅していた。この言葉は、元々、牛肉トレーサビリティの用語として広く消費者にも認知されていたもので、「個体」は、牛の生物としての一頭を指す言葉である。人間に対して「個体」という言葉を使うのは違和感がある。ワンクリ屋的な品性を感じるのだが……。

*2 また、5月28日に拝聴した講演の資料では、「個別サイトごとの取り組みに加え、共同監視プログラム(例:悪質ユーザーのブラックリストの管理)の導入を検討する」という構想も示されていたが、契約者固有IDをサイト間で共有して悪質ユーザの締め出しを実施するとなると、契約者固有IDをどのサイトまでに提供するのかといったことも、明確なルールが必要になると思われる。

*3 ただし、プロキシサーバで端末を識別する仕組みが用意できる必要があるので、iPhoneを無線LAN接続で使用しているときには、契約者固有IDは送信不可となるだろう。cookieを併用して実現する方法はありそうではあるが。

*4 これは問題になりそうな気がする。プロキシを外したEMnetは使えないようにした方がよいのではないか。

*5 課金システムが必要だったにせよ、契約者固有IDがなくとも課金システムは構築可能である。

本日のTrackBacks(全100件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20080722]

ここ数年、「初めてプログラムを書きました」というレベルの開発者が、こぞってケータイサイト開発をやらされているように見受けられる。ユーザの識別手段として契約者固有IDによる方法しか考えたこともないよ...

前回のエントリは、あまりにポジティブすぎる気もしたので、高木さんの懸念を補強するようなネガティブな話も。
総務省、というか、テレコム業界用語的な意味での「通信プラットフ祟..

健全なモバイルサイトを認定する民間機関・モバイルコンテンツ審査・運用監視機構(EMA)は9月16日、SNS&ゲームサイト「モバゲータウン」と、高校生向けSNS「en高校生」を認定したと発表した。 EMAはこれまでに、SNS「GREE」「MySpaceモバイル」、投稿サイト「魔法のiら..

検索

<前の日記(2008年07月19日) 次の日記(2008年07月26日)> 最新 編集

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
<前の日記(2008年07月19日) 次の日記(2008年07月26日)> 最新 編集