キャリアによる「通信の最適化」が原因でスマホ向けゲームに不具合が発生 114
ストーリー by hylom
HTTPSで送るしかないのか 部門より
HTTPSで送るしかないのか 部門より
複数のiPhone向けゲームアプリで、キャリアによる「通信の最適化」が原因でゲームデータがダウンロードできないという不具合が発生していたそうだ（開発者による告知、すまほん！！、Togetterまとめ）。
ファイルサイズなどが変わってしまうため、ゲーム内の不正行為チェックに引っかかっている模様。このような最適化はユーザーへの告知が不十分なことなどの問題が過去にも指摘されていた（Yahoo!ニュースの山本一郎氏の記事）。
この問題を受けてセキュリティ研究者の高木浩光氏は「見よ！これが電気通信の信用が地に落ちた現場だ。」とのTweetを行っている。
これは「最適化」ではなく「改ざん」と呼ぶべき (スコア:5, すばらしい洞察)
通信量が減るでのキャリアから見れば「最適化」ですが
ユーザ（＝ゲーム制作側，利用者）から見れば，これはデータの「改ざん」だと思います．
改ざんはユーザの同意を得ずに通信内容（データ）を勝手に書き換える行為であり，
他のキャリアでも時々問題になっています．
そこには通信の秘密や同一性保持権等の法律的な問題があります
今回の話はまさに「見よ！これが電気通信の信用が地に落ちた現場だ。」と捉えるべきで
我々は「最適化」ではなく「改ざん」と呼ぶべき事案だと思います．
符号、音響又は影像 (スコア:2)
「通信の秘密」に議論を持ち込むのは、法律論としてはスジが悪いなぁ。と思って、ざっと書いてみたのですが、ちょっと長くなったので今日の日記 [srad.jp]にしてみました。よければどうぞ。
Re: (スコア:0)
個人的には、"改ざん"とか他意を付与して言い換えるよりも"「通信の最適化」"とカギカッコで表現してる各記事の方が賢く見えるな。
Re: (スコア:0)
誰からみても改竄だよね
キャリアが言い訳するために最適化とか妄言を吐いているだけで
意図的に無断でデータ変えて使えなくしてるんだから
総務省なり警察なりちゃんと仕事しろ（罰せ）よとしか思わない
Re:これは「最適化」ではなく「改ざん」と呼ぶべき (スコア:1)
盗聴については難しいところ。
ISPの中継装置でウィルスチェックを行っている場合があるが、それは盗聴になるのか。
メールサーバでウィルスを取り除けばメールの盗聴のみならず改ざんになるのか。
メールサーバの場合、zipファイルの中までも展開して見られていることすらある。
どちらもユーザの同意により行っているのだから、これらは問題ないのか。
Re:これは「最適化」ではなく「改ざん」と呼ぶべき (スコア:1)
まず大抵のウイルスチェックシステムは、チェックでウイルスが見つかった場合は削除すると同時にその旨を表記しているから、受信者は「ウイルスが見つかったのか、だから消されたんだな」ということを認識できる
更にユーザーは合意しているし、大抵のユーザーは「ウイルスを自動でチェックして発見されたメールは削除されます」ぐらいのことは理解できる
でも「通信を最適化します」とかの説明だけではこんな挙動は理解できないし、アプリの誤動作を引き起こすことを想像できる人も多くはないだろう
ましてやそれでデータが改ざんされたことに気がつけるかといえば限りなく困難だと思う、PCなら兎も角iPhoneでは特に
（iPhoneがPCに劣るとは言わないけど、EXIFへのアクセスしやすさや、DLした画像のサイズ確認とかのハードルが高いのはスマフォという性質上仕方ないので）
要するに一番の問題はデータの改ざん内容が可視化されていないことと、そもそも改ざんされたことに気がつくことすら困難なことだと思うよ
「通信の最適化」によって、容量が増えることも (スコア:5, 興味深い)
BUZZAP！ [buzzap.jp]の記事によると、ソフトバンクの「通信の最適化」によって画像の容量が増えることもあるようです。Twitter のつぶやき [twitter.com] によると、容量が4倍にもなるケースもあるようです。
どういったアルゴリズムで圧縮をかけているのかは公開されていませんが、圧縮によってファイル容量が増加するケースもあるということは、ファイル単位で圧縮せずに、JPEG画像だったらブロック毎に再圧縮して、当該ブロックの再圧縮が完了し次第即座に端末にデータ転送しているのでしょう。「通信の最適化」によってWebブラウジング中に画像が表示されるまでの時間を長くする訳にはいかないでしょうから、ファイル全体を圧縮してから元の画像とのファイルサイズを比較して容量が少ない方を転送するという仕組みにはできなかったのでしょうね。ブロック毎の再圧縮の場合、容量が増えてしまったブロックだけ再圧縮前のデータを用いると、ブロックノイズが目立ってしまいますし。
もし、「通信の最適化」によって逆に通信量が増えてしまうケースを回避することが技術的に難しいのならば、通信量に応じた金額を支払う従量課金となっているのですから、「通信の最適化」によって、かえって通信量が増える恐れがあることを十分に告知すべきではないでしょうか。ワンクリック詐欺のようなこと [srad.jp]をしているソフトバンクには難しいのかもしれませんが。
Re: (スコア:0)
課金だけの問題ではないでしょう。
通信量が増える恐れがあると告知すれば良いという問題ではないと思います。
残念なことに音楽ファイルは 「通信の最適化」 の対象外 (スコア:5, おもしろおかしい)
docomo [nttdocomo.co.jp] も au [kddi.com] も SoftBank [softbank.jp] も、画像や動画は「最適化」（不可逆圧縮やコーデックの変換）の対象ですが、残念なことに音楽ファイルは 「通信の最適化」 の対象外なようです。
え、何が残念かって？
もし、音楽ファイルも「通信の最適化」の対象だったら、ハイレゾ音源をダウンロード販売で購入したオーディオマニアの逆鱗に触れ、針の巣をつついたような大騒ぎになっていたでしょう。ハイレゾ音源が MP3 128kbps などに劣化してしまったら、苦情電話の1本や2本で収まりきるはずもありません。そして、ケータイキャリアは「通信の最適化」の撤回に加えて、謝罪と賠償を行うことになるという理想的な展開が待っていたのに……。
まさか、音楽ファイルを対象外にするとは……。大手ケータイキャリア3社はなかなかの策士でしたorz
Re:残念なことに音楽ファイルは 「通信の最適化」 の対象外 (スコア:1)
本当に残念だ
JASRACも参戦してきただろうに
Re:残念なことに音楽ファイルは 「通信の最適化」 の対象外 (スコア:1)
は? 「通信の最適化」をしないから音質は変わらない? 何をバカなことを言ってるんですか。真のピュアオーディオの道はキャリア選びから始まるんですよ。
ソフトバンク: どこまでも前進する輝き。
(以下略
なんで今になって？ (スコア:3, すばらしい洞察)
ソフトバンクの「最適化」なんて数年前から行われていて以前も話題になったのに、なぜ今になって問題が発生しているのかよく分からない。
Re:なんで今になって？ (スコア:2)
そうか、なんだと思ったけど昔読んだことあった。
ドコモがスマホ画像を圧縮する「通信の最適化」を導入へ、その狙いは？(2014年06月25日)
http://trendy.nikkeibp.co.jp/article/column/20140623/1058602/ [nikkeibp.co.jp]
画面の表示などを速くするため、auやソフトバンクなど大手キャリアが、スマートフォンに表示されるWebサイトの画像や動画などをあらかじめ圧縮する「通信の最適化」が、最近ネット上で大きな話題となった（関連記事は http://buzzap.jp/news/20140604-sbm-speed-network-optimize/ [buzzap.jp] ）。
Re:なんで今になって？ (スコア:1)
内容が公表されていないから、いまいち実態がよくわからなかったのが、
不具合の原因追及の過程でようやくわかってきた、ってところでは。
Re:なんで今になって？ (スコア:5, 参考になる)
公表されている。 [softbank.jp]
ご利用の際に制御することがあるコンテンツ・サービス
対象 説明
VoIP（Voice over Internet Protocol） 音声通話やテレビ電話などをパケット信号に変換し、
を利用する通信 データ通信にて実現するサービス
動画、画像などの一部 MPEG、AVI、MOV形式などの動画ファイル
BMP、JPEG、GIF形式などの画像ファイル
大量のデータ通信、または 動画閲覧、高画質画像閲覧をともなうサイト、アプリケーションなど
長時間接続をともなうパケット通信
（最適化されたデータの復元はできません）。なお、通信の切断は行いません。
これはひどい (スコア:1)
大炎上だと言いますが、対岸の火事状態の私は幸せなのかな
つーか、これ、訴えられたら免許はく奪案件なんじゃないの?
約款にそれとなく(拡大解釈幾らでもできる)匂わせておけばやりたい放題なのかな
おしえて!えらい人!
えらい人はごみのようだなんて言ってないで、ちゃんと仕事してください。
Re:これはひどい (スコア:1)
auもやってるみたい [kddi.com]よ。
通信の最適化について
通信の最適化を行う場合があります。
画像ファイル BMP、jpg、gif、PNG形式
動画ファイル MPEG、AVI、MOV、FLV、MP4、3GP、WebM、ASF、WMV形式
･･････
※最適化とは、スマートフォンの画面に適したサイズに画像を圧縮・変換することをいいます。
なお、圧縮・変換されたデータを復元することはできません。
Re:これはひどい (スコア:1)
auの場合は申し込めば解除できるし今は最初からかけてはないはず
Re:これはひどい (スコア:1)
docomoもやってる [nikkeibp.co.jp]。
spモードご利用細則 [nttdocomo.co.jp]
1．インターネット接続サービスについて
(3)通信の最適化
1 別途当社の定めるところに従い同意いただいた場合、spモードのアクセスポイントを経由したパケット通信において、
画面の表示速度や動画の再生開始時間を早くするための通信の最適化を行う場合があります。
最適化とは、端末の画面に適したサイズに画像・動画を圧縮することや、より伝送効率の高いコーデック形式に
動画を変換することをいいます。
2 HTTPS（Hypertext Transfer Protocol Secure）通信時の画像等、spモード電子メールを含むメールの添付ファイルの
最適化は行いません。
3 最適化された画像等を復元することはできません。
とまあ、3大キャリアはどこもやってるってこった。
Re:これはひどい (スコア:1)
テスト不足かなぁ？
24時間365日ソフトバンクが最適化をかけ続けてた、というならテスト不足と強弁することもできるかもしれないけど
それこそ特定の時間帯とか混雑時期に動的にかけてたとしたら、そんなのまでテストで洗い出せというのは不可能
そもそもインフラ側がデータを改ざんするなんてことをアプリで想定してたらきりがないし（偶発的なデータ破損への対策はアプリ側でなされていたわけだしね）
今回これで話が公になったから、今後はある程度の対策は求められるだろうけど
ソフトバンクだって通信最適化してる回線と、契約で申し込んでないために最適化してない回線とかも想定しうるわけで、ただでさえ複数のiPhone機種が世に出回ってて、更にキャリアごと・契約内容ごとに用意してテストしてるべき、というのは要求として過剰すぎると思うのだが
通信エラー時の処理とかはちゃんと対応するべきだと思うけど、特定のキャリア・契約内容の時に限りデータを意図的に改ざんされることがあるなんてのをアプリ開発者の責任でテストするべきだとしたら、そんなのは非現実的だと言わざるを得ない
＃「日本のISPがHTTPに干渉してすらどの表示内容を変化させてないか、すらど運営がチェックしてないのはテスト不足だしお粗末だ」って言ってるのと同じじゃん
Re:これはひどい (スコア:1)
> テスト不足かなぁ？
なんのテスト不足かわからないけど、テストってほとんどWifiでやってます。
まさかキャリア通すと品質が落ちるなんて思わないですよ。
Re:これはひどい (スコア:1)
それが本当ならこんな騒ぎにはならないよね。
説明が載ってたとしても周知が不十分だったとしか思えないのだが。
Re:これはひどい (スコア:2, 参考になる)
ブラウザベースのゲームであれば普通。暗号化とかまとめる方が手間と機種依存が高くなるので避ける。
Re:これはひどい (スコア:1)
圧縮された画像は再圧縮してもサイズはちっちゃくならないし、
Keep-Alive ちゃんとしてたら、そんなにオーバーヘッドないでしょ。
必要なものからバラバラに取ってこれるほうが効率いいと思うけど。
部門名 (スコア:1)
スラドも早くHTTPS化してくださいよう。
音声や動画は劣化している (スコア:0)
音声や動画は劣化しているのだから、画像が劣化しようが問題ないという発想？
化けっと (スコア:0)
これはモバイルでの事象だけれども、データのサイズを無闇とケチろうとすれば有線でも同じ結末になり得る。
こんなのでNTT東西地域会社が目指しているという回線交換網の廃止なんてできるのかねぇ。
Re:化けっと (スコア:3, すばらしい洞察)
これのせいでhttps化が加速してデータ量が逆に増えるまでなんか見えた気がする
有線通信なら採算が取れないのであり得ない (スコア:2)
いえ、電波資源が極めて高額（LTE通信1GBにかかる事業者側のコストが300円～400円）だから、「通信の最適化（不可逆・劣化圧縮）」を導入してももとが取れるのです。
有線通信であれば、DPIを導入してリアルタイム圧縮をかけるのに必要な計算資源を確保するコスト（電気代も含む）よりも、通信帯域の確保にかかるコストの方が明らかに安いため、事業者側に導入するメリットがありません。
勿論、ついでにDPIによる通信内容の分析も行い、閲覧したサイトや購入した商品、検索キーワードなどを収集、分析したデータを販売するといったことも同時にやるのならば、採算がとれるでしょうけど（今流行のビックデータの活用というやつ）。
Re:有線通信なら採算が取れないのであり得ない (スコア:1)
Re:有線通信なら採算が取れないのであり得ない (スコア:3, すばらしい洞察)
つi-mode
Re:有線通信なら採算が取れないのであり得ない (スコア:1)
とは言ってもセキュア通信の (スコア:0)
コンテンツは最適化と言う名の改ざんはできませんよね
※できたら大事
twitterみたいに既にクラウド側で最適化圧縮行うのもあるし
グーグル先生のサービスはどうなんだろう。
Re:とは言ってもセキュア通信の (スコア:2)
モバイル向けChromeにはデータ圧縮機能がついてますよね。
http://googlejapan.blogspot.jp/2014/01/google-chrome.html [blogspot.jp]
仕組み
http://www.teradas.net/archives/12842/ [teradas.net]
Re:とは言ってもセキュア通信の (スコア:1)
SSLを使えというご指摘はごもっともで
ゲームだし見られてもいいデータだし
というのは単なる運営会社の甘えです
Re: (スコア:0)
端末にあらかじめルート証明書入れればできるでしょ
Re: (スコア:0)
そりゃ、証明書とURLのチェックでばれるでしょ
Re: (スコア:0)
証明書を注意深く見れば分かるけどルート証明書がインストールされているので警告はでないし
中間者攻撃だからURLは変わらずに送られてくるファイルの内容を改ざんできる
Re:とは言ってもセキュア通信の (スコア:5, 参考になる)
https://www.example.com/ [example.com] と通信するとしよう。
普通は www.example.com の HTTPS サーバは、信頼されたルート証明機関、たとえばシマンテックへつながる証明書を送ってくる。
端末（ブラウザ）は、自分が信じる「この証明機関は信頼できる」とされる証明機関であるシマンテックへつながる署名があるから、「現在接続している "www.example.com" と名乗るサーバは本物である」と推定する。
ここで、キャリアが独自のルート証明書、"Carrier CA" を出荷時に端末の証明書ストアに入れておくとしよう。
ブラウザは www.example.com と思われるホストと通信をし、最終的に "CAREER CA" へつながる署名を確認した。
Carrier CA はシマンテック同様に「信頼できる証明機関」だから警告は何も表示しない。
通信の両端に居る「"www.example.com" のサーバ」も「クライアント（ブラウザ）」も正常に通信できる（何のエラーも発生しない）。
待て、この通信は本当にセキュアだろうか？
この通信の実態はこう。
クライアントは www.example.com につないでいるつもりだったが、実は "Carrier" のサーバと通信している。
"Carrier" のサーバはクライアントのつもりになって www.example.com と通信をする。
"Carrier" のサーバで一回デコードしてから暗号をかけなおして送信しているわけ（送受信両方とも）。
通常ならこういう乗っ取りをやると証明書が信頼されなくなるのでブラウザはエラーを吐くが、 "Carrier CA" は信頼された証明機関なのでブラウザは特に問題ないと判断する。
さて、キャリアである "Carrier CA" が可逆・不可逆圧縮あるいはもっと悪意のある盗聴をおこなっていた場合、利用者（よほど注意深い利用者以外）は気づくだろうか。
というのが #2838996 [mobile.srad.jp] や #2838997 [mobile.srad.jp] や Superfish 、証明機関の事故の話。
Re:とは言ってもセキュア通信の (スコア:1)
利用者が直接気付くのは難しいだろうという点は同意しますが、それでも、今ならCertificate Transparency (CT)があるので、Carrier CAが証明書を偽造していることはすぐに発覚するはずです。そのため、現在のいわゆる「通信の最適化」のように黙って実施することはないと期待して良いのではないでしょうか。
CTが生まれたきっかけも、偽造証明書の事故（DigiNotarのときの）ですし。
CT（Certificate Transparency：透かし入り証明書）の現状 [digicert.ne.jp]
Re: (スコア:0)
Re: (スコア:0)
（利用者としてそれが適用されるのを好まない人はいますが）
TLSしよう (スコア:0)
TLSしてHTTP/2しようぜ。
なぜ非可逆圧縮なのか？ (スコア:0)
可逆圧縮なら問題にならなかったと思うのだけど、
とかの理由で非可逆にしたのだろうか？
また、元々圧縮済みのデータまで再圧縮しても、負荷の割に効果は少ないと思うのだが。
Re: (スコア:0)
たぶんあなたの観点がずれてる
可逆圧縮だとして、端末側のどのタイミングで元に戻すのか？
ブラウザ？それともOSのパケット受信部分？
全ての利用者に対して、そんなところにソフトバンクやauが手を入れられるとは思えないので、
コンテンツの容量を削ってるんだと思う。
たとえば画像の場合、縦横をそれぞれ半分のサイズに縮小したデータを端末に送れば通信量の圧縮になるかと。
通信の最適化をやめさせたとしても (スコア:0)
国内の全事業者のサービスが横並びで遅くなるだけですよ。
残念ながらこれは技術の限界。
彼らが設備投資を怠ってるわけじゃなくて、
割り当てられた周波数の範囲でしか容量がないわけですから。
(いっぱい割り当てられてる事業者が有利になるというのはあるかもね)
最適化の装置に設備投資しなくてよくなるから嬉しいくらい
なんじゃないかな?
遅くてもいいから通信の秘密を厳格に遵守させるか、
「最適化」を許容して速度を得るか、どっちにする？
(あるいは、最適化やるならどこまでやっていいか？)
という議論だと思っています。
同じ話で、固定電話から携帯にかけたらG.711(非圧縮PCM)から
EVRCやAMRに変換されるもケシカランというなら、
音声チャンネル数減らして無線区間もG.711で流せばいいと思います
Re:通信の最適化をやめさせたとしても (スコア:1)
元々、劣化することが明白な音声データと劣化しないという前提で
今までやってきたデジタルデータを同一に扱うのはいかがなものかと思います。
画像を劣化させることで速度を稼ぐというアプローチが必ずしも無しとは
言いませんが、それをやるのであれば顧客に正しく通知されるべきです。
＃個人的には、通信会社が通信の内容を見ること自体に反対です。
Re:通信の最適化をやめさせたとしても (スコア:1)
>遅くてもいいから通信の秘密を厳格に遵守させるか、
「最適化」を許容して速度を得るか、どっちにする？
少なくともソフトバンクは、ユーザに選択できる仕組みを用意しているのかな？
うめ～このみかん (スコア:0)
そういや昔画像埋め込みファイルとか流行ってたよね。
きっとあーゆー違法ツールを撲滅するための根本的な対策だったんだよ！
#なわけない
Re: (スコア:0)
御茶御茶言ってんじゃないよ！