アカウント名:
パスワード:
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を受信しないことができなくなります。
現在は、ほとんどが広告プラットフォームによる広告配信だと思いますが、このような、別ドメイン・別サーバによる広告データの配信でもサーバプッシュできるのでしょうか。
なるほど非表示は可能なので最大の問題はモバイル端末での受信なのか。とはいえiPhoneでの広告ブロックは現状一般的とは思えないので、テザリングで使用する場面だろうか。PC用の大サイズ広告を拒否できないのは確かに困る。
やりたければ、サーバにリバースプロキシを設定するだけで出来る。
広告ブロック対策をやりたくて、そのためだけに掲載側サーバに手を加えることをアリとするなら、現状でもやりようはあると思うんです。ドメインでブロック判定をするものなら、それこそリバースプロキシで掲載側ドメインのものとしちゃえばいいわけで。なんなら、掲載ページのhtmlファイルに直接書き込んじゃってもいい。
未だにHTTPSを使わないスラドは大丈夫でしょう。
HTTP/2なんて話題をApache1.3が動いているサーバーで議論している違和感
最新トレンドを全部追えとは言わないけど、どうにかならないの?少なくとも技術者系サイトとは思えないトレンドの低さ最新ネタとかやめて、PC9800シリーズとかの回顧記事を中心mに取り扱った方が身の丈にあってるかもしれませんね。
>広告ブロックが困難というか事実上不可能になるというデメリットGoogleだけが悪いっぽく言われてるけど、趣味も含めたサイト運営者の少しの足しになると思うけどなぁ。(広告以外のマネタイズするのが望ましいかもしれないけど)
広告ブロックの定義にもいろいろあって、例えば、私はiframeをCSSで切っていますが、コンテンツはダウンロードしているはずです。単に表示されないだけなので。
それブロックって言わない
消費者が広告や帯域消費を受け入れたら、サイト主も広告主も儲かってより良いコンテンツが生まれるんだから、それくらいは我慢してあげてもいーじゃんと思うけどね。
Amazonのおすすめシステムのように、正確かつ受け入れられやすい広告サジェストシステムであれば、ユーザーも拒否することはないでしょうが、見たくもない肌色成分多めの広告や下劣な広告を見せつけられていれば、こういう反応になるのが至極当然。それに、 > サイト主も広告主も儲かってより良いコンテンツが生まれる のくだりがよく理解できないのですが。儲かれば(運営者に収入が発生すれば)、必ずより良いコンテンツが生まれますかね?そもそも、広告収入を受けているサイトが良いコンテンツを提供している、という前提が間違っているのではないでしょうか。
>儲かれば必ずより良いコンテンツが生まれますかね?
必ず生まれますよ。
世の中の良いコンテンツを作っている人の大多数はそれで儲けようとしていた人です。良い仕事をする人の殆どは職業としてそれをやっています。お店は儲けようとして良い商品を用意するんです。サイトは設けようとして良いコンテンツを作るんです。
良いコンテンツを作ろうとせずに良くなってしまうのは極まれです。作ろうというモチベーションは大体が報酬を得るためなのです。
芸術等では手弁当でとにかく自分の作りたい(良い)物を作ろうとする人もいるので、「適切な対価が得られる方が継続して良いものを作りやすい」、「収入があればコンテンツ制作で機材・資材・資料集めに費用をかけられる」の2点を追加してもらったほうが分かりやすい気がします。
>世の中の良いコンテンツを作っている人の大多数はそれで儲けようとしていた人です。>良い仕事をする人の殆どは職業としてそれをやっています。>サイトは設けようとして良いコンテンツを作るんです。
>良いコンテンツを作ろうとせずに良くなってしまうのは極まれです。>作ろうというモチベーションは大体が報酬を得るためなのです。
大筋の考えは同意するところだけど、そこまで強く肯定できる程の真理ではないと思う。
スマホゲーや、このサイトのストーリーの採用傾向にも感じることなのだが、最近はとにかく人を集める事を是とし、徒に利用者の情を煽って利益を捻り出そうとする事例が目立つ。良いか悪いかで言って、良いものと言えないものでも利益は生成できる現実があり、殊に広告主が抽象化された報酬システムでは、雇い主への配慮を鑑みずに下劣な内容でページビューを稼ぐ手法が珍しくない。
あるいはページビューを稼げるものを「良いもの」と定義する人もいるだろうが、一般の感性と必ずしも一致するものではないだろう。
本当に生まれますか?hymlaが全うに仕事するなら喜んでスラドの広告ブロックを解除しますよ?
っていうスラド民はごまんと居るだろう
万人に同一の評価が下る筈もないのに「必ず」と言い切るその自信に驚きを禁じえない
AKB好き?ボカロ好き?アニソン好き?演歌好き?J-POP好き?K-POP好き?儲かって昇華したコンテンツがどれほどあるかな?すべてが昇華したと言い切れるかな?
これは流石に、「馬鹿なの?」としか言いようがない。アフィリエイトで運営されているデマサイト、パクリサイト、悪意ある誤報を広めるサイトの類は、「サイト主も広告主も儲かって、より悪いコンテンツを生み続ける」現実の事例です。
良い仕事をする人の殆どは職業としてそれをやっています。
悪い仕事をする人だって、職業としてやっているのは同じです。むしろ、「良い仕事には原価が掛かる、原価を掛けずに良い仕事と同じかそれ以上に儲けるためにはどうすれば?」と知恵を絞ってるのが世間のスタンダード(世間の商売人の多数派)です。
>Amazonのおすすめシステムのように、正確かつ受け入れられやすい広告サジェストシステムであれば、ユーザーも拒否することはないでしょうが
いいえ、そのためにトラッキングをすると「プライバシーが-」と文句を言われます。相手の行動様式や興味対象が判ればサジェストも可能ですが、現状ではそれはそれで否定されてしまうわけです。
>のくだりがよく理解できないのですが。儲かれば(運営者に収入が発生すれば)、必ずより良いコンテンツが生まれますかね?そもそも、広告収入を受けているサイトが良いコンテンツを提供している
広告設置してるなら金が欲しいってことだろうから普段から利用しているサイトが邪魔にならない程度に広告設置するのならなんら問題ないです。なんでもかんでもただで利用できて当然だって思ってません?
自分もそう思う。そこまで必死に拒絶しないといけないものじゃないでしょう。何かを作るには費用が掛かるのだし。
TLSを使ってるからってプロキシでブロックできなくなるわけじゃないでしょプロキシで生成したCA証明書をブラウザにインストールして中間者攻撃って方法もあるわけだし
> プロキシで生成したCA証明書をブラウザにインストールして中間者攻撃って方法もあるわけだしスマートフォンではわからんがPCではLenovo事件の反応を見るに許されることじゃないでしょ
へ?それはLenovoがユーザーに黙ってやったから問題になったのであって、自分でやる分には、すくなくともLenovo事件と同様の問題にはならないでしょ。
別に広告垂れ流すのは構わんけど、もっと通信量を抑えろといいたい。通信料が増えれば増えるほどISPやキャリア側の負担が重くなるんだぞ。
Google は得てして通信量の増大には無頓着ですからなぁ。Android 使っていて、通信量の上位が片っ端から Google アプリ(しかも多くがバックグラウンド通信)ってのはよくある話。
何がそんなに憎いかわからんが広告は悪ではないよ広告を悪用するやつが悪なんだけどな
#それに受信しても見ない方法はいくらでもあるじゃん
世に中に溢れてる大半のIEは対応していないのでこんな企画でっちあげても使われることはないかと
まあ、Win10 / IE11 or Edgeからってのは確かですが(そっちはPUSH対応してそうっぽい...)、それ言ってもしょうがない気が。
# Push Promiseは帯域的とかよりは、クライアント側からNAKすれば(予約を通知されたストリームIDでの応答でリセットかける)とか# たとえ押しこまれてもレンダリングしないはあるよな、とかもうちょっとやりようはありそう# すくなくとも完全に無理矢理ではない気がする。
そもそもアドサーバと本サーバが同じ(or リダイレクト的にあれこれする設定がされてる)とか本格的にアレじゃないとこの想定は機能しないような
>広告ブロックを導入している環境で Webブラウジング(動画鑑賞を除く)のみで 所謂7GB制限に引っかかっている人
一体どんなサイトを見たらそうなるのか知りたい。しかも動画抜き、って・・・
2ch全体をクロールでもしてるのかなぁ…
Facebookとか写真貼りまくる人がいると結構ヤバイですね。
スマホでTumblrのダッシュボード見てると、1時間で100MBくらい行ってますね。gifアニメは入ってるけどいわゆる動画鑑賞は無しで。モバイル回線しか無かったら、7GB超えてるでしょう。
> 高速化という名目のもと Google Adsense のコードを php などにして、コンテンツと同一のサーバから送信するようにすれば(コンテンツを提供する Webサーバが Google の広告サーバと通信する形式にする)通信内容の書き換えによる広告ブロックが完全にできなくなります
これをされたら 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&from=http://it.srad.jp/story/15/05/18/054217/&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 が普及したら、広告表示の高速化と、広告ブロック妨害(サーバプッシュの利用)の為、昔のようにサーバサイドスクリプトの広告コードに戻る可能性もあると思います。
2番目の例だとhtmlをパースした後でないとブロックできないから,imgをBASE64に変換されて埋め込まれたら,現状でも対応できない。
こんな議論は pgp/gpg や s/mine の暗号メールにおけるスパムでも議論がありましたが,暗号メールはなかなか普及しないな。
a タグを解析してブロックするだけだと、img タグに JavaScript で、onclick で飛ぶようにリスナー追加するだけで回避されてしまうような。
あるいは、必要な画像に広告リンクを貼って、ブロックするとまともに見れなくするとか。
まぁでも自分のサイトから広告を送出するとになると、帯域の問題もあるからそんなに酷いことにならない予感。(Google が全サイトに CDN を無料提供とかすれば別だけど)
JS殺すことで通信料低下と表示速度向上してる私にとってきついんだよなあ。数倍違うんで。
でもま、最大の欠点はセキュリティじゃないかな。data-uriもそうだったけどね。
AdBlockはブラウザがページをデコードした結果に介入しているのだから普通にブロックできますが。むしろ中間の土管にそんな介入許すほうが恐ろしい。広告をブロックできるということは自社の広告に差し替えもできるということ
わたしも,コンテンツの破棄や拒否といったブロックは,クライアント・サイドがやるべきことで,プロクシには触って欲しくないと考えている人間です。もし中間でやるとしても,ユーザと目的のサイトの間に挟むのは管理化にあるサーバになると思います。
最後に転送量の問題はのこりますが,あまりに多くの量をプッシュする広告は,ポップアップ広告のように淘汰されていくのではないかと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:5, 参考になる)
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つ増えただけのことで、これについてはたいした問題はないかもしれません。
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:3)
現在は、ほとんどが広告プラットフォームによる広告配信だと思いますが、このような、別ドメイン・別サーバによる広告データの配信でもサーバプッシュできるのでしょうか。
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:1)
なるほど非表示は可能なので最大の問題はモバイル端末での受信なのか。
とはいえiPhoneでの広告ブロックは現状一般的とは思えないので、テザリングで使用する場面だろうか。
PC用の大サイズ広告を拒否できないのは確かに困る。
Re: (スコア:0)
やりたければ、サーバにリバースプロキシを設定するだけで出来る。
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:2)
広告ブロック対策をやりたくて、そのためだけに掲載側サーバに手を加えることをアリとするなら、現状でもやりようはあると思うんです。
ドメインでブロック判定をするものなら、それこそリバースプロキシで掲載側ドメインのものとしちゃえばいいわけで。
なんなら、掲載ページのhtmlファイルに直接書き込んじゃってもいい。
Re: (スコア:0)
未だにHTTPSを使わないスラドは大丈夫でしょう。
Re: (スコア:0)
HTTP/2なんて話題をApache1.3が動いているサーバーで議論している違和感
最新トレンドを全部追えとは言わないけど、どうにかならないの?
少なくとも技術者系サイトとは思えないトレンドの低さ
最新ネタとかやめて、PC9800シリーズとかの回顧記事を中心mに取り扱った方が身の丈にあってるかもしれませんね。
Re: (スコア:0)
>広告ブロックが困難というか事実上不可能になるというデメリット
Googleだけが悪いっぽく言われてるけど、趣味も含めたサイト運営者の少しの足しになると思うけどなぁ。
(広告以外のマネタイズするのが望ましいかもしれないけど)
Re: (スコア:0)
広告ブロックの定義にもいろいろあって、例えば、私はiframeをCSSで切っていますが、コンテンツはダウンロードしているはずです。単に表示されないだけなので。
Re: (スコア:0)
それブロックって言わない
Re: (スコア:0)
消費者が広告や帯域消費を受け入れたら、
サイト主も広告主も儲かってより良いコンテンツが生まれるんだから、
それくらいは我慢してあげてもいーじゃんと思うけどね。
Re: (スコア:0)
Amazonのおすすめシステムのように、正確かつ受け入れられやすい広告サジェストシステムであれば、ユーザーも拒否することはないでしょうが、見たくもない肌色成分多めの広告や下劣な広告を見せつけられていれば、こういう反応になるのが至極当然。
それに、
> サイト主も広告主も儲かってより良いコンテンツが生まれる
のくだりがよく理解できないのですが。儲かれば(運営者に収入が発生すれば)、必ずより良いコンテンツが生まれますかね?そもそも、広告収入を受けているサイトが良いコンテンツを提供している、という前提が間違っているのではないでしょうか。
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:1)
>儲かれば必ずより良いコンテンツが生まれますかね?
必ず生まれますよ。
世の中の良いコンテンツを作っている人の大多数はそれで儲けようとしていた人です。
良い仕事をする人の殆どは職業としてそれをやっています。
お店は儲けようとして良い商品を用意するんです。
サイトは設けようとして良いコンテンツを作るんです。
良いコンテンツを作ろうとせずに良くなってしまうのは極まれです。
作ろうというモチベーションは大体が報酬を得るためなのです。
Re: (スコア:0)
芸術等では手弁当でとにかく自分の作りたい(良い)物を作ろうとする人もいるので、「適切な対価が得られる方が継続して良いものを作りやすい」、「収入があればコンテンツ制作で機材・資材・資料集めに費用をかけられる」の2点を追加してもらったほうが分かりやすい気がします。
>世の中の良いコンテンツを作っている人の大多数はそれで儲けようとしていた人です。
>良い仕事をする人の殆どは職業としてそれをやっています。
>サイトは設けようとして良いコンテンツを作るんです。
>良いコンテンツを作ろうとせずに良くなってしまうのは極まれです。
>作ろうというモチベーションは大体が報酬を得るためなのです。
Re: (スコア:0)
大筋の考えは同意するところだけど、そこまで強く肯定できる程の真理ではないと思う。
スマホゲーや、このサイトのストーリーの採用傾向にも感じることなのだが、
最近はとにかく人を集める事を是とし、徒に利用者の情を煽って利益を捻り出そうとする事例が目立つ。
良いか悪いかで言って、良いものと言えないものでも利益は生成できる現実があり、
殊に広告主が抽象化された報酬システムでは、雇い主への配慮を鑑みずに下劣な内容でページビューを稼ぐ手法が珍しくない。
あるいはページビューを稼げるものを「良いもの」と定義する人もいるだろうが、一般の感性と必ずしも一致するものではないだろう。
Re: (スコア:0)
本当に生まれますか?
hymlaが全うに仕事するなら喜んでスラドの広告ブロックを解除しますよ?
っていうスラド民はごまんと居るだろう
Re: (スコア:0)
万人に同一の評価が下る筈もないのに「必ず」と言い切るその自信に驚きを禁じえない
AKB好き?ボカロ好き?アニソン好き?演歌好き?J-POP好き?K-POP好き?
儲かって昇華したコンテンツがどれほどあるかな?すべてが昇華したと言い切れるかな?
Re: (スコア:0)
これは流石に、「馬鹿なの?」としか言いようがない。
アフィリエイトで運営されているデマサイト、パクリサイト、悪意ある誤報を広めるサイトの類は、
「サイト主も広告主も儲かって、より悪いコンテンツを生み続ける」現実の事例です。
良い仕事をする人の殆どは職業としてそれをやっています。
悪い仕事をする人だって、職業としてやっているのは同じです。むしろ、
「良い仕事には原価が掛かる、原価を掛けずに良い仕事と同じかそれ以上に儲けるためにはどうすれば?」
と知恵を絞ってるのが世間のスタンダード(世間の商売人の多数派)です。
Re: (スコア:0)
いいえ、そのためにトラッキングをすると「プライバシーが-」と文句を言われます。
相手の行動様式や興味対象が判ればサジェストも可能ですが、現状ではそれはそれで否定されてしまうわけです。
Re: (スコア:0)
広告設置してるなら金が欲しいってことだろうから普段から利用しているサイトが邪魔にならない程度に広告設置するのならなんら問題ないです。
なんでもかんでもただで利用できて当然だって思ってません?
Re: (スコア:0)
自分もそう思う。そこまで必死に拒絶しないといけないものじゃないでしょう。何かを作るには費用が掛かるのだし。
Re: (スコア:0)
TLSを使ってるからってプロキシでブロックできなくなるわけじゃないでしょ
プロキシで生成したCA証明書をブラウザにインストールして中間者攻撃って方法もあるわけだし
Re: (スコア:0)
> プロキシで生成したCA証明書をブラウザにインストールして中間者攻撃って方法もあるわけだし
スマートフォンではわからんがPCではLenovo事件の反応を見るに許されることじゃないでしょ
Re: (スコア:0)
へ?
それはLenovoがユーザーに黙ってやったから問題になったのであって、
自分でやる分には、すくなくともLenovo事件と同様の問題にはならないでしょ。
Re: (スコア:0)
別に広告垂れ流すのは構わんけど、もっと通信量を抑えろといいたい。
通信料が増えれば増えるほどISPやキャリア側の負担が重くなるんだぞ。
Re: (スコア:0)
Google は得てして通信量の増大には無頓着ですからなぁ。
Android 使っていて、通信量の上位が片っ端から Google アプリ(しかも多くがバックグラウンド通信)ってのはよくある話。
Re: (スコア:0)
何がそんなに憎いかわからんが広告は悪ではないよ
広告を悪用するやつが悪なんだけどな
#それに受信しても見ない方法はいくらでもあるじゃん
Re: (スコア:0)
世に中に溢れてる大半のIEは対応していないのでこんな企画でっちあげても使われることはないかと
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:1)
まあ、Win10 / IE11 or Edgeからってのは確かですが(そっちはPUSH対応してそうっぽい...)、それ言ってもしょうがない気が。
# Push Promiseは帯域的とかよりは、クライアント側からNAKすれば(予約を通知されたストリームIDでの応答でリセットかける)とか
# たとえ押しこまれてもレンダリングしないはあるよな、とかもうちょっとやりようはありそう
# すくなくとも完全に無理矢理ではない気がする。
M-FalconSky (暑いか寒い)
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:1)
そもそもアドサーバと本サーバが同じ(or リダイレクト的にあれこれする設定がされてる)とか本格的にアレじゃないとこの想定は機能しないような
M-FalconSky (暑いか寒い)
Re: (スコア:0)
>広告ブロックを導入している環境で Webブラウジング(動画鑑賞を除く)のみで 所謂7GB制限に引っかかっている人
一体どんなサイトを見たらそうなるのか知りたい。
しかも動画抜き、って・・・
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:1)
2ch全体をクロールでもしてるのかなぁ…
Re: (スコア:0)
Facebookとか写真貼りまくる人がいると結構ヤバイですね。
Re: (スコア:0)
スマホでTumblrのダッシュボード見てると、1時間で100MBくらい行ってますね。
gifアニメは入ってるけどいわゆる動画鑑賞は無しで。
モバイル回線しか無かったら、7GB超えてるでしょう。
Re: (スコア:0)
> 高速化という名目のもと Google Adsense のコードを php などにして、コンテンツと同一のサーバから送信するようにすれば(コンテンツを提供する Webサーバが Google の広告サーバと通信する形式にする)通信内容の書き換えによる広告ブロックが完全にできなくなります
これをされたら 1.1 で通信しててもブロックできないと思うけど、最近の広告ブロックはウィルススキャン並みにファイル解析処理を行って判定してるの?
広告ブロッカーは結構賢い (スコア:2)
HTTP 1.1 であれば、普通にブロックできます。
JavaScript の広告コードはこんな感じです。この場合、"googlesyndication.com" というドメインの JavaScript のロードを阻止することで、広告の読み込み(受信)をブロックができます。
そして、サーバサイドで広告コードをhtml化して注入するシステムだと、下記のような感じのHTMLソースになります。その場合は、広告画像がコンテンツと同一のサーバから配信される仕組み (サーバサイドスクリプトでGoogleの広告サーバから受信したものを配信) であっても、広告クリック時のリンク先はサイト管理者がクリック数を不正に増やすことを防止するためにGoogleのドメインになるでしょうから、広告ブロッカーはa要素のhref属性に "googlesyndication.com" が含まれていた場合、a要素に包括されるimg要素を含めて受信をブロックします。
しかし、HTTP/2 のサーバプッシュで広告画像とコンテンツhtmlをまとめてバイナリデータとして送信する仕組みにしてしまえば、広告ブロッカーで広告を非表示にしたとしても、広告データの受信を阻止することができなくなり、広告ブロッカーを導入するメリットが半減することになり(邪魔な広告を見たくないという要求を満たすことはできるが、通信量を減らしたりページのロードを早くしたりしたいといった要求を満たすことができなくなる)、広告ブロッカーの導入率を下げることができます。
ちなみに、最近の広告配信システムではサイト管理者がページに貼り付けるコードが JavaScript なのが一般的ですが、昔の広告配信システムでは Perl や php のコードが用いられているところも結構ありました。
特に i-mode などのモバイル向けでは、100% サーバサイドスクリプトでした(JavaScript 非対応端末が一般的であったため)。
従って、HTTP/2 が普及したら、広告表示の高速化と、広告ブロック妨害(サーバプッシュの利用)の為、昔のようにサーバサイドスクリプトの広告コードに戻る可能性もあると思います。
Re: (スコア:0)
2番目の例だとhtmlをパースした後でないとブロックできないから,imgをBASE64に変換されて埋め込まれたら,現状でも対応できない。
こんな議論は pgp/gpg や s/mine の暗号メールにおけるスパムでも議論がありましたが,暗号メールはなかなか普及しないな。
Re: (スコア:0)
a タグを解析してブロックするだけだと、img タグに JavaScript で、onclick で飛ぶようにリスナー追加するだけで回避されてしまうような。
あるいは、必要な画像に広告リンクを貼って、ブロックするとまともに見れなくするとか。
まぁでも自分のサイトから広告を送出するとになると、帯域の問題もあるからそんなに酷いことにならない予感。(Google が全サイトに CDN を無料提供とかすれば別だけど)
Re: (スコア:0)
JS殺すことで通信料低下と表示速度向上してる私にとってきついんだよなあ。数倍違うんで。
でもま、最大の欠点はセキュリティじゃないかな。
data-uriもそうだったけどね。
Re: (スコア:0)
AdBlockはブラウザがページをデコードした結果に介入しているのだから普通にブロックできますが。
むしろ中間の土管にそんな介入許すほうが恐ろしい。広告をブロックできるということは自社の広告に差し替えもできるということ
Re: (スコア:0)
わたしも,コンテンツの破棄や拒否といったブロックは,クライアント・サイドがやるべきことで,プロクシには触って欲しくないと考えている人間です。
もし中間でやるとしても,ユーザと目的のサイトの間に挟むのは管理化にあるサーバになると思います。
最後に転送量の問題はのこりますが,あまりに多くの量をプッシュする広告は,ポップアップ広告のように淘汰されていくのではないかと思います。