@Jirajine #2 但是不是可以故意给有很多已知漏洞的旧版本？顺着请求的 IP 打过去…

V2EX 自己的 1brc

对我来说没有吸引力，我连苹果自带的钥匙串都很抗拒，因为：
1. 跨平台体验问题
2. 如何备份到多处？这种重要数据只在 iCloud 存一份不带历史、无法确定是否和本地一致的数据我是绝对不放心的

@tangshuier #19 我不了解早期是什么样，但在我看来只是因为 chromium 是浏览器里绝对的主流。我认为反指纹不只是随机几项参数来生成不同的指纹就行，还应该追求隐匿在海量真实用户之中，所以如果要基于 firefox 做，除了考虑对抗那些常规的浏览器指纹检测点，你还要想办法把 firefox 伪装成 chromium 或是其它用户占比高的浏览器（举个例子就是 firefox 自带的 privacy.resistFingerprinting=true 会在 Linux 上伪装成 Windows 的 UA ），而 Firefox 和 chromium 之间的差异太多了，例如 TLS 、HTTP/2 、QUIC 这些指纹全得处理，工作量太大了吧。

@raw0xff #24 不是大佬，不过很喜欢讨论这些

https://gchq.github.io/CyberChef/#recipe=From_Base64('A-Za-z0-9%2B/%3D',true,false)RSA_Decrypt('-----BEGIN%20RSA%20PRIVATE%20KEY-----','','RSA-OAEP','SHA-1')&input=b28zSlNNRnl4QVVaaEJlVXZIOHU0MHVXQWxGN2gxcmJxaTF5ZElCNUxZdWZDUndXdzNybEJjWk5aR0FzSUp6Z3JybFE4aTBTdlNOMXVCd3BKUjIyOGR0TWlxQ0ZGVFdxS2hxNjR3TWNUN29SWWgva2FWMW9kZ0tkQUw3dkh6eituZDJwd3MvcGUrdlkybkpPc0t5ZEJUcVBmaCtNQmtwSEhaajFON2dycHhVPQ&ieol=FF&oeol=NEL

需要深入理解浏览器指纹原理，知道怎么对抗；需要能搞懂 Chromium 这个庞大的项目并且找到用来 patch 过各种检测项的合适位置，能给 Chromium 设计和添加好用的 API ；需要应对可能存在的法律风险，我不觉得它和你说的一样一定是合法的

随便哪个都很难吧，何况确实很多人做，只不过你只能看到成功的 ads 、紫鸟等

翻墙和 VPN 回家

@busier #38

我在 #33 并没有将你的应用跟“所有 Web 网站”对比，我是将你的应用与常见的 E2EE 应用做对比。它们解决了，而你的方案或者说浏览器没解决，在这个重要问题没有解决的时候说 "解决服务器不可靠"、"管理员也获取不到明文信息，包括 CDN 也是" 就是不对的。

> 加解密部分的代码是静态不改变且开源的
> 用户只要校对这部分代码(或设计个校对功能)便不是问题

首先，我认为不可能只审计一部分代码，而是你的网站前端的所有代码都要审计，而目前 Web 的运作方式让这个事情失去它应有的意义，因为作为用户根本没办法保证下一次请求的代码不会变。除非你自己分发前端 HTML 文件，或者用个外部软件来提供保障，那这也就和你原文中 "客户端浏览器纯前端"、 "浏览器加载页面时" 矛盾了。

推荐这篇讨论 https://news.ycombinator.com/item?id=39436238 浏览器有往这方面发展的趋势，但并不够

E2EE 可以让用户只信任客户端，我个人对 E2EE 应用的要求是：开源的客户端、客户端会执行的代码在编译后就是确定的、客户端经过审计。而对于你的 "纯 Web 界面的端到端加密"，用户还必须信任浏览器每次加载的页面，你作为网站管理员被胁迫了或者你服务器被黑了怎么办？你用的 CDN 被黑了怎么办？还是说你打算单独分发前端源码文件？

@NewYear #24 #15 我看了下，v2ex 的 RSS 是有 ID 的，是我记错了

遇到过有的 RSS 不带 ID ，RSS 工具就会自己算 id/guid ， # 后面的内容也会被带进去计算

我也一直觉得应该分为两个，最新发布的主题是一个，有最新回复的主题是另一个。我记得它会在后面带上#reply 并且没有唯一的 ID ，就会重复推送了。

该学第二三四五六七八门语言了

想起前些天遇到穿警服的随机让路人填表，调查这个那个的满意度，我认真填完了之后对方让写上姓名和手机号，我说不必了我要匿名反馈，感觉对方两人噎了一下。。。

> 目前有人脸识别的地方我都非常谨慎，也就政府网站和支付宝银行认证过。其他坚决不搞

看到这里我有点不理解，当时为什么妥协啊？这又不是什么耽误不起的急事。。。

> 家里女票为了薅羊毛省钱
> 家里人把灯给卖了

就算当时妥协了，既然后悔了，就该质问官方到底是什么情况啊，保留证据。这都只是打打客服电话和举报电话的事情，而且这和家里人也无关吧，服务商要求不合理不是用户的错。

我觉得有，而且不止保险，各种条款细则多到普通人很难读的产品，都可以做个工具站来处理，例如总结出需要着重关注哪些，例如对比多个高亮出差异，例如常见陷阱条款。但这不是用一用目前的 LLMs 就能搞定的吧，你也要足够专业才行。

@0o0O0o0O0o #4 以及你提到的证书的限制，还可以扩展到中间件、服务商等等的限制

好玩，我觉得可以加一些东西：

1. 可以选择根据 UA 生成极限长度，我记得不同浏览器是不同的，相信不同工具、语言也会不同
2. 在首页科普域名的最大长度、真实世界的 URL 的最大长度

我觉得只要不是在海鲜市场里淘一些稀奇古怪的设备，很难遇到不满足这个要求的