Webブラウザ Vivaldiの広告ブロッカーが不安定 （2024/04/16） [Android＆スマホ]
私の個人スマホで、Android Vivaldiに標準搭載されている広告ブロッカー機能が不安定なんです。設定で機能を有効にしているのですが、気付いたら無効になっていたり、無効になっていることに気付いて有効化しようとしても設定が変わらなかったり。（画面遷移すると無効に戻ってしまっている）
気付いたのは半年以上前で、そのうち不具合解消されるものかと思っていたら、まったく改善しないのです。今日もVivaldiのアップデートがあったので、改修内容に含まれていると思ったがそんなことはなく。
以前、自分なりに調べたところ、以下のように類似のバグ報告があがっており、開発チームも認識しているのですぐに修正されるものと思っていた訳です。バグ報告は2023年11月の話ですし、不具合報告されているバージョンは当時のものなので、2024年4月現在、とうの昔に直っていると思っていたら、、、、私の環境では今も不具合は続いています。
-------------------
【Android版】トラッカー・広告ブロックレベルの指定が勝手に変更される
https://forum.vivaldi.net/topic/92935/android%E7%89%88-%E3%83%88%E3%83%A9%E3%83%83%E3%82%AB%E3%83%BC-%E5%BA%83%E5%91%8A%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E3%83%AC%E3%83%99%E3%83%AB%E3%81%AE%E6%8C%87%E5%AE%9A%E3%81%8C%E5%8B%9D%E6%89%8B%E3%81%AB%E5%A4%89%E6%9B%B4%E3%81%95%E3%82%8C%E3%82%8B/6
まぁ、待っていても永遠に直らなそうなので、アグレッシブに切り分けをしてみました。不具合が発生した場合は、以下の症状となります。②③まで確認できれば発病確定です。
①ブラウザを再起動させる
②広告ブロッカーが無効になっている
③広告ブロッカー機能の説明に、「ブロックなし（デフォルト）」と表示される
④何をどうやっても機能を有効化できない
⑤広告ブロッカー（ソース）に関する設定「トラッカーブロックソースの管理」や「個別設定」の中身が空欄になってしまう ※本来、「DuckDuckGo Tracker Radar」や「EasyPrivacy」などのチェックボックスが表示される
実験したことの一例（全部ダメでした）
（1）タブを全部閉じる
（2）デスクトップモードにしてみる
（3）いろいろなサイトを巡ってみる（Webサイトとの相性）
（4）再起動するタイミングを変えてみる
体感的に98%の確率で失敗し、ごく稀に広告ブロッカー機能が有効になって立ち上がってくるようですが、アプリの再起動をすると98%の運ゲームに戻ります。
■Vivaldi初期化
ブラウザキャッシュやcookieの削除といった生易しいものではなく、Androidのアプリ設定箇所からデータを削除しました。いわゆる初期化というやつです。アプリケーション新規インストール直後の状況と等しいはずです。
これでダメだったら…という思いでしたが、すぐに再発しました。広告ブロッカー（ソース）に関する設定は、変更してもしなくても発生率は変わらないようです。（98%）
はい、打つ手がなくなりました。初期環境と同等にしても再発してしまうということは、アプリそのものが現在も不具合を抱えているということです。…そうなんですが、ただこの場合世界中（日本中）のユーザで同様事象発現しているはずで、その割に不具合報告がないことや、開発チームが放置していることに疑問ですね。
とりあえず、さらなる切り分けを検討しました。まずWindows11のデスクトップ版Vivaldiを確認しましたが、全く問題ありません。次に、最近新規購入したAndroidタブレットで同様の試行を繰り返してみました。…なんとこちらも事象が発生しないようです。
Windowsはともかく、事象が発生しないAndroidデバイスが存在するということは、私個人のスマホ環境に問題がある可能性があるということです。Androidとしては、私のスマホもタブレットも同じAndroid13（あるいは13相当）ですし、端末依存の何かでしょうか？ ハードウェア依存の不具合というのもの考えにくいのですが。。。。
■ほぼ解決しました！
事象解決しました。正確には事象改善しました。
実は一点、「結果的に」に違っていることがありました。事象が発生している私のスマホは1年前から使用しており、VivaldiはGoogle Playから何度も「更新」を行ってきました。事象が発生しないタブレットは、最近購入しVivaldiを新規インストールしたばかりということです。
インストールしてからの連続使用期間は明らかな差異があります。
AndoroidアプリのGoogle Playによる「更新」がどういった処理か分かりませんが、仮にある時期にVivaldi環境が腐ったとして、その腐った環境を絶妙に残しつつ「差分更新」されているのではないかと考えました。そこで試しに完全アンインストール → 新規インストールをしたところ、なんと見事に直りました。
正確には完全解決した訳ではなく、体感98%の確率で正常起動するようになり、ごく稀に②③④の症状が出るような感じです。仮に起動に失敗しても再起動すれば直るので、問題ないでしょう。
まぁこの確率であれば、確かに不具合報告がなくてもおかしくはないような気がします。
というわけで、直りました。
もしAndroid系で同様の原因不明の不具合を抱えている場合、Vivaldiに限らずアプリの完全削除 → 新規インストールは有効であると思われます。Vivaldiで同じ不具合に悩んでいる人は、ぜひ一度アプリをアンインストールしてみてください。
気付いたのは半年以上前で、そのうち不具合解消されるものかと思っていたら、まったく改善しないのです。今日もVivaldiのアップデートがあったので、改修内容に含まれていると思ったがそんなことはなく。
以前、自分なりに調べたところ、以下のように類似のバグ報告があがっており、開発チームも認識しているのですぐに修正されるものと思っていた訳です。バグ報告は2023年11月の話ですし、不具合報告されているバージョンは当時のものなので、2024年4月現在、とうの昔に直っていると思っていたら、、、、私の環境では今も不具合は続いています。
-------------------
【Android版】トラッカー・広告ブロックレベルの指定が勝手に変更される
https://forum.vivaldi.net/topic/92935/android%E7%89%88-%E3%83%88%E3%83%A9%E3%83%83%E3%82%AB%E3%83%BC-%E5%BA%83%E5%91%8A%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E3%83%AC%E3%83%99%E3%83%AB%E3%81%AE%E6%8C%87%E5%AE%9A%E3%81%8C%E5%8B%9D%E6%89%8B%E3%81%AB%E5%A4%89%E6%9B%B4%E3%81%95%E3%82%8C%E3%82%8B/6
まぁ、待っていても永遠に直らなそうなので、アグレッシブに切り分けをしてみました。不具合が発生した場合は、以下の症状となります。②③まで確認できれば発病確定です。
①ブラウザを再起動させる
②広告ブロッカーが無効になっている
③広告ブロッカー機能の説明に、「ブロックなし（デフォルト）」と表示される
④何をどうやっても機能を有効化できない
⑤広告ブロッカー（ソース）に関する設定「トラッカーブロックソースの管理」や「個別設定」の中身が空欄になってしまう ※本来、「DuckDuckGo Tracker Radar」や「EasyPrivacy」などのチェックボックスが表示される
実験したことの一例（全部ダメでした）
（1）タブを全部閉じる
（2）デスクトップモードにしてみる
（3）いろいろなサイトを巡ってみる（Webサイトとの相性）
（4）再起動するタイミングを変えてみる
体感的に98%の確率で失敗し、ごく稀に広告ブロッカー機能が有効になって立ち上がってくるようですが、アプリの再起動をすると98%の運ゲームに戻ります。
■Vivaldi初期化
ブラウザキャッシュやcookieの削除といった生易しいものではなく、Androidのアプリ設定箇所からデータを削除しました。いわゆる初期化というやつです。アプリケーション新規インストール直後の状況と等しいはずです。
これでダメだったら…という思いでしたが、すぐに再発しました。広告ブロッカー（ソース）に関する設定は、変更してもしなくても発生率は変わらないようです。（98%）
はい、打つ手がなくなりました。初期環境と同等にしても再発してしまうということは、アプリそのものが現在も不具合を抱えているということです。…そうなんですが、ただこの場合世界中（日本中）のユーザで同様事象発現しているはずで、その割に不具合報告がないことや、開発チームが放置していることに疑問ですね。
とりあえず、さらなる切り分けを検討しました。まずWindows11のデスクトップ版Vivaldiを確認しましたが、全く問題ありません。次に、最近新規購入したAndroidタブレットで同様の試行を繰り返してみました。…なんとこちらも事象が発生しないようです。
Windowsはともかく、事象が発生しないAndroidデバイスが存在するということは、私個人のスマホ環境に問題がある可能性があるということです。Androidとしては、私のスマホもタブレットも同じAndroid13（あるいは13相当）ですし、端末依存の何かでしょうか？ ハードウェア依存の不具合というのもの考えにくいのですが。。。。
■ほぼ解決しました！
事象解決しました。正確には事象改善しました。
実は一点、「結果的に」に違っていることがありました。事象が発生している私のスマホは1年前から使用しており、VivaldiはGoogle Playから何度も「更新」を行ってきました。事象が発生しないタブレットは、最近購入しVivaldiを新規インストールしたばかりということです。
インストールしてからの連続使用期間は明らかな差異があります。
AndoroidアプリのGoogle Playによる「更新」がどういった処理か分かりませんが、仮にある時期にVivaldi環境が腐ったとして、その腐った環境を絶妙に残しつつ「差分更新」されているのではないかと考えました。そこで試しに完全アンインストール → 新規インストールをしたところ、なんと見事に直りました。
正確には完全解決した訳ではなく、体感98%の確率で正常起動するようになり、ごく稀に②③④の症状が出るような感じです。仮に起動に失敗しても再起動すれば直るので、問題ないでしょう。
まぁこの確率であれば、確かに不具合報告がなくてもおかしくはないような気がします。
というわけで、直りました。
もしAndroid系で同様の原因不明の不具合を抱えている場合、Vivaldiに限らずアプリの完全削除 → 新規インストールは有効であると思われます。Vivaldiで同じ不具合に悩んでいる人は、ぜひ一度アプリをアンインストールしてみてください。
タグ：Vivaldi
Unboundを有効活用する その5 （FreeBSD 13.3R、2024/04/12） [FreeBSD]
muninの設定としては、こんな感じで。controlなどの設定はFreeBSDのlocal_unboundの初期設定でちゃんと面倒みてくれているはずですが、心配なら、/usr/sbin/local-unbound-control statusを実行して、ちゃんと結果が返ってくることを見ておけば良いです。
unbound.stateの指定は、私が参考にしたWebから設定を流用したため、しばらく間違ったまま運用していたのですがその際も可視化できていたので、実際に有効な設定なのかよくわかりません。
結果はこんな感じで、ちゃんと可視化できていますね。端末が多ければもっと派手にグラフが立ち上がるのでしょうが、こんなものでしょう。
unbound.stateの指定は、私が参考にしたWebから設定を流用したため、しばらく間違ったまま運用していたのですがその際も可視化できていたので、実際に有効な設定なのかよくわかりません。
root@MyFreeBSD:~ # cat /usr/local/etc/munin/plugin-conf.d/plugins.conf [unbound*] user root env.statefile /var/munin/plugin-state/root/unbound.state env.unbound_conf /etc/unbound/unbound.conf env.unbound_control /usr/sbin/local-unbound-control
結果はこんな感じで、ちゃんと可視化できていますね。端末が多ければもっと派手にグラフが立ち上がるのでしょうが、こんなものでしょう。
Unboundを有効活用する その4 （FreeBSD 13.3R、2024/04/12） [FreeBSD]
ちゃんと動けば、あとはDHCP払い出しでのDNSサーバに追加するだけです。これはその2で示したように、障害時などの冗長性を考えて設定します。
次に、ここからは完全オプションですが、Unboudの統計情報をmuninで可視化してみます。muninについては、基本的な可視化（情報収集やWebサーバでの公開）は、既に実現できているものとします。
muninには標準で可視化用のpluginが多数用意されており、FreeBSDの場合、pkgから導入すると /usr/local/share/munin/plugins/ 配下にインストールされます。ここでのポイントとしては、Unbound用のpluginはmunin標準では提供されず、Unbound側の成果物として提供されていることです。
うれしいことに、FreeBSDのlocal-Unboundでも、munin用のpluginはきちんと配布物に包含されています。分かりにくいですが具体的な場所は以下となります。
/usr/src/contrib/unbound/contrib/unbound_munin_
muninを設定した人なら分かると思いますが、自分が可視化したい情報（plugin）をシンボリックでpluginの実体に紐付ける設定構造になっています。これはシンボリックの名前の付け方で対象を指定する設定構造となっており、理にかなっていますね。
たとえば「if_」の実体に対し、「if_re0」でリンクを張ればインタフェース「re0」が可視化対象になるといった感じです。
Unboundのplugin構造もそういった構造になっており、一つのpluginの実体に対し、リンクの張り方で取得する情報を指定できるようになっています。具体的な名前の付け方はドキュメント等に書いてあると思われますが、pluginの中を覗けば分かるようになっています。（cat等でそのまま中を見ればOK）
私の今のバージョンだと、unbound_munin_hits、unbound_munin_queue、unbound_munin_queue、
unbound_munin_memory、unbound_munin_by_type....（以下略）など、いろいろ指定できるようです。
その5へ続く。
次に、ここからは完全オプションですが、Unboudの統計情報をmuninで可視化してみます。muninについては、基本的な可視化（情報収集やWebサーバでの公開）は、既に実現できているものとします。
muninには標準で可視化用のpluginが多数用意されており、FreeBSDの場合、pkgから導入すると /usr/local/share/munin/plugins/ 配下にインストールされます。ここでのポイントとしては、Unbound用のpluginはmunin標準では提供されず、Unbound側の成果物として提供されていることです。
うれしいことに、FreeBSDのlocal-Unboundでも、munin用のpluginはきちんと配布物に包含されています。分かりにくいですが具体的な場所は以下となります。
/usr/src/contrib/unbound/contrib/unbound_munin_
muninを設定した人なら分かると思いますが、自分が可視化したい情報（plugin）をシンボリックでpluginの実体に紐付ける設定構造になっています。これはシンボリックの名前の付け方で対象を指定する設定構造となっており、理にかなっていますね。
たとえば「if_」の実体に対し、「if_re0」でリンクを張ればインタフェース「re0」が可視化対象になるといった感じです。
root@MyFreeBSD:~ # ll /usr/local/etc/munin/plugins/ total 0 lrwxr-xr-x 1 root wheel 34 Jun 12 2022 cpu@ -> /usr/local/share/munin/plugins/cpu lrwxr-xr-x 1 root wheel 39 Jul 2 2022 dev_cpu_freq@ -> /usr/local/share/munin/plugins/dev_cpu_ lrwxr-xr-x 1 root wheel 33 Jul 1 2022 df@ -> /usr/local/share/munin/plugins/df lrwxr-xr-x 1 root wheel 42 Jun 12 2022 if_errcoll_re0@ -> /usr/local/share/munin/plugins/if_errcoll_ lrwxr-xr-x 1 root wheel 42 Jun 12 2022 if_packets_re0@ -> /usr/local/share/munin/plugins/if_packets_ lrwxr-xr-x 1 root wheel 34 Jun 12 2022 if_re0@ -> /usr/local/share/munin/plugins/if_ ....
Unboundのplugin構造もそういった構造になっており、一つのpluginの実体に対し、リンクの張り方で取得する情報を指定できるようになっています。具体的な名前の付け方はドキュメント等に書いてあると思われますが、pluginの中を覗けば分かるようになっています。（cat等でそのまま中を見ればOK）
私の今のバージョンだと、unbound_munin_hits、unbound_munin_queue、unbound_munin_queue、
unbound_munin_memory、unbound_munin_by_type....（以下略）など、いろいろ指定できるようです。
その5へ続く。
Unboundを有効活用する その3 （FreeBSD 13.3R、2024/04/08） [FreeBSD]
不具合の状況がよく分からないので、まずはログですね。以下を追加してログを残すようにします。なお、chroot環境なので、ログのひな形を事前touchする際は作成場所の注意が必要です。
で、分かったのは以下の大量のエラーが表示されているということ。
DNSSEC絡みか…とちょっと頭が痛い感じです。最近、DNSSEC関連のトラブルはよく聞きますよね。私は正直なところあまり理解できてないです。エラーメッセージはGoogle検索してみたのですが、これといった有力な解決策は提示されていない感じです。
ただ、個人的な感覚として、そもそもコンフィグファイルで設定されている内容がほとんどなく、ルートキー関連の設定も問題なさそうなので、ハマる要素はないように思えるのですが。。。
で、Google見つけた回答（翻訳）ですが、「フォワーダーに設定しているISPのDNSサーバがDNSSECに対応していないので、DNSSEC自体を無効にすればいいよ」というものです。確証はないですが、私もなんとなくそんな気がしました。（笑）
DNSSECを無効化するにはauto-trust-anchor-fileの設定をコメントアウトすれば良いので、修正してサービスを再起動します。
…うまく動きました。
その4へ続く。
root@MyFreeBSD:/etc # cat /etc/unbound/unbound.conf
server:
verbosity: 1
logfile: /var/log/unbound.logで、分かったのは以下の大量のエラーが表示されているということ。
[1712290383] local-unbound[40359:0] info: generate keytag query _ta-4f66. NULL IN [1712290384] local-unbound[40359:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN [1712290384] local-unbound[40359:0] info: generate keytag query _ta-4f66. NULL IN [1712290384] local-unbound[40359:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN [1712290384] local-unbound[40359:0] info: generate keytag query _ta-4f66. NULL IN [1712290384] local-unbound[40359:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN [1712290384] local-unbound[40359:0] info: generate keytag query _ta-4f66. NULL IN [1712290384] local-unbound[40359:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN [1712290384] local-unbound[40359:0] info: generate keytag query _ta-4f66. NULL IN [1712290384] local-unbound[40359:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN
DNSSEC絡みか…とちょっと頭が痛い感じです。最近、DNSSEC関連のトラブルはよく聞きますよね。私は正直なところあまり理解できてないです。エラーメッセージはGoogle検索してみたのですが、これといった有力な解決策は提示されていない感じです。
ただ、個人的な感覚として、そもそもコンフィグファイルで設定されている内容がほとんどなく、ルートキー関連の設定も問題なさそうなので、ハマる要素はないように思えるのですが。。。
で、Google見つけた回答（翻訳）ですが、「フォワーダーに設定しているISPのDNSサーバがDNSSECに対応していないので、DNSSEC自体を無効にすればいいよ」というものです。確証はないですが、私もなんとなくそんな気がしました。（笑）
DNSSECを無効化するにはauto-trust-anchor-fileの設定をコメントアウトすれば良いので、修正してサービスを再起動します。
…うまく動きました。
その4へ続く。
Unboundを有効活用する その2 （FreeBSD 13.3R、2024/04/07） [FreeBSD]
そういえば、やりたいことを説明していませんでした。
やりたいことはUnboundを自宅内のキャッシュDNSサーバとして稼働させることです。FreeBSDサーバ機自身だけでなく、DHCP等で家庭内にアドレス配布し、Windows機、スマートホンなどにも使わせるイメージです。
ただ、以前似たようなことをBINDで実装したとき、FreeBSD機の障害や電源OFF時に、家庭内でDNS名前解決ができなくなり、復旧が面倒だったので、今回は一工夫入れます。
至ってシンプルですが、
・キャッシュDNSサーバ（FreeBSD）のフォワーダーはISPのDNSサーバを設定する
・DHCPで配布するDNSサーバは、①FreeBSD Unbound ②ISP DNSサーバとする
こうやることで、FreeBSD障害時でも最低限の名前解決は維持できるようにします。
その3へ続く。
やりたいことはUnboundを自宅内のキャッシュDNSサーバとして稼働させることです。FreeBSDサーバ機自身だけでなく、DHCP等で家庭内にアドレス配布し、Windows機、スマートホンなどにも使わせるイメージです。
ただ、以前似たようなことをBINDで実装したとき、FreeBSD機の障害や電源OFF時に、家庭内でDNS名前解決ができなくなり、復旧が面倒だったので、今回は一工夫入れます。
至ってシンプルですが、
・キャッシュDNSサーバ（FreeBSD）のフォワーダーはISPのDNSサーバを設定する
・DHCPで配布するDNSサーバは、①FreeBSD Unbound ②ISP DNSサーバとする
こうやることで、FreeBSD障害時でも最低限の名前解決は維持できるようにします。
その3へ続く。
Unboundを有効活用する その1 （FreeBSD 13.3R、2024/04/05） [FreeBSD]
うちのFreeBSDのサーバ、CPUはPentium Silver J5040、メモリは16GBでそこそこ良いモノを装備しているんですが、あまり有効に使えてなかったりします。ほぼ常時稼働のNASサーバとしても使っているので（というかこれがほぼメイン）、なんかないですかね？
というわけで、FreeBSD標準添付のUnboudを使って、DNSキャッシュサーバ兼、muninの可視化でもやってみることにしました。
FreeBSDには標準構成にUnboundが含まれており、pkgから導入しなくてもそのまま使うことができます。さすがBSDライセンスですね。標準添付のUnboundは自分自身に対するローカルキャッシュサーバの用途に特化しているようで、rc.confの設定上でも「local_unbound」としてpkg導入のものと区別されています。
ただ、local_unboundに関してはあまり参考ドキュメントがないようで、正直使い方がよく分からない。デフォルトコンフィグがどこにも置かれていない。share/exapmlesのどこかにあるかなと思って探してみたのですが、それそれもなさそう。
賢いFreeBSDのことなので、エラーメッセージで何か教えてくれるだろうと思い、rc.confにlocal_unbound_enable="YES"を書き込んで強制的にサービス開始。と、…/etc/unbound配下に勝手にコンフィグ作って動作してくれました。しかもほぼ完成版で、修正する箇所がなくて困るぐらい。
control.conf
forward.conf
lan-zones.conf
root.key
unbound.conf
ただ、これでめでたしめでたし、といかないのが楽しいところ。名前解決…できませんでした！
resolv.confも修正されており、もともと設定されていたDNSサーバはforward.confにちゃんと移植されていて、コンフィグは問題なさそう。
サービスも立ち上がっていて、127.0.0.1でListen状態だし、はてな？？ 勝手に作成されたコンフィグ本体のunbound.confも特には問題なさそうです。
その2へ続く。
というわけで、FreeBSD標準添付のUnboudを使って、DNSキャッシュサーバ兼、muninの可視化でもやってみることにしました。
FreeBSDには標準構成にUnboundが含まれており、pkgから導入しなくてもそのまま使うことができます。さすがBSDライセンスですね。標準添付のUnboundは自分自身に対するローカルキャッシュサーバの用途に特化しているようで、rc.confの設定上でも「local_unbound」としてpkg導入のものと区別されています。
ただ、local_unboundに関してはあまり参考ドキュメントがないようで、正直使い方がよく分からない。デフォルトコンフィグがどこにも置かれていない。share/exapmlesのどこかにあるかなと思って探してみたのですが、それそれもなさそう。
賢いFreeBSDのことなので、エラーメッセージで何か教えてくれるだろうと思い、rc.confにlocal_unbound_enable="YES"を書き込んで強制的にサービス開始。と、…/etc/unbound配下に勝手にコンフィグ作って動作してくれました。しかもほぼ完成版で、修正する箇所がなくて困るぐらい。
control.conf
forward.conf
lan-zones.conf
root.key
unbound.conf
ただ、これでめでたしめでたし、といかないのが楽しいところ。名前解決…できませんでした！
resolv.confも修正されており、もともと設定されていたDNSサーバはforward.confにちゃんと移植されていて、コンフィグは問題なさそう。
root@MyFreeBSD:/etc # cat /etc/unbound/forward.conf
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
forward-zone:
name: .
forward-addr: 192.168.x.xサービスも立ち上がっていて、127.0.0.1でListen状態だし、はてな？？ 勝手に作成されたコンフィグ本体のunbound.confも特には問題なさそうです。
root@MyFreeBSD:/etc # cat /etc/unbound/unbound.conf
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
server:
username: unbound
directory: /var/unbound
chroot: /var/unbound
pidfile: /var/run/local_unbound.pid
auto-trust-anchor-file: /var/unbound/root.keyその2へ続く。
