Narusaseの日記 -ハニポってどうよ?(仮)- このページをアンテナに追加 RSSフィード

2015-07-16

[] 「通信最適化問題論点まとめ  「通信の最適化」問題の論点まとめを含むブックマーク  「通信の最適化」問題の論点まとめのブックマークコメント

注意:

途中で力尽きました、ぜんぜんまとめきれてません・・・orz



通信最適化とは

いわゆる3大キャリアを中心に、MVNOなども含む非wifi通信時(いわゆるLTEなど)におこなわれる、画像動画等に対する非可逆圧縮のこと


問題点

問題点としては複数あり、主に下記のように類型化できると思われる

1. 品質劣化問題

サービス提供者もしくはユーザー意図に反する形で(あるいは基づかない形で)、画像等に対する非可逆圧縮をおこない品質劣化をおこしている点

2. サービスへの干渉問題

一部のアプリにおいて「通信最適化」によりアプリを起動できないなどの問題が発生し、各サービス提供者およびユーザー不利益を与えている点

3. 通信の秘密への侵害問題

ユーザによる「明確な同意」に基づかずにおこなっており、いいわゆる電気通信事業法 および 日本国憲法 における「通信の秘密」を侵しており、盗聴や検閲に相当する点

4. ネットワーク中立性に反する問題

インターネットユーザー自分が見るコンテンツや使用するアプリケーション自分で選択できるべきだとするネットワーク中立性の考え方に反する点

5. 著作権侵害問題

画像等の非可逆圧縮をおこなうことから著作権における同一性保持権侵害している点

6. その他



通信最適化はどのように実現されるか

ドコモauSoftbank、その他MVNOなどで差異はあるが主として下記のようにな構造想像される


+-------------------------+
| クライアント            | ... ユーザーからみるとブラウザやアプリ相当
+-------------------------+
   ↓              ↑
  ( LTEなどのキャリア網 )
   ↓              ↑
+-------------------------+
| 透過的Proxy              | ... ここで一部のレスポンスに対して非可逆圧縮を実施
+-------------------------+
   ↓              ↑
  ( インターネット網 )
   ↓              ↑
+-------------------------+
| サービス提供者のサーバー |
+-------------------------+

凡例
↓ --- リクエスト
↑ --- レスポンス

キャリアとも「通信最適化」の詳細な仕組みや非可逆圧縮対象の選定方法などは公開されていないため想像になるが

いわゆるキャリア網とインターネット網の境界付近に透過的Proxyを配置しそこで通信パケットを一次復元画像動画、音声などに対して非可逆圧縮をかけていると想定される。


○同一レイヤー同一ペイロード原則(造語)について

話をわかりやすくするため先に、余計な話をしておこう


いわゆる、「インターネット」はサーバークライアントがありその間にネットワークがあるという形が基本となっているかと思う。

クライアントネットワークを介してサーバーに対しリクエストを行い、サーバはレスポンスとして結果を返すというのが基本的フローである。

ネットワーク内ではリクエストやレスポンスは、いわゆるプロトコルスタックにしたがって分割、パケットか、信号化され最終的には電気信号や光として伝達される。

一般的教科書的に想定されるウェブブラウズにおけるプロトコルスタックとしては、低レイヤーから順に 100BASE-TX - 802.3(ethernet) - IP - TCP - HTTP - アプリ(プログラムブラウザ) といったものあたりが想定されると思われる。


ここで、とあるクライアントと、とあるサーバー通信する場合単純化してかんがえると、クライアントは高いレイヤーから順にプロトコルスタックをたどって100BASE-TX信号としてリクエストネットワークに送出する

これに対してサーバー信号として100BASE-TX信号としてリクエストを受け取り低いレイヤーから順にプロトコルスタックをさかのぼって解釈リクエストを受け取り、プログラムで処理し、それに対して今度は逆順にレスポンスを返し、最終的にブラウザに表示されるといった流れとなる


ここで、このリクエスト or レスポンスのクライアント側とサーバー側で同一のレイヤー(同一のプロトコル)のいわゆるペイロード部分だけを注目した場合、どちらのプロトコルスタック上でも同じレイヤーにおけるペイロード部分の総体(あくま総体であって個別パケットは分割されていたり順番が相違することなどはありうる)はどちらも同一であることが原則として保障される。

このペイロード総体が同一であることが保障されていることでインターネット網での正常な通信が可能になる。

たとえば、レスポンスを対象として、サーバ側でHTTPの層でペイロードgzip圧縮(可逆圧縮)(HTTPのContent-Encodingの機能)したとしても、クライアントgzipされたペイロードHTTPの層で受け取り、それを解凍して上位の層に渡すので、双方のアプリの層では同じペイロードが得られる

従来のレスポンス
 サーバー                                                    クライアント
+--------------------------------+ (1)                   (1)+--------------------------------+
| アプリ(サーバ側プログラム)     | ↓<-                ->→ | アプリ(クライアント側ブラウザ) |
+--------------------------------+ ↓                    ↑ +--------------------------------+
| HTTP                           | ↓<- 各層で見ると   ->↑ | HTTP                           |
+--------------------------------+ ↓                    ↑ +--------------------------------+
| TCP                            | ↓<- 総体として同一 ->↑ | TCP                            |
+--------------------------------+ ↓                    ↑ +--------------------------------+
| IP                             | ↓<-                ->↑ | IP                             |
+--------------------------------+ ↓                    ↑ +--------------------------------+
| 802.3(ethernet)                | ↓<-                ->↑ | 802.3(ethernet)                |
+--------------------------------+ ↓                    ↑ +--------------------------------+
| 100BASE-TX                     | →→→→(中略)→→→→↑ | 100BASE-TX                     |
+--------------------------------+                          +--------------------------------+
従来のレスポンスは(1)のペイロードの総体はサーバー、クライアント間で維持される
また、中略の部分に無線LANや光ファイバー、ハブやL2スイッチ、ルータなどなどが存在している想定だが
その場合であっても、総体としてのペイロードは維持される


今回の「通信最適化」ではこの総体としてペイロードが同一であることが、通信経路におかれた透過的Proxyによる非可逆圧縮の影響で最上位のアプリの層で崩れてしまうことで、アプリに悪影響を与えてしまっている。


「通信の最適化」のレスポンス
 サーバー                                                    透過的Proxy(ここで改変)                                 クライアント
+--------------------------------+ (2)                   (2)+--------------------------------+(2')                  (2')+--------------------------------+
| アプリ(サーバ側プログラム)     | ↓<-                ->→ | 画像、動画などの圧縮プログラム | ↓<-                ->→ | アプリ(クライアント側ブラウザ) |
+--------------------------------+ ↓                    ↑ +--------------------------------+ ↓                    ↑ +--------------------------------+
| HTTP                           | ↓<- 各層で見ると   ->↑ | HTTP                           | ↓<- 各層で見ると   ->↑ | HTTP                           |
+--------------------------------+ ↓                    ↑ +--------------------------------+ ↓                    ↑ +--------------------------------+
| TCP                            | ↓<- 総体として同一 ->↑ | TCP                            | ↓<- 総体として同一 ->↑ | TCP                            |
+--------------------------------+ ↓                    ↑ +--------------------------------+ ↓                    ↑ +--------------------------------+
| IP                             | ↓<-                ->↑ | IP                             | ↓<-                ->↑ | IP                             |
+--------------------------------+ ↓                    ↑ +--------------------------------+ ↓                    ↑ +--------------------------------+
| 802.3(ethernet)                | ↓<-                ->↑ | 802.3(ethernet)                | ↓<-                ->↑ | 802.3(ethernet)                |
+--------------------------------+ ↓                    ↑ +--------------------------------+ ↓                    ↑ +--------------------------------+
| 100BASE-TX                     | →→→→(中略)→→→→↑ | 100BASE-TX                     | →→→→(中略)→→→→↑ | 100BASE-TX                     |
+--------------------------------+                          +--------------------------------+                          +--------------------------------+
「通信の最適化」のレスポンス(2)のペイロードの総体はサーバー、クライアント間で維持されず、Proxyで改変された(2')を受け取ってしまう



また、中略の部分に無線LAN光ファイバーハブやL2スイッチルータなどなどが存在している想定だが

その場合であっても、 サーバー - Proxy間、Proxy - クライアント間の総体としてのペイロードはそれぞれ維持される



○「通信最適化」の対象になっているか調べる方法


対象かどうか

まずは第一に3大キャリアの設定ページにて、自分対象になっているのか確認する方法は、下記を参照にすると良いだろう


通信最適化」を設定・解除する方法ドコモauソフトバンク】 ? WEBサイトでチェックもできるぞ ≫ 使い方・方法まとめサイト - usedoor

http://usedoor.jp/howto/digital/smartphone/tsuushinnosaitekika-docomo-au-softbank/


・今現在通信最適化」されているかどうか

いくつかのサイトで今現在通信最適化」がされているか確認することが出来る

有名どころを二つほど上げておくので参照してみると良いと思う


通信最適化テストページ

http://seaki.sastudio.jp/nise/photos/SANY9274i.html


通信の最低^H^H最適化確認

http://horobi.com/Saiteika/



過去に「通信最適化」されていた可能性があるかどうか

これまでの報告によると、ドコモauSoftbankBIGLOBEb-mobileU-mobileぷららモバイルLTEDTIなどで「通信最適化」が報告されています


通信最適化」、3キャリアと11社のMVNO適用実態を調べてみた | 格安スマホ回線研究所

http://yesmvno.com/optimization/


なお、IIJmio については下記のTweetによれば、現時点では行っておらず、導入の予定も(いまのところ)ない とのこと

https://twitter.com/iijmio/status/615456060028006400


加えて、下記にて紹介されているが Google Chromeの「データセーバー」や、Operaの「Turboモード」など意図して「通信最適化」をする機能意図して利用している場合、今回のキャリアによる「通信最適化」とは別に適用されている場合があるので注意が必要です。


MVNO格安SIM)であえて「通信最適化」をする方法 | エンジニア休日

http://xins.club/lab/mvno-optimization-apk/



○これまでの流れ

おおよそ下記のまとめを追うと大まかな流れは確認できると思われる


ハッハッ、見ろ!第1種電気通信事業ゴミのようだ!! #通信最適化() - Togetterまとめ

http://togetter.com/li/839917


高木浩光先生通信最適化についてau電凸(前編)「元に戻せない圧縮であるが、改ざんではない」 - Togetterまとめ

http://togetter.com/li/846035


高木浩光先生通信最適化についてau電凸(後編)「そんな適当なこと言って大丈夫か?」「大丈夫だ、問題ない」 - Togetterまとめ

http://togetter.com/li/846061


kadongo38氏「日本通信事業者よりAppleFacebook, Google の方が問題」 - Togetterまとめ

http://togetter.com/li/847364


通信最適化に対するshi3zさんのネットワーク構成認識 - Togetterまとめ

http://togetter.com/li/847799


shi3zさんの通信上の圧縮アルゴリズム利用の認識と、big_brosさんによる指摘及び圧縮アルゴリズム解説 - Togetterまとめ

http://togetter.com/li/847777


ソフトバンクの「通信速度1位」のカラクリが明らかに、ヒントは「通信最適化」 | BUZZAP!(バザップ!)

http://buzzap.jp/news/20140604-sbm-speed-network-optimize/


通信最適化に関する回答(KDDI

https://www.evernote.com/shard/s12/sh/43e35fea-d581-45df-8025-87506ab27e83/6fb4e1214127812e


個人的意見

個人的には重要論点は3つ


1. 中間圧縮することは有っても良いけど、方法がマズイ

HTTPgzip圧縮とか標準仕様にしたがってやる分には、アプリレイヤーに対して悪影響もないし問題ないけど、非可逆圧縮っていうのは無理筋

どうしてもやるなら、標準のパケット交換サービスに組み込むのではなく、オプションなり、安い別サービスなりにするべき。

サービス土管やるなら良いけど、土管勝手に余計なサービスするのは・・・・


2. 「通信最適化」をやるなら、不動産などの契約における重要事項説明と同等のレベルで「明確な個別同意」をとるべき

これがきちんとしているならそもそも通信の秘密を犯すことにはならないはず。


3. 不可逆圧縮はどのレイヤーであっても勝手にやってはならない

サービス提供者の意図、あるいはユーザー意図によってやる分にはレイヤーという意味ではアプリの層で圧縮することは正しい

・・・が、通信経路中のサービス提供者も、ユーザーも感知しないところで勝手にやるのはいけない

通信当事者では無いキャリア勝手にやることは通信の秘密を侵すいわゆる検閲でしかなく、正当業務行為としての違法性阻却事由にも合致しない


■各問題点についての整理


1. 品質劣化問題


重要論点はあまり無く、あまりに自明問題なので詳細は省略


2. サービスへの干渉問題


下記の案件で実際にサービスに悪影響発生しており、単なる懸念ではなく現実問題となっている


スマホゲーム不具合、原因はソフトバンク画像圧縮 ? すまほん!!

http://smhn.info/201506-softbank-assyuku?utm_source=dlvr.it&utm_medium=twitter


たとえば、アプリで利用するデータについてダウンロード後にCRCなどのハッシュによる破損、改変のチェックを行うようなアプリ場合、「通信最適化」で非可逆圧縮された場合当然ハッシュも変わってしまうためエラーが発生する

上記のアプリ場合、まさにこのパターン問題が起こっている


また、技術的な詳細が不明適用条件が不明な点についても問題である


3. 通信の秘密への侵害問題


まずはこちらを見てもらう


ソフトバンク、「通信最適化」は『正当業務行為』。解除不可 - Engadget Japanese

http://japanese.engadget.com/2015/07/15/softbank/


ソフトバンクによると「通信最適化」は「正当業務行為」とのことだが、この「正当業務行為」とはどういうことだろうか?

刑法では定められたいくつかの「違法性阻却事由」が定められている。

これは、たとえ違法行為であっても、当該の違法性否定する事由に合致する場合例外的違法行為であっても、違法性否定するという「違法性阻却事由」に合致するため違法ではないというロジックである

これは「通信の秘密」に対しては「正当業務行為」「正当防衛」「緊急避難」の三つが適用できると想定されている。


しかし、なにが「正当業務行為」に該当するかについては 帯域制御の運用基準に関するガイドライン などで3つの要件が示されている


帯域制御の運用基準に関するガイドライン

http://www.jaipa.or.jp/other/bandwidth/


(1). 目的正当性(帯域制御実施する目的ISP 等の業務内容に照らして正当なものであること)

(2). 行為必要性(当該目的のために帯域制御を行う必要性があること)

(3). 手段の相当性(帯域制御方法等が相当なものであること)


この全てに合致するかどうかは議論があり下記サイトなどが詳しい


ソフトバンクの「通信最適化」の適法性ロジックを突き崩す方法。 ? すまほん!!

http://smhn.info/201507-softbank-tuusin-no-saitekika-ihou?utm_source=dlvr.it&utm_medium=twitter


なお、本来ルータなど機械的な処理により、人の手による監視がない場合であっても通信の秘密侵害したことには変わりはないとされている。

そのため、ISPの業務の多くは通信の秘密侵害しているとされている。

ただし、「当事者同意」がある場合、「正当業務行為」として「違法性阻却事由」に合致する場合のいずれかを満たすため業務を行うことが出来ている。


また、通信の秘密への侵害回避する方法としてはもう一つユーザによる「当事者同意」というものもある

こちらは、たとえばSPAMメール隔離サービスなど、明らかに「通信の秘密」を犯す場合であっても、当事者の一方が「明確な同意」をしている場合には、同意に沿ってメールの中身を見ることができたりする。

ドコモauロジックとしてはこちらを採用しており、ユーザによる「個別かつ明確な同意」をとってあると強弁している。


しかし、「個別かつ明確な同意」というのはいわば重要事項説明のようなものであり、単に規約に書いてあるからOKといったものではないとされている。

いわば、「オプトイン」相当の意思の表示が必要とも・・・


4. ネットワーク中立性に反する問題


まとめ切れなかったので省略


5. 著作権侵害問題


同一性保持権著とは著作権における作者人格権の一種であり、著作物に対して著作者の意に反して変更、切除その他の改変を禁止することができる権利のことで、今回の「通信最適化」においては、画像ファイルに対し非可逆圧縮を行いしかも品質劣化が起こっているという時点で権利を侵していることはほぼ自明であるといって問題ないと思われる。

ただ、親告罪なので権利の主張をしなければ無視することも出来るし、仮に権利の主張をしたとしても裁判を経て権利を認めてもらう必要がありハードルが高い



6. その他


まとめ切れなかったので省略

KoichiYasuokaKoichiYasuoka 2015/07/16 23:07 私が http://srad.jp/~yasuoka/journal/594142 で提示した法律的論点は、問題点の議論の中には入れてもらえなかったのですね。ちょっと残念です。

narusasenarusase 2015/07/22 02:05 なるほど、そのような問題もあるのですね・・・ いかんせん、アンテナが低いもので突っ込んだ法律談義までは受信できませんでした(笑