「技術ネタ」カテゴリーアーカイブ

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ロック解除論議もいいけど、こういう消費者保護のための説明責任こそ法律やガイドラインで強制すべき段階に来ているのではないかなあ。

2010-04
12
00:51:38
続:携帯で端末ID詐称は可能かもしれない話


前回の記事から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に関して各社の仕様を網羅的に記した有意義な資料なのだが、特に以下の部分に注目して欲しい。

携帯3キャリア個体識別情報(uid)の特徴 から抜粋

用途
分類 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 追記しました。

2010-04
03
01:48:15
ああ、これで日本のケータイWEBが終わる


SIMロック議論にとっては慌ただしい一日だった。
Softbank松本氏の説明会に始まり、総務省のヒアリング、フリーライターたちのUstream座談会(まあ議論の場ではなかったね)と続いた後に(どれもUstreamやTwitterで中継してもらえたのは有り難かった。この場を借りて関係者にお礼申し上げます)、政府は早々に原則SIMロック解除の方針を打ち出した。

ユーザーの求めに応じてSIMロックは原則解除へ、総務省の公開ヒアリングで結論

方針は原則一律禁止との方向性のようだ。できれば既存の出回っている端末もロック解除したいらしい。
個人的には併存がよいと思うのだけど、恐らく官僚ではなく政治主導とやらで拙速に決めつつあったのではないかな。

まあその結論でもよいと言えばよいとも思うのだけど、ただこれでほぼ「日本型ケータイWEB」の崩壊もほぼ決まったようなものだ。
SIMフリー化によって他社回線で端末が使われる可能性を考慮しなくてはならなくなった。つまり日本のケータイWEBを脆弱に支えてきた端末ID(サブスクライバーID、個体識別番号)はもうこれまでのコンテキストにおいても信用ならないものとなることが確実になった。

繰り返すが現在のケータイWEBで端末IDをかろうじて信頼できるのは

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

という三要素があるからだ。
詳細はまた別のエントリーに回すとしても、この三位一体が崩れることでその端末IDが偽装されていないことを確実に保証することはほぼ不可能になる。
つまり完全SIMフリー化後のケータイWEBでは端末IDという「認証」を用いることはできなくなるはずだ。

まあ、しらばっくれてこのまま突き進むことも考えられるが、一体キャリアはどうするだろうね。
なおこれらは従来の「ガラケー」(およびガラケー向けアクセスポイント)での問題であって、スマートフォン系は「まだ」影響は受けない。

今後総務省でガイドラインを策定するとのことだが、上記に気付いた時果たしてどのような対応にするんだろうか。あるいはまるで気付かずスルーの可能性も高いけど。
もしそうなら、「結局得をするのは裏を分かっている犯罪者たちばかりなり」ということになってしまうんだろうか。