パスワードを忘れた? アカウント作成
12069883 story
インターネット

RFC 7540「Hypertext Transfer Protocol Version 2(HTTP/2)」がリリースされる 60

ストーリー by hylom
ついに登場 部門より

RFC 7540「Hypertext Transfer Protocol Version 2(HTTP/2)」が公開された。

HTTP/2はHTTPの新規格で、今年2月に、Internet Engineering Task Force(IETF)による承認が完了していた。Google ChromeやFirefoxなどではすでにHTTP/2のサポートが進められている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  •  HTTP/2 は Google の SPDY がもとになるなど、RFC制定にもGoogleが関わっている、Googleの陰謀ともいえる規格です。実は、HTTP/2 の 広告ブロックが困難というか事実上不可能になるというデメリット(Googleにとっては最大限のメリットであることから)が隠されています。Google は 表向きはユーザのプライバシーを理由に TLS 化を推進していますが、裏に広告ブロックを妨害したいという陰謀が隠れていると思います。

     

     まず、Microsoft が反対したこともあって RFC では TLS は必須とはなりませんでしたが、Chrome と Firefox(Firefox の最大のスポンサーは残念なことに Google です)の実装においては TLS 必須のため、事実上 HTTP/2 では TLS が必須ですから、プロキシやVPN(Android における広告ブロックによく用いる仮想VPNを含む)等による広告ブロックが完全にできなくなります。勿論、広告配信サーバのIPアドレスが違えばできますが、高速化という名目のもと Google Adsense のコードを php などにして、コンテンツと同一のサーバから送信するようにすれば(コンテンツを提供する Webサーバが Google の広告サーバと通信する形式にする)通信内容の書き換えによる広告ブロックが完全にできなくなります(HTTP/2 の速度向上効果は同一サーバからのデータ送信の方が高いという大義名分があります)。

     

     そして、今までの HTTP 1.1 では、まず html ファイルを取得して、それからクライアントが画像なり JavaScript 外部ファイルなりをリクエストする形式でしたが、HTTP/2 ではサーバプッシュ (RFC 7540 - 8.2. Server Push) という機能があり、サーバ側が html ファイルと同時に画像なり JavaScript 外部ファイルなりを一方的にまとめてバイナリ形式で送り付けることが可能です。これにより、広告画像・広告JavaScriptを受信しないことができなくなります。ブラウザのプラグインで広告を非表示にしたとしても、広告データを受信して無駄な通信が発生することを回避できないのです。広告ブロックを導入している環境で Webブラウジング(動画鑑賞を除く)のみで 所謂7GB制限に引っかかっている人は、HTTP/2 の世界においてはその10分の1以下のWebページしか見ることができなくなるでしょう(例えば、スラドの1ページあたりの通信量のうち、大部分は広告の通信です)。勿論、既にキャッシュしているファイルのサーバプッシュを拒否することはできますが、初めてアクセスするサイトではファイル名等が分からないので不可能ですし、広告画像等のファイル名等をランダムな文字列にするなどで、サーバプッシュ拒否を完全に妨害することができます。

     

     次に問題となるのは、プライバシー上の問題です。サーバプッシュ (RFC 7540 - 8.2. Server Push) 機能で既にブラウザがキャッシュしている画像等を再送信することを防ぐため、クライアント側は既にキャッシュしているファイルの一覧をサーバに送信することになりますが、ファイル名等をランダムにすることで Cookie を無効にしていてもユーザをトラッキングすることが容易にできてしまいます。まぁ、今でも Cookie 無しでトラッキングする方法は山のようにありますから、それが1つ増えただけのことで、これについてはたいした問題はないかもしれません。

    • サーバ側が html ファイルと同時に画像なり JavaScript 外部ファイルなりを一方的にまとめてバイナリ形式で送り付けることが可能です。これにより、広告画像・広告JavaScriptを受信しないことができなくなります。

      現在は、ほとんどが広告プラットフォームによる広告配信だと思いますが、このような、別ドメイン・別サーバによる広告データの配信でもサーバプッシュできるのでしょうか。

      親コメント
    • by Anonymous Coward

      未だにHTTPSを使わないスラドは大丈夫でしょう。

      • by Anonymous Coward

        HTTP/2なんて話題をApache1.3が動いているサーバーで議論している違和感

        最新トレンドを全部追えとは言わないけど、どうにかならないの?
        少なくとも技術者系サイトとは思えないトレンドの低さ
        最新ネタとかやめて、PC9800シリーズとかの回顧記事を中心mに取り扱った方が身の丈にあってるかもしれませんね。

    • by Anonymous Coward

      >広告ブロックが困難というか事実上不可能になるというデメリット
      Googleだけが悪いっぽく言われてるけど、趣味も含めたサイト運営者の少しの足しになると思うけどなぁ。
      (広告以外のマネタイズするのが望ましいかもしれないけど)

      • by Anonymous Coward

        広告ブロックの定義にもいろいろあって、例えば、私はiframeをCSSで切っていますが、コンテンツはダウンロードしているはずです。単に表示されないだけなので。

      • by Anonymous Coward

        消費者が広告や帯域消費を受け入れたら、
        サイト主も広告主も儲かってより良いコンテンツが生まれるんだから、
        それくらいは我慢してあげてもいーじゃんと思うけどね。

        • by Anonymous Coward

          Amazonのおすすめシステムのように、正確かつ受け入れられやすい広告サジェストシステムであれば、ユーザーも拒否することはないでしょうが、見たくもない肌色成分多めの広告や下劣な広告を見せつけられていれば、こういう反応になるのが至極当然。
          それに、

          > サイト主も広告主も儲かってより良いコンテンツが生まれる

          のくだりがよく理解できないのですが。儲かれば(運営者に収入が発生すれば)、必ずより良いコンテンツが生まれますかね?そもそも、広告収入を受けているサイトが良いコンテンツを提供している、という前提が間違っているのではないでしょうか。

          • >儲かれば必ずより良いコンテンツが生まれますかね?

            必ず生まれますよ。

            世の中の良いコンテンツを作っている人の大多数はそれで儲けようとしていた人です。
            良い仕事をする人の殆どは職業としてそれをやっています。
            お店は儲けようとして良い商品を用意するんです。
            サイトは設けようとして良いコンテンツを作るんです。

            良いコンテンツを作ろうとせずに良くなってしまうのは極まれです。
            作ろうというモチベーションは大体が報酬を得るためなのです。

            親コメント
            • by Anonymous Coward

              芸術等では手弁当でとにかく自分の作りたい(良い)物を作ろうとする人もいるので、「適切な対価が得られる方が継続して良いものを作りやすい」、「収入があればコンテンツ制作で機材・資材・資料集めに費用をかけられる」の2点を追加してもらったほうが分かりやすい気がします。

              >世の中の良いコンテンツを作っている人の大多数はそれで儲けようとしていた人です。
              >良い仕事をする人の殆どは職業としてそれをやっています。
              >サイトは設けようとして良いコンテンツを作るんです。

              >良いコンテンツを作ろうとせずに良くなってしまうのは極まれです。
              >作ろうというモチベーションは大体が報酬を得るためなのです。

            • by Anonymous Coward

              大筋の考えは同意するところだけど、そこまで強く肯定できる程の真理ではないと思う。

               

              スマホゲーや、このサイトのストーリーの採用傾向にも感じることなのだが、
              最近はとにかく人を集める事を是とし、徒に利用者の情を煽って利益を捻り出そうとする事例が目立つ。
              良いか悪いかで言って、良いものと言えないものでも利益は生成できる現実があり、
              殊に広告主が抽象化された報酬システムでは、雇い主への配慮を鑑みずに下劣な内容でページビューを稼ぐ手法が珍しくない。

               

              あるいはページビューを稼げるものを「良いもの」と定義する人もいるだろうが、一般の感性と必ずしも一致するものではないだろう。

          • by Anonymous Coward

            >Amazonのおすすめシステムのように、正確かつ受け入れられやすい広告サジェストシステムであれば、ユーザーも拒否することはないでしょうが

            いいえ、そのためにトラッキングをすると「プライバシーが-」と文句を言われます。
            相手の行動様式や興味対象が判ればサジェストも可能ですが、現状ではそれはそれで否定されてしまうわけです。

            >のくだりがよく理解できないのですが。儲かれば(運営者に収入が発生すれば)、必ずより良いコンテンツが生まれますかね?そもそも、広告収入を受けているサイトが良いコンテンツを提供している

          • by Anonymous Coward

            広告設置してるなら金が欲しいってことだろうから普段から利用しているサイトが邪魔にならない程度に広告設置するのならなんら問題ないです。
            なんでもかんでもただで利用できて当然だって思ってません?

        • by Anonymous Coward

          自分もそう思う。そこまで必死に拒絶しないといけないものじゃないでしょう。何かを作るには費用が掛かるのだし。

    • by Anonymous Coward

      TLSを使ってるからってプロキシでブロックできなくなるわけじゃないでしょ
      プロキシで生成したCA証明書をブラウザにインストールして中間者攻撃って方法もあるわけだし

      • by Anonymous Coward

        > プロキシで生成したCA証明書をブラウザにインストールして中間者攻撃って方法もあるわけだし
        スマートフォンではわからんがPCではLenovo事件の反応を見るに許されることじゃないでしょ

    • by Anonymous Coward

      別に広告垂れ流すのは構わんけど、もっと通信量を抑えろといいたい。
      通信料が増えれば増えるほどISPやキャリア側の負担が重くなるんだぞ。

      • by Anonymous Coward

        Google は得てして通信量の増大には無頓着ですからなぁ。
        Android 使っていて、通信量の上位が片っ端から Google アプリ(しかも多くがバックグラウンド通信)ってのはよくある話。

    • by Anonymous Coward

      何がそんなに憎いかわからんが広告は悪ではないよ
      広告を悪用するやつが悪なんだけどな

      #それに受信しても見ない方法はいくらでもあるじゃん

    • by Anonymous Coward

      世に中に溢れてる大半のIEは対応していないのでこんな企画でっちあげても使われることはないかと

    • by Anonymous Coward

      >広告ブロックを導入している環境で Webブラウジング(動画鑑賞を除く)のみで 所謂7GB制限に引っかかっている人

      一体どんなサイトを見たらそうなるのか知りたい。
      しかも動画抜き、って・・・

    • by Anonymous Coward

      > 高速化という名目のもと Google Adsense のコードを php などにして、コンテンツと同一のサーバから送信するようにすれば(コンテンツを提供する Webサーバが Google の広告サーバと通信する形式にする)通信内容の書き換えによる広告ブロックが完全にできなくなります

      これをされたら 1.1 で通信しててもブロックできないと思うけど、最近の広告ブロックはウィルススキャン並みにファイル解析処理を行って判定してるの?

        1. これをされたら 1.1 で通信しててもブロックできないと思うけど、最近の広告ブロックはウィルススキャン並みにファイル解析処理を行って判定してるの?

        HTTP 1.1 であれば、普通にブロックできます。

         

        JavaScript の広告コードはこんな感じです。この場合、"googlesyndication.com" というドメインの JavaScript のロードを阻止することで、広告の読み込み(受信)をブロックができます。

         

        <!-- 広告ここから -->
        script type="text/javascript"><!--
        google_ad_client = "ca-pub-0123456789012345";
        google_ad_slot = "0123456789";
        google_ad_width = 300;
        google_ad_height = 250;
        //-->
        </script>
        <script type="text/javascript"
        src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
        </script>
        <!-- 広告ここまで -->

         

        そして、サーバサイドで広告コードをhtml化して注入するシステムだと、下記のような感じのHTMLソースになります。その場合は、広告画像がコンテンツと同一のサーバから配信される仕組み (サーバサイドスクリプトでGoogleの広告サーバから受信したものを配信) であっても、広告クリック時のリンク先はサイト管理者がクリック数を不正に増やすことを防止するためにGoogleのドメインになるでしょうから、広告ブロッカーはa要素のhref属性に "googlesyndication.com" が含まれていた場合、a要素に包括されるimg要素を含めて受信をブロックします。

         

        <!-- 広告ここから -->
        <a href="http://pagead2.googlesyndication.com/pagead/jump.cgi?id=987654321&amp;from=http://it.srad.jp/story/15/05/18/054217/&amp;client=ca-pub-0123456789012345">
        <img src="http://it.srad.jp/google-adsystem/show-ad.php?id=mi39ha3a">
        </a>
        <!-- 広告ここまで -->

         

        しかし、HTTP/2 のサーバプッシュで広告画像とコンテンツhtmlをまとめてバイナリデータとして送信する仕組みにしてしまえば、広告ブロッカーで広告を非表示にしたとしても、広告データの受信を阻止することができなくなり、広告ブロッカーを導入するメリットが半減することになり(邪魔な広告を見たくないという要求を満たすことはできるが、通信量を減らしたりページのロードを早くしたりしたいといった要求を満たすことができなくなる)、広告ブロッカーの導入率を下げることができます。

         

        ちなみに、最近の広告配信システムではサイト管理者がページに貼り付けるコードが JavaScript なのが一般的ですが、昔の広告配信システムでは Perl や php のコードが用いられているところも結構ありました。

        特に i-mode などのモバイル向けでは、100% サーバサイドスクリプトでした(JavaScript 非対応端末が一般的であったため)。

        従って、HTTP/2 が普及したら、広告表示の高速化と、広告ブロック妨害(サーバプッシュの利用)の為、昔のようにサーバサイドスクリプトの広告コードに戻る可能性もあると思います。

        親コメント
        • by Anonymous Coward

          2番目の例だとhtmlをパースした後でないとブロックできないから,imgをBASE64に変換されて埋め込まれたら,現状でも対応できない。

          こんな議論は pgp/gpg や s/mine の暗号メールにおけるスパムでも議論がありましたが,暗号メールはなかなか普及しないな。

    • by Anonymous Coward

      JS殺すことで通信料低下と表示速度向上してる私にとってきついんだよなあ。数倍違うんで。

      でもま、最大の欠点はセキュリティじゃないかな。
      data-uriもそうだったけどね。

    • by Anonymous Coward

      AdBlockはブラウザがページをデコードした結果に介入しているのだから普通にブロックできますが。
      むしろ中間の土管にそんな介入許すほうが恐ろしい。広告をブロックできるということは自社の広告に差し替えもできるということ

  • by Anonymous Coward on 2015年05月18日 16時09分 (#2816266)

    自宅やVPSに立てた自前の串なりVNCなりで対応可能かも
    sshトンネルで張れば経路も安全になるし

    一般民は泣き寝入りかもしくは
    同様のサービスをキャリアが有料化して
    提供側Win-Win(ウマウマ)になるかもしれませんね

    # 手がないのは手が見えないだけなのかも

    • by Anonymous Coward

      モバイルの通信量減らしたいなら
      よく見るサイトからコンテンツ引っこ抜いて整形するサーバ立てるのがよいかもね
      ラズパイとかの低消費電力サーバ使えばランニングコストもあまりかからないし

      #ちょうどKobo用にそういうサーバ作ってるところ

  • by Anonymous Coward on 2015年05月18日 17時22分 (#2816310)

    ブラウザアドオンが使えるなら、指定サーバには強制的にHTTP1でアクセスさせるようにすればいいのでは

    • by Anonymous Coward

      NSS(Firefox)やBoringSSL(Chrome)の実装レベルでそういうドメイン指定でのHTTP/2、1.1の切り替え機能が存在しない限りは無理

      • by Anonymous Coward

        NSSやBoringSSLはTLS(トランスポート層かセッション層)の実装で、その上のアプリケーション層がどんなプロトコルを使っているかなど知ったことではないのだがいったい何言ってるの

  • by Anonymous Coward on 2015年05月18日 20時01分 (#2816388)

    Don't be evilはどこへいったんでしょうかね?

    • 多分、

      We're not evil.
      We're simply careless.

      と答えるんじゃないかな…
      (Careless about not being evil..)

      --
      fjの教祖様
      親コメント
    • by Anonymous Coward

      単に「Googleのやってることだからevilに決まってる」って馬鹿が騒いでるだけじゃん

    • by Anonymous Coward

      スローガンってのは,「実際はそうじゃない」ときに使われる,とよく聞くなあ…

      # 清廉潔白,という単語が一番使われるのは政治の世界だと思うww そりゃないぜセニョリータ.

  • by Anonymous Coward on 2015年05月18日 20時47分 (#2816415)

    こんなばかばかしい陰謀論が「スコア:5, 参考になる」だったり
    そこにぶら下がってるべきコメントがルート直下になってたり
    もう目茶苦茶だな…

  • by Anonymous Coward on 2015年05月19日 10時22分 (#2816739)

    HTTP/2がだめなら、HTTP/1.1にフォールバックすればいいじゃない。
    同時接続数は1で結構です。それがだめな鯖は用がないですたぶん。

    まあ、なんだかんだでHTTP/2対応串がオプソで出るでしょうけど。
    顔本からおあつらえ向けなライブラリ出てましたよね。
    このくらいの車輪は演習として自作にしようと思って未評価なんですけど。

typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...