%E3%82%88%E3%81%8F%E3%81%82%E3%82%8B%E8%B3%AA%E5%95%8F - Yuki2718/adblock2 GitHub Wiki

最終更新:2024/03/25

内容は各項目執筆時点のものですのでご了承ください。脚注は詳しい方向けです。

1. ブロッカー選択

Q 1-1 AdBlock — 最高峰の広告ブロッカーやAdblock Plus(ABP)ではダメなのですか?

A 1-1

ダメです。理由は3つあります。

  1. 日本語フィルタが不在の出来が悪い

現在主流の広告ブロッカーはフィルタリストに書かれたルールを強制するためのプログラムであり、フィルタこそが心臓部です1-1。主要な日本語サイトの広告を大体除去するだけなら、100ほどのドメインをブロックするだけでもかなりの効果がありますが、一部の厄介なサイトに対応するには特殊な文法で書かれたフィルタが必要です。そして、各ブロッカーにはそれぞれ専用のフィルタ記法があり、それを無視して使うと十分な効果が得られません。執筆時点で、ABP、AdBlockとも日本語サイト用のフィルタリストを用意していません。(2024年3月24日更新)現在はABP、AdBlockとも日本語サイト用のフィルタリストを用意していますが、外国人がメンテナンスしているためお世辞にも出来はよくありませんし、更新頻度も非常に低いです。EasyList ChinaやRU AdListの更新履歴みればわかるように、インターネットの主要言語のフィルターリストは毎日何度も更新されるのが一般的です。ではもちフィルタや豆腐フィルタといった外部フィルタを購読すればよいかというと、これもうまく機能しません。これらのリストはuBlock Originを前提としていますが、ABPやAdBlockはuBlock Origin用の文法を解釈できません。ないばかりか、そのような解釈不能ルールがあるとそのページ上でほかのルールまで無効にしてしまいますhttps://github.com/uBlockOrigin/uBlock-issues/issues/1785#issuecomment-954813522)。 さらに、機械学習に基づく非表示ルールが多くの日本語サイトに適用された結果、様々な不具合起きています

  1. 機能面

日本語でABPとuBlock Originを比較する話になると、大体がパフォーマンスと後述の「控えめな広告」に終始しがちですが、ABPは純粋なブロック機能においてもuBlock Originに大きく後れを取っています。これはフィルタ作者にとってこそ死活問題であり、主要な日本語フィルタがすべてuBlock Originを前提としているのは偶然ではありません。たとえばCSS挿入やリソースリダイレクト、またnowoifなどの有用なスクリプトレットの多くが欠如していますし1-2、ドメインワイルドカードにいたってはすでにパッチがあるにもかかわらず採用されていません。これでは一部のアンチ広告ブロックに対して無力になりますが、ABPはそもそもアンチ広告ブロックには対処しない方針です。組み込みのフィルター(ABP filters)の性能もuBlock filtersより大きく劣っており、迂回・悪質広告のブロックが十分とは言えません。また、EasyPrivacy(とFanboy系各種リスト)はuBlock OriginとAdGuard用に、高度な文法を要するルールを含んだコンポーネントを持っています。ABP用のコンポーネントもあるのですが、これは主にABP filtersの$genericblockによる例外許可を補完するもので、ユーザーにはメリットがありません。要するに、ABPのEasyPrivacyは劣化版です。今後、ブロッカー毎の専用コンポーネントはEasyListにも拡張される予定です。

  1. 信頼面

これは個人的な価値観にもかかわるので軽く触れるにとどめますが、現在の広告ブロッカーはユーザーがアクセスする全URLをのぞける強大な権限を持っているため、信頼は大事です。ABPを提供しているeyeo社の主要な収入源は「控えめな広告」という仕組みによるもので、デフォルトで許可される広告のリストに追加するかわりに、一定規模以上の事業者からお金を受け取るものです。この許可は設定から無効にすることも可能です。一方で多角的な事業展開をしており、彼ら自身が広告を提供しだしたり、Android版Edgeに組み込ませたりしています。2022年からはプレミアム版の提供も始めましたが、無料版の機能に制限を加えたうえで、プレミアム用のフィルタリストを追加しただけで、はっきり申し上げて年20ドルの価値はありません。さらに、AdBlockは2015年に「身元を明かしたくない」何者かに買収されましたが、実はそれがABP開発元のeyeo社であることが2021年に判明しました。当初は買収していないとコメントしていたため、それは嘘だったことになります。uBlock(Originでない方)は2018年にAdBlockに買収されているため、eyeo社はuBlockも買収していたということです。

注意点として、ABPはデフォルトでは広告のみをブロックするのに対し、uBlock Originはアクセス解析もブロックするため、これによる不具合に遭遇することがあります。アクセス解析をブロックしたくない方は、フィルタリストからuBlock filters - Privacy, EasyPrivacy, およびPeter Lowe's Ad and tracking server listのチェックを外してください。

おまけ: AdGuard, uBlock Origin, Brave, Adblock Plus, Vivaldiの標準設定(Vivaldiは広告とトラッカーをブロック)で同じサイトを訪れたときの比較(2022年6月時点)

comparison1

1-1: Firefox版uBlock Origin公式ページ:「この拡張機能は、あらかじめ設定されているフィルターのリストが無ければ意味を成しません。ですので、何かしらの形で貢献したいと考えることがあった時は、これらのリストを無料で懸命に更新し続けている方々を思い出してください。」、uBlock Origin Github公式ページの一節:"Have a thought for the maintainers of the various lists. These lists are everything. This can't be emphasized enough."、また、AdGuardTeam/AdGuardFilters(AdGuardのフィルタ専門リポジトリ)の副題:"The place where ads are actually blocked"

1-2: ABPではuBlock Originでいうprocedural cosmetic filtersとスクリプトレットをまとめてスニペットと呼んでいますが、ABPのスニペットは、hide-if-contains-image-hashのような非表示系に偏っています。一方で、uBlock Originのset.jsに相当するoverride-property-readなどはYoutube広告対策に必須となった2020年8月になってようやく実装される始末です。

Q 1-2 AdBlocker Ultimateはどうですか?

A 1-2

2024年3月24日追記:下記の後、Ultimate Security filterをuBlock filters - Badware risksに入れ替えたようですが、公式サイトの記述はOnline Malicious URL Blocklistのままなのでライセンス違反です。

2023年8月7日追記:2023年8月5日ごろ発生した不具合の対応で、問題を起こしているリストを空にするという対応をしました。詳しい原因まで調べるのが面倒だったのかもしれませんが、杜撰と言わざるを得ません。uBlock Originは同様の被害はなかったものの、ミラーURLの切り替えという当然の対応をしました。しかも、中身はAdGuardなのにuBlock Origin用のリストを使っています。自分たちが提供しているブロッカーの機能さえまともに把握していない可能性があります。

この拡張機能は、古いバージョンのAdGuard広告ブロッカーのコピーであり、最新に追随するという口約束すらまったく守っていません。典型的な、他人の努力にただ乗りしてお金を稼ごうという業者です。古いバージョンなので、本物のAdGuard広告ブロッカーより性能も落ちます。それでも使いたいでしょうか?

Q 1-3 AdBlockとAdblock Plusの違いは?

A 1-3

歴史的な経緯についてはほかに優れた記事(日本語ではたとえばこちら)があるのでそちらに譲ります。現在はAdBlock(getadblock.com)のエンジンはAdblock Plusそのものであり、外装を付け替えただけです(2023年8月7日追記:最近はYoutube特定チャンネルの例外追加機能など、徐々に差別化を図っているようです)。A 1-1で述べたように、AdBlockはABP運営元に買収されているので当然かもしれません。

Q 1-4 ブラウザ組込みのブロッカーはどうですか?

A 1-4

A 1-1を参照していただきたいのですが、豆腐フィルタやもちフィルタも採用しているuBlock Origin文法に対応した組込みブロッカーは、PCでは私の知る限りBraveのみです。(一部の正規表現フィルタが機能しないなど、対応は不完全です。CEO自ら認めているように、ブロック機能はuBlock Originのほうが上です)。Vivaldiは基本的な文法しかサポートしていません。Manifest V3問題から移行先にあげられることがありますが、2021年5月現在のVivaldiの実装ではむしろV3対応のブロック拡張のほうが(ルール数などマイナーな点を除いて)自由度が高いです。いずれにせよ、もし広告ブロック拡張機能を追加するのであれば組込みのブロッカーは完全に無効にし、併用は避けるべきです。

なお、あまり知られていなさそうですがBraveの広告ブロックは標準ではファーストパーティー広告、つまり訪問したサイトから直接配信される広告(たとえば検索エンジンの広告)はブロックしません。Shields設定からブロックを「積極的」に変えることでそれらもブロックされるようになります。また、デフォルト設定では日本語のモバイルサイトにほとんど対応していないため、モバイルでご利用の方は必ずchrome://adblockからAdguard Mobileを追加してください(A 4-8参照)。

Q 1-5 Chrome拡張機能のManifest V3(MV3)移行で、広告ブロック拡張は使えなくなると聞きました。

A 1-5

2022年9月17日追記:MV3対応ブロック拡張機能の性能ですが、現行のMV2拡張機能と比べれば大幅に落ちるものの、総合的には「iOS15以上でのSafariコンテンツブロッカー + Safari拡張機能より少しまし」程度になると思います。ルール数制限はiOSより厳しく、整形フィルタの安定性やフィルタ更新に大きな問題があるものの、正規表現の制約がiOSほどには厳しくなく、リソースリダイレクトなどの高度な機能が概ね使えるためです。(2023年3月14日修正:正規表現のメモリ制約が厳しく、現時点ではどちらがいいとも言い難い状況です。)

2022年8月28日追記:BraveがManifest V2のサポートを継続することは確定しています

2022年5月19日追記:FirefoxもいずれはManifest V3に移行しますが、それによってuBlock Originが死滅するようなことは(作者がやる気をなくさない限り)まずありえません。そもそも、MV3や宣言的アプローチが根本的に悪いというよりGoogle主導のChromium MV3が問題です。MozillaでMV3対応の指揮を執っているRob Wu氏はList Authors Chat(広告ブロックフィルタ作者を中心としたコミュニティ)のメンバーでもあり、十分な時間をかけアドオン作者のフィードバックを反映しながら進めていくことを約束しています。仮にブロッカーの機能に一定の制限が出るとしても、それによって実際にセキュリティが向上するならuBlock Origin作者が反対するとは考えにくく、どこかで妥協点を探すことになると思います。また、MV3の結果として拡張機能のレビューが高速化するならブロッカー側にとっても大きなメリットとなります。

まず、専門外ですので以下には間違った点があるかもしれません。広告ブロック拡張自体はManifest V3準拠のDeclarative Net Request APIでも可能です。V3移行で広告ブロック拡張が死ぬかのような主張は的外れです。しかし、現状のまま移行されるとuBlock Originのような高度で柔軟な機能を持った拡張機能は死滅します。それ以上に、少数のボランティアに頼っている現在のフィルタコミュニティは打撃を受けるでしょう1-3。すでにiOSは大きな負担となっています。広告ブロックコミュニティ側も、Manifest V3のすべてに反対しているわけではもちろんなく、ちゃんと意味のある制約は受け入れる意思を示しています。批判の要点は、プライバシー保護が目的というなら筋違いではないかという点と、広告ブロックコミュニティの実情を理解していないという点が大きいのではないかと思います1-4。webRequest APIのうちブロック以外は残るため、Chromiumチームが挙げているような悪用はManifest V3でも可能で、プライバシー保護への直接的な効果はほぼありません。

1-3: 機械学習を使えばいいという人もいますが、現状ではフィルタコミュニティの代替になるようなものではありません。Adblock PlusはすでにFacebookのフィルタ作成用に機械学習を使っていますし、Braveが関与しているAdGraphをはじめ、機械学習を広告やトラッキングのブロックに使った論文は多く出ています。

1-4: 当初、Googleはパフォーマンスも理由に挙げていましたが、現行のAPIがまったく足かせになっていないデータが示されたためプライバシーに軸足を移しました。一方で、一般にはルール数の制約といったわかりやすい点ばかりが流布している気がします。ルール数は本題ではありません。そもそもuBlock Originが持つような高度な機能が必要となった背景には広告提供側とのいたちごっこが一因としてあります。実際にAdGuardやuBlock Originは絶えず新機能を追加し続けてきましたが、Manifest V3下では多くの場合ブラウザ開発側にそれを要求しなければならず、迅速に対応してもらえるか、そもそも対応してもらえるか自体保証はありません。

Q 1-6 Nano Adblocker(+ Nano Defender)のほうがよいと聞きました。

A 1-6

2020年10月17日追記:Nanoプロジェクト(Chrome版)はトルコの開発者に売却され、危険な機能が追加されたためストアから削除されました。ChromeでNanoをご利用の方は速やかにアンインストールしてください。Firefox版は別の方がメンテナンスしているため大丈夫です。以下の内容は執筆当時のものです。

目的と使い方によります。もし、アンチ広告ブロックを念頭に置いておられるのなら、uBlock Originで十分です。2020年時点で、Nanoに報告されるすべてのアンチ広告ブロックはuBlock filtersかuBlock filters - Annoyancesにて対処されています1-5。ただ、Nanoではコンテンツを妨害しないソフトアンチブロック(例:Outlook.com無料版で右側に出る「お願い」)もデフォルトで対処するのに対し、uBlock Originの場合はuBlock filters - Annoyancesの購読が必要になります。Nanoの最大の利点は強力だがリスクもあるスクリプトレットで一部の迷惑要素に対処できる点ですが1-6、Nano filters - Annoyancesはほぼ海外向けです。日本語サイトを中心に見る人は、自分でルールを書くのでなければNanoを使うメリットはほぼありません。むしろ新機能への追随が遅れることがあり1-7、使うフィルタによってはデメリットさえあります。ただ、NanoにはQuick reporterという問題報告ツールがあり、これは別の意味で大きなメリットといえます。アンチ広告ブロックは目立つため、初心者の方にはなにか特別な対処を要するものに思えてしまうのかもしれませんが、フィルタ作者にとって対処は容易です。しかしこれは評判が悪かったため、近年増えてきているのはブロッカーを検知してそれを迂回する広告を再挿入するパターンです(これもあまり成功していないようです。広告を見たくない人に無理やり見せるのだから当然ですが)。

1-5: Nano Defenderには、あるタイプのアンチ広告ブロック全般に対処するgeneric solutionという仕組みもありますが、機能的にはuBlock Originでもほぼ同等のことは可能です。しかし、パフォーマンスや副作用への懸念などからあえて避けています

1-6: スクリプトレットにはもともとリスクがありますが、uBlock Originではあらかじめハードコードされたスクリプトのみを使うようにしてリスクを抑えています。この点はNanoも同じです。では何が違うかというと、uBlock Originの組込みスクリプトは最悪でもページの外見や機能を壊すくらいしかできないのに対し、Nanoのスクリプトにはたとえばクリックをエミュレートするものがあり、これを使ったフィルタの存在を知っている攻撃者が対象サイトを乗っ取れば、マルウェアのリンクを自動クリックさせることもできます。ショッピングサイトなどであればもっと直接的な悪用もできるでしょう。このため、uBlock Originではこれらのスクリプトが広告やアンチ広告ブロックへの対処にどうしても必要となるまでは採用しないと決めています。

1-7: DandelionSprout氏によると、domainオプションのワイルドカードサポートへの対応遅れが問題となったようです。

Q 1-7 Nano Defenderの代わりはありますか/アンチ広告ブロック対策をどうすればいいですか?

A 1-7

2023年5月16日追記:Fuck FuckadblockはuBlock Originのbadlistに登録されました

A 1-6で述べたように、Nanoはいらないと思います。uBlock Originに戻したことでアンチ広告ブロックが出るようになったという人は十中八九、フィルタ選択を間違えていると疑われます。まず、uBlock filtersが有効なことを確認し、それからほかのフィルタについても見直してみてください。初心者の方はフィルタを追加する方向に動いてしまいがちですが、AdGuardへの報告ではむしろ過剰購読により惹起してしまっているケースが後を絶ちません。追加する前に、減らすか切り替えることをご検討ください。また、アンチ広告ブロックのテストページはuBlock filtersの対象外です。テストページでブロッカーが検知されるからと言って、アンチ広告ブロック対策がされていないと早合点しないでください。それでもアンチ広告ブロックに遭遇してしまった場合1-8フィルタ作者に報告してください。フィルタで対処できないアンチ広告ブロックは知られておらず、サイト側がこちらの対策を監視していたちごっこにならない限りは必ず対処できます1-9。予防的な対処がしたいのであれば、一番簡単で効果的なのは「汎用整形フィルターを無視する」にチェックを入れることです。ただし広告枠やテキスト広告、一部ポップアップが隠し切れなくなるなど副作用もあるため、ある程度自己対処できる方向けです。また、Firefoxの強化型トラッキング防止機能は無効にしたほうが遭遇率が下がります。どうしても標準のリストと日本用フィルタ以外にフィルタを追加したいのであれば、せいぜいAdGuard Baseくらいでしょう(uBlock Originの設定の、フィルターリスト > 広告にあるもの)。まれにuBlock filters未対応のアンチ広告ブロックに対応している場合もあります。ただし、uBlock Originで使うとそれなりに不具合もあり、逆にアンチ広告ブロックを起動してしまうこともあります(一例。スクリプトレットの干渉により起動するケースも時々あります)。Fuck FuckadblockはA 4-6と同様の理由に加え、不具合リスクやパフォーマンス負荷の高いルールが多いためおすすめしませんし、uBlock filtersとBaseがあればまず不要です1-10。Fanboy's problematic-sitesはA 4-6で述べたFanboy's Enhanced Tracking Listのサブフィルタで、A 4-6と同様の理由でおすすめしません。これらのフィルタで効果がある方は、もともとのフィルタ選択に問題があり、アンチ広告ブロックのトリガーを引いてしまっている場合がほとんどです。一方、AdGuard AnnoyancesやuBlock filters - Annoyances、Adblock Warning Removal Listなどが対応するのはA 1-6で述べたようにソフトアンチブロック、つまり邪魔にならないか×を押せば消せるようなものですので、悩む方は少ないと思います。とくにAdblock Warning Removal Listはロシア語のマニアックなサイトを見る人以外には無意味といってよく、uBlock Originでブラックリスト指定されています。

1-8: 日本用フィルタでのみ惹起されるアンチ広告ブロックもあります。この場合uBlock filtersは対応しませんので、ご利用のフィルタ作者に報告してください。また、AdGuard日本語フィルタで対処されているアンチ広告ブロックは、原則としてuBlock filtersでは対処しません。同様の理屈でちょっと罠かもしれないのが、日本人利用者が多いと思われる違法コンテンツサイトやアダルトサイトの中に、たとえばスペイン/ポルトガル語のサイトがあります。この場合、uBlock Originではスペイン/ポルトガル語用のフィルタを購読するのが前提となりますが、実際にそうされている日本人利用者がどれほどいるか疑問です。AdGuradにはフィルタの自動有効化機能があるためこうした問題は起きにくいですが、人によってはめったに訪れないサイトのフィルタを大量購読する結果になります。

1-9: uAssetsでcan't fixとなっているものは、いたちごっこの結果、対策が副作用をはらむものとなってしまったものです。一方、迂回広告やポップアップ、迷惑要素の中にはフィルタで対処できないものもあります。

1-10: 同リストのソースのほとんどはuAssetsとAdGuardFiltersであり、uBlock filters, Base, または各言語用フィルタのいずれかで対処されます(作者自身、大部分冗長であることを認めています)。しかしそれらと異なるフィルタ記法も多く、それらを購読している人には無駄になるのみならず、干渉によりかえってアンチ広告ブロックを起動してしまったり、不具合を起こしたりする場合もあります(。ほかにもときどきIssueに報告されています)。加えて、多くの汎用非表示用が無効にされており、「汎用整形フィルターを無視する」同様、枠残りなどの原因ともなります。たまにこれらを報告する人がいますが、「同リストの目的はサイトへのアクセスを可能にすることであり、副作用は関係ない。」として追い返されています(例:https://github.com/bogachenko/fuckfuckadblock/issues/204)。広告の素通りも辞さず(「A 4-6と同様の理由」)、たとえば@@|http*:*/ima3.js|$script,xmlhttprequestというルールは確かに一部のアンチ広告ブロックに有効ですが、特定の広告が素通りするようになります。なお、同リストへの直接の報告も、大半はuBlock filtersに取り込まれています。

Q 1-8 uBlock OriginもNanoのように売却されないか心配です。

A 1-8

確かなことは何も言えませんが、個人的な意見としては、Raymond Hill(uBlock Originの開発者、gorhill)は開発を中止することはあっても売却やその他ユーザーを危険にさらすことはないんじゃないかと思います。彼自身が今回の騒動で述べているように、現在の広告ブロック拡張機能は強大な権限を持っており、開発者を信用できなければ使うべきではありません。私はuBlock Originの前々身であるHttp Switchboardの誕生にも立ち会っている最初期ユーザーの一人で、そのころから何度か言葉を交わしていますが、ことセキュリティやプライバシーには厳格な人です。ほかの悪質な拡張機能を見回ったり、HTMLの書き換え機能をセキュリティ上の問題で却下したり(同機能を採用したAdblock Plusは後に脆弱性として指摘されることに)、例には事欠きません。また、お金に影響されるのを避けるため寄付すら拒否しており、儲け話の誘いがあればさらし者にしています

Q 1-9 初心者におすすめのブロッカーを教えてください。

A 1-9

PCではブラウザ上のブロックで大抵の人は足りると思います。この場合、一番のおすすめはuBlock Originです。Macは使っていないのでわかりませんが、FirefoxならuBlock Originが使えるようです。モバイルではアプリ内の広告もまれではないため、デバイス全体をカバーできた方がよいでしょう。AdGuard for Android/AdGuard for iOS(PlayストアにあるAdGuardは似て非なるものですので注意)がもっともメジャーで、かつ機能的にも十分だと思います1-11なんJ AdGuard部さんに記事がまとまっています。なお、iOSではiOS15と14以下で機能に大きな差があります。ネットワーク全体をカバーするには、Pi-holeやAdGuard Homeを使う方法と、DNSキャッシュサーバーを広告ブロック機能のあるものにする簡易的な方法があります。AdGuard Homeについては280blockerさんがわかりやすい記事を書いてくださっています。ただしこれらはドメイン単位の粗いブロックしかできないため、各デバイスのブロッカーを置き換えることはできません。少々乱暴に、主要なブロッカーを機能を機能が強力な順に並べる(フィルタによる差は無視)と

AdGuard(iOS、コンテンツブロッカーを除く), uBlock Origin > Brave > Adblock Plus, AdBlock, Safariコンテンツブロッカー(Mac, iOS15), Chromium Manifest V3下のブロッカー >> Safariコンテンツブロッカー(iOS14), Vivaldi >> ドメインブロック(hostsファイル、広告ブロックDNS、Pi-holeなど)

のようになると思います。

1-11: Android上でuBlock Originを使う場合、Firefoxにインストールするのが無難です。よく挙げられるKiwiブラウザはもともと公式にサポートされていない上に、最近の更新でuBlock Originなどのコンテンツブロッカーが機能しないURLが大量に追加されました。

Q 1-10 ブロッカーを複数入れてもいいですか?

A 1-10

やめてください。1.で述べたブロッカーとフィルタの区別が理解できれば、無意味なことがわかるはずです1-12。しかもuBlock Originのリソースリダイレクトルールを無効にしてしまい、いたずらに不具合、アンチ広告ブロック、広告再挿入を引き起こしてしまいますし、$ghide$badfilterも無駄にしてしまいます。ブロックを強化したり、アンチ広告ブロックを除去したりしたいのでしたら、するべきことはブロッカーの複数使用ではなく、適切なフィルタの選択です。中級者以上の方であれば、ブラウザの広告ブロック拡張機能にDNSブラックホールなどネットワーク全体のブロックを組み合わせるのもありですが、不具合への対処といった点から初心者にはおすすめしづらいものがあります1-13。また、トラッキング対策のGhosteryやPrivacy Badgerなどを勧める人もいますが、これもほとんど意味がありません。多くの論文で、uBlock Origin(デフォルト設定)が最高レベルのトラッキング保護と高パフォーマンスを両立していることが実証されています。トラッキング対策を強化したいなら、ブロッカーの併用などよりMedium modeといったデフォルト拒否の採用を考えるべきです。

2022年8月3日追記:Windscribe VPNの拡張機能、Windscribe - Free Proxy and Ad Blockerは非常に古いバージョンのuBlock Originを組み込んでおり、しばしば問題を起こしています。最新のuBlock Originを導入して同拡張機能のブロック機能は無効にすることをおすすめします。なお、この件についてuBlock Originの作者が直接抗議しており、Windscribe側も対応を約束しましたが何年たっても、再三要請しても果たされていません。個人的に、Windscribeは新興VPNの中では比較的よいサービスだと思っていますが開発者の倫理意識には疑問を抱かずを得ず、残念です。

1-12: たとえばuBlock OriginにAdblock Plusを追加した場合、理論上追加されるブロック項目はuBlock内製フィルタとABP filtersの差分になります。ABP filtersは日本のサイトは一切扱っておらず、海外についてもフランス、ポーランド、ロシア、中国などいくつかの言語を除けばuBlock内製フィルタに遠く及びません。これらの言語は、uBlock Originが(Adblock Plusと異なり)地域用フィルタに高度な文法を利用可能なフィルタリストを採用しているため、内製フィルタで対応する必要がないものになります。また、ABP filtersへの報告でuBlock Originに有用なものはuBlock filtersに取り込んでいるのですが、必ずしもコミットで言及しないため、各リポジトリのコミット内容をきちんと把握している人でなければ知らないかもしれません。主要なリスト間にはこうした非自明な関係性が多数あります。なお、併用したブロッカーのカウンターやログに計上されるのはブロック漏れではありません。これはFirefoxのトラッキング防止や、ブラウザ上のブロックとAdGuard for Android/Windowsを併用した場合にもあてはまります。

1-13: たまに、コンピュータのリソースを使わないからパブリックDNSでのブロックのほうが処理が速いと信じている人がいます。通信のフローを考えれば自明なはずですが、ブラウザ上でブロックすればそもそもDNSや広告サーバーへの通信自体が発生しないのに対し、パブリックDNSでのブロックはキャッシュがなければDNSの応答を待つ必要があります。ブラウザ組込みのブロック機能を除けば、アプリケーション版AdGuardのみが、場合によりブラウザ拡張機能より先にブロックすることがありますが、これは一定のコストがかかる方法のため必ずしもパフォーマンス上ベターとはいえません。ただ、ブラウザ上でもブロックしている場合、ブロック漏れにみえるおそれがあります。なお、Chromium拡張機能ではprefetchがブロックできず、こちらはある意味本当の漏れですが、prefetchではハンドシェイクやTLSネゴシエーションまでしか行われないため、問題とみなすかは人によるでしょう。

Q 1-11 AdGuardとuBlock Originの違いについて教えてください/どちらがよいのでしょうか。

A 1-11

両者間には非常に多くの違いがあり、ここで詳細に論じる余裕はありませんし単純にどちらが優れているということもありません。さらにAdGuardの場合、拡張機能とアプリ版ではまったく別といってよいですし、iOS版もまた別物です。最終的には各自が何をどこまでしたいのか、どこを重視するのかという問題になってきます。まず、パフォーマンスについてはuBlock Originに利があります。ブロックにせよ非表示にせよ、正しくフィルタを書けばフィルタ数が問題にならないといえるのはuBlock Originならではです。人によっては完全無料であることやオープンソースであることもポイントになるかもしれません。また、AdGuard Japaneseを除いたすべての日本用フィルタリストがuBlock Originを前提としており、たまにAdGuardで互換性の問題が起こることがあります。上級者で動的フィルタリングが利点となる方もいると思います。一方、AdGuardの利点としては、アプリ版ならデバイス全体をカバーできることがまず挙げられます。ChromeがManifest V2を廃棄しても影響を受けません。人によってはステルスモードもポイントになるでしょう。上級者の方には、別途ユーザースクリプト用の拡張機能などを用いたり、面倒な設定をしたりせずとも自由度の高いスクリプト挿入ができるのも魅力かもしれません。ブロック機能自体については違いは大きくなく、どちらでも十分なブロックができます1-14。ただ、実際のブロック性能はフィルタによって決まるため、違いは出てきます。これもどちらがよいと単純にいえるものではないですが、アンチ広告ブロックへの遭遇率はuBlock Originのほうが少し低いです。これは、uBlock filtersがアンチ広告ブロックプラグインへの汎用解を採用したり、ある種のリクエストをデフォルトでredirect-resourcesに回したりしているためで、ブラウザ拡張機能のみである(多様なプラットフォームを考慮する必要がない)ことが利点となっています(AdGuardに当サイト提供のAdGuard Japanese filter Plusを追加していただくと理論上はほぼ同等になりますが、プラットフォームによっては機能しません)。一方、AdGuardのフィルタはサイトの外見をより丁寧に整え、追跡防止フィルタはuBlock Origin標準のEasyPrivacyより不具合が少ない傾向にあります。また、モバイルアプリのトラッキング対策はEasyPrivacyより充実しています。

1-14: サポートしているフィルタオプションやスクリプトレットの種類はAdGuardがやや多く、カスタムスクリプトが使えるメリットもあり自由度ではAdGuardが上回りますが、必要性の高いものは結局両者とも採用します。両者に貢献しているフィルタ作者としては、サポートの有無よりも細かな仕様の違いが問題になることが多いです。上述のYouTubeの問題もjson-pruneの違いによるものでした。

Q 1-12 ブロッカーの性能を手軽に比較できるテストサイトを教えてください。

A 1-12

ありません。いじわるではなく、本当にないのであきらめてください。Ad Blocker Testなどは有名かもしれませんが、こんなものでブロッカーの性能は評価できません。このサイトが行っているのは、いろいろな広告サーバー(どういう基準で選ばれたのか不明)に空っぽのxmlhttprequestを投げ、それらが狭い意味でブロックされたかどうかを評価するというものです。しかし、実際にそれらのサーバーが使って1-15いるURLと異なるため、現実ならブロックされるのにテストでは失敗判定になるケースが多数あります。また、ウェブ上のテストなのにモバイルアプリのトラッカーを多数含んでいたり、クリックスルートラッカーという、本来リクエストを発生させずユーザーがリンクをクリックしたときのみ機能するものも含んでいたりします。挙句の果てにリソースリダイレクトがされるとブロック判定に失敗するためuBlock Origin標準設定の評価が大きく落ちます。きちんと信頼性のある広告ブロックテストを作ることは理論上は可能ですが、AV-Comparativesのような機関でなければ難しいと思います。

また、「広告が多いページ」をテストに使うのもナンセンスです。視覚的に広告が多くても、それらが単一のよく知られた広告サーバーから配信されていることはよくあります。また、多数のrevolving adservers(数時間ごとに切り替わる広告サーバー)を使うサイトでも、個別対応されればそれで終わりです。個別対応も広告サーバーの登録も必ずしも系統的に行われるわけではないため、ほとんど同一の二つのサイトのうち片方だけしっかりブロックされているようなこともよくあります。そのため、フィルタ作者がrevolving adserversを収集する場合は特定のサイトではなく、そういったサイトを効率的に数十回り、そのときたまたま漏れているものを追加するようにします。木ではなく森をみなければ、まともな性能評価はできません。

1-15: パスを含んでいない、リクエストタイプが異なるというのみならず、サブドメインさえ現実と違う場合がありドメインリストの評価すら正しくできません。たとえばfreshmarketer.comは、現実のトラッカーとしては必ずcdn.freshmarketer.comとして使われるためPeter Lowe’s Ad and tracking server listでブロックされますが(本稿執筆時点で、実際にはもう稼働していない模様)、このテストではhttps://freshmarketer.com/というURLのためブロックされません。

Q 1-13 Braveはアフィリエイトリンクを挿入したと聞きました。

A 1-13

これは事実であり、Braveに関する懸念事項の一つなのですが、日本ではいろいろ尾ひれがついて広まっている気がします。「アフィリエイトの挿入」「リンクを書き換えた」というとバックグラウンドでこっそりURLを書き換える動作がイメージされますが、Braveが行ったのはURLバーでの検索時の検索候補(サジェスト)において、Binanceなどいくつかのサイトのデフォルト候補(そのままEnterを押したら採用される候補)にアフィリエイトを付加したというものです。サジェストを無効にしている場合や、ほかの候補を選択した場合には影響はありません。また、これがトラッキングだったという話も耳にしますが、アフィリエイトコードはBraveのソースコードにハードコードされていたものであり、サイトにはBraveから来たという以上の情報は伝わりません。Braveから来たというのはどのみちわかる情報ですし1-16、Braveもこのコードでユーザーを追跡することはできません。報告者であるcryptonator1337氏の指摘もあくまでモラルや法的な面についてであり、プライバシーではありません1-17。もちろん、こんなことをする企業だからプライバシー面でも信頼できないという主張は成り立ちます。なお、これ以外にBraveのアフィリエイトリンク挿入とされるインシデントは起きていないはずです。検索していくとBraveがAmazonのアフィリエイトを挿入していたなどという話がみつかりますが、もし事実でありご存じの方がいましたらソースとともに教えてください。

Braveは各方面で議論の的となっていますが、一般にはあまり知られていない論点として、BraveがuBlock Originのアクセス解析ブロックを迂回した件があります。Brave自身がuBlock Originのフィルタを使ってアクセス解析をブロックしているのに、自分のアクセス解析は通そうとするのは倫理的とはいえないでしょう(AdGuardは自社のアクセス解析もブロックしています)。また、日本では一時期多くのサイトがBraveに誘導するアンチ広告ブロックを設置しました。これについてBraveの中の人に聞いたところ、リファラルコードをどう使うかはサイト次第であり、報告があれば対応したであろうとのことですが、Braveは本当にこれらを把握していなかったのかなど、個人的には疑問が残ります(リファラルプログラムは終了しており、現在こうしたアンチ広告ブロックをみることはないはずです)。

1-16: ユーザーエージェントをChromeとそろえたところで、BATなどを通してサイトとインタラクションする性質上、Braveであることは隠せません。このため多くのサイトがアンチBraveスクリプト(典型的にはnavigator.braveを検知)を設置しており、この点も批判されることがあります。

1-17: アフィリエイトと明示しないのは違法だという指摘をしていた記憶があるのですが、ソースがみつかりませんでした。消された?

Q 1-14 uBlock Originは脆弱性が見つかったからやめたほうがいいといわれました。

A 1-14

まったくの誤解です。そもそも、脆弱性が見つかるのはよいことです。ある程度の規模のソフトウェアなら必ずといってよいほど脆弱性は存在します1-18。本当に怖いのは、あるのにみつかっていない脆弱性で、これが悪用されるとゼロデイ攻撃として被害を出すため、多くのIT企業が莫大な報奨金をかけて脆弱性報告を募集しています。脆弱性のニュースをみたらまず注意すべきは悪用可能性です。脆弱性はどれも同じではなく、現実的には問題にならないものも少なくありません今回でいうと、ユーザーは悪意のあるフィルタリストを購読しなければなりません。ユーザーが自分で購読してしまう可能性もありますが1-19、よりありそうなのはフィルタ作者のアカウントやフィルタをホストしているサイトが乗っ取られた場合でしょう。これまでにそうした事例は報告されていませんが、可能性としてはあり得るので、ある程度危険な脆弱性だったといえます。なお、こちらのコメントにあるように、脆弱性がなくてもフィルタはサイトのセキュリティを低下させたり、サイトを壊したりすることが可能です。フィルタを購読するなら、多かれ少なかれその作者を信頼しなければなりません(報告者の一人であるTavis Ormandy氏はこの点を当初誤解していたようです)。次に、脆弱性の内容も様々です。今回の脆弱性はuBlock Originのセキュリティ対策に穴があったというもので、実際の攻撃には様々な工夫が凝らされていますが、一般にはそもそも対策すらしていないものや、素人でも気づくような脆弱性が多数あります。A 1-8で述べたように、uBlock OriginはのちにAdblock Plusの脆弱性となったURLの書き換え機能を、セキュリティを理由に当初から却下しています1-20。Adblock Plusは今回の脆弱性の影響は受けませんが、これはセキュリティ対策によるものではなく単に機能が欠如しているだけです。Ormandy氏が認めているように、実際のところuBlock Originはセキュリティに細心の注意を払って開発されています。最後に脆弱性への対応も重要です。タイムラインをみていただくとわかるように、今回の脆弱性は極めて迅速に対応されています。

1-18: 興味のある方はほかのブロッカーの脆弱性、たとえばAdGuardAdblock PlusBraveなどと比較してみるとよいでしょう。とくにAdblock PlusのCVE-2019-11593はuBlock OriginのCSS Injectionと攻撃条件が同じ(悪意あるリストの購読)です。

1-19: バージョン1.30.0から購読可能なURLがGithubなど一部の著名サイトに制限され、購読時にリストのページに飛び内容を確認した上で、初めて購読できるよう変更されています。これらのサイトに悪意のあるリストをホストすることは可能ですが、個人サイトなどより衆人の目が届きやすく、緩和効果はあると思われます。

1-20: 参考:Users may also switch to uBlock Origin, which does not support the vulnerable filter option. The feature has been rejected by the maintainer of the extension, citing concerns over security and performance.

2. AdGuard

Q 2-1 シェアボタンやツイートボタンが消えてしまいます

A 2-1

AdGuardインストール時にSNSウィジェットのブロックを選択していたなら至極当然です。これらを表示するため、ブロックを(そのサイトで)オフにするのはとんでもない話です。対応は簡単で、設定 > フィルタから「SNSウィジェット」または「ソーシャル」の項目を無効にしてください。インストール時のナビゲーションではデフォルトでチェックが入っているので、気づかずに有効にしてしまった方が多いのかもしれません。これに限らず、よくわからずにフィルタを有効にしてしまい、不具合に遭遇してブロッカーをオフにしてしまう方が多いようです。

3. uBlock Origin

Q 3-1 ブロックのカウンターが上がり続けます。/Adblock PlusのほうがuBlock Originよりたくさんブロックしているようです。

A 3-1

カウンターの上昇は何も問題ありません。どういうわけか、カウンターが上がり続けるとパフォーマンスに悪影響があると信じている人が多いようです。確かに、ブロックされた場合に大量のリクエストを送り続けるケースはあり、フリーズしたりCPU使用率が跳ね上がったりしますがこれはそのサイトの問題です。1秒に1つ程度のカウンター上昇なら何も影響ありません。どうしても信じられないなら、開発者ツールからパフォーマンスレコードをとって報告してください。また、逆にカウンターの数字が大きいほどたくさんブロックしてくれていると信じてアドオンやフィルタを比較する人もいますが、これも一概に言えません。Adblock PlusとuBlock Originではカウンターの仕様が異なりますし、HTMLフィルタで除去してしまえばカウンターの数字は上がりません。そもそもブロッカー検知用プローブ(アンチ広告ブロックとは無関係に、統計的情報を得るため使われることも多いです)などはブロックしない方がいいのですが、この点を理解されていない方も多そうです()。

Q 3-2 uBlockとuBlock Originの違いは何ですか?

A 3-2

複雑な事情があるのですが、uBlockはいわば偽物です。歴史的には、HttpSwitchboardという拡張機能を分岐する形で2014年にuBlockが生まれます(この時点では本物)。しかし、2015年4月に主任開発者のRaymond Hill(gorhill)がユーザーサポートの負担に耐えかね、プロジェクトを譲渡するとともに自らはuBlockのフォークとしてuBlock Originの開発を始めます。このあたりの事情はこちらのリンクによく説明されています。ただ、ソースの訳としてはすばらしいのですが、前後の文脈を知っているものからみると細かいところは少し違います3-1。いずれにせよ、プロジェクトを譲り受けたChris Aljoudiはろくに開発を行わず、寄付金を集めることに腐心します。2018年にはAdBlockに買収され、2022年にはアーカイブ化されました(実質的に開発終了)。

3-1:1番目の点として、「uBlock開発チームに渡したつもりだったのに、Chrisだけに渡っていた」というわけではありません。uBlock開発チームは2015年1月に立ち上げられ、gorhillを中心にChrisなど3名が所属していました。そもそもの始まりをみていただくとわかりますが、gorhillはあくまでChrisにプロジェクトを任せたのであり、当時gorhillと会話していたものの間でもChris版uBlockとgorhill版uBlock Originにわかれたというのは共通認識でした。2番目に、uBlockの運営方針を疑問視したからOriginの開発を始めたわけではなく、譲渡直後にすでにOriginの開発は始まっており、そのあとでChrisの問題行動が始まったという流れです。なお、ソースはその後更新されており、後日談があります。ChrisはWikipediaを書き換えたり、Redditでデマを吹聴したりしてOriginでないuBlockに誘導しようとしました。

Q 3-3 uBlock Originでフィルタのパフォーマンスを測りたいのですが

A 3-3

ここではChromiumブラウザでの測定を前提とします。Firefoxでも可能ですが、(ローカル)サーバーが必要です。まず、こちらからrequests.jsonをダウンロードしてください。これがベンチマーク対象となるURLデータセットです。次に、「私は上級者です」にチェックを入れ、隣の歯車アイコンからrequests.jsonのファイルパスをfileスキームに続けて打ち込み設定します(たとえばfile:///C:/Users/User/Downloads/requests.jsonのようになります)。Chrome拡張機能の設定から、「ファイルの URL へのアクセスを許可する」にチェックを入れてください。最後に、uBlock Originの「サポート」タブにある「さらに表示」をクリックし、開いたタブ内のSNFE: Benchmarkをクリックすると、ダウンロードしたデータセットに対するベンチマークが開始されます。この方法で測定できるのはネットワークルールのパフォーマンスである(整形ルールはなし)点に注意してください。

4. フィルタ一般

Q 4-1 フィルタを追加しすぎると重くなりますか?

A 4-1

ご利用のブロッカーとフィルタの種類や書き方に依存します。AdGuardではそうなる可能性はありますが、フィルタの種類や書き方によって影響は大きく異なるため、単純な量の問題ではありません。uBlock Originでは、正しく書けばフィルタ/ルールの数は処理時間やCPU消費に影響を与えません(文字列長など、別の要因のほうが大きな影響を与えます)。「正しく書けば」についてはA 4-3, A 4-4に要点をまとめていますが、ABP文法からは自明でないことが多いです(uBlock Origin開発者がいうには、いつか暇があれば効率的なフィルターライティングのポイントをまとめたいとのこと)。逆に、たった一つの非効率なフィルタがパフォーマンスを悪化させた例は過去にいくつもあり、数は問題になりませんが質は問題になります。ですから、フィルタをいくら追加しても重くならないというのも間違いで、質を評価する必要があります。なぜ数が影響しないかについて、大幅に単純化した説明を試みてみます。

あるリクエストが何万ものフィルタのどれかにマッチするかしないかを判定するとき、一個一個ルールを調べていたのでは効率が悪いです。もしそのリクエストがスクリプトなら、$image指定された(= 画像ブロック用の)ルールはマッチする可能性がまったくなく、$script指定されたルールとタイプ指定なしのルールだけ調べれば十分です。これらのタイプ指定はメモリ上にフラグとして置かれており、一括してフィルタリングできるため$image指定されたルールが1個であろうと10000個であろうと関係ありません。1個ないし10000個のルールはマッチング処理の早い段階で、同様の計算コストで候補から除外されます。このような手続きをさらにパーティ種別やトークンに対してもおこなうと、最終的にマッチする見込みのある、調べる価値のあるルールはそれほど多く残らず、その数は元のルール数が指数関数的に増えない限りほとんど変わりません(トークンの部分はもう少し複雑)。

汎用整形フィルタに対してはuBlock OriginはDOM surveyorというものを用い、そのページで実際に必要な汎用整形フィルタだけを挿入するためやはり数は問題になりません4-1。AdGuardでは汎用非表示フィルタの数はパフォーマンスに影響を与えますが、実際は数だけでなく質にもよります。

4-1 :厳密にはLow-generic cosmstic filtersの場合のみ。

メモリ消費とアドオン起動時間、フィルタ更新時の処理時間はフィルタ数の影響を受けます。とはいえFirefox上のuBlock Originでは10万を超えるフィルタを搭載してもそれによるメモリ消費は10MBに満たず、アドオン起動時間や更新時の処理時間もわずかな差です。

Q 4-2 クラス名が毎回ランダムに変わる要素はどう消せばいいのでしょうか?/「要素をブロック」「このページの広告をブロックする」で消したものがすぐ復活します。

A 4-2

uBlock Originの「要素をブロック」はフィルタ作者のための補助ツールです。同機能で自動生成されたルールをたくさん作るのはおすすめしません。AdGuardの「このページの広告をブロックする」は補助ツールではありませんが同様です4-2。クラス名が変わる場合、まずはクラス名以外で使える属性がないか、開発者ツールで見てみるのがよいと思います。もしなければ、該当要素の先祖や子孫で安定した属性を持つものや、使えそうなテキストを含むものがないか探します。そうしたものがあれば(必ずと言っていいほどあります)、あとはProcedural cosmetic filtersを使うだけです。初心者であれば:has, :has-text:upwardだけでも十分でしょう。

4-2: スライダーの選び方にもよりますが、YouTubeのような複雑なサイトで下手にフィルタを作ると、のちに問題に見舞われるケースもあります。基本的に、要素をブロックは一時しのぎ程度に使っていただくのが無難かと思います。そのためのElement-zapper(要素抹消モード)もあります。

Q 4-3 uBlock Originで効率的なネットワークルールの書き方を教えてください。

A 4-3

こちらに要点がまとまっています。大事なのは、

  1. 良質なトークンが抽出されるようにすること、すなわち、仕切られた語(できればbad tokenでない)をフィルタ中に確保する(8文字以上の単語は切り捨てられ最初の7文字が使用されます)。
  2. それが難しいときは、タイプオプションやドメイン指定によりできるだけ限定する
  3. フィルタ中に2つ以上のワイルドカードを使うのはなるべく避ける

効率的なフィルタは正しいフィルタの上に初めて成り立ちます。残念ながら、インターネット上に公開・共有されているフィルタには(ケアレスミスの範囲を超えて)間違ったものが少なくありません。たとえば、||.example.com^||*.example.com^のようなフィルタはuBlock Originでは基本的に間違いです(AdGuardではiOSのために使う場合があるようです)。これではドメインアンカーの意味がなく、誤爆の可能性が高まります。また、/path/to/が正規表現フィルタになってしまうことを理解していなさそうなもの、セパレータ^を「とにかくフィルタの最後につけるもの」と誤解しているようなケースも見受けられます。

なお、正規表現はとくに注意が必要で、最悪の場合ブラウザがハングすることもあります。(https以外の)トークンを確保することだけでなく、ステップ数も考慮して書くのが望ましいです。ステップ数はマッチする場合、しない場合、もう少しでする場合のすべてを検討する必要があります。具体的なコツはこのFAQの範囲を超えますし、フィルタに限った話でもないので他に譲ります。

Q 4-4 uBlock Originで効率的な非表示ルールの書き方を教えてください。

A 4-4

細かいTipsはありますが、一番大切なのは最小マッチングを意識することです。通常の非表示ルールでもそうですが、Procedural cosmetic filtersと:style():remove()といったaction oepratorにおいてはとくに重要4-3、最初のprocedural operatorが評価するノード数を最小化し(ブラウザのCSS処理とは逆に、左から右に読む)、かつそのノードが存在するのはProcedural cosmetic filtersが必要なときのみとなるようにするのが理想です。これを怠るとたった一つのフィルタでもパフォーマンスの問題起こすことがあります。あるイラストサイトで実際にパフォーマンスの問題に直面した事例がありました。私のPCでもノード数が5桁(1000超のルールが多数)を超えるとサイトが使えないほどの遅延を生じましたが、消したい対象が存在するときだけ評価するように書きなおすと、ルールがいくら増えても一切遅延が生じないことを確認できました。

汎用整形フィルタの場合、Highly generic cosmetic filtersでなければ、すなわち###ad##.adのようなセレクタであれば数はパフォーマンスに影響しませんA 4-12の註4-10も参照。

4-3: リンク追加。フィルター作者でもこの点を順守していない人もいますし、知っていてもあまり気にしない人もいます。

https://github.com/uBlockOrigin/uAssets/issues/20792#issuecomment-1820079941

Q 4-5 :has()と:upward()は同じに見えますが、どちらがよいのでしょうか?

A 4-5

2024年03月19日追記:現在、Firefox ESRを除く主要ブラウザではCSS4の:has()擬似クラスがすでに利用可能であり、なるべく:has()を使ったほうがよいといえます。Firefox ESR 115でもlayout.css.has-selector.enabledtrueにすれば使えます。

目的とサイトの構造次第であり、どちらがよいということはありません。効果だけみると同じになることもありますが、パフォーマンスを考慮すればどちらを使うべきか自然に決まります(A 4-3参照)。なお、EasyListはAdblock Plus文法しか使えないこともあり非効率な:has()ルールを多く含みますが、著名なリストだから効率的に書かれているとは限らないという例かもしれません。

Q 4-6 uBlock Originでおすすめのフィルタ構成を教えてください。

A 4-6

フィルタ構成についてはこれが正解といえるものはなく、各自で調べたり試したりして自身の好みに合うものを選択するしかありません。ただ、間違いといえるものはあります。フィルタを解釈して評価できる人はまれなため、インターネット上には主観的な使用感や信念にもとづいた「おすすめ」がたくさん転がっています。たとえば、Adblock Warning Removal Listは、多くの人がイメージする(狭義の)アンチ広告ブロックは対象外でまったく効果がないのですが、以前はあちこちでアンチ広告ブロック対策に推奨されていました。ほかに、あまり正しく理解されていなさそうなリストとしてFanboy's Enhanced Tracking Listが挙げられます。このリストの最大部分は許可ルールによるブロッカー検知回避なのですが、ちょっと大雑把すぎて検知と関係ない広告スクリプトまで許可してしまっています。不要なスクリプトを走らせてまで一部の検知を回避することを、ユーザーが求めているかは疑問です4-4。NoCoinも意味のないリストです。コインマイニング自体、絶滅してはいないものの下火ですが4-5、NoCoinでブロックされるものはすべてEasyPrivacy + uBlock filters - Resource abuseでカバーされています。

初心者の方はともかく購読しすぎに注意することです。日本用フィルタ、特定用途用フィルタの多重購読はおすすめしません。おそらく、たくさん購読するとそれだけ多くブロックしてくれるという考えからなのでしょうが、これは正しくありません4-6。また、フィルタによる不具合は天災のようなもので、普段はあまり遭遇しませんが忘れたころにやってきます。多く購読すればするほど、メリットは薄くなっていき、不具合の確率ばかり高まります。そもそもフィルタの購読は「なんとなく役に立ちそう」というあいまいな感覚ではなく、実際のニーズに基づいて行うべきです

もう少し具体的に、PCの場合なら(あくまで参考程度にお願いします)

  • 内製:最低でもuBlock filtersは維持することをおすすめします。ほかのフィルタに比べると不具合の率が少なく、日本語サイト利用者でもメリットは大きいです。Badware risksやUnbreakは、明確な理由がなければ維持するのが無難でしょう。Quick fixesは一部のサイトのいたちごっこへの対策と、深刻な不具合の迅速な修正を兼ねるものです。
  • 広告:通常はEasyListを維持。非表示/整形の意味がわかっており、必要ない中級者以上の方ならEasyList without element hiding rulesも選択肢となります。これはEasyListから整形フィルタを除いたもので、初期には組込みリストの一つでした。
  • プライバシー:トラッキングを気にしない人は外してもよい4-7。気にする人やよくわからない人はEasyPrivacyの維持が基本ですが、平均的な不具合率が低い代わりにやや漏れが多いAdGuard Tracking Protectionへの切り替えも選択肢に入ります。両方併用については、無駄が多く不具合の確率も高まるものの、トラッキングのカバー率が最優先で不具合に自己対処できる人ならありかもしれません。Block Outsider Intrusion into LANはLANへのフィンガープリンティングやCSFRなどの攻撃を防ぐもので、不具合はまれです。一般にコンシューマー向けのルーター等LAN機器のセキュリティは低いと言われており、基本的なセキュリティ対策の補完として有効にしておくのはよいと思います。
  • マルウェアドメイン:お好みで。デフォルトのOnline Malicious URL BlocklistはGoogle Safe Browsingとデータ共有しているため、FirefoxやChromeでのメリットは大きくありません。Google Safe Browsingを使わないEdgeでのメリットは相対的に大きいでしょう。
  • 迷惑系:ソーシャルボタンを消したい人はAdGuard Social Mediaを追加してもよいでしょう。もちおさんが提供されていることりフィルタも検討してみてください。ほかの迷惑要素についても同じく、AdGuard Annoyancesまたはそのサブリストねぎフィルタからの選択をおすすめします。uBlock filters - Annoyancesはやや特殊で、主にコンテンツを阻害しない範囲の広告ブロック解除のお願いと、右クリック/コピー禁止系への対策になります。EasyList Cookieを含むFanboy系は不具合の率が高く、初心者にはおすすめしません。
  • 多目的:デフォルトのPeter Lowe'sはフィルタ数のわりに良い仕事を(主に海外サイトで)してくれているのですが、たまに誤爆することがありますし、しばしばトラッキングリンクをブロックします。日本のサイトを中心に見る方や、トラッキングを気にしない方は好みで外してよいと思います。余談ですが、EasyListはよく訴訟の対象になり、その場合、対象ドメインをEasyPrivacy(トラッキングも兼ねている場合)やPeter Lowe's(純粋な広告サーバー)に肩代わりしてもらうことがあります。
  • 地域・言語:英語、日本語以外のサイトをよく見る人はその言語のフィルタを追加。
  • カスタム:お好みで。当サイトではAdGuard Japaneseを補完するAdGuard Japanese filter Plusを提供しています。

日本のサイトしか見ないという方なら、昔から知られている豆腐フィルタまたはもちフィルタを中心に使用し、EasyList, EasyPrivacy, Peter Lowe's, AdGuard Japaneseを外す用法もありかもしれません。これについては賛否両論聞きますが、EasyListやEasyPrivacyの不具合が多めであることから個人的には理解できます。一方、EasyListを使用するのであればAdGuard Japaneseのほうが相性はよいでしょう(EasyListに起因するアンチ広告ブロックはもとより、EasyListの不具合でも日本のサイトであればAdGuard Japaneseで修正できるようになりました)。豆腐フィルタともちフィルタの併用を勧める人がいますが、これはほぼ意味がなく、豆腐フィルタだけで十分だと思います。もちフィルタだけが対応している非広告要素(セルププロモーション)がわずかにありますが、人によってはむしろ消したくないかもしれないもので、それらが気になる人だけ「要素をブロック」で対応するなどしたほうが堅実かつ無駄もないでしょう。もちフィルタの利点は最小限のルールによる不具合(とメモリ消費)の最小化であり、併用するとその意味がなくなります。

フィルタ構成とは別に、中級者以上の方であれば「汎用整形フィルターを無視する」はおすすめできるオプションです。パフォーマンスの向上に加え、誤爆やアンチ広告ブロックへの遭遇率を下げることもできます。その代わり広告枠やテキスト広告が隠し切れないケースも出てきます。

4-4: 汎用非表示が有効なら、結局検知されてしまうことが多いです。そもそも同リストで許可されている検知スクリプトは、多くがEasyListなどの主要フィルタですでにブロックから除外されています。

4-5: coinhiveをはじめ主要なマイナーのほとんどがサービス終了しており、フィルタ作者ですら実際に機能しているマイニングに会うことは極めてまれです。

4-6: 理由は大きく二つあります。まず、許可ルールは原則的にブロックルールに対して優先されます。ある程度の規模のフィルタリストであれば必ずといっていいほど不要になった許可ルールが含まれますし、リストによっては絞り込みが甘い許可ルールもあるかもしれません。こうした許可ルールによって広告が貫通するケースが報告されています(最近の)。もう一つは広告再挿入です。これはアンチ広告ブロックと原理は同じで、ブロッカーを検知し、アンチ広告ブロックの派手な警告の代わりにブロッカーを迂回する広告を再挿入するものです。あるリストがせっかく再挿入を惹起しないようにしていても、他のリストが惹起してしまうと意味がありません。

4-7: uBlock Originの開発者はこのような使い方(very easy mode)は実際は想定していないと述べており、まれにあるトラッカーをブロックしないことによる不具合については公式のサポートは受けられません。

Q 4-7 フィルタリストの選び方を教えてください。

A 4-7

実際の問題に遭遇してフィルタを購読する際は、まずは各ブロッカー組込みのフィルタの中から探すとよいと思います。どうしてもその中に適切なものがなければ、

  • 一定の評価を確立したフィルタで、広告ブロック界で長年の実績がある人やグループがメンテナンスしている
  • よく更新されている(広告ブロック用なら目安として週に一度、少なくとも月に一度。ソーシャルや迷惑系ならもっと低くてもよい)
  • それを購読することで実際に問題が解決する

の3点を確認してください。国内外を問わず「○○用」と銘打ったフィルタを勧める人がたまにいますが、ほとんどの場合意味がないどころか下手をすると不具合の原因にさえなります。たとえばアンチ広告ブロックについては、それ用をうたうフィルタを追加する前に標準のフィルタ構成で再現するか確かめるとよいでしょう。Youtubeの広告などは複雑なA/Bテストもあり、多数の情報が集まる標準のフィルタリストに勝るものはありません。アダルトサイト用としていちごフィルタを追加する人も多いようですが、アダルトサイトへの対応は標準フィルタリストのほうがはるかに網羅的で、内製フィルタ、EasyList、およびAdGuard Japaneseをすでに使っているなら追加の意味はありません4-8。標準のフィルタ構成は大多数の人に最適となるよう調整されており、中途半端な知識でいじるとおかしなことになることも多いです。以下では、uBlock Originの組込みフィルタの一つであるAdGuard Baseを有効にする場合、どういったメリットとデメリットがあるか概説します。十分な評価が確立され、かつuBlock Originでの使用を考慮して調整されているAdGuard Baseでさえも、むやみやたらと有効化すべきではないことがわかるかもしれません。

AdGuard Baseのメリット

  1. 一部uBlock filters未対応の広告、ポップアップ、アンチ広告ブロックに対応している

uBlock filtersメンテナーはAdGuardのIssueもある程度見ていますが、漏れはどうしてもあります。また、Baseにはアンチ広告ブロック対策という点では有効だがuBlock filtersの基準では採用できない汎用例外ルールがいくつかあり、これらによってBase有効時のみ惹起されないアンチ広告ブロックは何度か見たことがあります。ほかにChromium限定のメリットとして、BaseはCNAMEを利用して迂回を狙う広告サーバーをブロックしています。一部はuBlock filtersでも正規表現などでカバーしていますが、限界はあります。またおまけとして、AdGuardもuBlock Originも各言語用リストで対応されない問題を自分のところで扱う方針は同じなのですが、Baseのほうが各言語用ルールが充実しています。そのため、「ある言語のサイトを頻繁に訪れるわけではないのでその言語用のリストは有効にしていないが、たまたまその言語のサイトを見ることになった」ような場合に、余計な広告を見ないで済む場合もあるかもしれません。

  1. 広告による空白や枠残り、残骸などの整形を丁寧にやっていることが多い

uBlock filtersの古参メンテナーはこれらにあまり興味がない人が多く、またgorhillが示した内部的な方針(あくまで目安で、実際は各メンテナーの判断に委ねられている)でもページ下部の小さな空白などは無視してよいとされています。一方、AdGuardはこれらを比較的丁寧に処理しています。サイト指定の整形フィルタが多いため、英語サイトをよく見る人で汎用非表示を無効化している場合もレイアウトへの影響を緩和できるでしょう。

AdGuard Baseのデメリット

  1. ルールの干渉により不具合が起きたり、アンチ広告ブロックを起動してしまったりすることがある

多いのはスクリプトレットやリダイレクトリソース同士の干渉です。これらは頻繁に起こるわけではありませんが、珍しいというほどでもありません。A 1-7で述べた例などは運よく管理人が気づき、なおかつ影響が大きく確実に発生するため対応いたしましたが、気づかれていないケースもあるでしょう。このような干渉はBaseだけでなくスクリプトレットやリダイレクトリソースを使うすべてのフィルタリストに起こりうるため、それらの構文を含むリストを購読するときは注意が必要です。実際、組込みの地域・言語用リストのうちフランス語や中国語はAdGuardのリストに置き換えられたのにドイツ語はEasyList Germanyのままですが、その理由はuBlock filtersがすでにドイツ語サイトのルールを多く含み、干渉が懸念されるからです。

  1. 前提条件の違いにより不具合が起きることがある

たとえばCNAME uncloakingが考慮されていないため、Firefox上で大きな破損が広範に起きたこともあります。ほかにもCNAME由来の破損をいくつか把握していますが、対応を後回しにしてしまっています。

  1. 一部の古いルールが乱暴

たとえば##.top-bannersというルールは、深刻ではないにせよいくつもの誤爆を引き起こしており()、機会があれば削除を提案しようと思っています。__htas用とコメントされているルールも、ドメイン指定されていながらいくつかの動画を破損しており、一件は例外で対応しましたが、PRを開くか多数の報告が来るまでは根本的に対処されなさそうです (2022年5月30日修正:現在は修正済み)。

  1. uBlock Originにとって最適でないルールが多い

uBlock Originで効率の劣るルールが比較的多いのは否めません。一般のユーザーがパフォーマンスの影響に気づくことはめったにないと思いますが、Baseで追加的にブロックされる通信はまれであること、フィルタの無駄な重複が大量に出ることも併せますと、パフォーマンスを優先するならBaseは購読しないほうがよい、といっても間違いではないと思います。

  1. 廃れたルールが多い

不要になったルールが大量にあります。uBlock filtersは日常的にクリーンアップをおこなっているためここまで深刻ではありません。当管理人も暇を見つけてはBaseのクリーンアップをおこなっていますが、焼け石に水と言わざるを得ません。AdGuardのCTOも認識していますが、将来的に自動処理したいらしく、当面はどうにもなりません。メモリの浪費だけならよいとしても、廃れたルールが問題を起こすこともあるのでなんとかしたいと感じています。

4-8: よく知られているように、アダルトサイトは違法サイト、短縮リンクと並んで迂回広告の最前線であり続けているため、常にマークされています。もち系フィルタのポイントは、目的に合わせた最小構成とすることで不具合(とメモリ使用量)を最小限に抑える点にあります。

Q 4-8 uBlock Origin以外のブロッカー(PC)でおすすめのフィルタ構成を教えてください。

A 4-8

AdGuardでは組込みのフィルタを使っていただくのが無難と思います。AdGuardはuBlock Origin文法の大部分をサポートしていることになっていますが、実際は仕様の違いにより効かなかったり、動作が異なったりすることもあり、そうした細かい仕様は公式ドキュメントに必ずしも載っていません。当然ですが、AdGuardのフィルタはAdGuard上で完璧に動作します4-9。AdGuard日本語フィルタはかつて不評でしたが、今では昔と別物といってよいほど精度が高くなっています。

Braveも基本的には組込みのフィルタでよいと思いますが(A 1-4も参照)、モバイルでご利用の場合はchrome://adblockからAdGuard Mobile Ads filterの追加を強くおすすめいたします(モバイルではデフォルトで有効にすべきと思いますが、リジェクトされています)。ちなみにchrome://adblockにはフィルターを設定し過ぎるとパフォーマンスが悪化しますと書かれていますが、現在のBraveはuBlock Originのアルゴリズムを採用しているためフィルタの数がパフォーマンスに影響することはありません(参考:Brave自身の記事

Vivaldiでは、著作権の問題からもちフィルタ、たまごフィルタが日本用に採用されましたが、これらもuBlock Originを前提としています(VivaldiがuBlock文法をサポートするつもりなら歓迎すべきことですが)。Vivaldiでデフォルト有効のEasyList等と併用した場合、かなりの無駄も発生します。少なくともEasyList系を維持するのであれば、PCではiOS用AdGuard日本語フィルタに置き換えるのがよいかと思います。ただし、A 1-4で述べたように、現在Vivaldiのブロック機能は簡易的なものでPC用の本格的なブロッカーとは呼べません。一方で、Vivaldi上でuBlock Originを使うと固有のバグが多く、uBlock Origin開発者が公式にはサポートしないと宣言する事態になっています。

4-9: 逆に言うと、uBlock Originでは動作しなかったり、動作が異なったりするフィルタもあるほか、パフォーマンス面で最適とはいえないフィルタもありますが、そうしたフィルタの割合は大きくはありません。

Q 4-9 EasyListやEasyPrivacyは不具合が多いと聞きます。

A 4-9

事実です。私もこれまでいろいろな形で、数十件は報告しています。また、EasyPrivacyは純粋な追跡・解析以外にプッシュ通知やセキュリティシールなども一部ブロックしており、人によっては困ることもあるかもしれません。なお、ルールが多いから不具合が多いわけではありません。大部分のルールは不具合と無関係な一方、誤爆しやすいルールというのがあります。またアンチ広告ブロックを惹起しやすいという議論も聞きます。これは間違ってはいませんが、「それほど違わない」という印象です。EasyListで"Remove unused filter"というコメントで削除されているルールの多くは、私を含むフィルタ作者からのフィードバックに基づくアンチ広告ブロックのトリガーです。逆に日本用フィルタでのみトリガーされるものもあり、とくに海外サイトではその傾向が強いです。ところで、不具合が多い理由の一つは日本のユーザーからの報告がほとんどないことです。EasyListでなくとも、日本では280blockerさんを唯一の例外として、フィルタ作者への報告自体がまばらな印象です。すべてのユーザーが不具合を自己修正できるとは思えないため、ブロックをそのサイトで無効にしたり、動的フィルタリングの緑で上書きしたりといった対処をされている方が多いのではないかと思います。フィルタ作者はそういった「荒療治」より効果的な対処ができますし、あなたの報告がほかの多くのユーザーを助けるかもしれません。ぜひ積極的な報告をお願いします。uBlock Origin標準リストの不具合については、こちらでも受けつけています。

2021年4月12日追記:EasyListは海外用と認識されている場合があるようですが、実際は全世界の広告ブロックのための標準フィルタです。日本用のルールも多く含み、たとえば##.res_adなどはモバイル版5ちゃんねるくらいでしか使われていません。ABPのページに"Specialization: English"と書かれているのもそうした認識が広まった一因かもしれませんが、おそらく、これまでの日本用フィルタがEasyListの併用を前提としていなかったこともあると思います。

Q 4-10 ページをクリックすると発生するポップアップ/リダイレクトや「見えない広告」をなんとかしたいです

A 4-10

透明なオーバーレイを使用するケースはありますが、多くの場合、HTMLにクリックイベントが仕込まれているだけで「見えない広告」という表現はあまり適切ではありません。原因はケースバイケースで、シンプルなブロックルールで済む場合もあれば、スクリプトレットが必要な場合もあります。これらを用いるサイトの多くはアダルト、違法コンテンツ、または短縮プレミアムリンク系のサイトで、頻繁に仕様やドメインを変えてくるため個人フィルタでの十全な対応は困難です。これらのサイトを用いる方はEasyListとuBlock filtersの両方を有効にし、Adguard Japanese filter Plusを追加することをおすすめいたします。たいていは同時にAdGuard Japaneseでも対応しています。

Q 4-11 フィルタリストによるフィンガープリントが可能と聞きました。

A 4-11

2021年8月16日追記:Gizmodoで扱われたように、すでにFingerprintJSにオプションとして組み込まれていたようです。ただこちらをみる限り、実際にFingerprintJSユーザーが有効利用するには壁がありますし、uBlock Originをご利用であれば「汎用整形フィルターを無視する」のチェックにより防御可能です。そもそもEasyPrivacyではFingerprintJSを汎用フィルタであらかたブロックしており、スクリプトがリネームされている場合も見つけ次第対応しています。

心配するのはまったくの杞憂です。たとえばこのテストページで体験できますが、誤判定もありそれほど実用にならないでしょう。それでいて、日常的にリクエストログをみているフィルタ作者にはリストのフィンガープリンティングを試みているのが手に取るようにわかります。精度を高めようとすればなおさら隠すのは難しくなりますし、各リストの変更に追随する手間もかかります。実際にリストのフィンガープリントが疑われる例の報告はありませんし、みたこともありません。そもそも、広告ブロックユーザーのみが対象で、かつ大多数のユーザーが標準リストを使っている4-10時点でフィンガープリントとして単独では使い物にならず、やるとしたら趣味にしかなりません。ブラウザベンダーがフィンガープリント制限への動きを強めているとはいえ、既存のフィンガープリントライブラリはこんなものとは比較にならないほど高精度の判別が可能なので、それを適当にリネームして使うほうがはるかに賢明です(そういう例はあります。ただし多くはリネームすらしておらず、EasyPrivacyでブロックできます)。

4-10: 言語・地理による違いなどは、こんな手段を使わなくても判別できます。

Q 4-12 アンチ広告ブロック(広告ブロック解除要求)への対処法を教えてください。

A 4-12

ご自身でフィルタを書ける人は別として、最良の対処はフィルタ作者に報告することです。uBlock Origin標準設定で出る場合はこちらでも受けつけます。以下では、日本のサイトで比較的よくみるアンチ広告ブロックへの簡易的な対処をまとめました。内容的には、以前に「りぃのなんでも知恵袋」さんの記事にコメントさせていただいたものの更新になります。example.comでアンチ広告ブロックが出たという仮定です。参考画像は一例で、バリエーションがあります。100%の効果は保証できません。なお、ブロッカーの併用やフィルタの過剰購読を避け、(Firefoxのトラッキング防止やDNSでのブロックも使っていない)汎用整形フィルタを無効にすればこれらはめったにみることがないはずです。

  1. antiblock.orgの場合

以下のようなUIです。

antiblock_org_var1

antiblock_org_var2

antiadblock_org_var3

antiblock_org_var4

uBlock Originではexample.com##+js(acis, document.addEventListener, google_ad_client)、AdGuard(iOSおよびAdGuardコンテンツブロッカーを除く)ではexample.com#%#//scriptlet('abort-current-inline-script', 'document.addEventListener', '/google_ad_client/')をマイフィルター/ユーザールールに追加してみてください。たまに競合条件により安定して機能しない場合もあります。uBlock Originでは、Firefox上ならexample.com##^script:has-text(google_ad_client)に切り替えてください。AdGuardではexample.com$$script[wildcard="*load*google_ad_client*"][min-length="2000"][max-length="7000"]に切り替えてみてください(一部のプラットフォームでは機能しません)。それでダメな場合、uBlock Originではexample.com##+js(acis, document.addEventListener, nextFunction)に、AdGuardではexample.com#%#//scriptlet("prevent-setTimeout", "/\.displayMessage[\s\S]*?\.nextFunction\(\)/")に切り替えてみてください。iOS無料版AdGuardでは、コンテンツブロッカーに以下を追加してみてください(これだけではダメな場合もあります)。

@@#*/ad/$image,domain=example.com
@@||example.com^$generichide
  1. BlockAdBlockの場合

以下のようなUIです。

bab_var1

bab_var2

uBlock Originではめったにみることはないはずですが、遭遇した場合はexample.com##+js(nosiif, visibility, 1000)を追加してください。AdGuardではexample.com#%#//scriptlet("prevent-bab")を追加してください。iOS無料版AdGuardでは、コンテンツブロッカーに@@||example.com^$generichideを追加してみてください。

  1. Google Funding Choice Anti-adblockの場合

以下のようなUIです。

gfc_var1

×ボタンで消せるタイプのものもあります。AdGuard、uBlock Originともめったにみることはありません。それでも遭遇したら、@@||example.com^$generichideを追加してください。

  1. mdpDeBlockerの場合

以下のようなUIです。

deblocker_var1

deblocker_var2

uBlock Originの場合はexample.com##+js(aeld, DOMContentLoaded, adsBlocked)を追加してみてください。ダメな場合はexample.com##+js(nostif, show), example.com##+js(acs, eval, replace), example.com##+js(aost, document.getElementsByTagName, adsBlocked)に順次切り替えてみてください。AdGuardではexample.com#%#//scriptlet("prevent-addEventListener", "DOMContentLoaded", "adsBlocked")を追加してみてください。ダメな場合はexample.com#%#//scriptlet("prevent-setTimeout", "showModal()"), example.com#%#//scriptlet('prevent-eval-if', 'adsBlocked'), example.com#%#//scriptlet('abort-on-stack-trace', 'document.getElementsByTagName', 'adsBlocked')に切り替えてみてください。 iOS無料版AdGuardでは、コンテンツブロッカーに

@@||pagead2.googlesyndication.com/pagead/js/adsbygoogle.js$domain=example.com
@@||googleads.g.doubleclick.net/pagead/id$domain=example.com   

を追加したうえで、DNSフィルタリングを一時無効にするか、pagead2.googlesyndication.comgoogleads.g.doubleclick.netを(できれば一時的に)ホワイトリストに追加してください。AdGuard DNSなど広告ブロック機能のついたDNSサーバーを使っている場合は、一時ほかのDNSにする必要もあります。

  1. AdBlock Notifyの場合

以下のようなUIです。

notify

uBlock Origin, AdGuardとも基本的なフィルタ構成ではみないはずですが、カスタムリストを追加した場合みる可能性があります。uBlock Originではexample.com##+js(aopr, anOptions)、AdGuardではexample.com#%#//scriptlet("abort-on-property-read", "anOptions")を追加してください。iOS無料版AdGuardでは、コンテンツブロッカーに以下を追加してください。

/wp-content/uploads/*/*.js$domain=example.com
example.com#@##adsense
example.com#@#.an-advert-banner
example.com#@#.an-sponsored
  1. Admiral Anti-adblockの場合

以下のようなUIです。

admiral_var1

これはいわゆるsoft anti-adblockで、対策せずともContinue without disablingをクリックすることでコンテンツを閲覧することができます。そのためuBlock Origin、AdGuardともメインのフィルタでは対策せず、迷惑系フィルタ(uBlock filters - Annoyances, AdGuard Annoyances)で対応していますが、共同通信の場合は挙動の違いによりデフォルトで対応しています。また、EasyPrivacy, Peter Lowe’s Ad and tracking server list, AdGuard追跡防止フィルタのいずれかを使用することでも大部分回避できます。個別に対策したい場合、uBlock Originではexample.com##+js(acis, document.createElement, admiral)を追加し、効果がない場合example.com##+js(aopr, admrlWpJsonP)に切り替えてみてください。AdGuardではexample.com#%#//scriptlet("abort-current-inline-script", "document.createElement", "admiral")を追加し、効果がない場合example.com#%#//scriptlet("set-constant", "admiral", "noopFunc")に切り替えてみてください。

  1. AdUnblockerの場合

以下のようなUIです。

adunblocker

uBlock Originでは基本的にみないはずですが、Firefoxのトラッキング防止機能を利用している場合(標準ではプライベートブラウジング利用時)に遭遇することがあります。その場合はexample.com##+js(nostif, css_class.show)を追加してください。AdGuardでは以下を追加してみてください。

example.com#%#//scriptlet("set-constant", "adsbygoogle.length", "undefined")
||pagead2.googlesyndication.com/pagead/js/adsbygoogle.js$script,xmlhttprequest,redirect=googlesyndication-adsbygoogle,domain=example.com

iOS無料版AdGuardでは@@||pagead2.googlesyndication.com/pagead/js/adsbygoogle.js$domain=example.comを追加してみてください。

  1. ai_front Anti-adblockの場合

以下のようなUIです。

ai_front_var1

ai_front_var2

ai_front_var3

バリエーションが多く、ここですべてを網羅することはできません。uBlock Originではexample.com##+js(aopr, b2a)を試してみてください。AdGuardではexample.com#%#//scriptlet("abort-on-property-read", "ai_wait_for_jquery")を試してみてください。iOS無料版AdGuardでは、以下を追加してみてください。

example.com##[style*="cursor:"][style*="z-index:"][style*="transform"]
example.com##[style*="cursor:"][style*="z-index:"][style*="position: fixed;"]

  1. CHP Ads Block Detectorの場合

以下のようなUIです。無料版と有料のPro版があります。

chp_var1

chp_var2

2023年4月1日追記:CHP Ads Block Detector v3.9.2より、uBlock Origin対策がなされ汎用的な解決が難しくなりました4-11。このバージョンについては、uBlock Originではexample.com##+js(noeval-if, fairAdblock)、AdGuardではexample.com#%#//scriptlet('prevent-eval-if', 'fairAdblock')、iOS無料版AdGuardではexample.com##body > [id] ~ div[id][class*=" "]をお試しください。

uBlock Originではv3.9.1以前の無料版はめったにみないはずです。Pro版の場合はexample.com##+js(aopr, chp_adblock_browser)をお試しください。AdGuardでは、無料版にはexample.com#%#//scriptlet("abort-on-property-read", "adsBlocked")を、iOSではexample.com##body > script + div[id][class*=" "]example.com##body > #container > .content ~ script + div[id][class*=" "]を追加してみてください。Pro版はexample.com#%#//scriptlet("abort-on-property-read", "chp_adblock_browser")、iOSではexample.com##body > div[class][style="display:none;"] + div[id][class*=" "]を追加してみてください。

4-11: 汎用整形フィルタで対応することは一応可能ですが、uBlock Originの内部ディスカッションで行わないことに決まりました。たとえprocedural cosmetic filterでなくても、複雑なセレクタの汎用整形フィルタは誤爆はもとよりパフォーマンスに影響するおそれがあるとの意見。以下、gorhillのコメントから引用:Even if it's not procedural and natively executed by the browser, it's not free as it's not a simple selector, we shouldn't presume it has zero impact performance-wise (let alone worries about risk of false positives). The noeval-if approach is really the best here,

  1. Piano Composer Anti-adblockの場合

以下のようなUIです。

piano_var1

piano_var2

一番目はpiano.ioのブロックで消せますが、二番目は逆にブロックにより起動します。また、×ボタンで消せるものとそうでないものがあります。AdGuard, uBlock Originとも基本的にはみないはずです。それでも遭遇したら、AdGuard, uBlock Originとも一番目は||code.piano.io/api/tinypass.min.js$domain=example.comを追加、二番目はexample.com###tpModalを追加してください。

  1. 上記以外

アンチ広告ブロックプラグインにはほかにも多くのファミリーがあり、ここで網羅することはできません。また、独自実装のものも増えています。以下ではそうした場合にもしかしたら機能するかもしれない簡易的な対処をまとめます。

uBlock Origin:まず、(Firefoxの場合はトラッキング防止を無効にして)以下を追加

*$image,redirect-rule=1x1.gif,domain=example.com
*$script,redirect-rule=noop.js,domain=example.com
||googlesyndication.com/pagead/js/adsbygoogle.js$script,redirect-rule=googlesyndication_adsbygoogle.js:10,domain=example.com
@@||example.com^$ghide
@@||example.com^$script,xhr,1p

ダメなら||example.com^$inline-scriptに切り替え、ただしサイトの機能を壊す可能性が高い。

AdGuard:まず、DNSフィルタリング(とFirefoxの場合はトラッキング防止)を無効化して以下を追加

$image,redirect-rule=1x1-transparent.gif,domain=example.com
$script,redirect-rule=noopjs,domain=example.com
||googlesyndication.com/pagead/js/adsbygoogle.js$script,xmlhttprequest,redirect-rule=googlesyndication-adsbygoogle,domain=example.com
@@||example.com^$generichide
@@||example.com^$script,xmlhttprequest,~third-party

ダメなら||example.com^$inline-scriptに切り替え(DNSフィルタリングやトラッキング防止を無効化した人は戻してよい)、ただしサイトの機能を壊す可能性が高い。

Q 4-13 Twitterのおすすめトピック、おすすめユーザー、おすすめツイート、「タイムラインにトピックも表示しましょう」、新しいリストを見つけるを消したいです。

A 4-13

はちまさんという方が、みぞれフィルタ更新停止後もフィルタを提供してくださっています。uAssetsにもときどき問題報告してくださる方です。

Q 4-14 AdGuard Cookie Notices filterとEasyList Cookieなど、似たようなフィルタの違いを教えてください。

A 4-14

AdGuard Cookie Notices filterとEasyList Cookie

どちらもクッキーの同意ダイアログを対象とする点で目的は同じですが、特徴が違います。まず、全般的な網羅性はEasyList Cookieのほうが高い、つまり平均的にはより強力で漏れが少ないです。そのぶん不具合も多い傾向にありますが、それに負けないほど頻繁に不具合修正も行われています(少なくとも欧米のサイトにおいては)。一方、どのようなフィルタリストもそうですが地域による弱み強みもあり、日本のサイトに限ればAdGuard Cookie Notices filterも負けてはいません。もう一つ重要な違いはAdGuard Cookie Notices filterがset-cookieやクリッカースクリプトなどの強力な機能を使える点ですが、これはAdGuardで使う場合のみ恩恵があります。日本のサイトでこれらが必須となるケースはまだ少ないですが、ないわけではありません。ほかに、AdGuard Cookie Notices filterはEasyList Cookieに比べると汎用整形フィルタへの依存度が低いため、AndroidのuBlock Originで使う場合はEasyList Cookieより強力かもしれません。両方を併用することも可能ですが、不具合の確率が上がるうえに相当な無駄が出るため個人的にはおすすめしません。

AdGuard URL Tracking ProtectionとActually Legitimate URL Shortener Tool

どちらもクエリパラメータを除去しますが、方針と地域的な強みに違いがあります。AdGuard URL Tracking Protectionはその名の通りトラッキングパラメータのみを除去する方針です。トラッキングが疑われても、よくわからないパラメータは除去しません。不具合はそれほど多くない印象です。Actually Legitimate URL Shortener Toolはトラッキングかどうかにかかわらず、できるだけあらゆるパラメータを除去する方針です。そのぶん不具合もやや多いですが、報告されれば24時間以内に対応しており、平均的にはAdGuardより対応が早いです。また、メンテナーや報告者の傾向から、欧米のサイトに強いです。それに対してAdGuard URL Tracking Protectionは比較的アジアに強いといえます。

Q 4-15 EasyListのGithubリポジトリでコミットについているA, P, Mとはなんですか?

A 4-15

こちらに解説があります。AはAdditionでルールの追加、PはProblemで不具合の修正、MはMovedまたはModifiedでA, Pに当てはまらないもの、特定のURLを割り振れないものに使います。

5. その他一般

Q 5-1 YouTubeで検索が機能しない、メニューが開けない、接続が途切れるなど不具合が出ます。

A 5-1

2021年4月27日追記:Googleによる広告ブロック対策といった話が散見されるのではっきり申し上げますが、某ゲーム動画配信サービスと異なり、Googleは本気でブロッカーをバイパスしようとはしていないと思います。(2021年5月15日修正)実際のところわかりませんが、fetchによりバイパスが起きた件もパフォーマンス上の理由などと解釈可能なもので、今のところGoogleはブロックできない手段までは用いていません。ただ、一部の人にしか新型広告が配信されないため、解析が難しいのは確かです。「この設定/フィルタ/拡張機能なら出ない」という主張は、多くの場合、その人が新型広告の対象になっていないだけです。

2021年3月22日追記:Twitterなどで同様の報告が後を絶たないようなので、ABP Japanese filtersをブラックリスト指定させていただきました。

ABP Japanese filtersが原因の可能性が高いです。同フィルタは更新が停止しており、すでにAdblock PlusやuBlock Originの標準フィルタリストからは削除されていますが、昔インストールしてそのまま使っている場合は有効になっている場合があります。また、AdBlockでは今でもデフォルトで有効のようです。同フィルタを無効にして別の日本用フィルタに切り替えてください。なお、名前が似ていますがAdGuard Japaneseは問題ありません。また、不具合というより広告漏れの話ですがuBlock OriginのフィルタとBlockTubeは干渉するため、BlockTubeは使用しないでください。もちろん、A 1-10で述べたようにほかの広告ブロック拡張も使用しないでください。

Q 5-2 広告ブロッカーを使っていると表示や機能がおかしいサイトがあります。

A 5-2

ほとんどの場合フィルタの問題で、誤爆と呼ばれます。フィルタ作者に報告してください。uBlock Originでフィルタをいじっていない場合はこちらこちら(要アカウント)、AdGuardでカスタムフィルタを追加していない場合はこちらか、またはAdGuard本体から「問題・不具合を報告する」も利用できます。Twitterなどをみていますと、サイト側の広告ブロック対策のように勘違いされる方が多いようです(そういう場合もありますが、稀です)。現在主流のブロッカーは、ブロック対象が広告・追跡かどうか分析などしておらず、URLやHTMLタグが事前に定義されたパターンにマッチするかだけをみています。機械学習などを用いて分析する試みも行われていますが、パフォーマンスへの影響や、この方法でも誤判定が避けられないこともあり、簡易的なヒューリスティック(旧バージョンのPrivacy BadgerやAppleのIntelligent Tracking Prevention等)を除いて実用に至っていません。

Q 5-3 広告ブロックについて、ほかに参考になるサイトを教えてください。

A 5-3

広告ブロックについての情報は英語のほうが圧倒的に充実していますが、ここでは日本語で比較的信頼できるものをいくつか挙げてみます。なお、言語を問わずインターネット上には明らかに間違った記事やツイート、古い情報が蔓延しており、それが当FAQを作成した最大の動機です。

Q 5-4 AdguardFiltersに報告したのに対処されません。

A 5-4

2022年2月25日追記:ここのところ数名のユーザーにより処理能力をはるかに上回る大量の報告が送られたため、段階的に対策が取られています。その巻き添えで重要なIssueが閉じられてしまうこともあるかもしれません。

いろいろな理由が考えられます。AdguardFiltersで対処できるのはフィルタの問題だけですが、実際にはそれ以外の問題も多く報告されます。初心者の方にはその区別がつきにくいのは承知していますが、報告前にひと手間かけていただけるとこちらとしては助かります。

  • もっとも多いのは問題が再現できないケースです。再現のための手順を書いていただくのはもちろん、できましたらAdGuardの標準的な設定で、問題が確実に発生するか確認していただけると助かります。フィルタリストの過剰購読による不具合やアンチ広告ブロックはしばしば再現できず(購読数があまりに多い場合、こちらも環境再現をあきらめます)、できたとしてもせいぜい問題のリストの作者に修正を依頼するくらいしかこちらにはできません。iOSの場合はバグも多く、TUNNEL MODEをFull-Tunnelにすることで解決することもあります。もっと多いのはSafariのコンテンツブロッカーのバグで、コンテンツブロッカーを一度すべて無効にしてから再度有効にし、Safariを再起動してからフィルタの更新をかけてください。

  • そもそも何が問題なのかわからないケースも多いです。日本語で構いませんので(スクリーンショット中に日本語で説明を入れるのは控えてください)、一言、説明を加えてください。できればスクリーンショット中にマーキングをしていただけるとなおよいです。

  • AdGuardには何をブロックするかについて一定の基準があります。たとえば、SNS用フィルタではシェアボタンはブロックしますが、フォローボタンは一部例外(明らかに冗長で不要な場合など)を除きブロックしません。また、トラフィックが少ないサイト(目安として月100,000以下)は原則として個別対処しません5-1。上記リンクはあくまで総論なので、実際には現場で決められた指針や例外も多くあり、判断に迷う場合は議論して方針を決めています。議論はGitHub上でオープンに行うこともありますし、内部チャンネルで行うこともあります。すでに対処しないと決まったケースの再報告も多いため、過去に同様の事例がないか報告前に検索いただけるととても助かります。AdGuardの基準に当てはまらなくても個人的に邪魔だから消したいという場合、その旨をコメントいただければユーザールールに追加するフィルタを提案します。

5-1: 既存のルールにドメインを追加するだけで済むなど、変更が少ない場合は担当者の判断で対処することもできます。

Q 5-5 フィルタメンテナーになるにはどうすればいいですか?

A 5-5

個人開発のフィルタを公開するぶんにはなにも資格はいりませんが、uBlock filters(uAssets)など主要なフィルタリストの場合は招待制です。AdGuard、EasyList、uAssetsのなかでもっとも間口が広いのはuAssetsです。大まかな目安としては、半年ほど優良なプルリクエストを続けることでしょう。頻度も重要で、十分アクティブであるとみなされなければ声はかかりません。協調性も見られていると思います。プルリクエストをするユーザーには、そのリポジトリ/フィルタを自分の思うように変えたいという人が少なくない気がしますが、あくまでそのリポジトリの方針を理解し、メンテナーの負担や時間を軽減するような配慮ができる人が好まれます。フィルタの編集は、あくまで仕事の一部でしかないことにご注意ください。表からは見えなくても、フィルタ作者間では常に様々な調整や議論が行われていますし、当然、新人教育的なことも行います。AdGuardの場合はよくわかりませんが、実質的に社員になる資格のある人が社員にはなりたくない場合の選択といってよさそうです。単にプルリクエストを重ねるだけでなく、活動が安定しており、一人でどんなIssueでも処理できるが必要に応じてほうれんそうができる、といったところだと思います。EasyListのメンテナーになるのは現状ほぼ不可能です。

2021年3月25日追記:フィルタ作者にあこがれる人もいるそうですので、役に立つかわかりませんが国際的なフィルタリストを前提にもう少し書いてみます。当然ながら、フィルタ記法、HTML、CSS、Javascriptの基本的な知識は前提となります。なにかとPythonを使う機会もあるのでPythonスキルがあるとなおよいでしょう。英語でスムーズなコミュニケーションがとれることは必要条件です。Gitクライエントは使えたほうがいいでしょう。もっとも重要なのは根気です。フィルタメンテナンスなど、慣れてしまえばほとんどが数分で終わる単純作業の積み重ねにすぎません。それをいとわずに継続できるかが要となります。おすすめはしませんが、十分な実績を重ねれば生業にすることも不可能ではありません。ノルウェー用フィルタを提供しているDandelion Sprout氏はeyeoともう一つの広告ブロックベンチャーに就職していますし、当管理人もBraveとAdGuardよりフィルタエンジニアの打診を受けています(断りましたが)。

Q 5-6 セキュリティのためにコンテンツブロッカーを勧められることがありますが、実際に効果があるのでしょうか?

A 5-6

Malvertisingと呼ばれる広告を通してマルウェア(ウイルス)を配信する手法()はもとより、悪質な広告やクラックされたサイトからのリダイレクトにより様々な詐欺サイトに飛ばされることがあります。

Malvertisingや広告からの悪質リダイレクトについてはコンテンツブロックが大きな効果を発揮します。また、とくにuBlock Originではこれらの詐欺サイトやリダイレクターも直接ブロックしています。悪質サイトの数は星の数ほどあり、短期間で次々と生まれ変わるためごく限定的な保護しか提供できませんが、それでもこの種の詐欺に限っていえばブラウザの保護機能(Google Safe Browsing, Microsoft Defender SmartScreen)よりましだという事実があります。管理人はこれまで数百件以上の詐欺サイトをみてきていますが、ブラウザの保護機能がこれらをタイムリーにブロックした例はただの一度もみたことがありません5-2。観察していると数日から一週間程度でブロックされることが多いようですが、そのころには当該サイトは決まってドメイン失効しています。これに限らずドメインが失効したり脅威がなくなったりしても報告がなければブロックは(少なくとも当面)継続される模様で、おそらくGoogle Safe Browsingはかなりの無駄なエントリーを含んでいると思います。ブラウザの保護機能を使うなということではありません、むしろコンテンツブロッカーがその弱点を補強できるということです。問題はドメイン単位のブロックが悪質サイトに対してあまり有効ではないことで、AdGuardのブラウジングセキュリティも同様の問題をはらんでいます。uBlock filters - Badware risksではドメインブロックもしていますが、正規表現やパターンベースのブロックを組み合わせることで、とくに当選詐欺についてはときどきあるパターン変更の直後を除きほぼ100%といえるブロックができています。

一方で、メールやソーシャルメディアを通した悪質サイトへの誘導、フィッシングなどのより一般的なネット詐欺、および標的型/水飲み場型攻撃等にはあまり有効ではありません。水飲み場型攻撃については、アンチウイルスベンダーが発表する事例などをみているとMedium modeで防げるケースもかなりあるようですが万人向けとは言えないでしょう。コンテンツブロッカーはあくまで基本的なセキュリティ対策やユーザー教育に追加して使うものだと思います。なお、上記のような詐欺サイトに遭遇してしまった場合、基本的にそのタブを閉じてクッキーを削除していただけば問題ありません(参考)。

5-2: ちなみにFirefoxのDoHでQuad9, CleanBrowsingといったセキュアDNSを別々のプロファイルで使っていますが、Quad9で1件の明らかな誤判定があった以外にブロック(NXDomain)されたことはありません。

詐欺サイトギャラリー

scam1

scam2

scam3

scam4

scam5

scam6

scam7

scam8

scam9

Q 5-7 広告ブロックは違法ではないのですか?

A 5-7

違法ではありませんし、まともな法治国家においては今後も違法になる可能性はまずないでしょう。ドイツでは6度の訴訟においてすべて広告ブロック側有利の判決が出ました。ウェブ標準化団体のW3Cは、ユーザーは拡張機能やブロッカーをインストールして、望まないコンテンツをブロックできなければならない、それが倫理的な面でウェブのあるべき姿だと明言しています。プライバシー気運の強いEUにおいては、アンチ広告ブロックのほうが違法にされかけたこともあります。

また、違法でなくてもサイトの規約違反になるのではという意見もあります。海外の判例においては、規約が拘束力を持つのは、ユーザーがそれをしっかり読まなければサイトが使えないような仕組みの場合のみです。たとえばYoutubeの規約違反になるかについては10年以上前から議論されて来ましたが、2023年5月から実験的に導入されたプロンプトで、規約違反であると主張されました。

Q 5-8 みんなが広告ブロックするようになるとサービスが立ちいかなくなったり、ウェブが有料化するのでは?

A 5-8

広告ブロックをする人がいる、これは好むと好まざるとにかかわらず現実です。とくにウェブの場合は理念としてブロックできなければならないと明言されているので、サービス提供者や広告業界のほうがこれに適応する必要があります。大きな問題は、1. 広告に代わりうる収益化手段が乏しい、2. ウェブ広告が完全に嫌われ者になってしまっている、の二点になるでしょう。ただし、広告ブロックが本当に各所でいわれるような損害をもたらしているかは不明です。広告ブロックによる「損害」とされるもののほとんどは具体的な算出方法が不明で、統計もバラバラであり、利害関係のある団体による発表です。おそらくこれらの統計は近視眼的な仮定の下に計算されており、全体としてみると、理論上は広告ブロックが収益を増やすことさえありえます。鍵となるのは、広告への感受性は人によって様々であるというあたりまえの事実です。ブロックするユーザーの多くは仮にブロックしていなくても広告をクリックしないと考えられ、その場合はインプレッション収入しか得られません。さらに感受性が高いユーザーは離脱する可能性が高く、そうなると一切の広告収入が入りません。彼らはどうせ収益に貢献しないから問題ないという考えもありますが、SNSなど、ユーザー数が直接価値につながるサイトも多くあります。

1.については以前からずっと模索されており、日本ではCoinhiveの一件が有名でしょう。ユーザーの同意さえ得れば優れた方法であり、今でもArcなどがありますが、普及しているとはいえません。Braveは広告の収益分配の再構築を目指しており、クリエイターを直接支援する仕組みを実装しました。この方法なら本当に良いコンテンツだけにお金が集まる可能性が高く、SEOだけに注力した中身のないサイトを量産している現在の収益システムの問題は起こりにくいような気がします。

2.については、多くの調査で一貫して「それほど不快でなければ広告をみてもよい」という人が多数を占めています。つまりブロックされたくなければ不快でなくすればよいだけです。それでも一部の人はブロックを続けるでしょうが、本来広告とはそういうもののはずです。すべての人がみなくても、ニーズのある人に届けばいい――広い意味ではブランディングでさえそうです。新しいメディアが出るたびに同じ議論が繰り返されていますが、今ではCMをスキップしてはいけないとか、CM中にトイレに行ってはいけないとか、ポストに入ったチラシはすべて目を通さなければいけないとか、新聞・雑誌の広告欄は読み飛ばしてはいけないなどという人はいないでしょう。受け手の任意でみることができ、潜在的な、あるいは将来のニーズと商品や情報を結びつける限りにおいて、広告は有用で価値があります。ウェブ広告が嫌われ者になってしまったのは、そうした立ち位置を超えてきたのが一つの理由でしょう。加えて違法広告malvertisingもあり、今や有害になってしまっています。それに対し規制、自浄作用をという声が上がってもう何年も経っており、まったく自浄できない業界のありさまをガンにたとえる人もいます。また、「広告はサービスの対価」という人がいますが、広告はそれ自体別のサービスであって、対価ではありません。対価などという発想は広告が不快、マイナスであることを前提にして初めて生じるものです5-4。話をややこしくしているのはサービス提供者、ユーザー、そして広告主の三角関係です。ここで実際にお金を払うのは広告主で、それを支えるのは広告を通して商品を購買するといったアクションを起こす一部のユーザーです。インプレッション広告にしても、認知度以上に好印象を持ってもらう必要があるはずで、見たくないユーザーに無理やりみせても逆効果になりかねません。不快な広告を我慢してみることはその人にとって無駄なだけでなく、広告主にも益になりませんし、広告配信者にとってもリソースの無駄です。さらに、「ただでコンテンツを作る人などいない」といった主張もみますが、現在のインターネットはLinuxやApache HTTP Serverをはじめ、多くのボランティアによって成り立っていることを忘れるべきではありません。広告ブロックもボランティアによって成り立っている営みの一つです。

それでも広告は見るべきだと思うならそうすればよいですし、ブロッカーを使っていても支援したいサイトを除外することもできます。それでも、ほかの人は各自の価値観や利益に沿って行動するので、もしその結果としてあるサービスが衰退したなら仕方ありません。個人的には、日本のテレビCMはアメリカのそれと比べてセンスがあるものが多いと感じますし、日本の広告業界から現状を変えていっていただけたらと願います。もちろんそういう試みはすでにされていますが、現在の広告業界が変わるには相当な時間がかかりそうです。最後に、冒頭のリンクから引用:

消費者の身勝手さを非難したり、実際には存在しない広告ブロッカーに潜んだ秘密の利益についてとがめたりする代わりに、広告業界は、自分たちがユーザーとの友好関係を築けていないばかりか、立ち止まることなく積極的に問題を発展させてしまったことが、今の消費者の行動に直接つながっているということを認識しなければいけない。

(http://seo-lpo.net/web-news/%E5%BA%83%E5%91%8A%E6%A5%AD%E7%95%8C%E3%81%8Cadblock%E3%82%92%E5%8F%97%E3%81%91%E5%85%A5%E3%82%8C%E3%81%AA%E3%81%91%E3%82%8C%E3%81%B0%E3%81%AA%E3%82%89%E3%81%AA%E3%81%84%E7%90%86%E7%94%B1/) (元記事:https://techcrunch.com/2016/09/05/why-the-advertising-industry-needs-to-embrace-adblock/)

5-4: 市販のパソコンやスマートフォンの多くが格安で買えるのも、バンドルソフトのおかげです。対価論者はそれらのバンドルソフトを毎回すべて一通り使い、決して即アンインストールなどしないべきでしょう。そもそも、対価というのはあらかじめ値段が提示され、それに応じて払うか払わないか選べてこそ成り立ちます。

謝辞

このFAQの初版の作成に当たっては、@280blockerさん(トビラシステムズによる買収前の開発者様)から貴重なご意見をいただきました。ここに感謝申し上げます。 (元々見ていただくことを想定していたわけではなく、たまたま別件で話していたときにタイミングがあったため、ご意見をいただくことができました。間違い等の文責はすべて@Yuki2718にあります)

⚠️ **GitHub.com Fallback** ⚠️