#吐槽

In reply to nevent1q…87ru
_________________________

删除响应标头:

* Access-Control-Allow-Credentials
* Access-Control-Allow-Headers
* Access-Control-Allow-Methods
* Access-Control-Allow-Origin
* Access-Control-Expose-Headers
* Access-Control-Max-Age
* Access-Control-Request-Headers
* Access-Control-Request-Method
* X-XSS-Protection

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr (reply):

继续删除客户端请求标头: * Sec-CH-UA-Arch * Sec-CH-UA-Form-Factors * Sec-CH-UA-Full-Version * Sec-CH-UA-WoW64 新增和覆盖响应标头: * X-Robots-Tag * Referrer-Policy * Clear-Site-Data * Permissions-Policy * Content-Security-Policy * X-Content-Type-Opt [...]

#吐槽

goo.gl 现在不放弃了. 并且堂堂登场的是! goo.gle 和 g.gle 🤷‍♂️
goo.gle 的用途类似 aka.ms, g.gle 是去年才被注册出来现在用在 Google 的电子邮件链接点击追踪.
感觉 Google 其实只是不想用自己域名托管这些第三方重定向了想直接弃用. 但和 GitHub 的 git.io 一样, 最后也还是没有真正完全放弃.

quoting
nevent1q…a8ky
Google 在 2018 年 3 月就提醒开发者准备弃用 goo.gl 短链了, 到今天已经超过 6 年了, 现在又最终提醒一下启用中间页横幅通知迁移, 1 年之后才完全弃用, 怎么还有人骂呢? 通知强度不够? 是不是应该一年骚扰一次才够呢.
https://developers.googleblog.com/en/google-url-shortener-links-will-no-longer-be-available/

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr:

Google 在 2018 年 3 月就提醒开发者准备弃用 goo.gl 短链了, 到今天已经超过 6 年了, 现在又最终提醒一下启用中间页横幅通知迁移, 1 年之后才完全弃用, 怎么还有人骂呢? 通知强度不够? 是不是应该一年骚扰一 [...]

#吐槽

In reply to nevent1q…7fkt
_________________________

多玛姆, 我是来谈条件的

The next step for content creators in working with AI bots: Introducing AI Crawl Control
https://blog.cloudflare.com/introducing-ai-crawl-control/

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr (reply):

联邦抵制 Meta 还有个正当理由就是会让数据更轻易地未经同意就被用于模型训练. 没有人能够证明社交网络上的数据有多大价值能够被用于训练时分配足够高的权重. 冲浪高手应该都明白, 社媒上互动数据也 [...]

#吐槽

In reply to nevent1q…z0hc
_________________________

再去找人复刻一个 Nikocado Avocado 的剧本到身上, 还能再赚最后一笔. 不过不知道良子现在是处于哪个阶段. 看起来大概率没有如此成熟的计划, 他只是在吃和拍视频, 但是谁又知道呢.

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

Short Text Note by CXPLAY

又一个人形模因

良子的400斤大胃袋，装得下七宗罪吗？
https://mp.weixin.qq.com/s/uR40EvGGbiLA36rAlo38VA

#吐槽

又一个人形模因

良子的400斤大胃袋，装得下七宗罪吗？
https://mp.weixin.qq.com/s/uR40EvGGbiLA36rAlo38VA

via Nostr@cxplay

#吐槽

In reply to nevent1q…k8x4
_________________________

重新测试采样了一次, Vercel 平均延迟现在已经降到了 和 Netlify 一个水平.
新加了 AWS CloudFront, H2 + H3 平均延迟是 138ms. 其他的重新测试后的波动都不大.

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr (reply):

最近在多个平台部署了一个简单的 API, 有的还用一些 CDN 套了一层, 然后用一个客户端去测试全部 GET 多次取平均值, 目前的结果是 (速度降序): * 阿里云 ESA: 411ms (H2 + H3) * Cloudflare: 383ms (H2 + H3) * 腾讯 EdgeOne: 2 [...]

#吐槽

In reply to nevent1q…8clp
_________________________

继续删除客户端请求标头:

* Sec-CH-UA-Arch
* Sec-CH-UA-Form-Factors
* Sec-CH-UA-Full-Version
* Sec-CH-UA-WoW64

新增和覆盖响应标头:

* X-Robots-Tag
* Referrer-Policy
* Clear-Site-Data
* Permissions-Policy
* Content-Security-Policy
* X-Content-Type-Options
* X-Frame-Options
* Cross-Origin-Opener-Policy

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr (reply):

做好了: un.cx.ms 用法就是直接插入到白名单 URL 的域名之前, 将原始域名作为路径, un.cx.ms 作为域名直接访问. 比如原始 URL 是: https://example.com/track?url=123456 附加之后就是: https://un.cx.ms/example.com/track?url=123456 [...]

#吐槽

In reply to nevent1q…8clp
_________________________

DNT 的问题是它俩至今没有在市占率第一的某浏览器中默认启用, 而 Sec-GPC 更是没有被支持, 所以会主动启用的用户, 反而是给客户端添加了一个特征, 不得不说现实很讽刺. 我甚至敢暴论一下: 开启 DNT 的用户可能比用 Firefox 的用户还要少, 而带有 Sec-GPC 这个标头的用户要么是 Firefox 用户要么就是 AdGuard 本机客户端用户. :bili_fantastic:

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr (reply):

做好了: un.cx.ms 用法就是直接插入到白名单 URL 的域名之前, 将原始域名作为路径, un.cx.ms 作为域名直接访问. 比如原始 URL 是: https://example.com/track?url=123456 附加之后就是: https://un.cx.ms/example.com/track?url=123456 [...]

#吐槽

In reply to nevent1q…2z02
_________________________

做好了: un.cx.ms

用法就是直接插入到白名单 URL 的域名之前, 将原始域名作为路径, un.cx.ms 作为域名直接访问.
比如原始 URL 是: https://example.com/track?url=123456
附加之后就是: https://un.cx.ms/example.com/track?url=123456

自动覆盖客户端请求的标头:

* Accept-Language
* User-Agent

自动删除客户端请求的标头:

* DNT
* Sec-GPC
* Cookie
* If-None-Match
* Origin
* Referer
* Sec-CH-UA
* Sec-CH-UA-Architecture
* Sec-CH-UA-Bitness
* Sec-CH-UA-Full-Version-List
* Sec-CH-UA-Mobile
* Sec-CH-UA-Model
* Sec-CH-UA-Platform
* Sec-CH-UA-Platform-Version

自动删除服务端响应的标头:

* Accept-CH
* ETag
* Set-Cookie

除此之外被代理的当然也包括客户端 IP.
至于怎么让客户端自动附加, 可以用一些修改请求标头的浏览器扩展, 或者 AdGuard 的 $urltransform 修饰符, Android 上可以用 URLCheck.
主要提供演示, 自己从头造一个非常简单, 所以示例服务只对我自己保证 SLA, 没有用户协议也没有隐私协议 :bili_doge:

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr:

想做个专门代理短链接的小玩具, 之前在 URLCheck 那篇文章里面说过, 短链接的隐私问题可以用代理分流来缓解. 但是没有代理怎么办呢? IP 之外的信息如何剥离? 访问一个链接并不需要多完整的 User-Agent. 短链 [...]

#吐槽

In reply to nevent1q…why0
_________________________

最近在多个平台部署了一个简单的 API, 有的还用一些 CDN 套了一层, 然后用一个客户端去测试全部 GET 多次取平均值, 目前的结果是 (速度降序):

* 阿里云 ESA: 411ms (H2 + H3)
* Cloudflare: 383ms (H2 + H3)
* 腾讯 EdgeOne: 252ms (H2)
* Gcore: 243ms (H2)
* Fastly: 177ms (H2 + H3)
* Vercel: 142ms (H2)
* Netlify: 80ms (H2)

都是免费的套餐. 还不清楚运营商们是不是真的把 QUIC 和 UDP 统一对待, 但 QoS 应该还是有的. 目前浏览器(Chromium)普遍是先 H2 连接, 发现并缓存了 Alt-Svc 标头之后才会去尝试 H3, 并且似乎只要 H3 出现了一次错误, H3 的尝试就会被拉黑一段时间.
腾讯云 EdgeOne 的 H3 需要付费, 虽然有一个付费套餐但还没测试; Vercel 和 Netlify 这两家 PaaS 的边缘节点都还没支持 H3; Gcore 的 H3 已经在路线图正在进行, 但已经两年了还没出来.

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr (reply):

最早 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 推进 [...]

#吐槽

In reply to nevent1q…qw6s
_________________________

是的, 主要是比特币. 不过, 欢迎加入 Nostr!

via Nostr@cxplay

T (npub149…xq36n)

Short Text Note by T (reply)

是不是币圈的人多一点？

#吐槽

In reply to nevent1q…8udm
_________________________

为了加上一个简单的流量鉴权, Netlify 得要用边缘函数来实现, 消耗套餐配额. Vercel 一条规则就搞定了, 还有清晰的日志.

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr:

相比之下, Vercel 现在也提供 WAF 功能, 虽然自定义规则只有每个项目三条但好歹是有的. Netlify 这个 WAF 还有防火墙就需要企业级计划, 只能说换着用, 或者一起组合着用.

#吐槽

相比之下, Vercel 现在也提供 WAF 功能, 虽然自定义规则只有每个项目三条但好歹是有的. Netlify 这个 WAF 还有防火墙就需要企业级计划, 只能说换着用, 或者一起组合着用.

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr:

相比之下, Vercel 现在也提供 WAF 功能, 虽然自定义规则只有每个项目三条但好歹是有的. Netlify 这个 WAF 还有防火墙就需要企业级计划, 只能说换着用, 或者一起组合着用.

#吐槽

MoonTV 正式转为开源并移除授权码机制 - V2EX
https://www.v2ex.com/t/1155144

#opensource

via Nostr@cxplay

V2EX

MoonTV 正式转为开源并移除授权码机制 - V2EX

分享创造 - @guoziyang0033 - 此前一直没有在 V2EX 宣传过该项目，但是想着因为停更了也最好发一下公告仓库： https://github.com/MoonTechLab/LunaTV标题是好消息，那么坏消息呢？

#吐槽

In reply to nevent1q…rq76
_________________________

DNSCrypt 的概念很先进, 但推进的速度还是太慢了.

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr (reply):

说起被 DoH 和 DoT 乃至 DoQ 这些现代的加密 DNS 协议真正取代的对象或者说 "干掉" 的, 并不是传统的明文 DNS, 而是 DNSCrypt. 虽然已经是过去式了, 但 DNSCrypt 留下的一些遗产还是很具有实用价值. 它发明的 DNS Stam [...]

#吐槽

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

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr (reply):

DoH, DoT 和 DoQ 都得经过 TLS 和 DNS Bootstrap 才能进行 DNS 解析, 这是个先有鸡还是先有蛋的问题. 我觉得 ECH 主要还是补上了这些加密 DNS 的最后一块拼图, 把加密 DNS 的的 SNI 也隐藏在了通用 SNI 下面. 不过就我个 [...]

#吐槽

In reply to nevent1q…v45n
_________________________

那还挺唯心的, 可能这就是你不喜欢 JavaScript 的原因吧, 我理解了.

via Nostr@cxplay

ghost (npub14v…uuuge)

Short Text Note by ghost (reply)

在我的视觉里，楼主要分享的信息，类似于一堆中文用户的： 昵称 + npub

你视角度里是什么就不知道了。

#吐槽

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

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr (reply):

Chromium 中的开发者工具只展示应用层的协议连接, 所以 HTTP/3 可以被看到连接, 但是 QUIC 连接就和 TCP/UDP 一样无法查看. 于是 YouTube 这种网页应用就会直接用 QUIC 加载资源, 截至目前, Chromium (v139) 只要检测到 [...]

#吐槽

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

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr:

现阶段对 QUIC 支持最激进的 Android 浏览器是.... 微信的内置浏览器 :bili_fantastic: 测试下来一众 Chromium 只要系统的 VPN 或者系统代理状态发生变化, 立马就会全部回退, 只有微信的这个内置浏览器不会考虑本机 [...]

#吐槽

In reply to nevent1q…wxjk
_________________________

? 那你知不道 Nostr 是一个基于 WebSocket 的协议? 你到底在说什么? 你要喜欢禁用 JavaScript, 那现阶段 90% 的在浏览器运行的 Nostr 客户端都无法使用, 你真的了解过这个协议吗?

via Nostr@cxplay

ghost (npub14v…uuuge)

ghost on Nostr (reply):

答：前端无法这样做，所以呢？ 你是想表达：楼主要分享的信息，需要 WebSocket 才能展示，而 WebSocket 又依赖于 javascript，所以关闭了 javascript 会导致无法展示信息？ 如果这是你要表达的。我只能说：这 [...]