现在动画包括一部分厕纸改编在内，有些也会精心塑造反面形象，比如《憧憬成为魔法少女》（划掉，虽然其实传统意义上的魔法少女动画，也通常不会完全正义邪恶一边倒，除了完全面向低龄儿童的类型）
还有近年比较热门的转生恶役（如《转生成为了只有乙女游戏破灭 Flag 的邪恶大小姐》）系列，虽然某种意义上是让原始设定里的邪恶方变成正义方的反转设定，但另一个角度其中也描写了邪恶大小姐之所以成为邪恶大小姐的原因，放到“原始设定”里也会觉得合理的那种，从原本的“恶人本恶”变成了制度和历史经历共同塑造的反面行为

最近我发现把 bot 丢 cloudflare worker 上跑是一个好主意😜（前提是你会写 js/ts ）
尤其是考虑到免费+免维护这一点（不过我自己是用了 worker paid 套餐了）
不过架构方面和单体程序有点差异，单纯作为一个建议吧
日程提醒可以用 scheduled 来做，每分钟检查一次即可
tg 请求响应的话用 grammy 的 webhook
数据库，用 D1
另外一个思路:TG 目前开放了小程序的接口（实际就单纯网页套壳，但提供了无缝用户认证的能力），可以用 cloudflare page 搭建一个网页管理界面，后端对接到 worker 上（推荐用内置的 worker ），这样在 tg 对话式 ui 不够好用的时候可以用 web 来补充

都有 ptrace 特权了你还想怎么保护啊。。。你设置的所有限制都还是可以被绕过的呀，攻击者总是可以通过修改内核的方式来破坏你的保护
真的要做的话应该走可信计算的思路做

所以为啥要手动关闭，这玩意不是这么用的吧

android 现在要做的话，只有输入法可以后台读取剪切板了

这不都是你自己管理的东西吗，csp 防止的是未授权的修改，不是防止你在你自己域名上的授权修改

@Autonomous 替换了也没法解密用系统加密 api 加密的那部分，比如浏览器的 cookie ，保存的密码这些（）这些只有用户正常登录了才可以被解密

@iOCZS 你这个理解上有一些问题，首先不管 class 组件还是 function 组件，都需要重复执行 render ，react 的核心算法就是根据生成的 vdom 去 diff ，这个是无法避免的。
只不过，传统 class 组件有提供简便的（但实际上很容易误用的）方法去直接跳过更新，这个能力在函数组件里是否存在呢，也是有的，就是那个 memo 函数，当然由于 hook 的存在，不能像函数组件那样屏蔽来自 hook 的更新，但这也导致写出有问题的代码更为困难了

确实是不再推荐了，因为和并行渲染这些新的机制有冲突

@StruggleYang 经过测试，14.4.1 已经修复了这个错误，不是给 java 开后门，整个错误都修了

实践中，编译器会给你生成一个 double checking lock

啥，4k 你用 100%来看，和 1080p 用 100%不是一样的效果的吗。。。

nomodule 的兼容性是指：支持 nomodule 的浏览器就不去加载这个 script
不支持 nomodule 的就会自动加载（因为不认识的 attribute 被忽略）

要讨论这个问题，得先设定一个威胁模型吧，不如就来一个直接拉满的模型：
攻击者方面
1. 攻击者完全了解该协议。
2. 攻击者可以访问大量常用密码字典（并且有足够多的时间离线破解）。
3. 攻击者可以窃听客户端和服务器之间的所有通信。
4. 攻击者可以拦截、修改和伪造客户端和服务器之间的任意消息。
5. 没有相互信任的第三方。
最后攻击者的目标是冒充客户认证，这里不考虑“在线”暴力破解的情况，也不考虑注册过程中客户被冒充的情形。

这个模型下，所有基于固定密码的 web 认证方案都是无效的，因为攻击者只需要伪造登录页面就可以直接偷到正确密码。（ WebAuthn 是终极解决方案）
那我们可以弱化其中一个攻击条件，假设 webapp 已经事先作为 pwa 部署到用户设备上了，因此攻击者无法篡改登录页面（*），这种情况下，可以继续讨论前端加密的意义。

1. 首先排除单纯的摘要算法，因为只要把摘要本身认定为登录密码即可冒充用户
2. 我们可以考虑单纯的预先共享密钥的方案，也就是对称加密，这条基本上也可以 pass ，因为攻击者也能拿到预共享密钥（什么，你说一次一密？那攻击者伪造一个假的给客户端不就可以了）
3. 至于非对称加密的方案，尽管这次攻击者拿不到服务端私钥，没办法直接偷到密码，但是由于第二条，攻击者可以离线破解密码
。。。剩下的方案，基本也就是排列组合，在上面那个威胁模型下能起到的作用顶多是减缓攻击者的破解速度

那有没有完美的算法解决这个问题呢？答案是有的，只要从一开始，就不发送任何关于密码的信息给服务器即可
通过零知识证明，客户端和服务端分别向对方证明自己拥有密码，但服务端却无需得到密码的原文（或者任何衍生信息）
将零知识证明用到认证领域的协议就是（非对称的） PAKE ，一个常见的具体协议是 OPAQUE 协议。协议内容在这里不细说，可以在 https://blog.cloudflare.com/opaque-oblivious-passwords 里看到细节，但在理论上它是能抵御前面所提到的所有威胁的。

不是完美平替，企业的例子我不知道，mc 模组里，fabric 的模组，无法在 mixin 中使用 kotlin （原因是 kotlin 的标准库会有冲突）

@houshuu 但其实没什么用，这次的问题是随机概率触发的，上面有人就没触发过。。。
合理的方案是在不破坏互操作性的前提下(例如不能出现旧版本无法打开项目的情况)，进行灰度升级

全屏实现其实挺复杂的（因为跳过了窗口混合的过程），对老游戏可能可以 dxhook 一下，但虚拟机的估计没那么好做。。
除非 vmware 用的是无缝窗口模式，那种也许可以骗过去。。。

@daveh
这个修改也只是另一个性能优化 https://bugs.openjdk.org/browse/JDK-8283326

SafeFetch is important - mostly when writing hs-err reports, but it is also used in low level utility functions like `os::print_hex_dump()` and `os::is_readable_pointer()`. It is also used (JDK-8282306) as part of call stack printing. At the moment it is implemented via dynamically generated stub routines

@daveh 没错是改成 static 了，但还是用信号的啊 https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/safefetch_static_posix.cpp
只不过把 safefetch 本身的代码用汇编写成直接一个 mov 或者 ldr
https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_aarch64/safefetch_bsd_aarch64.S
不是很懂为啥要杠这一点