Technically Impossible

Lets look at the weak link in your statement. Anything "Technically Impossible" basically means we haven't figured out how yet.

オンライン広告のブロック、その現実的ソリューション(Hosts、DNS proxy、Local DNS)

オンライン広告の状況がひどい。

  • 俗にコンプレックス広告と呼ばれる類の、グロテスクさを強調したかのような写真の多用
  • オンライン・コミックの広告に表示される作品の内容
  • ペアレンタルコントロールを施しても、広告を通じて提供されるコンテンツは素通りさせる、プラットフォーマーの無責任さ

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を組み合わせた運用が現実的ではないか、という考えに辿り着いた。「現実的」というのは、どれもパーフェクトではなく、それぞれに一長一短があるということだ。

まず最初に結論

オンライン広告の表示抑制にHostsファイルを活用するのが一般的だが、Androidでの運用には難があるし、iPhoneiPadでの運用は現実的ではない。後述する前提、方針に則れば、次のソリューション構成が妥当、現実的と結論付けている。

理想的 ローカル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の場合では対応が面倒だ。加えて、iPhoneiPadではジェイルブレイクしない限り対応することができない。

名前解決するドメインを、サブドメインの単位で登録しなければならないのが、一番の問題点だ。表示抑制対象となり得るサブドメインを収録した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

対策前後比較-Yahoo!ファイナンスの場合

対策前 対策後

では、膨大に存在するサブドメインをどのように捉えるのか。それらをワイルドカード付きでドメインごと登録することができれば、負担ははるかに軽くなる。そこでDNS forwarder (DNS proxy)を活用する。

DNS proxy

適用可能 PC
Android
iPhoneiPad
長所 端末ごとに設定する必要がない
ドメイン登録、運用が楽
短所 モバイルでは利用できない場合もある
厳密な名前解決設定が難しい

まず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サービスへ転送する

広告ブロック機能のある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のようなサービスに依存することになるため、モバイル時には、次のどちらかで運用する必要がある。

  • AdGuard無しで運用→Hostsファイルのサブドメインのみブロック対象
  • 全てのDNS参照を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の場合、次のいずれかが妥当なインストール候補になるだろう。

インストール候補となるDNS
www.isc.org
technitium.com
github.com