オンライン広告の状況がひどい。
- 俗にコンプレックス広告と呼ばれる類の、グロテスクさを強調したかのような写真の多用
- オンライン・コミックの広告に表示される作品の内容
- ペアレンタルコントロールを施しても、広告を通じて提供されるコンテンツは素通りさせる、プラットフォーマーの無責任さ
I set the Content Restrictions —> Apps to 4+ years old but it still showed inappropriate ads for games that is for older ages.
How to stop inappropriate ads - Apple Community
などなどに対する自衛の必要性を感じていた。
広告業界も改善に動いている様子もある*1。コンテンツの無料提供を支える一端として、広告を必要悪と捉えていたこともあったが、時すでに遅しだ。もはや、コミック『こちら葛飾区亀有公園前派出所』から引用される不良更生エピソード*2に通じる白々しさすら感じる。
突き詰めて考えると、広告自体が鬱陶しいのではなく、そこに表示される画像が気に障る、という考えに辿り着き、画像だけをブロックしようとした。しかし、この方法は甘かった。画像を含む広告自体がwidget的に生成されることもあり、画像だけをブロックしようとしても、結局広告そのものをブロックすることになるのだ。
数日間模索した結果、Hostsファイル、DNS proxy、ローカルDNSを組み合わせた運用が現実的ではないか、という考えに辿り着いた。「現実的」というのは、どれもパーフェクトではなく、それぞれに一長一短があるということだ。
なお、この投稿で言及する方法とVPNを組み合わせることで、Androidをはじめとしたモバイル端末にも適用することはできる。モバイル端末はアプリの導入で対応したい場合は、次の投稿を参照してほしい。
impsbl.hatenablog.jp
まず最初に結論
オンライン広告の表示抑制にHostsファイルを活用するのが一般的だが、Androidでの運用には難があるし、iPhone、iPadでの運用は現実的ではない。後述する前提、方針に則れば、次のソリューション構成が妥当、現実的と結論付けている。
理想的 | ローカルDNS | PC | 全てを掌握できる 運用も楽 |
次点 | ローカルDNS proxy | PC | AdGuardのようなサービス依存 運用も楽 |
現実的 | DNS proxy + Hostsファイル | PC Android |
AndroidでのHostsファイル編集が課題 |
一般的 | Hostsファイル | PC Android |
サブドメイン登録、運用が大変 AndroidでのHostsファイル編集が課題 |
一般的 | DNS proxy | PC Android iPhone, iPad |
完全なサービス依存 Apple製品はこれしかない |
前提、方針
この投稿では、可能な限りユーザー自身でコントロール可能であるソリューションを目指している。オンライン広告を表示抑制するアプリ、DNSサービスは多数提供されているが、それらは次のようなリスクを抱えている。
ブロック対象 | ブロックしたいサブドメインが対象外かもしれない ブロックしたくないサブドメインがブロックされるかもしれない |
名前解決 | 不適切な宛先を示される可能性→攻撃への悪用 |
買収*3 | いつまで利用できるか分からない 改悪されるかもしれない |
ユーザーが意識していない、気づいていないうちに、本来表示すべきものが表示されなかったり、意図しないブロックによって、サイトが適切に動作しなかったり、という状況は避けたい。
これらアプリ、サービスの利用を最低限とし、可能な限り標準的な技術だけでソリューションを構成することにした。方針は次の通りだ。
Hostsファイル
適用可能 | PC Android |
長所 | ローカル環境に保存できる |
短所 | 登録候補のサブドメインが膨大に存在 配布されているHosts定義のリスク |
Hostsファイルはローカル環境に保存されるので、LANでも、モバイル通信でも、同じ定義を使い続けることができるし、同様にブロックできる。一方、それは端末それぞれのローカル環境に保存されている必要があり、Androidの場合では対応が面倒だ。加えて、iPhone、iPadではジェイルブレイクしない限り対応することができない。
名前解決するドメインを、サブドメインの単位で登録しなければならないのが、一番の問題点だ。表示抑制対象となり得るサブドメインを収録したHostsファイルが、様々なサイトで配布されている。*4。それらを用いることもできるが、必ずしも希望のドメインが収録されているわけではないし、ブロック無用なサブドメインを収録している可能性もある。加えて、不適切な宛先へ導く設定が紛れている可能性もある。
そもそも登録すべきサブドメインは、個人で運用管理するには膨大すぎるのだ。SecurityTrailsで、サブドメインを検索することができる。
🔎SecurityTrails
https://securitytrails.com/list/apex_domain/googlesyndication.com
https://securitytrails.com/list/apex_domain/outbrain.com
https://securitytrails.com/list/apex_domain/popin.cc
https://securitytrails.com/list/apex_domain/taboola.com
https://securitytrails.com/list/apex_domain/yimg.jp
https://securitytrails.com/list/apex_domain/yjtag.jp
この中には、今後消えていくサブドメインもあれば、この中には含まれない、新しいサブドメインも登録されるのだ。全てをHostsファイルで運用するのは無理だろう。
現実的には、対象を絞ることだろう。「自分の観測範囲」の中で見かける広告を調べ、頻繁に表示される広告のドメインだけを、Hostsファイルに登録する。パレートの法則に倣えば、20%程度のドメインによって、80%の広告が生成されているはずだ。例えば、前述のSecurityTrailsが示す、
- yimg.jp
- yjtag.jp
のサブドメインのうち、つぎの3つをHostsファイルに登録するだけで、Yahoo!の広告はほとんど表示されなくなる。
0.0.0.0 s.yjtag.jp 0.0.0.0 im.c.yimg.jp yads.c.yimg.jp
対策前 | 対策後 |
---|---|
では、膨大に存在するサブドメインをどのように捉えるのか。それらをワイルドカード付きでドメインごと登録することができれば、負担ははるかに軽くなる。そこでDNS forwarder (DNS proxy)を活用する。
DNS proxy
適用可能 | PC Android iPhone、iPad |
長所 | 端末ごとに設定する必要がない ドメイン登録、運用が楽 |
短所 | モバイルでは利用できない場合もある 厳密な名前解決設定が難しい |
まずHostsファイルと異なり、名前解決するドメインをワイルドカード付きで登録できるのが便利だ。具体的には、次のような具合だ。
Hostsファイルの場合
0.0.0.0 vra.outbrain.com 0.0.0.0 vrp.outbrain.com 0.0.0.0 vrt.outbrain.com 0.0.0.0 widgets.outbrain.com 0.0.0.0 www.api.taboola.com 0.0.0.0 www.c2.taboola.com 0.0.0.0 www.cdn.taboola.com
DNS登録の場合
*.outbrain.com *.taboola.com
宅内の通信環境においては、ルーターがDNS Proxyの役割を担っていることだろう。例えば、フレッツ光で貸与されるホームゲートウェイには、指定したドメイン毎に転送先となるDNSを設定する機能がある。
ここに表示抑制対象となるドメインを登録することで、次のように対応することができる。
広告ブロック機能のあるDNSサービスとは、例えばAdGuard DNS*5だ。このようなサービスを利用すれば、サブドメインごとの名前解決をアウトソースすることができる。
前述の2ドメインと、AdGuard DNSだけの設定だけでも、次に示す程度の効果がある。IGN Japan、togetter、いずれのケースでもTaboola、Outbrainの表示が消えてしまったのが確認できる。
対策前後比較-IGN Japanの場合
対策前 | 対策後 |
---|---|
対策前後比較-togetterの場合
対策前 | 対策後 |
---|---|
とはいえ、期待通りにブロック対象と認識されないこともある。例えば、ブロック対象として"*.yimg.jp"を登録したとする。次の2つのサブドメインを名前解決してみると、正式なIPアドレスが返される。
- im.c.yimg.jp
- yads.c.yimg.jp
ブロック対象とされている”www.taboola.com”同様に”0.0.0.0”が返されることを期待するのだが、これらはブロック対象とされていないのだ。
外部サービスに依存する場合、このようなことが起こる。指定したサブドメインを確実にブロックしようと思えば、外部サービスだけでは実現できないのだ。だからこのように考える。
疎なブロック・フィルタ | AdGuardのようなサービス | ドメインで登録する |
密なブロック・フィルタ | Hostsファイル | サブドメインで登録する |
つまりAdGuardのようなサービスには、大まかなブロックを期待し、そこから漏れたサブドメインをHostsファイルの登録対象として運用するのだ。このように役割分担するだけで、最低限の運用で、最大限の効果を得ることができる。このような具合だ。
DNS proxy + Hostsファイルでのブロック結果
🔎AdGurad転送ドメイン例
*.doubleclick.net *.googlesyndication.com *.googlevideo.com *.i-mobile.co.jp *.impact-ad.jp *.logly.co.jp *.microad.net *.outbrain.com *.popin.cc *.taboola.com *.taboolasyndication.com *.yimg.jp *.yjtag.jp
ローカルDNS
適用可能 | PC |
長所 | ローカル環境に保存できる ドメイン登録、運用が楽 |
短所 | 端末ごとに運用管理 構築、設定が難しい |
ルーターにDNS forwardingを設定する場合の問題は、それが持ち運びできないことだ。ほとんどのブロックをAdGuardのようなサービスに依存することになるため、モバイル時には、次のどちらかで運用する必要がある。
ローカル環境にDNSを構築すれば、forwarderとして機能するだけでなく、Hostsファイルも不要となる。運用形態として、次の2案がある。案1が理想案であり、ベスト・ソリューションだ。案2が次点となる。理由はAdGuardへの依存だ。案1は依存がないため、ユーザーが全てを掌握できる。
案1 完全なローカルDNS |
ブロックしたいドメインは全て”0.0.0.0”に名前解決する。→Hostsファイルの代わり それ以外のドメインは、本来のDNSへ転送する。 |
案2 ローカルDNS proxy |
ブロックしたいドメインは、AdGuardへ転送する。 それ以外のドメインは、本来のDNSへ転送する。 |
いずれにせよ、ブロックしたいドメインの登録管理はワイルドカード付きのドメインで対応できるため、Hostsファイルに比べて運用は楽になる。
DNSのインストール自体は、何も難しいことはない。ただしDNSの運用を学ぶ必要がある。ここが障害となるユーザーもいるだろう。ローカル環境とはいえ、Windows Defender Firewall with Advanced Security*6で、ローカル環境内でのDNS通信の疎通を確保しておく必要もある。
Windows 10の場合、次のいずれかが妥当なインストール候補になるだろう。