[過去ﾛｸﾞ] 【広告除去】AdGuard Part75【Android】 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
903(1): 2023/06/06(火)20:07 ID:/xaxcUeI(1) AAS
>>895
アドガは昔から割れ系のポップ広告に弱いイメージ
+入れるとだいぶよくなるね
904(1): 2023/06/06(火)20:32 ID:wxkN6eyP(1) AAS
>>902
ソース読んだけどGoogle Safe Browsingが機軸って書いてなくね？
905(1): 2023/06/06(火)20:34 ID:teNsX78H(1) AAS
>>904
AdGuard for Windows, Mac, and Android
We use the protocol Safe Browsing API version 2.2 for our work with filters.
906(1): 2023/06/06(火)20:59 ID:bTGxr0Dr(1) AAS
>>900
>>749がnot plannedで対応された理由が何となく分かりました
907(1): 2023/06/06(火)21:07 ID:Lii/u/aQ(1) AAS
>>905
多分それは機能的にはGoogleセーフブラウジングAPIを使っているという意味でフィルタは内製なのでは？
908: 2023/06/06(火)21:10 ID:G+Z91nrp(4/6) AAS
セキュリティ面はAdGuardにどこまで期待してるかが人それぞれ違うから難しいな
909: 2023/06/06(火)21:15 ID:G+Z91nrp(5/6) AAS
>>900
アレックスが言うようにブラウジングセキュリティで対処するのが理想
一方でユキさんが言うように危険度の高いやつは管轄違いだろうと被害者が増える前に速やかに対処するのもまた重要
どっちも一理あるからこそ揉めるんだなと
910: 2023/06/06(火)21:20 ID:EE1Ti7hN(1) AAS
ユキは優しいな
多少ルールを変えてでもユーザーを守ろうとしての行動
911(1): 2023/06/06(火)21:55 ID:+NSqGRAV(1) AAS
雪からAdGuard社のセキュリティ担当者に依頼するルートがないのが意外だわ
広告フィルタ開発の過程でフィッシングサイトを見つけても今回みたいなイレギュラーな対応する以外はAdGuard社の担当者が対処するのを待つしかないのかよ
912: 2023/06/06(火)21:58 ID:OW9rS4QL(1) AAS
>>907
詳しくないから予想だけどGoogleセーフブラウジングのAPIを使ってるならGoogleセーフブラウジングの標準フィルタはそのまま使えてそこにプラスアルファでAdGuard社が見つけた危険サイトも追加してるとかじゃないのか？
913(2): 2023/06/06(火)22:04 ID:MA8zcMea(1) AAS
多分大丈夫だと思うけどこういうのが原因で雪さんとAdGuard社の関係性が悪くならないことを祈るわ
914: 2023/06/06(火)22:35 ID:G+Z91nrp(6/6) AAS
>>911
他のフィルタメンテナと内部チャットでやりとりすることもあるらしいからアレックス経由で担当社員に伝えてもらったりというのはできるんじゃないかな
知らんけど
>>913
意見の対立はあれどアレックスはユキさんの実力を認めてるからそこは大丈夫だろ
ユキさんが異議を唱えてアレックスが対処を変更したのを見たことあるからね
アレックスが他人の意見を真面目に聞くのってAdGuard社内だとAメシュコフ（CTO＝技術部門のトップ）くらいなもんでしょ
915: 2023/06/06(火)23:29 ID:4ZzTh+lE(1) AAS
>>724
いやいや↓だよ？
> 要素内のすべてのリンクが、（一度アンテナサイトを経由した後）元のサイトの記事につながる場合はブロックしません。
916: 2023/06/06(火)23:30 ID:+GBEqtPR(1) AAS
>>903
報告ないから対応もそれないね
917(1): 2023/06/06(火)23:55 ID:vtFhtQmx(1) AAS
>>900 ID:G+Z91nrp
Yukiのcommitを採用するとブラウザセキュリティが壊れるので一応もなにもAlexが正しくYukiが間違っている
お気持ちは察するがYukiがいつも多用しているgeneral_url.txt - ! Malware/Phishingのようなものがadservers.txtやspecific.txtにないのだからやめろと言うほかAlexにもないのでは
きちんと事前連絡してなんらかの対応や代替手段を得ようとしてくれればAlexもgeneral_url.txt - ! Malware/Phishingのようにやりようがあったかもしれない
それに問題にきちんと対応しているのだから十分Alexは仕事をした
外部ﾘﾝｸ[html]:reports.Adguard.com
反論も感情的なものだしで中間管理職のAlexが可哀想なのが正直な感想
918: 2023/06/07(水)00:07 ID:2qf+raS0(1) AAS
やはり今後のために窓口や手順を確認しておきましょうと
すり合わせを行う必要があるという共通認識を作るのが大事だということですね
919(1): 2023/06/07(水)00:12 ID:+c1loWIw(1) AAS
>>917
アレックスが正しいのはわかってるよ
それでも余りにも被害が大きそうなときは緊急事態のため暫定措置として通常フィルタに入れといてブラウジングセキュリティが対応したら消すという考えもまあなくはないと思う
事前にこういうときどうするか話しとけばってのは同意
今回の件を活かして次から上手くやって欲しい
920: 2023/06/07(水)00:26 ID:s5R4aDww(1) AAS
>>887
読めてないのお前なんだがww
画像ﾘﾝｸ[jpg]:i.imgur.com
左上の文字も読めない馬鹿丸出し過ぎて引くわ
921(2): 2023/06/07(水)00:55 ID:mxvOPk0E(1) AAS
ブラウザセキュリティはプレミアム限定です
だから無課金ユーザーはamazonlogistics.jpに普通にアクセスできます
なおcommitがまだ有効になってしまっているためAdGuard DNSフィルタにamazonlogistics.jpが存在しています（アレックスがrevertしないできちんと見て見ぬ振りしていたことを皆さんお忘れですね）
そのためAdGuard DNSフィルタを利用しているプレミアムユーザーはブラウザセキュリティが動作せずnet::ERR_CONNECTION_REFUSEDになります（もちろん無課金ユーザーも）
うっかりオフにしてアクセスしたらプレミアムなのに悲惨ですね
AdGuard DNSフィルタを利用していないプレミアムユーザーはブラウザセキュリティではなくuBOライクなルールに基づく遮断画面になります
プレミアムでブラウザセキュリティオフでも同じですのでAdGuard DNSフィルタを利用していない無課金ユーザーも同様の効果が得られるでしょう
画像ﾘﾝｸ[png]:i.imgur.com
気づいていない人が多そうですがnet::ERR_CONNECTION_REFUSEDは置いておくとしてAdGuardユーザーであればすべてのユーザーがamazonlogistics.jpに釣られることはすでになくなっています
これはAdGuard PublicDNSも含みます
省5
922: 2023/06/07(水)00:56 ID:fJn+F7jG(1) AAS
アレックス・ロドリゲス
上下前次1-新書関写板覧索設栞歴
あと 80 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.023s