©CC BY-NC-SA 4.0

频道: cx.ms/channel
笔记: cx.ms/memo
博客: cx.ms/blog
剪贴: cx.ms/clip
社交: cx.ms/sns
#吐槽

In reply to nevent1q…6ww2
_________________________

DoH, DoT 和 DoQ 都得经过 TLS 和 DNS Bootstrap 才能进行 DNS 解析, 这是个先有鸡还是先有蛋的问题. 我觉得 ECH 主要还是补上了这些加密 DNS 的最后一块拼图, 把加密 DNS 的的 SNI 也隐藏在了通用 SNI 下面. 不过就我个人来说, 加密 DNS 完全可以用 IP 证书, 这就直接没了 SNI 也不需要 DNS Bootstrap, 很适合小规模部署 DNS 代理的组织和个人(也不知道市场里的 IP 证书是否经济实惠). 现阶段几乎所有(包括积极跟进 ECH 的 AdGuard)的 DNS 客户端在查询这些加密 DNS 上游的时候都没有支持 ECH, 当然最主要的还是这些加密上游都没有支持并且用到并且核心开源库也都没支持.

#AdGuard 在 23 年给自己作为 HTTPS 中间人过滤这个角色加入了 ECH 客户端, 所以现在理论上 AdGuard 能给所有的加密连接过滤之后发出之前全部启用 ECH. 所以这也是个问题: 反病毒安全软件的 HTTPS 中间人过滤会直接破坏 HTTP 客户端(特别是浏览器)的原生 ECH, 如果安全软件不能在请求过滤之后发出本机之前重新恢复 ECH 那浏览器们一众实现的客户端侧 ECH 就失效了. 我也不知道 AdGuard 是在安全软件之前还是之后过滤加密流量, 越来越觉得 AdGuard 有点像个不能反病毒的安全软件了.
> https://forum.eset.com/topic/38340-web-access-protection-and-encrypted-client-hello-ech/

对于 ECH 的问题现阶段的问题还是一众浏览器们都只会在设置里面显式启用加密 DNS 之后才能启用 ECH, 这就意味着本地 DNS 代理和路由器下发的 DNS 服务器配置都实际对有这种强制要求 HTTPS 记录查询也加密的客户端无用. 所以如果不使用 AdGuard 这样的中间人, 就得给自己的本地网络回环下部署的 DNS 代理也上 SSL 证书, 然而这又撞上了自签证书的信任问题, 不过好在有 mkcert 这种工具包简化了自签本地证书并信任的流程.
简而言之, 现阶段的 Edge, Firefox 和 Chrome 主流浏览器都对 ECH 启用条件十分苛刻, 它们不允许用户在使用本地回环网络的 DNS 服务器的情况下启用, 即使它们本来的上游就是加密 DNS 也能完成 HTTPS 记录的中继. 而非浏览器应用的 HTTP 客户端更没有动力去支持 ECH.
> https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Local-DoH#creating-your-own-certification

PS: AdGuard for Windows 现阶段依旧还在解决和带有 HTTPS 过滤的反病毒安全软件之间的兼容性问题.

via Nostr@cxplay
AdGuard 家庭版(9 设备)终身订阅平史低 $15.97

销售位于 StackSocial, 需要使用优惠券 FAMPLAN. 结算后 $15.97(约合人民币 ¥115), 平史低.

购买链接: AdGuard Family Plan Lifetime Subscription - StackSocial (aff)
注册 StackSocial 并获得 $10 余额: cx.ms/stacksocial

#折扣 #AdGuard

via CXPLAY's Memos
#吐槽

In reply to nevent1q…83xk
_________________________

作为 Web 环境的最终话事人, 如今的 Google 肯定不会允许有人破坏自己的游戏规则, 这应该是我能想到的它费尽心思打造 WEI 和 MV3 的目的.
它想要 Chrome 也变成现在的 Android 一样处处充满「公平」, 就像 GM 规定游戏里不准开挂一样.
可这互联网中从来就不允许有只手遮天的 GM, 也不是人人都想玩「游戏」.
AOSP 这边已经有点高温了, Chromium 这边才只是感受到水温而已.

via Nostr@cxplay
#吐槽

从来没想到我会给 #Fediverse#AdGuard 屏蔽规则, 已经变成QQ空间了, 在我记忆里曾经的QQ空间还不及于此吧.

我对个性化的选择总是最小化原则, 勿扰他人清闲, 最好能够让人选择不看.
因为不太在意社交媒体上人的立场, 所以我甚至想把名称里带有的 Emoji, 图标和关键词也去掉.
还好自定义表情不会跳出来给我眼睛一拳, 不然多少也保不住.

想不出更好的比喻了. 就像朋友发给你一张全是字的截图说它真的很有用, 然后打开一看结果是超级个性化的花体字体, 拼尽全力考古也无法解读背后的 Unicode 字符. 可惜这是截图, 我没办法从屏幕钻过去给它手机换成黑体或者其他什么标准字体, 就算是衬线体也好啊.

还好去中心化的 "QQ空间" 还能用 CSS 自定义样式, 不会让我只能用 App 刷.
那我也不敢有意见了, 已经很久不再向外表达个性化了, 所以我也自己悄悄屏蔽一下好了.

via Nostr@cxplay
#吐槽

#AdGuard 把哔哩哔哩移动端视频链接落地页重定向到 embed 播放器

```adblock
||m.bilibili.com/video^$urltransform=/^https:\/\/m\.bilibili\.com\/video\/(BV\S{10})(?:\/)?(?:\?(?:.*p=(\d+))?)?.*/https:\/\/www\.bilibili\.com\/blackboard\/webplayer\/mbplayer\.html\?bvid=\$1&p=\$2/i
||m.bilibili.com/video^$urltransform=/^https:\/\/m\.bilibili\.com\/video\/av(\d+)(?:\/)?(?:\?(?:.*p=(\d+))?)?.*/https:\/\/www\.bilibili\.com\/blackboard\/webplayer\/mbplayer\.html\?aid=\$1&p=\$2/i
```

哔哩哔哩移动端视频落地页完全不能用, 不仅一打开就会自动跳 App, 还要点两三下才能进入在线观看, 然后停留一段时间还会弹网页弹窗让你打开 App, 不打开还会给你自动下载客户端 APK, 简直就是💩.
规则没办法在 uBlock Origin 上使用, 因为不支持非同源重定向, 或者又想办法用 User Script 重新实现一遍.

via Nostr@cxplay
#吐槽

然而我并不能给 uBlock Origin 付 $16 就让它能在我想要的浏览器是继续运行, 就算是每个月付 $16 也不行, 不管是付给 Google 还是付给 uBlock Origin 都不行, 所以只能付给了 #AdGuard.
一个普通消费者, 自己的选择并不能改变象牙塔里的人的选择和境遇, 只有 Google 和 Microsoft 乃至 Mozilla 这种开源运动里的巨头才能动摇, 让人感到绝望.
User 越来越无法控制 User-Agent 的行为了, 我还是期望 Google 早点被拆了吧. 有 Chrome 和 Chromium 也只能部分舒适, 还把 Mozilla 养成了混子, 都别想给我好过, 给我起来干活!

via Nostr@cxplay
AdGuard 家庭版(9 设备)终身订阅史低 $15.97

销售位于 StackSocial, 需要使用优惠券 FAMPLAN. 结算后 $15.97(约合人民币 ¥115.72), 史低.

这次虽然是史低, 但因为美元涨回来了, 其实比上次折扣贵了一块多.


购买链接: AdGuard Family Plan Lifetime Subscription - StackSocial (aff)
注册 StackSocial 并获得 $10 余额: cx.ms/stacksocial

#折扣 #AdGuard

via CXPLAY's Memos
#吐槽

刚刚对比了 #AdGuard 和 uBlock Origin 浏览器插件在狐猴浏览器里面的表现, 完全兼容语法写的规则, AdGuard 无法完成过滤, uBlock Origin 正常. 对于浏览器端的体验, 看起来还是 uBlock Origin 的效果更好一点.
quoting
nevent1q…hqau
去应用商店搜了下
https://play.google.com/store/apps/details?id=com.lemurbrowser.exts


via Nostr@cxplay
#吐槽

In reply to nevent1q…zhne
_________________________

刚想着去设置里调下配置, 居然发现了这个没有启用的选项: 压缩 HTTP 响应正文
"为了优化数据传输, 处理后压缩 HTTP 响应正文, 包括浏览器 API 响应. 使用 GZip 压缩算法."

我还以为是我眼花了, 之前明明是没有的. 然后去装了个最新正式版 v7.19 一看果然是没有的, 看来是 beta 版本正在测试的功能, 但我怎么从变更日志找不到对应的改动呢? 这也算是个比较大的改动了吧.

另外上个帖子的理解还是有误, #AdGuard 确实会重写 accept-encoding 标头以让服务器响应适应自己的能力, 但并非是直接请求的未压缩版本 HTML, 现在 AdGuard 已经支持了解压缩 GZip 和 Brotli, Deflate 的响应, 所以实际上只会重写为这三种编码的 accept-encoding 值.

不知道重写后直接发给浏览器未压缩的响应正文和重写后 GZip 一遍再发给浏览器压缩版本的正文浏览器再解压缩一遍谁更快呢?

via Nostr@cxplay
#吐槽

#AdGuard 的中间人级别过滤会重写浏览器的 accept-encoding 标头指示服务器发送未压缩版本的 HTML 网页以方便它直接过滤.
这种 "妥协" 导致了网页的加载速度基础上就慢了差不多一倍, 而且没了压缩就相对更加消耗流量了.

图为开启前后相同网页下的体积和加载速度, 压缩算法是 zstd.

via Nostr@cxplay
 
 
Back to Top