没看懂你要干什么，是要通过反代对外发布家宽里的服务器内容吗？如果是这个需求而且全在墙内的用 vpn 就行，家宽对外连接不用怎么担心封杀问题。

现阶段 win11 还是预览版比较香。

我来说一些非合规方面的理由吧。
如果这套 E2E 系统的云端用户数据在失去访问权后是可以找回的，那它最低限度需要一个 PIN 。如果有任何一种找回途径低于此要求，那说明服务商有能力绕过用户解密数据。
即使是现有在国外可用的公开 E2E 系统，服务商理论上可能通过破坏握手和认证流程窃取密钥或进行 MITM 攻击，特别是客户端实现不完全透明的情况。
也就是说，想实现完备保密，用户不可避免地要自己完成认证和加解密。如果用户能做到这点，那他其实也不需要服务商提供 E2E 能力，例如传输 PGP 加密过的信息。

看链接的内容没看出直接关联。

我想到的方案是利用 URL 的最后一段，用特殊方法编码跟踪 ID ，客户端通过剪贴板得到 URL 后尝试解码出跟踪 ID 。这样即使整个 URL 是无效的也不影响分享，如果无法控制白名单地址显示的内容就最好是构造成非法地址避免意外跳转。
不过感觉这个方案似乎没有比淘口令那种好多少。

如果你想靠这个拿一大笔设计费可以很复杂，参考百事可乐和小米的新 logo 的设计稿。
至少在国内，用艺术字的确效果很好。

但是哔哩哔哩也不是人名啊，只是个外号而已。
就算是人名，那也是姓名权，虚构人物没有姓名权。
如果有注册成商标，那可以走商标权，但那个有领域限制。

检测是要同时关心灵敏度和特异度的，我怎么感觉这个方法是完全没管特异度的。

我知道特异度在这事上相对没那么重要，但如果特异度不行，那它在成本上并没有比白名单更好。

还有检测 TLS ApplicationData 首包大小的，跑在 TLS 上面的应用协议那么多，只要长得不像 HTTPS 的都一刀切？

上两个月测试过裸 ss2022 ，火速阻断，不知道是哪的问题，感觉一般还是套 TLS/QUIC 皮比较稳妥。

不是手残的我建议直接用原始的命令行项目，有丰富的画质选择策略和输出选项可以用。
例如我用这个设置下最高质量 vp9+opus+mp4 的组合，并写入元数据和封面图。因为绝大多数视频都有 vp9 版本，av1 在老视频上没有，容器选 mp4 是因为 vp9 默认用的 webm 容器不支持插入封面，mp4 串流支持比较广泛，不在意的话 mkv 也行。

```
yt-dlp --embed-thumbnail --embed-chapters --add-metadata
--merge-output-format mp4
-f bv[vcodec^=vp9]+ba[acodec=opus]
-o youtube_%(title)s_%(channel)s(%(channel_id)s)_%(id)s.%(ext)s
--proxy <Proxy URL> <VideoURL>
```
查下载的媒体信息推荐 mediainfo 。
ref: https://github.com/yt-dlp/yt-dlp#format-selection-examples

就算有 ROCm ，我也不建议你去吃螃蟹，AMD 并不打算在这个领域跟 NV 正面刚，换句话说没有未来可期。

虚拟硬件的链路速度是驱动自己报告的，实际表现要看跑分，多数软件也不看这个。
例如 qemu 的虚拟网卡可以虚拟 e1000 和 e1000e 等型号，分别对应 intel 的某款 pci/pcie 千兆网卡，实际跑起来超千兆不成问题，落后的 e1000 通常还高分一点。
真正影响的是前后端驱动实现，例如减少内存复制、绑核处理收发队列，卸载部分网络栈任务到宿主驱动或者硬件网卡等，VirtIO 准虚拟化驱动就是做这类事的。

感觉其中一个原因是油管上线 HEVC HDR 直播了，最近发布得 OBS 28.0 也增加了相关支持。
不过 chrome 实现策略跟 edge 一样要求走 Media Foundation 用系统解码器，不能用 DirectShow ，似乎只有这个途径有硬件级媒体 DRM 支持。

@Osk @jaleo
目前 Win10+上面的 HEVC 视频拓展（免费版&收费版）好像除了用户自己找安装包装或者花钱买之外不太可能被捆绑装上，所以用 UA 判断支不支持是完全不准确的。
另外 Edge+旧版拓展(我查到是 1.0.50361.0 以下)的 B 帧支持有严重问题，HDR 映射也有问题，所以使用前最好更新下。

结合这两点，B 站搞不好就继续一刀切不用 HEVC 或者统统 wasm 软解了，浏览器没 api 查解码器版本和硬解支持状况的。

阻生牙埋伏牙肯定便宜不了。
我这边诊所拔埋伏牙（完全没露出来）就要 2000 以上的，无菌手术+微创搞了大半个小时，一周拆线，麻醉到位全程无痛（遇上术后并发症除外）。比这便宜的可能创伤更大更痛？
最麻烦的那种藏得很深的拔牙要住院全麻手术的，诊所都做不了，价格可能要上万了。
右边那只别觉得不疼就不用处理了，会把旁边的恒牙顶坏的，尽早拔。

@arch9999
关于强制 MS 登录，有一个很充分的理由是配合设备加密。设备加密全新安装支持现代待机的机器上是自动启用的，不弄个账号上传恢复密钥就有丢失风险。当然你也可以认为这不是主因，只是为了卖广告。

企业域控的一般也不会那么快升，都能修。

人脸解锁我印象里是只用红外相机的，我的小新遮住大镜头都能过认证，也不清楚增强验证是怎么定义的，搞不好还跟相机驱动有关系。

我从来没觉得静态人脸安全了，就是图方便。增强防欺诈默认关闭估计是质量参差不齐的 ir 相机会导致认证通过不了所以设计成 opt-in 了，毕竟不像 faceid 可以深度定制方案，surface 其实也没亲爹待遇。

想主动升的建议自己下 iso
WSUS 执行大型更新有很多缺陷的，网络不能中断（不然就一直卡网络），第一阶段结束前不能关机否则得重下。如果你用的是低端 ssd 可能会比较煎熬。

找个不支持 pd 只支持 qc2.0 的快充，这样接 iphone 就是五福一安，保证不热。

没有带外管理手段想改 uefi bios 设置，我想到可以查 efivar 地址表，直接改 efivar 值。
不过我感觉这玩意的操作难度超出 OP 的理解范围了。

内网通信应该主要想使用 HTTP2 的 stream multiplex ，HTTP1.1 即使使用 keep-alive 也依然存在队头阻塞（ HOL Blocking ）的问题，头压缩什么的应该不是主要目的，跟 Web 应用需要每个请求都重复传一堆头字段不一样，gRPC 没这个问题。

另外 json 有一个缺陷是它是 schemaless+文本，除了编码要带上结构信息占据额外流量外还涉及大量字符串操作，会带来很大的 GC 压力。

另外 protobuf 还有些我道听途说的问题，protobuf 理论上编码很高效，但 protoc 生成的代码实际性能不见得高，经常搞出一堆编译警告； google monorepo 模式带来的副作用——跨版本兼容性不佳，你有信心保证一个大型项目（可能还有外部合作方）里所有组件都依赖相同版本的 protobuf 吗？