iOS 9 広告ブロック機能 — 実例と解説
iOS 9 から導入された広告ブロック機能は「Apple が Web 広告を殺しにかかった」と、大きな話題となりました。
この広告ブロック騒動に興味を持ち、私も実際に１つ広告ブロックアプリを作ってみました。その中で分かったことをまとめてみようと思います。
iOS 9 自体がブロック機能を持つわけではない
リリース直後に誤解されていたことが多かったのですが、iOS 9 にアップデートすれば広告がいきなりブロックされるようになるという訳ではありません。今回作ってみたような、サードパーティ製の広告ブロックアプリをインストールすることによって広告はブロックされます。
Apple が iOS 9 で行ったことは、そうした「ブロックアプリを開発するための仕組みをアプリ開発者に提供した」ということです。さらに言えば、ブロックする対象は広告に限ったものでもありません。トラッキングスクリプトなど、任意のリソース読み込みをブロックすることが可能です。
ブロックアプリの正体「Content Blocker Extension」
この、ブロックアプリを作るための仕組みである「Content Blocker Extension」は、2015年6月に開催された Apple の開発者会議 WWDC 2015 で発表されました。その時のビデオが以下に公開されています。
→ Safari Extensibility: Content Blocking and Shared Links
ここで述べられている通り、Content Blocker Extension は、Apple の Webブラウザ「Safari」のエクステンション（拡張機能）です。デスクトップ版の Safari や Chrome, Firefox などの Web ブラウザに以前から存在するエクステンション（アドオン）の仕組みと基本的には同じものです。
ブロックツールは以前から存在する
つまり、これまでデスクトップで既に存在した仕組みを、モバイルにも提供開始したというのが実状です。同じ仕組みなので、デスクトップでは広告をブロックするツール（エクステンション）が既に存在していました。
その中でも最大のブロックツールである AdBlock Plus は、全世界で3億ダウンロードを超えると発表されています。また、今年8月に PageFair, Adobe 社が発表した調査によれば、ブロックツールの月間アクティブユーザーは2億人に上り、2015年には合計218億ドル分のオンライン広告の読み込みがブロックされたといいます。
→ PageFair and Adobe 2015 Ad Blocking Report (PDF)
広告ブロックアプリの種類
ここで詳しい方であれば、「いや、デスクトップじゃなくてモバイルでも以前から広告ブロックアプリはあったよ」と思われるかと思います。それはその通りで、ブロックアプリ自体は iOS 8 以前でも存在していました。
ただし、以前から存在していたようなブロックアプリと、今回作成したような iOS 9 の Content Blocker Extension を利用したブロックアプリは、ブロックの実現方法が違います。３種類に分けて解説したいと思います。
- 広告ブロック機能を持った独自の Webブラウザアプリ
- Content Blocker Extension を利用した Safari 拡張アプリ
- 通信を独自サーバーに中継させ広告を遮断するサービス
まず、1. の独自ブラウザアプリは Ad-Blocker Browser のように、そのアプリ自体が Webブラウザであり、そのブラウザで閲覧するときのみ広告がブロックされます。これはユーザーから見れば、使い慣れている Safari からブラウザをスイッチしないといけないという点がネックになります。
2. は、今回作成した Filter のタイプですが、他にもいち早く出た Crystal などが有名です。これは Safari の拡張機能ですので、一部例外を除き（後述します）、Safari で閲覧する Webサイトの広告のみをブロックします。Safari 以外のアプリ内で表示される広告はブロックされません。
一方 3. は、Web ページだけでなく、アプリ内の広告すらをブロックします。Been Choice がこれに当たりますが、この種のタイプのブロックサービスが行っていたことは、VPN の設定をユーザーにさせることによって、iOS 端末からのインターネット通信の全てを独自のブロックサーバーを中継させるようにするというものでした。
これはユーザーの通信内容を広告ブロックサービスの提供者が覗き見れるような状況にするものであったため、プライバシーの観点から Apple はこの種のアプリを App Store から既に削除しています。
→ App Store removes root certificate-based ad blockers over privacy concerns
広告ブロックアプリの影響範囲
iOS 9 から Apple が提供した Content Blocker Extension を使った広告ブロックが、ユーザーにとって最も安全かつ快適であるため、今後ブロックアプリはこの種のものだけが残ると思われます。
では、この種のブロックアプリはどの程度のブロック能力を持っているでしょうか。上述したとおり、これは Safari の拡張機能であるため、基本的に Web サイトを Safari で閲覧した時のみブロックされます。アプリ内にある広告は、アプリ内ブラウザ (UIWebView / WKWebView) で表示される場合も含め、ブロックされません。
現在のモバイル広告のトラフィックは、Safari のような Web ブラウザ経由よりも、アプリからのアクセス割合の方が既に圧倒的に多いため、そういった意味では広告ブロックの影響は限定的であるといえます。
→ Good News, Publishers! Mobile Ad Blockers Won’t Actually Block Much Revenue.
ただし、iOS 9 からは、SFSafariViewController という、サードパーティアプリがアプリ内ブラウザを簡単に用意できる仕組みも提供されました。この仕組みを使って表示された Webページに対しては、アプリ内であっても Content Blocker Extension のブロック機能が適用されます。
まだこの SFSafariViewController を使ったアプリは殆どないので影響は少ないと思いますが、仮に Facebook や Twitter など、巨大アプリが採用した場合、無視できない影響を持つことになるかと思います。
広告ブロックアプリの仕組み
広告ブロックアプリは、どのようにして広告をブロックしているのでしょうか。Content Blocker Extension の仕組みはシンプルで、ブロックリストを予め Safari に伝え、Safari は任意の Webページを読み込む際に、そのブロックリストに照らし合わせ、必要に応じて読み込みをブロックするというものです。
こうした仕組みのため、この種のブロックアプリは、ブロック側がユーザーのアクセス情報を知ることはありません。
具体的には、
[
{
"action": {
"type": "block"
},
"trigger": {
"url-filter": "evil-tracker\\.js",
"if-domain": ["black-site.com"]
},
},
{
"action": {
"type": "css-display-none",
"selector": ".annoying-ads"
},
"trigger": {
"url-filter": ".*",
"unless-domain": ["white-site.com"]
},
}
]のような JSON 形式でブロックルールを定義します。上の例であれば、
- “black-site.com” というドメインのサイト内では、“evil-tracker.js” にマッチする URL リクエストをブロックする
- “white-site.com” というドメイン以外のサイト内では、“annoying-ads” というクラス名を持つ HTML 要素を非表示にする
という定義内容です。読み込み自体をブロックするものと、単に HTML 要素を非表示にする２種の方法が用意されています。
→ Introduction to WebKit Content Blockers
この JSON はバイナリ形式に変換されて Safari に予め渡されるため、従来デスクトップであった、ページ読み込み時に都度 JavaScript を実行するような方法で実現されていたブロックツールよりも高速に動作します。
広告ブロックアプリ対策
ブロックアプリに対して、広告表示をしている側は泣き寝入りするしかないのでしょうか。仕組みを知った上で、広告ブロック対策に有効だと思われることを敢えて列挙してみようと思います。
- Web ページからアドサーバーに直接アクセスしない
- 広告表示部分に特定可能な HTML タグを使わない
- 広告ブロックをしているユーザーにはコンテンツを見せない
- Web からネイティブアプリに移行する
[1] Content Blocker Extension の仕組みは上記の通りドメインのパターンでブロックが可能ですので、Webページから特定のドメインのアドサーバーにアクセスするような仕組みになっていれば、そのアドサーバーのドメインを登録すればブロックできます。一方、サーバーサイドで予め広告を取得するような仕組みになっていれば、ブロックすることができません。
[2] 広告表示時に、その広告が例えば <div class=“ads”> のような、他のコンテンツと区別できる HTML 要素に入っていれば、CSS のセレクタで非表示にすることができます。HTML の構造的に、広告を他の部分と分離できないような作りになっていると、ブロックすることができません。
[3] 特定の JavaScript ファイルの読み込みがブロックされた場合には、そのスコープにあるべき変数が null になっているかどうかでブロックされたことを判別できると思います。その場合、ユーザーに対して広告ブロックを検知したことを伝え、ユーザーにコンテンツを見れないようにするような対策は、技術的には可能です。
[4] そして、Content Blocker Extension がブロックできるのは Web ページに限られるため、ネイティブアプリの広告はブロックすることができません。なので Web からアプリへとコンテンツ公開の場を移すことによって、広告ブロックを回避することは可能です（これが今回の Apple の狙いの１つでもあるわけですが）。
Apple の今回の動きの背景
今回 Apple がモバイル Safari のコンテンツブロック機能の解禁に動いた背景としては、広告を Web から Apple 自身がコントロール可能なアプリへと移行させ、かつ Web 広告から巨額の利益を上げている Google を牽制するためだと言われています。
Google の広告事業のトップである Sridhar Ramaswamy は Apple のコンテンツブロック機能に対して、酷いユーザー体験の広告の存在が広告ブロックツールの普及を招いたとした上で、“The real problem is that ad blockers throw out the baby with the bathwater”（広告ブロックは良い広告まで一緒に捨ててしまう）と懸念を表明しています。
→ Google Ads Boss: ‘We Need to Deal With’ Ad Blocking as an Industry
モバイル広告とユーザー体験
Web 広告をブロックすることが Apple にとって有利に働くのは事実でしょう。しかし、このような事態にまで発展した根本的な原因は、多くのユーザーが今日のモバイル広告を嫌ってしまっているからに他なりません。Ramaswamy もインタビューの中で認めたように、モバイル Web には “terrible user experience” な広告が溢れかえっています。
デスクトップでの感覚で、狭いスマートフォン端末の画面にバナー広告を詰め込み覆い被せた結果、広告は主役である本来のコンテンツの閲覧を邪魔するようになってしまいました。結果、ユーザーはそれらバナーに苛立ち、意図的に無視するようになってしまったのです。
更に、多くの広告はページの読み込み時間も大幅に長引かせていることが分かっています。The New York Times の最近の調査によれば、Web ページの読み込みにかかる時間のうち、半分以上が広告由来であるという驚くべき結果が出ています。
本来、新しい価値を届けるためのものである広告が、多くのスマートフォンユーザーにとって無価値どころかマイナスの価値を持ってしまったことは悲しいことです。
鬱陶しい広告を消すことができ、ページの読み込み速度も早くなり、追跡もされなくなる広告ブロックアプリは、ユーザーにとってはメリットしかありません。しかし当然ですが、そこに広告があるからこそ良質なコンテンツが無料で読めているわけです。
嫌われてしまった旧来のバナー広告に代わる、ユーザーにとって価値のある持続可能なモバイル広告が必要とされており、今私たちはその過渡期の真っ直中にいるのだと感じます。
