「IT」カテゴリーアーカイブ

2010-11
23
22:12:27
w3cもケータイ認証には困惑している件

技術ネタ, , , , ,

以前Twitterでもツイートしてたんだけど一部誤解があったのでこちらでまとめてみる。

Global Authoring Practices for the Mobile Web (Luca Passani)
http://www.passani.it/gap/

上記をもって「w3cが個体識別番号に駄目出し」としていたんだけど、多少事情が違った。
実は上記には元になる対象文書がある。それがw3cのベストプラクティスだ。

Mobile Web Best Practices 1.0
http://www.w3.org/TR/mobile-bp/#d0e1925

上記のGlobal Authoring Practices for the Mobile Web(以下GAP)はこのw3cのベストプラクティス(以下MWBP)への一種の「アンチテーゼ」として書かれている感が強い。
それらの比較についてはこちらのページが詳しい。
そのほとんどはモバイルWEBでの実装方法についてなので本稿の趣旨とは外れる部分も多いのだが、例えばMWBPではCookieについてこのように解説している。

5.4.14 Cookies
[COOKIES] Do not rely on cookies being available.
5.4.14.1 What it means
Cookies are frequently used to carry out session management, to identify users and to store user preferences. Many mobile devices do not implement cookies or offer only an incomplete implementation. In addition, some gateways strip cookies and others simulate cookies on behalf of mobile devices.

(参考訳)
[Cookies]Cookieが必ず使えると考えるな
Cookieはよくセッション管理やユーザーの特定に使用されるが多くのデバイスでは利用できなかったり正しい実装がされていない。更にはゲートウェイによってはCokkieを削除したりエミュレーションしている。

これだけだ。ベストプラクティスと言いながら実は解決策は何も提示していない。

これに対しGAPは非常に現実的だ。

Practice: If an application only relies on cookies for improved service, but is not essential to the well-functioning of the service itself, then cookie support can be safely assumed.
If cookies availability is essential to the correct functioning of the application (typically for supporting user sessions), then alternative mechanisms should be assumed. URL-Rewriting is the common way to by-pass the lack of cookie support ([URLREWRITING]).

(参考訳)
アプリケーションがCookieのみをベースにできるならそれは安全と見なしていいだろう。
Cookieの利用が機能の要であるならその代替機能も必要とされるだろう(訳注:恐らくCookieが使えない場合のことを言っている)。URL-RewriteはCookieの代替に使用できる共通した方法だ。

そしてよく知られたセッションIDをURLへ付加しURL-RewriteでCookieと共存する方法を述べているのだが、その最後でこのようなことを提示している。

Finally, in many cases, operator gateways and independent portals attach unique headers and values to each HTTP request, such as phone number headers (x-wap-msisdn, x-nokia-msisdn, x-up-calling-line-id) and subscribeer id headers (x-up-subno). The headers can be exploited as unique keys to track users and the foundation for session management.
Some detailed techniques to track users are presented here [TRACKUSERS]

(参考訳)
最後に、多くの場合キャリアのゲートウェイなどは特別なHTTPヘッダーを付加する。x-wap-msisdn, x-nokia-msisdn, x-up-calling-line-id, x-up-subnoといったもので電話番号や契約者番号を示している。
これらのヘッダーをユーザートラッキングのためのユニークキーにしたりセッション管理のベースにすることは脆弱性をもたらしかねない。

ここでいうX-UP-SUBNOとは日本ではauで利用されているサブスクライバーIDと同じだ。当然言及はないが、docomoのuid、SoftbankのX-JPHONE-UIDも同列と考えていいだろう。つまりこのコンテキストにおいては「日本のガラケー界は根本から駄目出しをされている」と言えるだろう。

たとえ米国でもディベロッパーがユーザーの特定をあまり行っていない、そういうニーズが無いとは思わない。
ではw3cが何故ここまで踏み込んだ言及が出来ないかは幾つか理由もあると思うのだけど(個別製品への言及は馴染まないとか。X-UP-SUBNOはクアルコムOpenwaveのWAPゲートウェイでの仕様である)、大きな理由として「ベストな方法が考えつかなかった」という点も大きいだろう。
米国ではそもそも個体識別IDを送出しているキャリアばかりではない。つまり共通した手法として利用できる環境ではない。またCookieに対応する機種や環境も(日本と同じく)100%では無いようなので結局のところよい方法が示せなかったのではないか。

一方でこういうテクニカル文書もある。ユーザーをトラックするためのTIPSという感じだが 詳しくは参照してもらうとして、日本での脆弱な「ガラケー界」を見ている者としては少し口出ししたい気持ちにもなる。
つまりは問題ではあるがよい方法が見つからなくて複数の手法を組み合わせる、または端末の特性によって切り替えるしかない、というのは日本と同じ状況とも言えるかも知れない。
かくもモバイル環境(あえて言えば従来までのモバイル機器と環境) でのユーザートラッキングや認証については米国(あるいは世界)においても共通した手法は確立されていないし誰もが困惑しているということになるではないか。

翻って日本だ。幸い(?)日本の「ガラケー界」はベストプラクティスならぬ「バッドプラクティス」の宝庫だ。
しかし見方を変えればそれはベストプラクティスの種の宝庫とも言える。
こうした情報や経験が自由に交換され、国際的に包括されたベストプラクティスが熟成される環境が何とか作れないものか。そうした貢献が出来ていない点でも日本は「ガラパゴス」と呼ばれるのだろう。

(追記 2010/11/25)
“can be exploited..”について、コメント欄でも「単に使用できると言っているだけでは」との意見を幾つか頂いていました。
個人的にも気になったので、筆者であるLuca Passani氏へ直接メールして聞いてみました。以下がその最初の返信です。

(悪意されうると言いたかったのか？との質問に対して)
not really. I just meant that, if a developer needs to track users and cookies
are not available, other headers are an option.
Regards
Luca

との返答でした。
ということで、まずは「脆弱性になり得る」との参考訳を示したことについてお詫び申し上げます。
Passani氏とはその後少し話をして、僕からは日本での簡単ログインという方法が脆弱だと言われているんだよと伝え、彼に(恐らく彼が知る限りの)海外ではどのように捉えられているか尋ねたのですが、
「プライバシーの問題は特にヨーロッパ(彼はローマ在住の恐らくはイタリア人)では問題視される。但しオペレーターはパートナー(恐らく日本における公式サイトよりも厳しい業務提携先と推測)にしか『電話番号』は通知していないし、パートナー以外はIdentifier(例えばX-UP-SUBNOなどの個体識別番号)しか受け取れない」とのことでした。
電話番号というのは多少驚くところですが欧米(他の地域は言葉の問題でよく分かりませんが)では一部のキャリアではパートナーへのサービスとして行っているようです。また個体識別番号の取り扱いについては全く意に介していない様子でもありました。これはそもそも日本での「簡単ログイン」やセッション管理としての利用は一般的ではないため逼迫した問題化していないからだろうと推測します。
以上より、本文については「日本のガラケー界は特に興味も持たれていなかった」として訂正しご解釈下さい。
(であれば”can be exploited”なんて微妙な表現しないでよー、とは思いますがそれはそれとして)

ただ付け加えると、彼の経歴を見ると分かるのですが、実は長年Openwaveでエンジニアとして働いていた人物でもあります(現在はとある企業のCEOのようです)。つまり元々のX-UP-SUBNOを生み出した会社です(その他の通知ヘッダー類についても)。故に個体識別番号のプライバシーやセキュリティ問題について聞くのはそもそも野暮だったのだろうというのが印象です。

最後に、はてブのコメントなども見て多少気になったのですが、現時点において、ではモバイル認証によい方法がないのかと言えばそれは違います。単にCookieを使えば良いだけです(Passani氏も指摘している通り)。これは日本でももちろん同様です。
但しCookieが全面的には利用できないというある意味限定された環境下でのプラクティスの話と言うことになりますので誤解無きようにお願いします。
また個体識別番号の取り扱いについては国や地域で状況やプライバシーへの考えなども違うので一概には言いにくいかも知れませんが、しかし日本での経験が有意義なものに転嫁できるはず、という点はやはり変わりないだろうとも思います。
今回は相手が悪かったところもあるのですが(笑)、逆に如何に日本の実情が知られていないか伝えられていないかと言うことも肌で感じられたので、そうした取り組みが業界全体で行われるなら喜ばしいことだし重要な貢献であろうと思います。
以上、ご報告まで。

2010-11
23
00:55:15
ガラケー機能は須くクラウドを目指せ

技術ネタ, 時事ネタ, , , , , ,

IS01がAndroid1.6からバージョンアップされないことになってちょっとしたお祭りになった。
そもそも0円端末/8円運用が注目されていた矢先の発表で余計に注目を集めることになったことだろう。
しかし0円で買った人はともかく、発売直後にそれなりの価格で買った人も大勢いたはずで、2.1への移行に期待していたとしたらそちらの方がよほどショックなことだっただろう。

OSバージョンアップが出来ない、という残念な決定は別に国内メーカーに限らず、HTCでもMotorolaでも実は海外勢でもあることだ。ソニエリのXperiaが1.6から2.1へのアップグレードに半年ほどかかりユーザーをヤキモキさせたのも記憶に新しいところだろう。

こうした理由は単純に新しい今後のOSの求める性能や機能などが原因でそのハードウェアでは対応できないという理由が大半だとは思うが、一方で日本メーカーには今後更なる足枷となる原因が潜んでいるとも思う。それが「ガラケー機能」の搭載だ。
一般にこれまでキャリア各社は「始めにハードありき」のサービス展開を目指してきたと言える。着うたもそうだし、また「ガラケースマートフォン」の標準機能となりつつある、おサイフケータイ・ワンセグ・赤外線通信も当然そうだ。
しかしその前提はスマートフォンの登場と浸透で徐々に崩れ去ろうとしている。
OSと開発環境はGoogleが準備し、Android端末における基本的なハードウェアスペックの範疇のようなものも国際的に熟成されつつありこれを外れる調達と製造のコストは馬鹿にならなくなるだろう。
その上上記のような「最新OSへの対応速度」というものが端末やメーカー/キャリアの魅力に付加されるようにもなってきた。
当然特殊なハードウェアを国内機に限って使い続ける限り国際調達力はつかないし、ハードウェアと最新OSに合わせたドライバー・アプリ開発は製品開発サイクルの冗長化つまり競争力の阻害を招くだろう。

ルールは変わった。ならば対応もそれに応じて変わらなければならない。
そこで僕の考えはこうだ。ガラケー機能は今後如何にハードウェアから脱却できるかが今後も生き残れるかどうかの鍵となる。

おサイフケータイ・ワンセグ・赤外線機能をクラウドに

例えばおサイフケータイ。既報の通り、海外勢では同等の機能を目指してNFCにより近接無線通信を行うことになるだろう。またハードウェア的にも日本のように端末内部にFeliCaのようなハードを仕込むのではなく、SIMカードに内蔵させる方向であるらしい。Androidではすでに次期バーションでの採用が決定しており、またiPhoneでも同様の対応がされると聞く。
おサイフケータイの機種変更時の煩わしさは誰もが経験して評判も悪いところだが、それは端末本体に機密情報を格納するという方法を取っているからだ。これがSIMカードに変われば理論上は単にSIMを入れ替えるだけでおサイフケータイ機能も含めた機種変更が行える。よくよく考えるまでもなくこちらの方がメーカーにとってもユーザーにとっても合理的だし日本では何故その方法が取られなかったのか非常に不思議だ(というか、恐らく単純にFeliCaを売りたかった都合なのだろう)。
この場合端末にとってはSIMカードとのインターフェースさえ定義されていればいい。そしてそれは恐らくOSが吸収することになるだろう。機種ごとのドライバーなどは必要なく、あとはおサイフケータイを利用するアプリのみが開発され続ければよい。
もちろんNFCをベースとしたビジネスモデルがどうなるのか、どのような普及をするのかはこれからの課題だ。
しかし例えば一例を挙げれば、海外ではすでにこのようなサービスも登場しつつある。

Squareはおサイフケータイと闘うことになるのだろうか

簡単に言えばこれはおサイフ機能をローカルからアプリそしてネット側へ移行しようという発想だ。そしてこれらのビジネスモデルが世界を席巻し始めた時、iDやEdy、Suicaなどが如何に日本で普及していようと果たしてそれに抗い続けることは可能だろうか。
日本のおサイフケータイはほとんどがローカル機器での通信にて取引を完結させる発想を持っている。もちろんよい面もある(プライバシー保護など)が逆に言えばそれをすべてクラウドで完結させるサービスが登場すればそれほどの競争力を保ち得ないのではないかと思う。
オフィス製品や大規模なERP製品が今まさに徐々にクラウドサービスに吸収されつつあるように同じことが起こりえるのではないか。
その足かせとなるのがやはりハードウェア依存ということだ。ここから如何に脱却しネットワークへ主軸を移し端末依存を止めキャリアやメーカーの壁を脱却しない限り、そもそもおサイフケータイの各サービスは生き残れるかどうかの瀬戸際に立たされることだろう。

ワンセグについて、実は理論的には最も対応は簡単だ。ワンセグ放送のIP再送信を認めればよいだけだ。そしてそれを再生できるアプリを搭載する(マーケットから自由にダウンロードできる)だけだ。
そもそもワンセグ放送は携帯キャリアというよりは総務省と放送業界の強力な後押しで始まったに過ぎない。そしてデジタル放送始めIP再送信を阻んでいるのは通信と放送の分離政策および著作権行政だ。(放送法上一部の免許では特定地域にしか放送できない、などの制約がありボーダーレスなIP通信と馴染んでいない)
この問題はいつも多数の受益権者が絡みなかなか進展しないが、例えば既に海外のテレビ局が次々と行っているようにオン・デマンド放送を、しかも海外拠点から日本向けに行う企業が出てきたら果たしてどうなるだろう。インターネットには国境は無くまた日本の電波法・放送法を盾に海外の企業へ影響力を及ぼすのは国際司法上かなり無理があるだろう。
とは言え必ずしも悲観すべき状態ではなく各種実証実験なども細々とではあるが行われているようだが、大きな判断を速く下さなくてはこの分野さえ海外勢との競争に苦しむ事態に陥ることだろう。

赤外線機能に関して、逆説的だが果たして「赤外線機能が欲しい」と考えるユーザーは果たしてどれだけいるのだろうか。そう、ポイントはそこではない。ユーザーは赤外線機能ではなく、「アドレスの交換機能」が欲しいだけだ。
特別なハードウェアからの脱却という意味では、赤外線センサーを使用する必要性は全くない。例えばBluetoothなどを用いてアドレス交換を行うアプリも広く知られており、QRコード読み取りというのも一つの方法だろう。
従来のガラケーとの互換性という意味では最近のガラケーでもBluetoothは一般化しつつあり、逆にガラケーにそうしたアプリを搭載するのも一つだろう。
そしてまたAndroidやiPhoneもそうであるようにそもそものアドレス帳機能はローカルに隔離されているよりもクラウドで管理され複数の機器で共用できる方がよっぽど便利だ。この分野も単に赤外線機能などに止まらず、いかにクラウド対応を推し進められるかがポイントとなっていくだろう。そしてやはりまたそれはガラケー自身においても同様である。

キャリア依存からクラウド依存へ

何故このような極端に見える(かも知れない)サービスの再編が必要なのか。ハードウェア依存が「悪」なのか。それはスマートフォン、そもそもモバイル機器が宿命づけられている「ネットワーク親和性」故だ。
これまでキャリアがすべてのサービスを決める「牧歌的な」時代であればサービスがハードに依存していようとアプリだろうとクラウドだろうと関係なかった。しかしそうしたコントロールが行えなくなることは端末一体の訴求力をサービスやクラウド連携と言ったネットワーク指向性の高いサービスへ移行せざるを得ないことになる。でなければ既に述べたようにハードが足枷になり競争力の低下とサービス品質の低下を招くだけだ。
「日本発」のこれら「特異な」サービスは遠からず市場からの撤退を迫られることだろう。実際、例えば着うた/着うたフルはスマートフォンの浸透に伴い徐々にそのプレゼンスを無くしていくことだろう。それを見越してかLISMOなどのサービスはアプリとして再編されだしているように思うが、それがAndroidマーケットでの楽曲販売やAmazonのDRMフリーサービスあるいはiTunesStoreなどとどこまで同じ土俵で戦えるかはまだ未知数だ。何しろLISMOなどはそのキャリアでしか使えないのだから。

それを防ぎたいのであるなら、如何にこれまでの端末・回線・サービスの不可分一体サービスをクラウドへのみに移行していけるかにすべてはかかっているのだと思う。
だが果たしてこれまでの既得権を守りたいだけのキャリアや業界がそれを理解できるか。成功体験に浸りすぎた業界が「イノベーションのジレンマ」を自力で克服できるだろうか。
もしかするとようやく理解できた時には、既に日本としてのメリットは何もないサービスばかりが日本国内を席巻した後かも知れない。

2010-10
26
00:40:55
Titanium mobileが盛り上がっているようで何よりだ

技術ネタ, , , ,

実はしばらく前にTwitterのTLで流れてたのを見て触りだしてからはまっていたので、最近の盛り上がりは嬉しく思います。なんたって一時期は日本でTi mobile使ってるのは数人ぐらいしかいないんじゃないかとか思ってたぐらいなので。
へえまだアルファブロガーっているんだぁと思った次第。

実は既にそれなりにまともなiPhoneとAndroidアプリをTi mobileで作ってそれぞれAppStoreとAndroidマーケットで公開していたりします(本名で出してるからここでは紹介しない)。
ということで僕も別にそんな経験あるわけではないけど使っていて感じたこととかつらつらと書いてみますよ。

因みにTi mobileの日本での先駆者と言えばまとめサイトも作られてるdonayamaさんとかyuichi_katahiraさんとかですかね。また Yuichiro MASUIさんはAdMob用など幾つかiPhoneモジュールを公開されていらっしゃいます。

iPhone版は優秀だけどAndroid版は発展途上

僕の経験で言うと一週間でiPhoneアプリは出来てしまったんですがそこからAndroidに対応させるのに二週間かかりました。原因はAndroidでのバグ？らしき挙動とiPhone版さの差異のためです。
iPhone版は非常に優秀でJavaScript好きの人ならさらさらと簡単にアプリを作れてしまうと思います。ただそれと同じつもりでAndroid版に拡張し始めると要領があまりに違っていてかなりはまりました。
例を挙げると、何故かiPhoneでは当たり前に取得できるresponseXMLがAndroidではRSSフィードによっては文字化けしたり(結局最後まで原因はわからず、responseDataを使ってパースした)、windowのxIndexがwindowのlayout指定によって順序が異なったり、WebViewで取得したHTMLは外部からは取得できなかったり、windowのblur/focusイベントは動作しなかったり･･などなど。
「iPhoneとAndroidでは画面サイズとかが異なるからコードを分けないといけなくなる」程度の話が流れていますがそれどころではないです。僕はかろうじて同一レポジトリに閉じ込められましたが、現時点ではコードの規模によっては別々に開発することも考えた方がいいこともあるでしょう。
Titanium Developer製品(Ti mobileはその一環)はOSSで開発が進められているのですが、チケットを見てもAndroidのissueは多いように見えます。
まだまだ開発途上の製品なのでそれにうまく付き合えるかどうかがポイントになります。

iPhoneとAndroidのJavaScriptの解釈が異なる

恐らく先のAppleによる「AppStoreからの開発ツールの締め出し」騒動に関係していると思われますがiPhone版ではコンパイル時にネイティブコードに変換します。対してAndroidではJSエンジン(恐らくGoogleのV8？)でリアルタイムにインタープリターもしくはJITで実行しているようです。つまり解釈されるエンジンが異なるのです。これが前項の原因でもあり、また両者での違いを経験から読み取っていく必要があるでしょう。

メモリ管理しなくてもいいということはメモリ管理できないということ

僕もTi mobileを一番気に入っているのはメモリ管理を気にしなくて良いと言うこと。特にiPhoneでは顕著ですよね。しかし一方ではそれはメモリリークなどの管理をできないということも意味します。
開発元のAppceleratorでは「メモリリークはうまく回避しているよ」と言い切っていますが 実際に試してみると細かなメモリリークは発生し得るようです(特にネットワーク周り)。
あまり問題にはならないレベルとは思うのですが、JavaScriptに書き慣れていないとGCを意識できずオブジェクトを残し続けてしまいがちです。ブラウザでもよく話題にはなるのですがかなり巨大なコードにならないとあまり気にしない部分かと思います。しかしTi mobileではGCを意識した変数設計をしておかないと簡単にメモリを食い潰すアプリができてしまいます。
こういう時は逆にGCに頼るのではなく自由にメモリ管理も出来る仕組みがあるといいですね。

ドキュメントを信じるな、アンドキュメントな仕様が多すぎる

これはAppceleratorが基本的にはOSSで無償で提供しつつビジネスとしてサポートを有償にしていることと関係していると思うのですが、ドキュメントがあまりに杜撰です。
そもそも返値とパラメータが全く異なっていたり(多分コピーミスなど)、ドキュメントだけではちょっと複雑な仕様を実装しようとすると悩むことが多いかも知れません。
他の方もおっしゃっているように、APIドキュメントよりもサンプルアプリであるKitchenSinkを最大限利用しましょう。特にiPhoneとAndroidの実機に実際インストールして動作を確認することをお勧めします。
またドキュメントはあまり参考になりませんが、ディスカッションフォーラムは割と参考になることが多いです。凄く盛り上がっているとは言えないけど みんな同じ事で悩んでいるのです。

拡張モジュールを作るならObjective-CとJavaは知っておいた方がいい

Ti mobileでもiPhoneとAndroidのすべての機能に対応しているわけではありません。また世には様々な便利なライブラリが公開されていますが、当然それらはObjecive-CやJavaで書かれています。Ti mobileにはそれらネイティブコードを取り込むための「モジュール」という仕組みが用意されているのですがそのためにはObjective-CやJavaでもコードを書けなければなりません。更に言えばiPhoneやAndroidでどのようにアプリを開発するかの知識が必要です。
因みに僕は広告を掲載したかったのですが当然Objective-CやJavaのライブラリやサンプルしか提供されていないので、独自にiPhoneとAndroid用にモジュールを作成しました。広告程度なら表示するだけなのでそんなに難しくないです。但しiPhoneやAndroidの経験がないとかなり難しいと感じることでしょう。
なのでTi mobile自体は単に「Objective-CやJavaを知らなくてもJavaScriptを知っていればiPhone/Androidアプリを作れる」ツールなのではなくて、まずはやはりiPhoneやAndroid開発をある程度経験してからの方が相応しいツールなのではないかなぁと思います。

最後はコードを読もう！

先に述べたようにTi mobileはOSSとしてすべてのコードが公開されています。実際現時点でのコードをgithubから取得して自分でコンパイルして使うことも出来ます(Androidの拡張モジュールはそのようにして開発します)。
なのでどうしてもバグなのか仕様なのか回避のしようがなかったら最後はコードを読んでみることをオススメします。
個人的な例では、どうしてもAndroidの実機で位置情報が取得できない問題がクリアできなかったのですが、コードを読んでみるとgetLastKnownLocation()のみで取得していることが分かりました。これは時々ディスカッションでも話題になっていますが初回には位置情報は取れないのです。
ということでプロバイダーをNETWORKにして回避したのですが(これはこれでどうかと思いますが)、こういう部分もOSSとして提供されている利点であり、活用しない手もないでしょう。

といったところでしょうか。
何やら文句と愚痴が多くなった気もしますが(笑)、個人的には大変気に入っています。特にJavaScript好きには堪らないツールとなることでしょう。
一方で「初心者でも簡単にiPhone/Androidアプリが作れる」風のイメージには疑問を感じていて、どちらかと言えば現時点でiPhone/Android開発をバリバリされてらっしゃる方にこそ効率を上げるためにぜひオススメしたいツールです。
まずは使ってもらって、少しでも日本で広まるといいなぁ。

2010-04
28
06:55:51
日本のケータイWEBはどうしてこんな仕様になったのか

ガジェット, 技術ネタ, 時事ネタ, , ,

また高木さんが恐ろしい記事を上げている。
これまでも日本のケータイWEBの問題点は様々な人に数々挙げられてきたが、この記事の指摘は中でも最大のターニングポイントになるだろう。
ここまで破綻しているケータイID認証（簡単ログイン）
実はこの記事での指摘点には個人的にも言及したい点があるのだけど、ちょっと理由があるのでそれはまた後日にしたい。それは恐らくこの記事だけから受ける印象よりも実はこの問題はひどく根が深く影響は幅広いということだ。

日本のケータイWEBの有様は特徴的だ。特に技術的な立脚点によるものが大きいと思うが、それが「ガラパゴス」と呼ばれるゆえんであることはまず間違いない。特異な技術立脚点が海外や他キャリアとの互換性を蔑ろにし、独自な進化をせざるを得なかった(独自に進化したのではなく、せざるを得なかった点に注意)ということだ。

ではその「技術立脚点」とは何か。
僕は個人的には「パブリックなインターネットをインフラにしてクローズドなケータイ・ネットワークを作り上げること」を主眼にした点だと考えている。
以前モバツイで有名なえふしんさんがこんなことを言っていた。

http://twitter.com/fshin2000/status/9612891626
もろもろセキュリティのことまで考えると、携帯サイトはガラパゴス（国内で閉じてる）の方が良いんじゃないかなぁ。

個人的にも以前から感じていたことでほぼ同意である。
というか、そもそもケータイWEBネットワークはもともとここまでの興隆を予想して組み立てられていないのだと推察する。

以前挙げた日本のケータイWEB(モバイルEC)を脆弱に支えている三原則を再掲する。

(1) そのアクセスがそのキャリアの携帯網からのみであることをサービスプロバイダーが保証すること
(2) 携帯網では端末IDが偽装されていないことをキャリアが保証すること
(3) 端末の自由度を低くして端末IDの偽装などの可能性をできるだけ低く保つこと

これはつまり大前提として、ユーザーがこのケータイWEBに介入できるのはケータイ端末の「操作」までであって、自由な端末やアプリをケータイネットワークに接続することは想定していないということだ。
これは恐らくこういう事だったのではないだろうか。
そもそも一番最初にケータイWEBを企画する際にインターネットへの接続を行うことは当然MUSTだった。つまりインフラとしてはインターネットをそのまま利用すると言うことだ。またサービスプロバイダーを引きつけるためにはお金を生む仕組みを用意しなければならない。契約者固有IDのような課金通知の仕組みは必須である。
しかし当時セキュリティという観点ではPKIなどの完全なセキュリティ手法の導入には手間もかかり端末の性能も限られている。しかし何も行わなければインターネットという性質からはなりすましや情報漏洩はほぼ防げない。
そこで「簡単に」ケータイ側を「セキュアに」保つために先の三原則が考え出された。
つまり契約者固有IDを守るために「端末」「回線」「データ」をインターネット上からできるだけ切り離しその中にもう1つの「クローズド・ケータイネットワーク」とすることでこれら情報を守ろうという試みである。
IPアドレスでの制御であったり端末への独自アプリの禁止などといった稚拙な方法であり全くレベルは異なるが、「安直なVPN」とでも思えばいいのかも知れない。
当時今ほど日本は垂直統合モデルは強くなかったと記憶しているが、そのために端末仕様を強制したり一部のサービスプロバイダーを公式サイトと認めて契約者固有IDの取り扱いをキャリア支配に置くなど、必然的に垂直統合モデルが必然となった。

どうだろう。これは想像でしかない。しかし一定の説得力のある仮説にもなっていないだろうか。

しかし当然時代が変われば状況も変わる。高木氏が指摘したポイントも当時は想定されなかった技術的な変化故だし、またSIMフリー化の流れも微妙なプレッシャーを与えつつあるかも知れない。
ケータイWEBが変わったのではない。周りの環境が変わったのだ。一理ではだからこそケータイWEBはこのままでは変化は起こせないだろうとの諦めもある。一方で、まず間違いなくいつの日にか莫大な被害を及ぼしながら日本のケータイWEBビジネスが信用崩壊する危険性は日に日に高まっているとも言える。

だからこそえふしんさんの主張も説得力を持つことにもなる。
では現状ケータイWEBはどうあるべきなのか。
まず第一に契約者固有IDの送出先は各キャリアの認める公式サイトだけにすること。勝手サイト、すなわち「クローズド・ネットワーク」以外への送出は一切禁止とする。契約者固有IDのような「インターネット標準」ではないID送出を勝手サイトなど公式サイト以外に送出してはならない。
次に公式サイトはキャリアネットワーク(ゲートウェイ)とVPNなどのインターネット標準のセキュアな接続を行うことを必須とする。そしてこの場合のみ契約者固有IDを送出することにする。これは通信を秘匿する/通信先を限定するという意味もあるが契約者固有IDの送信先を各キャリアと限定的な「クローズド・ネットワーク」に閉じ込めてしまうという意味もある。これにより現行のあいまいなクローズド・ネットワークよりもより強固なクローズド・ネットワーク化により契約者固有IDは守られることになる。
第三に公式サイトはキャリアネットワークのVPN接続以外からの接続を受け付けてはならない。つまり通信は完全にクローズド・ネットワーク内に閉じ込めるようにする。
これらより詐称や偽装という問題は(データや処理を正しく取り扱える限り)ほぼ回避できるはずだ。

しかしこのままでは今より使い勝手が落ちユーザークレームももちろん増えるだろう。上記は現状の「ガラケー機」つまり契約者固有ID送出可能な従来の端末または携帯網用のアクセスポイント接続時に限ることにする。上記はすべてネットワークサイドのポリシー変更で可能なのでこれまでの端末はそのまま使用可能だ。
一方でスマートフォンに代表される、契約者固有IDに頼らない新しい認証や課金方式にWEB標準として対応可能な端末とアクセスポイントへの接続を共存させる。こちらは接続先には制限は設けなくてよい。何故なら純粋なインターネット利用端末に過ぎないからだ。そして時間をかけてこちらの方式への移行を促すことにする。

二方式を併存することは新方式への移行を促す期間のモラトリアムであると同時に、 自由競争を作り出す規範ともなるだろう。また明確なクローズド・ネットワークと位置付けることで、例えば未成年者用の端末はクローズド・ネットワーク対応のみとすることで例えば公式サイトしか接続できないような「キッズ・ケータイ」も可能になるかも知れない。

—

さて、これらのことは絵空事だろうか。全くの杞憂に過ぎないフィクションですむ話だろうか。
その答えは高木氏の指摘の行間に実は潜んでいると思っているが、その話はまた後日・・・(にできるといいなぁ。。)

2010-04
13
04:41:50
(追記) 続:携帯で端末ID詐称は可能かもしれない話

ガジェット, 技術ネタ, , , ,

前回の記事について。
不用意な不安を煽るのが目的ではないので(理解できている人はできていると思うのだけど)念のため追記しておく。
では今現在auのEZ番号について差し迫った脆弱性や危険性があるのかと言えばこれはNOだと信じている。
上記を実現するためには、auの携帯網に対してスマートフォン(に限らないけど)のように任意のアプリを作成して実行できる環境を用意する必要がある。しかしこれは少なくとも現在ではかなり敷居が高い。
まず携帯網とはつまり現在の「ガラケー」を接続しているアクセスポイントから接続されるキャリア内ネットワークである。アクセスポイントについては以前の記事を参照して欲しいが、現時点ではアクセスポイント名やユーザー名、パスワードなど接続に必要になる情報は公開されていない。つまり何らかの方法でこれを入手する必要があるが僕の知る限りまだこれら情報の流出はない。
スマートフォン網であれば近々提供されるIS-NETで公開されてある程度自由に使用できるのではと思うのだが、「ちゃんとセキュリティを考慮している」サービスプロバイダーでは携帯網からのアクセスのみを許可しこの場合のみEZ番号を使用するはずなので、携帯網に接続できなければいけないことになる。
また au環境で自由に接続可能なスマートフォンや携帯端末を入手するのも難儀だ。ご承知の通りauはCDMA2000という世界的にもマイナーな方式を採用しておりまた上がりと下りで海外とは逆の周波数帯を利用している。まさしくauオンリーワンな環境となっている。従って海外のCDMA2000に対応したSIMフリー機を買ってきてそのまま使えるわけでもない。最近発表されたAndroid/WindowsMobile機のISシリーズはシャープがau向けに独自に開発したのも恐らくこうした事情から海外調達が実質的に不可能だったためだろう。
その他、例えばBREWは公式アプリしか認められていない(勝手アプリが可能ならEZ番号を詐称するのも簡単になる)とか、SIMロックもユーザーロックと呼ばれるショップで登録しないと使用できない(勝手な端末を接続させない、端末とEZ番号の紐付けを厳密に行う)とか、EZ番号は初回接続時にゲートウェイからダウンロードして決定される(これも端末管理を厳密に行いたいためだろう)など、上記を補強するためであろう施策が見受けられる。

という状況があるので必ずしも切迫した状況が放置されているわけではないと思う。しかしその一方で当然にしてこれらのうち何かが偶然であろうと必然であろうと綻びた瞬間一瞬にして脆弱な状況が生まれ得ることも冷静に理解しておくべきである。

そもそも論として、ユーザーのセキュリティに関わる問題なのだから本来は「何故携帯網は安全なのか」「どのような状況においてどのようなリスクがあるのか」各キャリアは率先して消費者に対して説明すべきだ。それをNDAなどを振りかざして情報統制することで安全を守っていると思っているのなら、思い上がりも甚だしい。本当に安全だというのならきちんと論理立てて説明可能でなければ、常に脆弱性やリスクがつきまとっていると考えるのがセキュリティ上の基本である。
SIMロック解除論議もいいけど、こういう消費者保護のための説明責任こそ法律やガイドラインで強制すべき段階に来ているのではないかなあ。