©CC BY-NC-SA 4.0
🚩加入 Nostr!moe 社区: join.nostr.moe
🚩加入 Nostr!moe 社区: join.nostr.moe
#吐槽
In reply to nevent1q…8udm
_________________________
为了加上一个简单的流量鉴权, Netlify 得要用边缘函数来实现, 消耗套餐配额. Vercel 一条规则就搞定了, 还有清晰的日志.
via Nostr@cxplay
In reply to nevent1q…8udm
_________________________
为了加上一个简单的流量鉴权, Netlify 得要用边缘函数来实现, 消耗套餐配额. Vercel 一条规则就搞定了, 还有清晰的日志.
via Nostr@cxplay
#吐槽
相比之下, Vercel 现在也提供 WAF 功能, 虽然自定义规则只有每个项目三条但好歹是有的. Netlify 这个 WAF 还有防火墙就需要企业级计划, 只能说换着用, 或者一起组合着用.
via Nostr@cxplay
相比之下, Vercel 现在也提供 WAF 功能, 虽然自定义规则只有每个项目三条但好歹是有的. Netlify 这个 WAF 还有防火墙就需要企业级计划, 只能说换着用, 或者一起组合着用.
via Nostr@cxplay
#吐槽
In reply to nevent1q…gdwq
_________________________
说起被 DoH 和 DoT 乃至 DoQ 这些现代的加密 DNS 协议真正取代的对象或者说 "干掉" 的, 并不是传统的明文 DNS, 而是 DNSCrypt. 虽然已经是过去式了, 但 DNSCrypt 留下的一些遗产还是很具有实用价值.
它发明的 DNS Stamps, 也就是编码出 sdns:// 这个标识符的工具, 可以直接指示加密 DNS 的证书指纹, IP 地址, 主机名(SNI). 现在还在支持这个 sdns 标识符的 DNS 客户端我只知道有 AdGuard 和 AdGuard Home, 并且也不会用上全部指示和标志.
AdGuard 目前只会用 sdns 解码之后的主机名(和 DoH 路径)以及 IP 地址, 主要用途是无需 Bootstrap 直接得到加密 DNS 的目标 IP, 适合像 Google 和 Cloudflare 等等的 DoH 直接解析到一个 Anycast 或者固定 IP 的加密 DNS.
DNS Stamps 支持的编码目标 DNS 协议很全面, DoH, DoT, DoQ, 甚至明文 DNS 也都可以, 但现在基本上没有客户端还在积极支持了.
via Nostr@cxplay
In reply to nevent1q…gdwq
_________________________
说起被 DoH 和 DoT 乃至 DoQ 这些现代的加密 DNS 协议真正取代的对象或者说 "干掉" 的, 并不是传统的明文 DNS, 而是 DNSCrypt. 虽然已经是过去式了, 但 DNSCrypt 留下的一些遗产还是很具有实用价值.
它发明的 DNS Stamps, 也就是编码出 sdns:// 这个标识符的工具, 可以直接指示加密 DNS 的证书指纹, IP 地址, 主机名(SNI). 现在还在支持这个 sdns 标识符的 DNS 客户端我只知道有 AdGuard 和 AdGuard Home, 并且也不会用上全部指示和标志.
AdGuard 目前只会用 sdns 解码之后的主机名(和 DoH 路径)以及 IP 地址, 主要用途是无需 Bootstrap 直接得到加密 DNS 的目标 IP, 适合像 Google 和 Cloudflare 等等的 DoH 直接解析到一个 Anycast 或者固定 IP 的加密 DNS.
DNS Stamps 支持的编码目标 DNS 协议很全面, DoH, DoT, DoQ, 甚至明文 DNS 也都可以, 但现在基本上没有客户端还在积极支持了.
via Nostr@cxplay
#吐槽
In reply to nevent1q…v45n
_________________________
那还挺唯心的, 可能这就是你不喜欢 JavaScript 的原因吧, 我理解了.
via Nostr@cxplay
In reply to nevent1q…v45n
_________________________
那还挺唯心的, 可能这就是你不喜欢 JavaScript 的原因吧, 我理解了.
via Nostr@cxplay
#吐槽
In reply to nevent1q…j0f2
_________________________
最早 Chrome 支持 gQUIC 的时候被人发现用来显示 YouTube 广告, 被 Brave 一发新闻稿, 大伙以为 Google 又在 Be Evil 了.
(2017/04/25) QUIC in the wild | Brave
https://brave.com/blog/quic-in-the-wild/
这个时候, Google 才开始和 IETF 推进 iQUIC 标准化. 大伙不爽的地方是 QUIC 被拿来发广告且无法被 uBlock Origin 这类活在浏览器应用层里面的插件拦截 (好了现在 MV3 直接把老家端了). Brave 此时推出显式禁用 QUIC 的功能就是为了防止只有 Google 在用的 gQUIC 被拿来发广告.
这不禁让我想起了只有微信在用的 mmTLS :bili_doge:
via Nostr@cxplay
In reply to nevent1q…j0f2
_________________________
最早 Chrome 支持 gQUIC 的时候被人发现用来显示 YouTube 广告, 被 Brave 一发新闻稿, 大伙以为 Google 又在 Be Evil 了.
(2017/04/25) QUIC in the wild | Brave
https://brave.com/blog/quic-in-the-wild/
这个时候, Google 才开始和 IETF 推进 iQUIC 标准化. 大伙不爽的地方是 QUIC 被拿来发广告且无法被 uBlock Origin 这类活在浏览器应用层里面的插件拦截 (好了现在 MV3 直接把老家端了). Brave 此时推出显式禁用 QUIC 的功能就是为了防止只有 Google 在用的 gQUIC 被拿来发广告.
这不禁让我想起了只有微信在用的 mmTLS :bili_doge:
via Nostr@cxplay
#吐槽
In reply to nevent1q…66fl
_________________________
Chromium 中的开发者工具只展示应用层的协议连接, 所以 HTTP/3 可以被看到连接, 但是 QUIC 连接就和 TCP/UDP 一样无法查看. 于是 YouTube 这种网页应用就会直接用 QUIC 加载资源, 截至目前, Chromium (v139) 只要检测到了系统代理配置或者改变了应用内代理, 那也会直接默认回退, 因为最常用的 HTTP 和 SOCKS5 对 HTTP/3 和 QUIC 的支持不完善, QUIC 并非是完全可以当 UDP 来处理的连接. Chromium 也会优先用 QUIC 来尝试发起 ECH, 失败之后会回退到 TCP.
现在网上交流的时候也都太容易混淆 QUIC 和 HTTP/3 了.
via Nostr@cxplay
In reply to nevent1q…66fl
_________________________
Chromium 中的开发者工具只展示应用层的协议连接, 所以 HTTP/3 可以被看到连接, 但是 QUIC 连接就和 TCP/UDP 一样无法查看. 于是 YouTube 这种网页应用就会直接用 QUIC 加载资源, 截至目前, Chromium (v139) 只要检测到了系统代理配置或者改变了应用内代理, 那也会直接默认回退, 因为最常用的 HTTP 和 SOCKS5 对 HTTP/3 和 QUIC 的支持不完善, QUIC 并非是完全可以当 UDP 来处理的连接. Chromium 也会优先用 QUIC 来尝试发起 ECH, 失败之后会回退到 TCP.
现在网上交流的时候也都太容易混淆 QUIC 和 HTTP/3 了.
via Nostr@cxplay
#吐槽
In reply to nevent1q…wxjk
_________________________
? 那你知不道 Nostr 是一个基于 WebSocket 的协议? 你到底在说什么? 你要喜欢禁用 JavaScript, 那现阶段 90% 的在浏览器运行的 Nostr 客户端都无法使用, 你真的了解过这个协议吗?
via Nostr@cxplay
In reply to nevent1q…wxjk
_________________________
? 那你知不道 Nostr 是一个基于 WebSocket 的协议? 你到底在说什么? 你要喜欢禁用 JavaScript, 那现阶段 90% 的在浏览器运行的 Nostr 客户端都无法使用, 你真的了解过这个协议吗?
via Nostr@cxplay
#吐槽
In reply to nevent1q…natw
_________________________
那我也要问了, 纯前端如何在不用 JavaScript 的情况下完成 WebSocket 协议升级?
via Nostr@cxplay
In reply to nevent1q…natw
_________________________
那我也要问了, 纯前端如何在不用 JavaScript 的情况下完成 WebSocket 协议升级?
via Nostr@cxplay
#吐槽
In reply to nevent1q…xydt
_________________________
结果 API 的 Gemini 2.5 Pro 也给出几乎一模一样结构的回答: 先积极地评价用户问题质量, 然后一个简短答案, 接下来开始分点分节回答, 最后给出整体结论.
而 GPT-5 则是: 简短答案, 然后分点回答, 最后给出建议.
via Nostr@cxplay
In reply to nevent1q…xydt
_________________________
结果 API 的 Gemini 2.5 Pro 也给出几乎一模一样结构的回答: 先积极地评价用户问题质量, 然后一个简短答案, 接下来开始分点分节回答, 最后给出整体结论.
而 GPT-5 则是: 简短答案, 然后分点回答, 最后给出建议.
via Nostr@cxplay
#吐槽
发现 Google One 里面附带的 Gemini 2.5 Pro 对比用 API 和对话客户端组合的 GPT-5 更倾向于谄媚用户一方(一个问题一开头 Gemini 基本必然要以积极的态度总体评价一次用户的问题质量), 可能是 Google One 的 Gemini 是个具体的产品, 而 GPT-5 的 API 是个面向开发者的服务.
等会试试用 Gemini 2.5 Pro 的 API 再继续对比看看, 大概率是系统提示词给 LLM 调成了这种不同状态.
via Nostr@cxplay
发现 Google One 里面附带的 Gemini 2.5 Pro 对比用 API 和对话客户端组合的 GPT-5 更倾向于谄媚用户一方(一个问题一开头 Gemini 基本必然要以积极的态度总体评价一次用户的问题质量), 可能是 Google One 的 Gemini 是个具体的产品, 而 GPT-5 的 API 是个面向开发者的服务.
等会试试用 Gemini 2.5 Pro 的 API 再继续对比看看, 大概率是系统提示词给 LLM 调成了这种不同状态.
via Nostr@cxplay
#吐槽
In reply to nevent1q…vx6x
_________________________
Just like jumble.social does. A timeline consisting of one or more relays.
via Nostr@cxplay
In reply to nevent1q…vx6x
_________________________
Just like jumble.social does. A timeline consisting of one or more relays.
via Nostr@cxplay
#吐槽
In reply to nevent1q…ttpc
_________________________
Add relay and relay set timeline support
via Nostr@cxplay
In reply to nevent1q…ttpc
_________________________
Add relay and relay set timeline support
via Nostr@cxplay
#吐槽
现在在隐私优先的用途里面, 浏览器扩展特别是 MV2 就是天然不安全的功能, 于是一些 Android 的 Chromium 分支就直接不考虑扩展支持, 然后选择自己实现一个内置的用户脚本管理器和兼容 AdBlock 语法的广告拦截器.
好吧, 我也能理解这是为了安全和隐私考量. 但我现在没有 uBlock Origin 和 Dark Reader 这样的插件我简直浏览器都不想打开, 而全部重新实现的开源内置替代都没有能真正完全替代.
我一直坚持不要强行帮用户选择安全性, 因为多数普通用户分不清安全和隐私的边界, 如果真的需要强制执行, 市场调研是最基本的一个保障, Google 为了客观上的安全性而强推 MV3 造成的后果就是最好的例子. 大多数时候被强调的只是安全性附带的那一层 "隐私糖衣", 被普通用户 "入口" 之后逐渐溶解就开始露出里面坚硬锋利的 "安全内核", 无法适应的用户会被排斥, 能适应的用户大多也只会变成 "隐私怪", 以 "嘴" 里塞满这种不明觉厉的 "硬糖" 为乐, 还喜欢到处张开大嘴炫耀里面有多少奇形怪状的硬货.
然而 "硬糖" 本来是要让人吃下去并且形成意识的, 至少 "吃糖" 时请不要吧唧嘴. 另外在我看来, 主动暴露安全工具也并不是个明智的选择.
via Nostr@cxplay
现在在隐私优先的用途里面, 浏览器扩展特别是 MV2 就是天然不安全的功能, 于是一些 Android 的 Chromium 分支就直接不考虑扩展支持, 然后选择自己实现一个内置的用户脚本管理器和兼容 AdBlock 语法的广告拦截器.
好吧, 我也能理解这是为了安全和隐私考量. 但我现在没有 uBlock Origin 和 Dark Reader 这样的插件我简直浏览器都不想打开, 而全部重新实现的开源内置替代都没有能真正完全替代.
我一直坚持不要强行帮用户选择安全性, 因为多数普通用户分不清安全和隐私的边界, 如果真的需要强制执行, 市场调研是最基本的一个保障, Google 为了客观上的安全性而强推 MV3 造成的后果就是最好的例子. 大多数时候被强调的只是安全性附带的那一层 "隐私糖衣", 被普通用户 "入口" 之后逐渐溶解就开始露出里面坚硬锋利的 "安全内核", 无法适应的用户会被排斥, 能适应的用户大多也只会变成 "隐私怪", 以 "嘴" 里塞满这种不明觉厉的 "硬糖" 为乐, 还喜欢到处张开大嘴炫耀里面有多少奇形怪状的硬货.
然而 "硬糖" 本来是要让人吃下去并且形成意识的, 至少 "吃糖" 时请不要吧唧嘴. 另外在我看来, 主动暴露安全工具也并不是个明智的选择.
via Nostr@cxplay
#吐槽
Oh Wonder - Magnificent - YouTube
https://www.youtube.com/watch?v=-085LqsijCw
#Music
via Nostr@cxplay
Oh Wonder - Magnificent - YouTube
https://www.youtube.com/watch?v=-085LqsijCw
#Music
via Nostr@cxplay
