「通信の最適化」の論点

論点書き出してみたけど多すぎて超絶カオス。

  • 現状発生している実害
  • 技術的詳細が非公開
  • 「最適化」という単語の是非
  • オプトインとオプトアウト
    • 送信者(コンテンツ提供者)の同意
      • 自衛のために全HTTPS化することで、かえってトラフィック増える問題
      • HTTPS化による計算機コスト、ファイル改竄による不具合対応のリスクの負担
      • サービス内容の意図しない/再現が難しい劣化*1
        受信者の財産権の侵害とも言える。
    • 受信者(顧客)の同意
      • 消費者保護観点からより深い内容周知の上での同意が必要では無いか
    • オプトアウトが可能かどうか
  • ISPとしてのサービスが土管であるべきか否か
    • 例えば、可逆圧縮での再圧縮なら良かったのかどうか
    • 携帯キャリアが提供しているのは「インターネット」サービスかどうか
  • ISPとしての正当業務行為に含まれるかどうか (以下の各種法令における違法性阻却事由)
  • アプリケーションレベルで内容を見ることが「通信の秘密」に触れるか否か
    • DPIè­°è«–
    • 帯域制御の運用基準に関するガイドライン
      • 帯域制御を目的するか否か
      • 「個別かつ明確な同意」があったかどうか
    • 電気通信事業法第四条
      • 特に「符号、音響又は影像」で音響と映像が切り出されていることの解釈
  • アプリケーションレベルで内容を変更することが「検閲の禁止」に触れるか否か
  • 著作権 (同一性保持権)
  • 公職選挙法
    • 「候補者のウェブサイトの改ざん等、選挙に関し、文書図画を毀棄し、その他不正の方法をもって選挙の自由を妨害」*2

判断ポイント

  • オプトアウトができれば良いのか
  • デフォルトoffで明確な利用者(端末契約者)のオプトインがあれば良いのか
  • 可逆圧縮での再圧縮なら良いのか
  • HTTPレスポンス本文のデコード結果を改変しないレベルなら良いのか
    • 例: HTTPレスポンスをTransfer-Encoding: gzip(delfate)にして圧縮する
    • 例2: HTTP/1.1のpersistent connectionã‚„pipeliningで接続をまとめる
  • HTTPレスポンス本文は変更せずヘッダの改変だけなら良いのか
    • 例: Content-Length外してchunkにする

  • ＜トランスポート層の壁＞

  • TCPの再構成だけなら良いのか
  • パケットのフラグメント再構成*3なら良いのか

  • ＜極論の壁＞

  • NAPTに必要なTCP/UDPのポート番号変更以外の全てのIPパケットペイロードの変更を禁じるのか(インターネット原理主義者)
  • NAPTも禁止し、IPパケットヘッダ以外の全ての変更を禁じるのか(真のInternet Protocol原理主義者)

*1:とくにニコニコ動画など「画質」によるフリーミアムモデルを採用している場合

*2:http://twitter.com/kei1_yama/status/624094538659860480

*3:例: PFのscrub