Posts filed in ‘ガジェット’

auのPCサイトビューアーで脆弱性が発覚か？ – 続:auのEZWebがそろそろ終了しそうな件

この記事はauのEZWebがそろそろ終了しそうな件の続編です。

当該記事では「EZブラウザとPCサイトビューアーのIPアドレス帯域が統一される」ことから場合によってはEZWebの課金システムや一部認証が脆弱性に晒され得るのではないかと危惧したのだが、もしかすると本当に現在それが起きていた(いる)かも知れない。

F001のHTTPヘッダ

F001（PCサイトビューアー）※一部伏せ字
あれ？REMOTE_ADDRが111.87.241.##？
これ、2011年秋冬モデル以降の一部機種のEZブラウザ/PCSVのIPアドレス帯域じゃないですね。
従来のPCサイトビューアーのIPアドレス帯域でもありません。

EZWebとPCサイトビューアーのIPアドレス帯域が具体的にどんなアドレスになるかは上記の通り既に公表されているのだが、どうやら現在PCサイトビューアーからアクセスすると全く別のアドレスになっているようだ。つまり以前からのアナウンスにも関わらずEZWebとPCサイトビューアーのIPアドレス帯域は統一されておらず別のものになっているようだ。これは何を意味するのか。

auの2011年秋冬モデルである「F001」のHTTPヘッダが従来機と比べて大きく変更になっているようです

通常のEZwebブラウザとPCサイトビューアーのIPアドレス帯域が統一された関係で、PCサイトビューア＋JavaScriptを使っての値のねつ造ができないかどうかが気になります。

上記の記事を見ると、本来来るはずのない帯域からアクセスが来ているとのことなのですが、この辺りの問題が解決できてなかったからとかではないでしょうね。。。

恐らくk-tai.orgさんの予想か当たっているのではないだろうか。

これは想像だが、当初はもちろんEZWebとPCサイトビューアーのIPアドレス帯域は統一されたのだろう。しかしPCサイトビューアーでEZWebのHTTPヘッダーのケータイID(個体識別番号、サブスクライバーID)を偽装できる問題が発覚してしまったのでは無いだろうか。
そのため少なくとも一時的にでも問題を回避できるように、PCサイトビューアーのIPアドレス帯域をEZWebとは急遽別にしたのではないか。

以前の記事からも繰り返しになるが、ケータイIDを脆弱ながらもぎりぎり安全に保つには一般に三つの条件がある。

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

このうち2についてはauでは採用されていない可能性がある。そして今回PCサイトビューアーとIPアドレス帯域を統一することで1でサービスプロバイダー側にてEZWebからだけのアクセスでありHTTPヘッダーのケータイIDをそのまま信じていいのかどうかは微妙になった。後は3の条件のみが頼みの綱となった。
すなわち「PCサイトビューアーからケータイIDを偽装して付加できることがあっては絶対にならない」のだ。もしそうなってしまえばケータイECの信頼性は崩壊する。
しかしながら、それが今回偽装できることが発覚してしまったのでは無いだろうか。

以上はあくまで想像に過ぎない。またとりあえずPCサイトビューアーのIPアドレス帯域が緊急的に変更されているのなら差し迫った危機は回避されている。

そこで以下のような公開質問をauのカスタマーサポートへ行ってみた。

「PCSVのIP帯域とセキュリティについて」
表題についてご質問です。
1. 今秋冬モデルからEZWebとPCSVのIP帯域が統一されるとのアナウンスがありますが
http://j.mp/vzi7QB
http://j.mp/tG3hDj
こちらの記事 http://j.mp/uEniDb によれば実際には記載の無いアドレスからPCSVはアクセスされているようです。
これは事実ですか？事実である場合理由は何ですか。
2. どこかでこれらはアナウンスされていらっしゃいますか。
3. http://j.mp/v4AqrD では「PCSVにてHTTP_X_UP_SUBNOの偽造が可能なのでは」との推測がされています。
私も同様の疑いを持ちますが事実関係はいかがでしょうか。
4. 3が事実であった場合、現在まで告知がされていません。それは何故ですか。脆弱性は隠したいとの意図でしょうか
なお本件は公開質問として送付させて頂いております。ご回答に付き適時適切に公開させて頂く場合があります旨ご了承下さい。
以上、お忙しい中大変恐縮ではございますが、ご回答頂けましたら幸いです。どうぞ宜しくお願い致します。

(なお質問がつっけんどうで分かりにくく感じられると思うが、これはauの問い合わせフォームが上限500文字で最低限まで文字数を削る必要があったためだ。せめて1000文字ほどあればもう少し丁寧に書けるのだが…)

結果が帰ってくればまたご報告したいと思う。
以前脆弱性公開ポリシーについてauへ質問した際には、「システムに脆弱性があることについて事実確認されアップデートによって脆弱性が解消できることが判明した場合には必ずWEBサイトで告知を実施した上でアップデート対応を実施する」「セキュリティに関わる問題については悪用される危険性があるため詳細な内容については公表しない。但し該当ユーザーについては個別に周知している」と回答頂いているので、仮に事実であれば問題解消後には必ず公表されるだろうし、また少なくともF001ユーザーやコンテンツプロバイダーには事後報告がされるはずだ。今回の件はその試金石となることだろう。

事実であったとして、F001にはセキュリティアップデートが行われるかも知れない。しかし全ての端末がアップデートをするとも限らない。とすればIP帯域の統一は簡単には戻せないかも知れない。果たしてどのような改修が行われ得るだろうか。
今後その点にも注目しておきたいと思う。

追記(2011/11/23)
Kimuraさんの検証によれば、F001のPCサイトビューアーではJavaScriptでUserAgentおよびX-UP-SUBNOの変更や追加は出来なくなっているとのこと。(以前の機種では出来た)
F001のPCサイトビューアーでsetRequestHeader
こうした仕様はIPアドレス帯域を統一する以上想定内(大前提)の仕様なのだが、にも関わらずIP帯域が分けられていると言うことは、これを回避して変更・追加する方法が存在するということになりますね

追記(2011/11/28)

KDDIから回答が来ましたが、「PCでもPCサイトビューアーでもHTTPヘッダーの書き換えが出来るのは当然のこと」「セキュリティ確保のためEZWebとPCSVのIPアドレス帯域は分離している」のだそうで・・。この自分で整えたちゃぶ台をひっくり返す回答はどうしてくれようか、混乱中です･･･。
因みにEZfactoryのお知らせとIPアドレス帯域に変更がされましたね。何やらこれまでアナウンスしていた「EZWebとPCSVのIPアドレス帯域の統一」が無かったことにされているのですが・・？？

とりあえずこういう質問にしておいた。

以前よりKDDI様では「2011年秋冬モデルよりEZWebとPCSVのIPアドレス帯域は統一する」とアナウンスされていらっしゃいましたが、
下記ご回答とEZfactoryを拝見する限り、これらが無かったことになっているようですね。
今後ともEZWebとPCSVのIPアドレス帯域は恒常的に分離されたままになる、ということでしょうか。
またずっと以前よりアナウンスされていた内容がここに来て突如変更された理由は何でしょうか。私が指摘させて頂いていたように
「当初統一する予定だったが、本来変更できてはいけないX-UP-SUBNOがF001のPCSVでは変更できてしまった脆弱性(または仕様抜け)
が発覚したため、予定を変更してIPアドレス帯域を分離することにした」との理由しか思いつかないのですが、いかがでしょうか。
仮にこれが事実であれば全ユーザーが影響を受けるセキュリティ問題であった訳ですから、お立場のある通信事業者としては
隠蔽するのでは無く明白に公表されるべきと思いますが、いかがでしょうか。

追記(2011/11/29)

徳丸浩氏から今回の脆弱性の詳細について公表されました。

KDDIの新GWで「かんたんログイン」なりすましの危険性あり直ちに対策された

端的にはPCSV単独の脆弱性ではなく、PHPなど特定言語との組み合わせの問題ですね。しかし結果として脆弱性として「合成」されてしまう訳で･･･。悩ましいですね。ただ当面は回避されていること、かんたんログイン時のみの問題であることはまだ幸いであるとも言えるでしょう。

追記(2011/12/03)

遅くなりましたが、11/30に上記質問に対してauより返答がありました。
「敢えて」そのまま回答を掲載します。

IPアドレスの帯域は恒常的に分離しておく予定です。
以前よりアナウンスしていた内容を変更した理由は、セキュリティ確保のためです。
セキュリティ確保のために、IPアドレスを分離したことは既に公表しております。
詳細につきましては、セキュリティの観点から回答は差し控えさせていただきます。

とのことです。

この回答への評価についてはまずは皆さんにお任せしますが、後日別途エントリーを上げるかも知れません。

Posted by ROCA No Comments

日本のパケット通信料(単価)が馬鹿高すぎる件

先日、auのiPhoneで店側がデータ定額(ISフラット)を契約時に付け忘れとてつもない額が請求されてきたという話があった。その額なんと395万9160円。

auのiPhoneにしたらパケ代400万円も請求された！

その後交渉によりISフラットと同額の4980円になったようだが、たった一ヶ月にも満たない期間で(しかも恐らくは通常の利用で)400万にも達する料金体系にも驚きだし、そもそもそれだけの利用料金が定額サービスに加入するだけで5000円程度になってしまう仕組みにも驚きだ。

何故このようなことが起こりえるのかと言えば単純に「日本のキャリアでのパケット通信料=パケット単価は恐ろしく高い」からだ。それが問題にならないのは単にパケット定額サービスを別に設けてユーザーにはほぼ例外なく加入させているからだけに過ぎない。
では果たして海外と比べてどれぐらいの内外格差があるのか？というのが本稿の趣旨だ。

続きを読む »

Posted by ROCA 1 Comment

Nexus Sを買ったらネット環境が劇的に便利になった件

別にNexus Sに限ったことではなく、Android2.3.xなら同じ話だとは思うのですが。
最近遅ればせながらNexus Sを入手しました。以前は日本円で5-6万円ぐらいしていたと思うのですが最近1shopmobileを見ると3万円台半ばまで下がってる！
ということでとりあえず買っただけなんですが、これが使い出してみるとやけに便利。動作きびきびというのもあるんですが、それ以上に便利機能満載で値段以上に満足でした。
ということで備忘録代わりに置いておきますね。

続きを読む »

Posted by ROCA Comments (4)

ソフトバンク回線のパケットロスがほんとーーにひどいのかTCPでも確かめてみた

前回記事に対して、「ICMP(ping)のパケットの優先度を落としているだけでは」という意見も幾つかあったようだ。
本文でも書いているとおり、僕自身はパケットロス率に注目したのではなく、それに伴うラウンドトリップタイム(RTT)の時間帯での差異から(ICMP/TCPあるいはUDP関わらず)バックボーンを守るための何らかのパケット制限がかけられているのではないか、という見解だ。
ただ70-90%という値があまりにセンセーショナルだったため数字が一人歩きしたか、エントリー全文が読まれていないということかと思うのだが、せっかくなので、ではTCPではどうなのか確かめてみた。以下、その結果。

続きを読む »

Posted by ROCA Comments (2)

ソフトバンク回線のパケットロスがひどいというので、ほんとーーにそうなのか確かめてみた

追記書いてます。

—

#softbank 携帯によるデータ通信でのパケロスは本当に酷いのか？

という話があって、聞こえてくる話では75%のパケットロスもあるのだという。
一般的にネットワークに関わる層には一概に信じられないロス率だが、Twitterなどで流れてくる数値ではよく信用できないのと、ある程度偏ったテスト環境になってしまっている気もしたので、ドコモ回線含め時間帯も変えて比較してみることにした。
テスト環境は以下の通り。

テスト概要
JailBreakしSIMフリー化したiPhone3GS(iOS4.2.1)にてソフトバンク iPhone通常回線(smile.world)とドコモ データ定額(mopera.flat.foma.ne.jp)で複数のサーバーに対してping(ICMP echo)テストを実施し、パケットロス率およびラウンドトリップを計測する。

テスト方法
SSHでiPhoneへログインし、Cydiaのinetutilsに付属するpingコマンドを計30回試行し平均値を得る。

テストサーバー

1. www.yahoo.co.jp(ロケーション: 東京 丸の内 ブロードバンドタワー)
2. www.google.co.jp(ロケーション: 恐らくアメリカ西海岸)
3. テストサーバー1(ロケーション:アメリカ FremontにあるVPSサーバー)
4. テストサーバー2(ロケーション: さくらインターネットのVPSサーバー。設置場所は不明だが国内)

テストは都内から行っている。また時間帯も変えることとし、とある日曜日のPM9時台と翌日AM2時台の二度行った。

結果は以下の通りである。

テストケース1: PM9時台に実施

テストケース2: AM2時台に実施

比較のためWi-Fi(回線はフレッツ光)も付記している。

まず第一に流れている話通り、PM9時台では確かにロス率は70%から最大90%にも達している。まさしく通常はあり得ないレベルだと言ってもいいだろう。
しかしもう一点注目すべきなのは、ラウンドトリップに関しては、実はドコモのそれと遜色ない、若しくは場合により上回っている場合もあるということだ。
次にAM2時台となるとロス率は格段に改善されている。ほぼ問題無いレベルと言ってもいいだろう。しかしその反面ラウンドトリップは極端に落ち込み、特にmax値は10倍以上遅延しているケースもあった。また平均偏差も非常に大きくなっている点にも注目したい。これはネットワーク状態が安定していないことを示している。
果たしてこれらは何を意味しているのか。

ここから憶測にすぎないが、テストケース1において、恐らくソフトバンクのバックボーンネットワークの性能自体はドコモと比較してもそれほどの遜色は元々無さそうだと言うことだ。しかしそれはパケットロス率を上げることでバックボーンへの負荷を低減しているからではないか。
これはテストケース2においてロス率が下がったと同時にラウンドトリップが極端に下がった(つまりネットワークが飽和しつつある)ことからも想像できる。
すなわち、パケットロス率はバックボーンへの負荷を減らすべく元から意図されたもので、時間帯により例えばスイッチングルーターのバッファ量を調整するなどして日夜調整されているのではないかという推測が成り立つ。

僕自身はネットワークの実務経験も乏しく専門性は持ち合わせていないのでこれ以上の論評は差し控えるが、これはこれで1つの「見切り」かも知れないという気はする。
ユーザーとしての感想を述べるなら、僕自身はパフォーマンスも少なくとも最近は1Mbpsを下回ることもなく安定して使えていると思っており、これまでもソフトバンク回線に(電波の入り以外に)大きな不満を感じたことはない。
スマートフォンに絞ればほとんどの通信はTCPベースであることは確かであり(UDPで困るのはDNSぐらいか)非常に多くのリトライパケットが発生するとしても全体としてはそれなりの「実測値」が得られると言うことなのかも知れない。

ネットワーク屋にとってはとても考えられない対応かも知れないし(僕自身もそうしたチューニングを決意する度胸はないが)、単にパケットロス率のみ取り上げて非難するのは簡単だ。しかし1つの方法論として今後「冷静に」大いに議論されても良い点ではないだろうかとも思う。
何故なら、これはもしかすると今後いずれのキャリアも通る道かも知れないからだ。

Posted by ROCA Comments (41)

ドコモもauも「これまでのケータイネットはインターネットではなかった」と言い出した背景

ここしばらくキャリア各社の新製品発表なども続き、その中で時あたかもドコモ・auで立て続けに同じような興味深い発言が続いた。

ネットの大海原に出るための「再定義」――ドコモ伊倉氏に聞くスマートフォン時代の“パラダイムシフト”戦略（後編） (3/3)

では、なぜキャリアがスマートフォンを推進しているのかというと、まずフィーチャーフォンの垂直統合のモデルから、そうならないところに移ることが重要である、ということがあります。それをドコモが積極的にやることによって、インターネットの世界や新しい世界をきっちりと理解し、その中でクラウドを意識して、サービスの設計をする。将来的にクラウド系のサービスをやる前提として、スマートフォンを推進しなければならない。

【WIRELESS JAPAN 2011】 KDDI田中社長、「なんちゃって」から「真のインターネット」へ

「この10年は、携帯電話の10年だった。また3Gと定額の時代でもあり、その中で、なんとか（パソコン向けの）インターネットの価値を小さなデバイスに取り込む、『なんちゃってインターネット』の時代だった。非常に良い時代だったと思う」と表現した

微妙にニュアンスは異なるが、ともに「もう携帯電話に独自ネットを閉じ込められない」危機感を有しているのがよく分かる。

キャリアから見た場合には見方が異なっていると思うのだが、この10年は携帯電話のCPUなど性能の問題で「なんちゃってにせざるを得なかった」という意見のようだ。
しかし当然理解されることとして、日本のガラケーは既に何年も前からスマートフォンだったという人もいるように(僕はそう思わないが)、またフルブラウザはもう5年以上も前から登場しているし海外ではスマートフォンはやはり5年も前から普通に使われていたことから考えて、単にここに来て「各キャリアが従来の携帯網ビジネスを手放さなくざるをえなくなった」一種の敗北宣言と捉えられよう。

日本のキャリアがこれほどまでに垂直統合モデルによって過分な利益を享受しモバイルECをここまで発展させられたのは、これまでも何度か書いている通り「閉塞された携帯網」でのみネット接続を許し、その中でのみコンテンツの利用をユーザーに許し囲い込んできたからだ。
まさしく「なんちゃってインターネット」であったわけだ。

参考:
iモードはダイヤルQ2から始まった
“ガラパゴス”の定義とは

約1年前に「SIMロック解除よりもアクセスポイントの解放こそが有効だ」という記事を書いた。そこではSIMロック「だけ」ではなく、閉塞した携帯網ではなく、インターネットへ開かれたアクセスポイントの解放が必要だと書いた。実のところ、こうしたコンテンツを囲い込む閉塞した携帯網でビジネスを続けてきたのは日本のキャリアだけであり、だからこそ寡占状態を生み出せて成功もしたのだが、世界的にはこうした垂直統合の名の下の囲い込みビジネスは珍しい。他国ではそもそも携帯網とはインターネットへ直結されている、携帯網とそれ以外の違いはなかったからだ。

では従来の携帯網をそのままスマートフォンに適用すればよいかというとそれも難しい。モバイルECを支えているケータイID(端末ID)はセキュリティ的には非常に脆弱であり、閉塞した携帯網でしか機能できない。
またもともとスマートフォントは、キャリアが企画して作り上げたものではない、いうなれば海外直輸入の「黒船」であるのでそうしたビジネスモデルが構築できない。

そこをどうするかを各キャリアは今必死に考えているところであり、それを示すのが上記の記事でもあるわけだ。
そして長期的に見れば、各社とも認めているとおりこのビジネスは衰退せざるを得ないだろう。そして否定はしているものの、各キャリアはやはり「土管屋」として、これまでのようなコンテンツビジネスからは市場からは追い出され回線費用のみで稼がざるを得なくなっていくだろう。
それがこうした弱気さともあるいは前向きとも捉えられる発言の背景なのだと思う。

では今後誰がケータイやスマートフォンのコンテンツ市場を担っていくのか。
それこそまさに「本当のインターネット」の世界が決めていくことであろう。これはここに来てようやく日本のケータイがインターネットに繋がりつつあるのだということだ。
これからのケータイネットにおいても、少なくとも現在主流のYahooなどのポータル勢やまたゲームを中心にしたSNS勢、またはFacebook、Googleといった海外勢が多くを担っていくことになるだろう。

では果たしてこれまで各キャリアと組むことで謳歌してきたコンテンツプロバイダー(C/P)各社はどうだろうか。
先日このような発表もあった。

「スマートフォンでiモード」を普及の「武器」に──ドコモ夏モデル発表

今年冬には、スマートフォン向けにiモードの課金・認証の仕組みを導入。iモード端末ユーザーが「マイメニュー」をそのまま引き継ぎ、iモード公式サイトコンテンツをスマートフォンでも利用できるようにする

さもあらん、という感じだが、このiモードコンテンツのスマートフォン対応というのが何かはよく分からない。そもそもコンテンツとしてはスマートフォンへ完全に作り替えなければならないのでこれまでのケータイ向けノウハウは全く役に立たないだろうし、また課金などの仕組みもiモードから移行させるのだろうが、これがうまく行くのか(セキュリティ的にも)よくわからない。
実のところ、個人的にはこれはドコモが主体で行いたいと考えているのではないだろうと思っている。つまり売り上げ低下の激しい従来のC/Pからの激しい追求・要望があった故ではないか。
ではうまくいくだろうか。
一つ思うのは「檻の中で飼われたライオンは野生では生きられない」ということだ。課金の仕組みもお仕着せのユーザー導線も何もないところから競争を勝ち上ってきた「真インターネット」組に太刀打ちできるとは到底思えないのだ。

キャリアが望もうと望むまいと、あるいは如何に抵抗しようと徐々に「土管屋」へ近づくのは時間の問題だ。つまり焦点は既に土管屋にはなく、果たして(主に海外)メーカーがまたは他のサービス事業者がどのような施策を打ち出しつつあるかに注目した方がよい。
二年後、恐らく日本の携帯業界は今とは全く別の力関係が存在していることだろう。

Posted by ROCA No Comments

iPhone 3Gの電池が膨張してケースが割れたけど、AppleCareサービスで無償交換してもらえた話

検索する限りは同じ現象に遭っている人はいなさそうに見えたんですが、もしかしたら遭遇する人がいるかも知れないので、記録のために残しておきますね。

先日ふと今やテスト用と化したかれこれ2年半ほど使っているiPhone 3Gを掴んだ時に違和感を感じてケース裏を確認したら、ケースの真正面に縦向きに大きなヒビが入っているのに気付きました。

林檎マークからiPhoneロゴのところまで約10cmぐらいの比較的大きなヒビでした。
ケースの裏側も普通は真っ平らだと思うんですが 、こころなし林檎マークを中心に少し盛り上がって平らではない感触。
瞬間的に「電池膨張してケースが内側から割れた？」と感じました。
普段常用しているのは3GSなのですが、3Gは開発テスト用に使っていたのでこれはこれで無くなると困ります。かと言って使い続けたら、ニュースで時々聞くようにいつか爆発なんてことになったら大変です。
ということでサポートに連絡を取ってみることにしました。

まずは近くにソフトバンクショップがある(3Gは発売月にそこで買った)のでそこへ持ち込み。
んでお兄さんが言うには、

• ソフトバンクショップでは最新機種で保証期間中なら無償で交換できるが、3GSや3Gについては受け付けていない
• 原則として外面上キズがある場合には交換料として一律22,000円頂くことになる

との返答。Apple Careにも入っていないので当然保証期間は切れています。
ただ、ソフトバンクショップが頼りにならないのは最初から想定内。
とりあえずソフトバンクのサポートポリシーを聞き出してから(要するにアップルとの契約上、サポートについては何も出来ないとのこと)、直接アップル・サポートへその場で電話してもらって担当へつないでもらうように頼みました。
日曜だったので少し時間はかかりましたが、 アップル・サポートへ事情を伝えてもらい、どうも電池の不具合らしいということは理解してもらえたようです。
但しこうした製品瑕疵(多分事故に関わる問題という意味かな？)については上位部署につながないといけないのだが、当日は日曜だったため混んでいて電話が繋がらず、後日あらためて連絡して欲しいとのこと。
受付番号をもらってその日はソフトバンクショップを後にしました。

翌日連絡すると、その上位部署というのはAppleCareサービスだったようです。通常のサポート部署とは違うんですね。
昨日対応できなかったことをお詫びされながら、まず「怪我や被害はでていないか」「ケースやPCなどが破損したりしなかったか」などこちらの被害がなかったかきめ細かく聞かれました。
その後再度裏面の様子や利用環境、PCとの接続形態なども細かく聞かれ、結論として

• 直接確認しないと何とも言えないので(そりゃそうですね)、配送業者を手配するのでiPhoneと接続していたUSBケーブルを送って欲しい
• 原則修理と言うことは行っていない。出来る対応は交換のみとなる(シリアル番号が変わるという注意があり)。
• 本来保証期間外だが、無償交換できるかどうかは現物を見てみないと現時点では何とも言えない
• 早めに現状を確認できると思うので可能であればヒビの様子を写真に撮ってメールで事前に送って欲しい

とのことでした。
実は開発・テスト用に3GはiOS3.1.3に止めており、仮に交換となった際にiOS4.xに上げられていると困るためどうなるかも質問したのですが、折り返しで「3GならiOS2.xで交換される」との回答をすぐもらえたので手続きをお願いしました。
3Gは復元でデータ初期化してから、木曜日に配送業者が引き取りに来ました。

その後連絡はなかったのですが、翌週火曜日に突然宅配便が来て、中には交換された新品(なのかな？)の3Gとやはり新しく交換されたUSBケーブルが入っていました。つまり「無償で交換」という判断をしてもらったということなのでしょう。
但し詳細について連絡も詳しい説明書なども入っていなかったので、後日こちらから連絡して(何かあったら連絡下さい、とのことで内線番号まで聞いていた)、折り返しでどういう判断をしてもらったかを聞きました。
実のところ(少なくとも日本では？)AppleCareサービスでは故障品の中身を空けて原因を調べると言うことはしないそうで、ただ外見上や利用状況から判断して「自然発生であったこと」「ユーザー瑕疵は無さそうなこと」「このまま使えば事故に繋がりかねないと判断したこと」などから部署内に在庫もあったため無償交換をしてくれた、ということのようです(ただしあまりはっきりとした判断を示されず、上記は少し曖昧な話からの僕の想像で補っています)。
また「常に出来る対応とは限らない」点は念押しされました。

ということで一件落着。3Gは新しくなったし(と言っても常用じゃないしそれ自体にはあまり意味は無いんですが)、テスト用の環境も簡単に戻せたので満足です。
アップルのサポートの評判は僕はよく知らないのですが、全般的に非常に親身で丁寧、かつ迅速な対応と判断でしたので少なくとも今回に限っては大満足でした。素晴らしいサポートが体験できました。
もちろん常にということではないかも知れませんし、特に今回は事故に繋がりかねないという点が大きかったのだろうとも思います。

めったにあることでは無いと思うのですが、もし電池が膨張などした場合には大変危険ですので、すぐにアップルのサポートへ連絡されることをお薦めします。上記と同じ対応が取られるとは限りませんが、爆発事故など起きてからでは遅いですからね。気を付けましょう。
本当は使わない時はケーブルから外して時々は放電もしておくのがいいんですよね。開発に使っているとなかなか難しいんですけどね。

Posted by ROCA Comments (3)

勝手に添削 – iモードが世界制覇できなかった本当の理由

iモードが世界制覇できなかった本当の理由

事実を正しく指摘してはいるけど、「本当の理由」ではないと思う。

「事実は正しく指摘」しようよ。
結論は、元の中島氏の結論も含めて携帯関係クラスタやらそうした関連記事ではさんざん出ている指摘なので特に異議もないのだけど、その「前振り部分」の事実誤認なのか無知なのか分からないが、事実無根の記述がこんなに短いエントリーなのに三つ(数え方により四つ)もあるよ。
はてブとか読む限り、勘のいい人たちは「何かおかしくね？」とちゃんと気付いてるみたいだけど、言葉のまま信じ切っている人も多いみたいなので、きちんと添削しておく。

ガラケー端末も遙か昔からTCP/IPぐらいサポートしている

WAP1.0の前世紀ならいざ知らず、少なくともiモードはその登場時からTCP/IPベースの携帯端末だった。 小飼氏が言っているのはその10年も昔のWAP1.0と取り違えたような話だ。
というよりWAP1.0のプロトコル・ゲートウェイ的なダサイ実装が嫌だったのでそもそも独自にiモードをTCP/IPベースにして開発した、というのは有名な話だ。
この端末からゲートウェイからもちろん外部のインターネットまで通信層をTCP/IPでデザインするというというアーキテクトはその後のWAP2.0へそのまま踏襲された(つまり現在世界的に見ても『IPアドレスが割り振られない』携帯端末はまず存在しない)。
そもそもガラケーでも問題なくSSLが出来ている(完全なピア・ツー・ピアという意味)時点でTCP/IPをサポートできていないはずが 無いのだが。
なおこれはEZWebやYahoo!ケータイでも(初期にはWAP1.0な時代があったかも知れないが、そこの歴史は僕には分からない。識者の教示を求む)同じことだ。

参考: WAP2.0で何が変わったのか

別にiPhoneだからと言って「グローバルIP」とは限らない

あいまいな論の文章なので判断しにくいのだけど、小飼氏の論やツイートを見ると「iPhoneにはグローバルIPが振られ、外部からも自由にアクセスされ得る」から「終端として主導権を握れる」のが他の端末との大きな違いとなった、とも読める。つまりグローバルIPを自由に使える点が重要だったという意味だろうか(正直こうしてまとめていても僕にはよく分からない)。
仮にそうだとして、日本ではソフトバンクのいわゆる「panda-world.ne.jp」と呼ばれる「iPhone専用網」でサービスされておりここではグローバルIPが割り振られる。IPがグローバルかプライベートかは通常は分からないが、JailBreakしていれば自機のIPが把握できるアプリもある。
しかし世界的にはそんなキャリアだけではない。
例えばこちらの資料をみれば一目瞭然だ。世界的にはグローバルIPを使用するキャリア、 プライベートIPを使用するキャリア(つまりキャリアグレードNATを導入しているキャリア)が混在している。

APN Settings for iPhone 3G | The iPhone User Guide

これらの国ではiPhoneの他の機種に対する魅力は無いのだろうか。ノキアは悠々自適なビジネス環境を生きているか。そんなことは無い。
更に言えば、そもそもスマートフォン網だのガラケー網などと分かれている(アクセスポイントが分けられている)国の方が珍しいので、従来の携帯端末でもグローバルIPが割り振られる場合も同様にある。
「日本のガラパゴス現象」を主題にしているのは理解しているが、しかしその論では「海外においてもiPhoneがスマート」になっている理由付けにはならないだろう。
論理的帰結として、iPhoneはまたはスマートフォンとはそうした「外的要因」からは分離されたところにその存在意義や魅力があると考えるべきだろう。

なお僕には詳細は分からないのだが、「そもそもiモードにも外部接続を受け付ける仕組みはあるよ？」という指摘もある。

定額データ料金はiPhone以前からずっと存在している

これまたあいまいな文章なので判断しにくいが、「iPhoneは定額データ(=常時接続)が無ければこれほど浸透しなかった」は自明としても「定額データを導入したからiPhoneが浸透した」なら成り立たない。既に多くの人が理解するようにiPhone以前の何年も前からガラケーで定額データは一般的だったからだ。
今に始まった経緯では無いのだから「iPhone『だけ』を特別なものにした」論の論拠としては甚だ疑問だし、では何故ガラケー(やその他従来端末)がiPhoneになれなかったかの論としては成り立っていない。

ガラケーがiPhoneになれなかった訳もしくはキャリアがiPhoneを企画できなかった理由

このブログでは、あるいはTwitterでも散々ツイートしているし長くなる話なのでかなり簡単にまとめるが、僕自身は「肝」はいわゆる固有端末ID(uid, X-UP-SUBNO、X-JPHONE-UIDなど)をベースにしたモバイルECが想像以上に成功しそれ以外の方向性に舵を切る必然性がキャリア・メーカーともに無くなったからだと思っている。つまり「イノベーションのジレンマ」かも知れないし、中島・小飼両氏の「結論」も別に異議はない。それ故にキャリアはメーカーを飼い慣らす(実は飼い慣らしたかったのはユーザーだろうが)必要があったしメイドにもならざるを得なかった(つまり両氏の「結論」は「結果論」)、というのが本質論だと思っている。
もし興味があるのなら以下の以前のエントリーも参照して欲しい。

日本のケータイWEBはどうしてこんな仕様になったのか
結局SIMロック論議もオープンプラットフォーム構想も端末IDの話に尽きるのかも知れないなぁ
Appleは本当に垂直統合なのか – 日本の携帯キャリアとの違い
ガラケー機能は須くクラウドを目指せ

ともあれ。エンジニアたる者、事実に立脚せず思い込みだけで論陣を張るなど以ての外だし、知らないことは知らないでよいのではないか。その上で知りたいのなら(議論したいのなら)きちんと新たに学べばいいだけだ。これはネットだけでなくリアルにおいても「技術屋」としては最低限の矜持である。

ROCA,  the mere engineer.

Posted by ROCA No Comments

Appleは本当に垂直統合なのか – 日本の携帯キャリアとの違い

よく「日本の携帯キャリア構造を垂直統合と言われるがAppleこそ垂直統合ではないか」「Appleは日本のケータイ業界を参考に垂直統合戦略を組み立てた」などという人がいる。
しかし個人的には果たして日本のキャリア構造とAppleの戦略を同一視し、更にはそれを理由に日本のキャリア構造について肯定的に捉える(または言い訳に使う)論法には反対だ。
また更にはそれをして「勝てば官軍、負ければガラパゴス」とまで拡大解釈する向きもあるようだ。
ここではその「Appleこそ垂直統合・ガラパゴス」主張について反論をしてみようと思う。

続きを読む »

Posted by ROCA No Comments

SH-03C/IS03/003SHのスペックと保有コストを比較してみる

各キャリアから2010-2011冬春モデルの発表が出そろって、皆さんどれを買うかわくわくされていることと思います。
僕も例外ではないんですが、一つ特筆すべきはSH-03C/IS03/003SHといった同一メーカーの兄弟機が一斉に主要キャリアから発売されるということ。もしかしたらこれって史上初めてのことではないでしょうか(少なくとも今世紀以降では。2Gの頃にはあったのかも知れません)。
そもそも各キャリアは独自のサービスとハード的にも強く結びついた端末を出してくるというのがこれまでの建前であったわけですがそれが一部とは言え崩れ去ろうとしつつあります。
これはあまり喜ばしい理由によるとは思わないのですが、つまりは「ガラケースマフォ」を日本キャリアのためにわざわざ作ってくれるメーカーが国内にほとんど無くなってしまい特定のメーカー(ここではシャープ)に集中してしまったこと、Androidベースのスマフォであるためベースが同じにならざるを得ないこと、がその理由でしょう。
もしその端末が気に入っていれば今度はどのキャリアにするかが今後は大いに悩ませることになるかも知れません。
(その点国際機と言われるXperiaやGalaxyシリーズ、Desireシリーズなどはうまくキャリアの棲み分けが出来ているようです)

これは一見するとキャリア毎の端末の差異が無くなりつつあり逆に選び方が難しくなったと思えるかも知れません。
そこでここでは発表資料を中心にスペック面と保有コスト面を中心にキャリア毎に比較をしてみたいと思います。
これはあくまで SH-03C/IS03/003SHでの比較ですが、場合によってはこうした差異の無くなりつつある状況でのキャリア毎の戦略を表している、とも言えるかも知れません。
なお内容の正確さには配慮したつもりですが、事実誤認などありましたら指摘いただければ幸いです。

続きを読む »

Posted by ROCA Comments (16)