「通信の最適化」問題の論点まとめ
注意：
途中で力尽きました、ぜんぜんまとめきれてません･･･orz
○通信の最適化とは
いわゆる3大キャリアを中心に、MVNOなども含む非wifi通信時(いわゆるLTEなど)におこなわれる、画像、動画等に対する非可逆圧縮のこと
○問題点
問題点としては複数あり、主に下記のように類型化できると思われる
1. 品質劣化の問題
各サービス提供者もしくはユーザーの意図に反する形で(あるいは基づかない形で)、画像等に対する非可逆圧縮をおこない品質劣化をおこしている点
2. サービスへの干渉の問題
一部のアプリにおいて「通信の最適化」によりアプリを起動できないなどの問題が発生し、各サービス提供者およびユーザーに不利益を与えている点
3. 通信の秘密への侵害の問題
ユーザによる「明確な同意」に基づかずにおこなっており、いいわゆる電気通信事業法 および 日本国憲法 における「通信の秘密」を侵しており、盗聴や検閲に相当する点
4. ネットワーク中立性に反する問題
インターネットのユーザーが自分が見るコンテンツや使用するアプリケーションを自分で選択できるべきだとするネットワーク中立性の考え方に反する点
5. 著作権の侵害の問題
画像等の非可逆圧縮をおこなうことから著作権における同一性保持権を侵害している点
6. その他
○通信の最適化はどのように実現されるか
ドコモ、au、Softbank、その他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/
・過去に「通信の最適化」されていた可能性があるかどうか
これまでの報告によると、ドコモ、au、Softbank、BIGLOBE、b-mobile、U-mobile、ぷららモバイルLTE、DTIなどで「通信の最適化」が報告されています
「通信の最適化」、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氏「日本の通信事業者よりAppleやFacebook, 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. 中間で圧縮することは有っても良いけど、方法がマズイ
HTTPのgzip圧縮とか標準仕様にしたがってやる分には、アプリのレイヤーに対して悪影響もないし問題ないけど、非可逆圧縮っていうのは無理筋
どうしてもやるなら、標準のパケット交換サービスに組み込むのではなく、オプションなり、安い別サービスなりにするべき。
サービスが土管やるなら良いけど、土管が勝手に余計なサービスするのは････
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. その他
まとめ切れなかったので省略
