2021年8月21日にオンライン広告のブロック方法を投稿した*1。その投稿では、DNS、あるいはDNS proxyを構築し、Hostsファイルと外部DNSサービスを組み合わせて、効率的、かつ現実的に広告ブロックに対応するアイデアを紹介した。それらと連携するVPNを組み合わせれば、Androidをはじめとするモバイル端末にも適用できるアイデアだ。
以降、オンライン広告の状況は大きく変化してきた。最も特筆すべき変化は、オンライン広告に対する認知だろう。コンプレックスを刺激する、グロテスクな画像など、無用に注意を引き付ける不快、不愉快な存在として以上に*2、なりすましや詐欺、誤解や誤操作を誘いマルウェアをインストールしようとするなど、セキュリティ上の脅威として認識されている*3。
PC、モバイル端末を問わず、共通の脅威ではあるのだが、モバイル端末に与える影響は、より深刻だろう。
- 画面を覆うほどの広告
- コンテンツ閲覧に支障を与える広告配置
- 誤タップを誘うインタフェイス
などなど。
先週、モバイル端末用広告ブロックの一つである280blockerが、非公開を経て、公開断念に至った*4。すでに導入済みのユーザーであれば、現在利用中のアプリをアンインストールしない限りは継続利用可能なのだが、280blocker難民を含め、その代替手段を求めるユーザーは多いのではないかと予想した。
この状況を背景に、2021年投稿のモバイル版として、類似サービスとpersonalDNSfilterの紹介を投稿することにした。モバイル版とはいえ、私自身が前提としている、次の方針に変化はなく、
- 可能な限りユーザー自身でコントロール可能であるソリューションであること
その手段として、ローカルDNS proxyとHostsファイルに通じる技術の組み合わせであることにも変化はない。uBlock Origin*5のように、コンテンツ・レベルで表示内容を操作するツールは利用しない。
モバイル端末向けの広告ブロック
2021年の投稿で紹介した結論に倣えば、次のソリューション構成が妥当、現実的と結論付けている。モバイル端末の場合、それ用のアプリを導入することで、類似の運用を実現できる。後述する前提、方針に則れば、この投稿時点で構成が妥当、現実的と考えるのは、次のソリューションだ。
| 理想的 | ローカルDNS | PC | 全てを掌握できる 運用も楽 |
| 次点 | ローカルDNS proxy | PC Android |
AdGuardのようなサービス依存 運用も楽 定義ファイルの供用が不便 |
| 現実的 | DNS proxy + Hostsファイル | PC | |
| 現実的 | personalDNSfilter RethinkDNS 280 blocker |
Android iPhone, iPad |
Hostsファイルの書換を伴う |
| 一般的 | Hostsファイル | PC | サブドメイン登録、運用が大変 |
| 一般的 | DNS proxy | PC Android iPhone, iPad |
完全なサービス依存 |
Android上にDNS proxyを構築するならば、次のプログラムを活用する方法がある。宅内LAN環境にDNSを構築したり、PCにHostsファイルを設定するように、全てをユーザーが掌握できるのが強みある一方、ブロック対象となる定義ファイルを他の環境と共用しにくい不便さがある。
最もお手軽なのは、類似の技術を採用した、一般向けに配布されているアプリを導入することだろう。
ブロック対象を記録した定義ファイルは、外部から与えられるものを利用できる一方、必ずしもユーザーが求めるブロック対象が含まれているとは限らないことを申し添えておく。未収録のレコードは、ユーザーが自ら追記するか、Hostsファイルなどを編集して定義ファイルとして書き換える必要がある。
例えば、次のアプリが挙げられる。
私は、Android用にpersonalDNSfilterを利用している。後述するように、ブロック対象を記録した定義ファイルとして、編集したHostsファイルを共用できるため、宅内環境と運用を統一しやすい。
RethinkDNSはpersonalDNSfilterに比して高機能だが、私にはオーバースペックすぎる。VPN連携だけでなく、Orbot*6を利用することで、Tor連携もサポートしている。とはいえ、そこまでの機能を私は求めていないし、広告ブロックに限れば不要な機能でもある。
現在、RethinkDNSはAndroid版のみが提供されているが、iOS版がリリースされる可能性はありそうだ。
A lot of our users have asked us for iOS support. We are already discussing buying a Mac to make this happen. Stay tuned. Write to us in case you've got any questions or suggestions: hello (at) celzero (dot) com.
前提、方針
この投稿では、可能な限りユーザー自身でコントロール可能であるソリューションを目指している。オンライン広告を表示抑制するアプリ、DNSサービスは多数提供されているが、それらは次のようなリスクを抱えている。
| ブロック対象 | ブロックしたいサブドメインが対象外かもしれない ブロックしたくないサブドメインがブロックされるかもしれない |
| 名前解決 | 不適切な宛先を示される可能性→攻撃への悪用 |
| 買収*7 | いつまで利用できるか分からない 改悪されるかもしれない |
ユーザーが意識していない、気づいていないうちに、本来表示すべきものが表示されなかったり、意図しないブロックによって、サイトが適切に動作しなかったり、という状況は避けたい。可能な限り、そのようなリスクを避け、標準的な技術だけでソリューションを構成することにした。方針は次の通りだ。
またuBlock Originのように、コンテンツ・レベルで表示内容を操作するツールも利用しない。たとえ広告をブロックしても、文章自体の読解に差し障る影響が生じるのでは、対策の有効性が損なわれる。
最近、アクセス管理を参照していて散見されるのが、このようなツールの影響を受けている画面だ。ユーザーが意図していることなのか、ツールのなすがままなのかは置いて、なぜか、あらゆる表示要素、コードの引用スニペットまでもが中央寄せされている。モバイル端末に限らず、WindowsやMac OSでも、同様の状況を確認している。
 |
 |
 |
定義ファイル
まずブロック対象となるドメインが記録された定義ファイルは、オンラインで公開されているものがある。
定義ファイルとしてではなく、情報として流通しているものもある。このような場合、定義ファイルへ必要なドメインを追記するか、新たな定義ファイルを作成する必要がある。
https://www.reddit.com/r/Adblock/comments/ia2q7k/how_to_block_microsoft_news_taboola_outbrain_ads/www.reddit.com
おそらく圧倒的多数のユーザーは、独自に定義ファイルを作成するようなことはせず、ただ与えられた定義ファイルを設定して利用することだろう。ただし、オンライン上で配布されている定義ファイルに、ユーザーが求めるブロック対象が確実に含まれているとは限らない。
最近は、HTMLファイルに直接記述されたJavaScriptがJSONファイルを読み込んで広告表示するものもある。そのような場合、JSONファイルをホストしているドメインを、定義ファイルへ記録する必要がある。
PCで使用中のHostsファイルを転用したいユーザーもいることだろう。personalDNSfilterや280 blockerが用いる定義ファイルも、本質的にはHostsファイルの対応と変わりない。一つ注意しなければならないのは、レコードの記述方法だ。Hostsファイルの場合、次のような記述スタイルが許容される。
0.0.0.0 im.c.yimg.jp yads.c.yimg.jp
このスタイルは定義ファイルでは許容されず、次のように1行、1レコードのスタイルで書き直さなければならない。もしブロック対象を定義済みのHostsファイルがあり、それを定義ファイルとして転用するならば、以上の記述スタイルに書き換える必要がある。
0.0.0.0 im.c.yimg.jp 0.0.0.0 yads.c.yimg.jp
定義ファイルの登録
広告ブロック・アプリが定義ファイルを読み込むに際し、指定されたURLからインターネット経由で参照することができる。Hostsファイルを書き換えたり、ユーザーが追記した定義ファイルを参照させるには、インターネット経由で参照できるサービスへ定義ファイルをアップロードする必要がある。
契約しているISPがホームページ・サービスを提供しているのであれば、そこへ保存しても良いし、GitHub Pages*8を活用するのも一案だろう。
personalDNSfilterの場合、複数の定義ファイルを併用することができる。以下の画像で示すのは、Hostsファイルを書き換えたものと、paste.binで配布されている定義ファイルを登録し、通信のブロックを確認している状況だ。
アプリに定義ファイルのURLを登録すれば、ブロック対象のレコードが読み込まれ、該当ドメインあての通信がブロックされる。ログに緑で表示されているドメインは、許可されている通信、赤で表示されているのがブロックされた通信だ。
 |
|
ブロック対象となるサブドメインの特定方法
まず率直で確実なのは、広告が表示されているwebサイトのソースコードを参照し、広告が配信されているドメインを特定することだ。手間はかかるが、特定したドメインのみを記録した定義ファイルを用いれば、ブロック対象を必要最低限に抑えることができる。
もしドメインに察しがついていれば、その情報をもとにサブドメインを、SecurityTrails*9で検索することができる。以下は、その一例だ。
🔎SecurityTrailsでの検索結果
https://securitytrails.com/domain/googlesyndication.com/dns
https://securitytrails.com/domain/outbrain.com/dns
https://securitytrails.com/domain/popin.cc/dns
https://securitytrails.com/domain/taboola.com/dns
https://securitytrails.com/domain/yimg.jp/dns
https://securitytrails.com/domain/yjtag.jp/dns
この中には、今後消えていくサブドメインもあれば、この中には含まれない、新しいサブドメインも登録されている。全てを定義ファイルに記録するのは無理だろう。
現実的な対策は、対象を絞ることだろう。「自分の観測範囲」の中で見かける広告を調べ、頻繁に表示される広告のドメインだけを、定義ファイルに登録する。パレートの法則に倣えば、20%程度のドメインによって、80%の広告が生成されているはずだ。
つまり、自分の観測範囲内で表示される広告については定義ファイルで対処し、そのほかは広告ブロック機能のあるDNSへ転送するのが良いだろう。例えばAdGuard DNS*10だ。このようなサービスを併用することで、観測班以外の広告対応について、効率的にアウトソースすることができる。
この考え方は2021年の投稿で紹介したことと共通だ。詳細については、2021年投稿を参照してほしい。
impsbl.hatenablog.jp
