まだ曖昧な部分もあるので書くかどうか迷いはしたのだが、一定の結果には至ったので僕自身が持っている疑問の提示と皆さんへの問いかけという意味を込めて書き連ねてみる。
iPhoneアプリに「楽天銀行アプリ」というものがある。名前通り楽天銀行へログインし自身の取引結果や振り込みなどを行えるアプリだ。
僕自身も楽天銀行には口座を持っているので試してみたのだけど、「あれ？」と思わざるを得ない仕様があった。
簡単に説明すると次のような手順でこのアプリは使用する。
年末だなぁ。ってのはやけにテレビが面白くて感じることが多いですよね。
ということでふと気が向いたので僕もちょっと来年2011年(あるいはそれ以降？)に起こりそうな変化というか展望についてちょっと考えてみました。予想と言うほどでもないしもちろん予言でもなく、僕自身が期待している分野の話と言うことで。
因みにモバイル・IT混在です。 続きを読む »
以前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という感じだが 詳しくは参照してもらうとして、日本での脆弱な「ガラケー界」を見ている者としては少し口出ししたい気持ちにもなる。
つまりは問題ではあるがよい方法が見つからなくて複数の手法を組み合わせる、または端末の特性によって切り替えるしかない、というのは日本と同じ状況とも言えるかも知れない。
かくもモバイル環境(あえて言えば従来までのモバイル機器と環境) でのユーザートラッキングや認証については米国(あるいは世界)においても共通した手法は確立されていないし誰もが困惑しているということになるではないか。
翻って日本だ。幸い(?)日本の「ガラケー界」はベストプラクティスならぬ「バッドプラクティス」の宝庫だ。
しかし見方を変えればそれはベストプラクティスの種の宝庫とも言える。
こうした情報や経験が自由に交換され、国際的に包括されたベストプラクティスが熟成される環境が何とか作れないものか。そうした貢献が出来ていない点でも日本は「ガラパゴス」と呼ばれるのだろう。
(悪意されうると言いたかったのか？との質問に対して)
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が全面的には利用できないというある意味限定された環境下でのプラクティスの話と言うことになりますので誤解無きようにお願いします。
また個体識別番号の取り扱いについては国や地域で状況やプライバシーへの考えなども違うので一概には言いにくいかも知れませんが、しかし日本での経験が有意義なものに転嫁できるはず、という点はやはり変わりないだろうとも思います。
今回は相手が悪かったところもあるのですが(笑)、逆に如何に日本の実情が知られていないか伝えられていないかと言うことも肌で感じられたので、そうした取り組みが業界全体で行われるなら喜ばしいことだし重要な貢献であろうと思います。
以上、ご報告まで。
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をベースとしたビジネスモデルがどうなるのか、どのような普及をするのかはこれからの課題だ。
しかし例えば一例を挙げれば、海外ではすでにこのようなサービスも登場しつつある。
簡単に言えばこれはおサイフ機能をローカルからアプリそしてネット側へ移行しようという発想だ。そしてこれらのビジネスモデルが世界を席巻し始めた時、iDやEdy、Suicaなどが如何に日本で普及していようと果たしてそれに抗い続けることは可能だろうか。
日本のおサイフケータイはほとんどがローカル機器での通信にて取引を完結させる発想を持っている。もちろんよい面もある(プライバシー保護など)が逆に言えばそれをすべてクラウドで完結させるサービスが登場すればそれほどの競争力を保ち得ないのではないかと思う。
オフィス製品や大規模なERP製品が今まさに徐々にクラウドサービスに吸収されつつあるように同じことが起こりえるのではないか。
その足かせとなるのがやはりハードウェア依存ということだ。ここから如何に脱却しネットワークへ主軸を移し端末依存を止めキャリアやメーカーの壁を脱却しない限り、そもそもおサイフケータイの各サービスは生き残れるかどうかの瀬戸際に立たされることだろう。
ワンセグについて、実は理論的には最も対応は簡単だ。ワンセグ放送のIP再送信を認めればよいだけだ。そしてそれを再生できるアプリを搭載する(マーケットから自由にダウンロードできる)だけだ。
そもそもワンセグ放送は携帯キャリアというよりは総務省と放送業界の強力な後押しで始まったに過ぎない。そしてデジタル放送始めIP再送信を阻んでいるのは通信と放送の分離政策および著作権行政だ。(放送法上一部の免許では特定地域にしか放送できない、などの制約がありボーダーレスなIP通信と馴染んでいない)
この問題はいつも多数の受益権者が絡みなかなか進展しないが、例えば既に海外のテレビ局が次々と行っているようにオン・デマンド放送を、しかも海外拠点から日本向けに行う企業が出てきたら果たしてどうなるだろう。インターネットには国境は無くまた日本の電波法・放送法を盾に海外の企業へ影響力を及ぼすのは国際司法上かなり無理があるだろう。
とは言え必ずしも悲観すべき状態ではなく各種実証実験なども細々とではあるが行われているようだが、大きな判断を速く下さなくてはこの分野さえ海外勢との競争に苦しむ事態に陥ることだろう。
赤外線機能に関して、逆説的だが果たして「赤外線機能が欲しい」と考えるユーザーは果たしてどれだけいるのだろうか。そう、ポイントはそこではない。ユーザーは赤外線機能ではなく、「アドレスの交換機能」が欲しいだけだ。
特別なハードウェアからの脱却という意味では、赤外線センサーを使用する必要性は全くない。例えばBluetoothなどを用いてアドレス交換を行うアプリも広く知られており、QRコード読み取りというのも一つの方法だろう。
従来のガラケーとの互換性という意味では最近のガラケーでもBluetoothは一般化しつつあり、逆にガラケーにそうしたアプリを搭載するのも一つだろう。
そしてまたAndroidやiPhoneもそうであるようにそもそものアドレス帳機能はローカルに隔離されているよりもクラウドで管理され複数の機器で共用できる方がよっぽど便利だ。この分野も単に赤外線機能などに止まらず、いかにクラウド対応を推し進められるかがポイントとなっていくだろう。そしてやはりまたそれはガラケー自身においても同様である。
何故このような極端に見える(かも知れない)サービスの再編が必要なのか。ハードウェア依存が「悪」なのか。それはスマートフォン、そもそもモバイル機器が宿命づけられている「ネットワーク親和性」故だ。
これまでキャリアがすべてのサービスを決める「牧歌的な」時代であればサービスがハードに依存していようとアプリだろうとクラウドだろうと関係なかった。しかしそうしたコントロールが行えなくなることは端末一体の訴求力をサービスやクラウド連携と言ったネットワーク指向性の高いサービスへ移行せざるを得ないことになる。でなければ既に述べたようにハードが足枷になり競争力の低下とサービス品質の低下を招くだけだ。
「日本発」のこれら「特異な」サービスは遠からず市場からの撤退を迫られることだろう。実際、例えば着うた/着うたフルはスマートフォンの浸透に伴い徐々にそのプレゼンスを無くしていくことだろう。それを見越してかLISMOなどのサービスはアプリとして再編されだしているように思うが、それがAndroidマーケットでの楽曲販売やAmazonのDRMフリーサービスあるいはiTunesStoreなどとどこまで同じ土俵で戦えるかはまだ未知数だ。何しろLISMOなどはそのキャリアでしか使えないのだから。
それを防ぎたいのであるなら、如何にこれまでの端末・回線・サービスの不可分一体サービスをクラウドへのみに移行していけるかにすべてはかかっているのだと思う。
だが果たしてこれまでの既得権を守りたいだけのキャリアや業界がそれを理解できるか。成功体験に浸りすぎた業界が「イノベーションのジレンマ」を自力で克服できるだろうか。
もしかするとようやく理解できた時には、既に日本としてのメリットは何もないサービスばかりが日本国内を席巻した後かも知れない。
実はしばらく前にTwitterのTLで流れてたのを見て触りだしてからはまっていたので、最近の盛り上がりは嬉しく思います。なんたって一時期は日本でTi mobile使ってるのは数人ぐらいしかいないんじゃないかとか思ってたぐらいなので。
へえまだアルファブロガーっているんだぁと思った次第。
実は既にそれなりにまともなiPhoneとAndroidアプリをTi mobileで作ってそれぞれAppStoreとAndroidマーケットで公開していたりします(本名で出してるからここでは紹介しない)。
ということで僕も別にそんな経験あるわけではないけど使っていて感じたこととかつらつらと書いてみますよ。
因みにTi mobileの日本での先駆者と言えばまとめサイトも作られてるdonayamaさんとかyuichi_katahiraさんとかですかね。また Yuichiro MASUIさんはAdMob用など幾つかiPhoneモジュールを公開されていらっしゃいます。
僕の経験で言うと一週間で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は多いように見えます。
まだまだ開発途上の製品なのでそれにうまく付き合えるかどうかがポイントになります。
恐らく先のAppleによる「AppStoreからの開発ツールの締め出し」騒動に関係していると思われますがiPhone版ではコンパイル時にネイティブコードに変換します。対してAndroidではJSエンジン(恐らくGoogleのV8？)でリアルタイムにインタープリターもしくはJITで実行しているようです。つまり解釈されるエンジンが異なるのです。これが前項の原因でもあり、また両者での違いを経験から読み取っていく必要があるでしょう。
僕もTi mobileを一番気に入っているのはメモリ管理を気にしなくて良いと言うこと。特にiPhoneでは顕著ですよね。しかし一方ではそれはメモリリークなどの管理をできないということも意味します。
開発元のAppceleratorでは「メモリリークはうまく回避しているよ」と言い切っていますが 実際に試してみると細かなメモリリークは発生し得るようです(特にネットワーク周り)。
あまり問題にはならないレベルとは思うのですが、JavaScriptに書き慣れていないとGCを意識できずオブジェクトを残し続けてしまいがちです。ブラウザでもよく話題にはなるのですがかなり巨大なコードにならないとあまり気にしない部分かと思います。しかしTi mobileではGCを意識した変数設計をしておかないと簡単にメモリを食い潰すアプリができてしまいます。
こういう時は逆にGCに頼るのではなく自由にメモリ管理も出来る仕組みがあるといいですね。
これはAppceleratorが基本的にはOSSで無償で提供しつつビジネスとしてサポートを有償にしていることと関係していると思うのですが、ドキュメントがあまりに杜撰です。
そもそも返値とパラメータが全く異なっていたり(多分コピーミスなど)、ドキュメントだけではちょっと複雑な仕様を実装しようとすると悩むことが多いかも知れません。
他の方もおっしゃっているように、APIドキュメントよりもサンプルアプリであるKitchenSinkを最大限利用しましょう。特にiPhoneとAndroidの実機に実際インストールして動作を確認することをお勧めします。
またドキュメントはあまり参考になりませんが、ディスカッションフォーラムは割と参考になることが多いです。凄く盛り上がっているとは言えないけど みんな同じ事で悩んでいるのです。
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開発をバリバリされてらっしゃる方にこそ効率を上げるためにぜひオススメしたいツールです。
まずは使ってもらって、少しでも日本で広まるといいなぁ。
また高木さんが恐ろしい記事を上げている。
これまでも日本のケータイ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標準として対応可能な端末とアクセスポイントへの接続を共存させる。こちらは接続先には制限は設けなくてよい。何故なら純粋なインターネット利用端末に過ぎないからだ。そして時間をかけてこちらの方式への移行を促すことにする。
二方式を併存することは新方式への移行を促す期間のモラトリアムであると同時に、 自由競争を作り出す規範ともなるだろう。また明確なクローズド・ネットワークと位置付けることで、例えば未成年者用の端末はクローズド・ネットワーク対応のみとすることで例えば公式サイトしか接続できないような「キッズ・ケータイ」も可能になるかも知れない。
—
さて、これらのことは絵空事だろうか。全くの杞憂に過ぎないフィクションですむ話だろうか。
その答えは高木氏の指摘の行間に実は潜んでいると思っているが、その話はまた後日・・・(にできるといいなぁ。。)
前回の記事について。
不用意な不安を煽るのが目的ではないので(理解できている人はできていると思うのだけど)念のため追記しておく。
では今現在auのEZ番号について差し迫った脆弱性や危険性があるのかと言えばこれはNOだと信じている。
上記を実現するためには、auの携帯網に対してスマートフォン(に限らないけど)のように任意のアプリを作成して実行できる環境を用意する必要がある。しかしこれは少なくとも現在ではかなり敷居が高い。
まず携帯網とはつまり現在の「ガラケー」を接続しているアクセスポイントから接続されるキャリア内ネットワークである。アクセスポイントについては以前の記事を参照して欲しいが、現時点ではアクセスポイント名やユーザー名、パスワードなど接続に必要になる情報は公開されていない。つまり何らかの方法でこれを入手する必要があるが僕の知る限りまだこれら情報の流出はない。
スマートフォン網であれば近々提供されるIS-NETで公開されてある程度自由に使用できるのではと思うのだが、「ちゃんとセキュリティを考慮している」サービスプロバイダーでは携帯網からのアクセスのみを許可しこの場合のみEZ番号を使用するはずなので、携帯網に接続できなければいけないことになる。
また au環境で自由に接続可能なスマートフォンや携帯端末を入手するのも難儀だ。ご承知の通りauはCDMA2000という世界的にもマイナーな方式を採用しておりまた上がりと下りで海外とは逆の周波数帯を利用している。まさしくauオンリーワンな環境となっている。従って海外のCDMA2000に対応したSIMフリー機を買ってきてそのまま使えるわけでもない。最近発表されたAndroid/WindowsMobile機のISシリーズはシャープがau向けに独自に開発したのも恐らくこうした事情から海外調達が実質的に不可能だったためだろう。
その他、例えばBREWは公式アプリしか認められていない(勝手アプリが可能ならEZ番号を詐称するのも簡単になる)とか、SIMロックもユーザーロックと呼ばれるショップで登録しないと使用できない(勝手な端末を接続させない、端末とEZ番号の紐付けを厳密に行う)とか、EZ番号は初回接続時にゲートウェイからダウンロードして決定される(これも端末管理を厳密に行いたいためだろう)など、上記を補強するためであろう施策が見受けられる。
という状況があるので必ずしも切迫した状況が放置されているわけではないと思う。しかしその一方で当然にしてこれらのうち何かが偶然であろうと必然であろうと綻びた瞬間一瞬にして脆弱な状況が生まれ得ることも冷静に理解しておくべきである。
そもそも論として、ユーザーのセキュリティに関わる問題なのだから本来は「何故携帯網は安全なのか」「どのような状況においてどのようなリスクがあるのか」各キャリアは率先して消費者に対して説明すべきだ。それをNDAなどを振りかざして情報統制することで安全を守っていると思っているのなら、思い上がりも甚だしい。本当に安全だというのならきちんと論理立てて説明可能でなければ、常に脆弱性やリスクがつきまとっていると考えるのがセキュリティ上の基本である。
SIMロック解除論議もいいけど、こういう消費者保護のための説明責任こそ法律やガイドラインで強制すべき段階に来ているのではないかなあ。
前回の記事から3年もしてから続編もないものだと思うけど、ちょっと興味深いことに気付いたのでまとめてみる。
とは言えもしかしたらこのことは周知のことであり気付いている人には目新しいことでも何でもないかも知れない。
まずは前回のおさらいから。
端末IDとか個体識別番号とかサブスクライバーIDとか呼ばれる「端末や契約を識別するために端末側やゲートウェイから送出される識別ID」が偽装できるのかどうか実験と考察をしてみた。
docomoのUTNやSoftBankのシリアル番号などのように「端末から直接送出されるID」は携帯網にスマートフォンを接続するなど任意のアプリを実行可能な環境では詐称可能なことを示した。これは例えばUser-Agent環境変数を偽装するだけなので非常に簡単だ。少なくとも当時から現在においてもこれらを認証に利用することは全く持って推奨されない。
またその時実験は行えなかったが、docomoのuidやSoftBankのx-jphone-uidのようにゲートウェイが付加する(であろうと推測される)IDについてはゲートウェイが正しく付加したり偽装を判別するならば偽装は難しいだろう、というのが結論だった。
逆に言えばもしゲートウェイが騙されるようなリクエストが作成できれば偽装も可能だろうと推測したのだが、実際そうした事例もあったようだ。
実はその後エントリーにはしなかったのだけど、自作のWindowsMobileアプリを搭載したスマートフォンをSoftBankの携帯網(WAP)とイーモバイルのEMNetでx-jphone-uidとX-EM-UIDを偽装してみたがゲートウェイでは正しく本来の端末IDに置き換えてくれた。つまり偽装対策はゲートウェイにて正しく行われているようだ。
但しdocomoとauでは環境が整わなかったので試しておらず未確認だ。
さてその前提で、面白い資料を発見した。元々端末IDに関して各社の仕様を網羅的に記した有意義な資料なのだが、特に以下の部分に注目して欲しい。
| 用途 | ||||||||
| 分類 | UTN | iモードID | NULLGWDOCOMO | EZ番号 | SB公式UID | SBｼﾘｱﾙ番号 | ||
| 公式連携 | × | × | ○ | ○ | ○ | × | ||
| 勝手サイト | ○ | ○ | × | ○ | ○ | ○ | ||
| SSL対応 | ○ | × | × | ○ | △ | ○ | ||
| URLだけで使用 | × | ○ | ○ | ○ | ○ | ○ | ||
| ログインに使用 | ○ | ○ | ○ | ○ | ○ | ○ | ||
| URL漏洩時の なりすまし防止 |
△ 不向き |
○ | ○ | ○ | ○ | ○ | ||
| SSL URL漏洩時の なりすまし防止 |
△ 不向き |
× | × | ○ | △ GW-SSLのみ |
○ | ||
「SSL対応」という箇所がある。docomoのUTNとSBシリアル番号およびauのEZ番号のみが○である。
SB公式UID(x-jphone-uid)はSSLゲートウェイを指定すればOKだが他については全て×だ。
これは大変重要な事実を示している。
UTNとSBシリアル番号が○なのは当然だ。SSLはポイント・トゥー・ポイントプロトコルであり、つまりブラウザ (この場合は端末)とWEBサーバーが直接暗号通信することで通信が傍受されたり改変されないことを保証するからだ。逆に言えば通常の携帯ゲートウェイがこの直接通信に介入することはできない(SSLゲートウェイは端末<->SSLゲートウェイ<->WEBサーバという2つの通信を見かけ上束ねているだけだ)。
なのでiモードIDやNULLGWDOCOMO、SB公式uidがSSLに対応しないのはゲートウェイでHTTPヘッダーを付加する必要があるから、と理解することが出来る。つまり当然の帰結なのだ。
しかしauのEZ番号(X-Up-Subno)は全てにおいて○だ。SSLにも対応している。
このことから分かるのは、EZ番号は端末から直接送信しておりゲートウェイは何ら偽装対策を行っていないはず、ということだ。
残念ながら(?)、環境が準備できないので本当にそうなのか僕には確認することが出来ない。しかしSSLの理屈からはまず間違いなくEZ番号は端末から直接送出されており偽装対策はまず取られていない。
何度でも記すが、現在の日本のケータイWEB、特にケータイECを脆弱に支えているのは
(1) そのアクセスがそのキャリアの携帯網からのみであることをサービスプロバイダーが保証すること
(2) 携帯網では端末IDが偽装されていないことをキャリアが保証すること
(3) 端末の自由度を低くして端末IDの偽装などの可能性をできるだけ低く保つこと
という三位一体の原則だ。これが1つでも崩れれば信頼性は崩壊する。
しかしもし上記の推測が正しければ、ことauのEZ番号については(1)と(3)によってのみしか支えられていない。SIMロック解除論議を持ち出すまでもなく、例えばauの携帯網のアクセスポイント情報が明らかになってしまったら。そこにスマートフォンなどで任意のアプリを実行できる端末が接続可能になったら・・・？ 恐らくサービスプロバイダーは偽装を見破る術を持たない。
それが現実になれば、恐慌にも似たケータイECの信用崩壊が起こる可能性が非常に高い。
様々な批判に晒される中で「それでも日本のケータイ技術は世界一なのだから」と嘯くのは自由だ。キャリアの皆さんは好きにすればいい。
しかしこんなにも脆弱な 技術に支えられたバブルをどのような理由で自慢できるのか、さっぱり理解できない。
これまで業界を支えてきたかも知れない日本のケータイ技術はすでに賞味期限切れなのだ。そのことに早く気付いて行動を起こして欲しい。
消費者を人質に取るような寡占業界故の保身はすぐにも止めてもらいたい。
2010/4/13 追記しました。
SIMロック議論にとっては慌ただしい一日だった。
Softbank松本氏の説明会に始まり、総務省のヒアリング、フリーライターたちのUstream座談会(まあ議論の場ではなかったね)と続いた後に(どれもUstreamやTwitterで中継してもらえたのは有り難かった。この場を借りて関係者にお礼申し上げます)、政府は早々に原則SIMロック解除の方針を打ち出した。
ユーザーの求めに応じてSIMロックは原則解除へ、総務省の公開ヒアリングで結論
方針は原則一律禁止との方向性のようだ。できれば既存の出回っている端末もロック解除したいらしい。
個人的には併存がよいと思うのだけど、恐らく官僚ではなく政治主導とやらで拙速に決めつつあったのではないかな。
まあその結論でもよいと言えばよいとも思うのだけど、ただこれでほぼ「日本型ケータイWEB」の崩壊もほぼ決まったようなものだ。
SIMフリー化によって他社回線で端末が使われる可能性を考慮しなくてはならなくなった。つまり日本のケータイWEBを脆弱に支えてきた端末ID(サブスクライバーID、個体識別番号)はもうこれまでのコンテキストにおいても信用ならないものとなることが確実になった。
繰り返すが現在のケータイWEBで端末IDをかろうじて信頼できるのは
(1) そのアクセスがそのキャリアの携帯網からのみであることをサービスプロバイダーが保証すること
(2) 携帯網では端末IDが偽装されていないことをキャリアが保証すること
(3) 端末の自由度を低くして端末IDの偽装などの可能性をできるだけ低く保つこと
という三要素があるからだ。
詳細はまた別のエントリーに回すとしても、この三位一体が崩れることでその端末IDが偽装されていないことを確実に保証することはほぼ不可能になる。
つまり完全SIMフリー化後のケータイWEBでは端末IDという「認証」を用いることはできなくなるはずだ。
まあ、しらばっくれてこのまま突き進むことも考えられるが、一体キャリアはどうするだろうね。
なおこれらは従来の「ガラケー」(およびガラケー向けアクセスポイント)での問題であって、スマートフォン系は「まだ」影響は受けない。
今後総務省でガイドラインを策定するとのことだが、上記に気付いた時果たしてどのような対応にするんだろうか。あるいはまるで気付かずスルーの可能性も高いけど。
もしそうなら、「結局得をするのは裏を分かっている犯罪者たちばかりなり」ということになってしまうんだろうか。
Xperia発売やauの新スマート”ブック”(笑)発表の影響もあるのか、最近SIMロック論争がTwitterなどを中心に活発に行われている。
また明日総務省がSIMロックに関してキャリアやメーカー、消費者団体を招いてヒアリングを行うとのことなので、この話題はまだもう少し続くことになるだろう。
これら一連の議論で「SIMロック解除がガラパゴス状態を改善する」との簡単な論理には幾分不安を感じる。消費者からすれば重要なことは「キャリアのガラパゴス政策が緩和されて、現在国境やキャリア観で分断されているサービスや機能が水平分業的に解放される」ことだと思っているのだが、先のSoftbank松本氏や昨日行われたau説明会でのキャリア側の言い分からは、仮にSIMロックが解除されても(ロック完全禁止であろうと一部禁止であろうとも)キャリアの対応によって骨抜きにされてしまう可能性が高い。
キャリア側の言い分は、仮にSIMロックを解除してもそもそもiモードなどのサービスがキャリアごとに違うのでほとんど意味がない、というものだ。そしてこれは実はほぼ正しい。
先日書いたように端末ID(サブスクライバID、個体識別番号)の仕様もキャリア毎に異なるので恐らくサービスプロバイダーの対応も複雑になるだけであまりメリットが無く、そもそもSMSのキャリア間送受信もまだ行われておらずdocomoのようにそもそもMMSも持っていずiモードのように他社ではとても対応できないようなサービスを提供していたり、WAP(ブラウジング)のような国際標準に対応しない端末が大量に出回っていたり、SIMを抜いてしまうと端末自体が全く動作しなくなったり、はたまた例えば購入したコンテンツがSIMに紐付いているのにフォーマットが異なるので他社や他機器では再生できない、などなど。要するに「よもやSIMロックが解除される事態が来るとは思ってもいなかった」事態が多発することだろう。
もちろんこれは、「そうであればサービスを共通して使えるようにしろよ」という話でもあり、この10年囲い込みにしか情熱を燃やしてこなかったキャリア各社の怠慢であり責任としか言えないのだが、これを逆手にとって仮にSIMロックが解除されても「ほらサービスが使えなくなっただけでしょ。SIMロック解除なんて有害なだけだったでしょ」という開き直りとも言える施策を取る公算が大変高い。
つまりSIMロック解除という点だけに注力するとまんまとサービスの非互換性を逆手にとってSIMロック解除を骨抜きにしてくるだろうな、というのが僕の読みである。
であるならではサービスも共通化して解放せよ、というのがまっとうな意見ではあるのだが市場にこれだけ溢れているガラケーを考えると、単にそう主張するだけなのも実効的ではない。
そこで僕の意見は、SIMロック解除だけを主体にするのではなく(但し今後の端末を考えればこれも重要だ)、各キャリアのアクセスポイント(AP)解放要求を主体に置くべきではないかと考える。
恐らくこの「アクセスポイント」とは何のことか気付いている人は少ないと思うので少し説明しよう。
一言で言えばWiFiで言うところのSSDのようなものだと思えばいい。つまり端末が通信を行う上でアクセスするダイヤルアップ先のだ。
普段、特に日本ではほぼこれの存在に気付くことはまず無い。何故ならこれは日本特有の現象なのだが、日本ではキャリアがどんなアクセスポイントを用意して端末に利用させているか隠しているからだ。
例えば海外製のスマートフォン(以下ではWindows Mobileの例)では以下のように通話やブラウザ(WAP)またはMMS(メール)向け接続のためにどのアクセスポイントに接続するか設定する画面が用意されている。
(因みにSIMフリーのiPhoneなら同様の設定がある)
アクセスポイントであるので、通常そのアクセスポイント名とユーザー名/パスワードを設定することで利用が可能になる。
海外ではスマートフォンに限らず通常の携帯でもこうした設定は存在している。しかし日本の携帯ではそうした設定を見たことのある人はほとんどいないだろう。なので恐らくケータイ関係のライターでも知らない人は意外に多いと思う。何故か？それは携帯側で「決め打ちで」自動的に設定してしまっているからだ(あるいはSIMにその情報が書かれていて自動設定する場合もあるようだ)。
では何故日本のキャリアはアクセスポイントを隠すのか。実は明確な理由はキャリアからは公表されないので正式には分からない。しかしSIMロックと同じように、「自社の端末と回線の組み合わせだけを間違いなく利用者に使用させたいから」という意図であろうことは容易に想像できる。つまりガラパゴスと揶揄されるのと同じようなキャリアによる囲い込み施策の一環である。
以下のURLの資料を見て欲しい。これは各国におけるアクセスポイントの一覧だ。
海外キャリアではほぼ例外なくこれら自社アクセスポイントの情報を公開している。これはSIMロックを行っている国でも同様だ。つまりSIMロックでの議論で言われるように「世界的にはSIMロックを採用している国の方が多い」という話とは明確に異なる状況だ。日本のまさしく特異な「ガラパゴス状態」を端的に表している例だと言えるだろう。
またユーザー名/パスワードも同時に公開されており秘匿はされていない。資料を見ても分かるように、パスワードと言っても複雑な文字列を設定している例はほとんど無く実態的にはパスワードをかけていることに意味は無い。まさしく「公開」されているのである。
1つのキャリアでも複数のアクセスポイントを使い分けている場合もある。良くあるのはWAP(ブラウザ)とMMS(メール)が異なる場合や、プリペイドかポストペイドかや定額制と従量制の場合など契約形態毎にアクセスポイントを指定している場合などだ。
つまりキャリアからすると使用されたアクセスポイントによってユーザーの利用形態や課金単位を変えたり判別するのに使用していると思っていい。
一方日本ではどうかというと、公開されていないものの、一部アクセスポイントの存在が判明しており一部ユーザーにより情報が公開されてしまっている。
実は判明しているのは従前から海外とほぼ同じ仕様を使用しているSoftbank(旧Vodafone)だけなのだが、それによれば通常の携帯網用AP以外にXシリーズと呼ばれるスマートフォンの定額用AP(通称open)やiPhoneはまた別のAPを使用しているようだ。また従量制のAPについては設定がそもそも必要になるのでこれは公開されている。
docomoとauはガードが高いらしく、これまで携帯網用のAPは明らかになっていない。しかしスマートフォン用APは別に用意されているらしく、また例えばdocomoでは一部moperaと呼ばれる接続サービスでPCデータ通信用AP(スマートフォン用ではないことに注意)は公開している。
ではアクセスポイントが公開されることで何が変わり得るのか。
前提はアクセスポイント情報が公開された上で「契約ユーザーが自由に自身の携帯やスマートフォンを設定して利用するのを認める」という点だ。ここで各キャリアの端末に縛られず自由に他社端末であろうと接続できることがポイントになる。
これでも先に述べたように各社サービスの非互換性は担保されない。レイヤーが異なるからだ。しかし端末の自由化がSIMロック解除以上に進むため、よりバラエティに富む端末やサービスの流入を呼び込む可能性が非常に高い。 但しこれは従来の携帯網向けアクセスポイントを解放すべきという話ではない。恐らくそれでは個体識別番号の脆弱性が顕在化し、従来のビジネスへの影響が非常に高い。海外では個体識別番号というものは存在しないので携帯網も公開されているのだが(というかそもそも携帯網とスマートフォン系という違いが存在しない)、残念ながらこうした過去の負債があるので日本では行えないだろう。
しかし各社は既に主にスマートフォン向けのAPを構築しつつある。Softbankはopenと呼ばれるAPやiPhone用APを既に持っているし、docomoもmoperaというプロバイダー事業でスマートフォンAPを用意している。auはこれまで無かったはずだが先日のISシリーズの発表でIS-NETというプロバイダーを発表している。これは恐らくスマートフォン向けのAPを用意することになるはずだ。
そこでこれらスマートフォン用と同様のフリーアクセス(課金が、という意味ではない)アクセスポイントを別に準備してもらうこととする。
但し例えばdocomoなどは従量制のAPを差して「既に利用できる」と言い張るかも知れない。しかしこのAPは従量制であるので利用料金は青天井だ。そこで他にスマートフォンなどで定額制を導入しているのならば同様の金額による定額制の導入は義務化することとする。
こうすることで従来の携帯網(すなわち「ガラケー」)を中心にした垂直統合型ビジネスモデルと、新たなフリーアクセス・アクセスポイントおよびSIMフリー端末による新たなオープンモバイル網が共存し、新たな競争原理が導入されることになる。前者の担い手は従来通りキャリアであり、後者の場合キャリアは通信部分に専念することになり担い手は端末メーカーかも知れず課金や認証含めたサービスプロバイダーまたは海外勢含めた業界全体という立ち位置になる。
—
残念ながら既存の「ガラケー・ビジネスモデル」はすぐに無くなるものでもなければ、また一気に無くしてしまうのは既に多くのユーザーを抱えている以上不要な混乱を起こすわけにもいかないだろう。また現状これ以上キャリアとしての競争相手が増えることも予想できず、カルテルとも言えるほど各社料金などが横並びの状態では大きな変化をキャリア自ら生み出すことは難しい。
しかし新たな競争軸を生み出すことは可能なのだ。そして自由度(端末やコンテンツ、価格の自由さと競争原理、参入の容易さ)が担保されれば必ずマーケットは動く。そして競争に晒されれば「ガラケー・ビジネスモデル」側も必然的に変化に迫られるはずだ。
まずはぜひこうした「アクセスポイント」という故意に隠された論点があることを知って欲しい。そしてそれは日本でのみ特異な扱い方をされている。
繰り返すが何故隠すかと言えば隠すことでそこから何らかのメリットを享受する人々が存在しているからだ。そうした視点を消費者としては手に入れるべきだ。
Powered by WordPress.
Template based on praegnanz.de.
![[Atom]](http://www.rocaz.net/pic/feed-icon-blue.png){kind=icon}
![[RDF Site Summary 2.0]](http://www.rocaz.net/pic/feed-icon-red.png){kind=icon}
Recent Comments