哦，不要加 setgroups

@guanzhangzhang unshare --fork --pid --map-root-user --mount-proc --propagation slave --setgroups deny
里面直接 mount/chroot 都没问题

这有啥办法，这种麻烦用户的措施，不强推就根本没人用，用户被盗号还会被大众批判“这么大一个公司，连账号都保护不好”

@62742a40 不联网的也要备案，就算工具类应用，你也得强行弄个域名，然后假装成服务域名，才能上架到应用商店

你都 unshare 了，不如再 map-root-user 一下（也就是用 user namespace ）
不过你这个“小巧的 rootfs 内的 shell 交互”真的可以在非特权用户下跑吗？
你这个 rootfs 要可变的还是不可变的呢
不可变的话，我这有一个封装 rootfs 的小工具 https://github.com/codehz/EasyPak ，本来是用于快速封装一个二进制及其依赖到单文件
只是单纯 chroot 的话，unshare 的 map-root-user 应该就可以用了

我猜还是因为启用了 hardened 的配置文件，导致了用上了一些先前没用上的语言特性，然后这些特性需要 gcc 的运行时库

还是需要一个地方存 revocation list （）
相比于其他不透明 session 来说，revocation list 可以在后端用 bloom filter 做初筛（因为数量上 revoke 的肯定比较少，分发 bloom filter 的状态更便宜）

libgcc 是自动加上的，用到了相关语言特性（甚至不是函数）就会需要链接，问题只在于链接静态的还是动态的差异
不过我怀疑，-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 这个里面，可能指定了强制用动态的

@AoEiuV020JP 还记得之前那啥 XXX 大炮事件吗，在百度首页加了一个外链图片，每个访问百度的用户都会去尝试访问这个地址，然后。。。
@thinkershare 唯一的例外就是图片加载，特指 img 标签直接写的情况，虽然 js 拿不到图片数据，但是图片仍然会被加载并显示，而服务端还不一定能检测到这样的外链（可以设置 referrerpolicy="no-referrer"）

android appops 可以禁用音频独占的权限（ audio focus ）
iOS 那种打开 app 自动暂停，多半是软件故意的，以前可以用这个保持后台运行

web-component+shadow dom 是最好的选择，里面可以确保你的 css 不和用户自己的 css 冲突
设置内部的 html 可以直接在 shadow-dom 里设置 innerHTML
（除了直接插入<style>到 shadow-dom 以外，也可以用 adoptedStyleSheets 的 api 去设置 shadow dom 内的样式）

libgcc_s 是 gcc 自己生成的依赖，没有的话，大概率只是静态链接上了，比如-static-libgcc 一类的选项，或者手动指定 spec --with-specs=%{!shared-libgcc:-static-libgcc}来避免链接到动态版本的

谷歌日常 a/b/c/d/e/f 测试（）
理论上可以在 chrome://flags 里看到选项，default 的话，大概就是随机

推荐用 UUIDv6 ，有序而且随机，128bit ，基本撞不到

@gps949 问题就是中间人攻击在 http 的场景下，不需要在客户端上搞事情啊，只要中途魔改你的代码即可，你没有任何办法验证，因为验证的代码也可以被改，不是说你实现有问题导致出事，而是就算实现完全没问题，假设一点协议上的漏洞都没有，它也不能提供任何可靠的安全保障
https 的一个性质就是双方有一个预先共享的信息（和代码），而这个信息和代码显然不能通过同一个不安全的信道传输
一个最简单的攻击方案，中间人直接在它设备上模拟浏览器，将渲染结果传递给受害者，然后把受害者的输入通过这个模拟浏览器传回服务器，而这个过程中，受害者除了真的去阅读每一行代码以外（实际上不可能），没有任何感知
https 的情况，你中间人要做这个，在没有服务器的证书的情况下，就没办法伪造你服务器的身份，因为验证代码和证书链都是已经预制在客户端上的，你不能在不接触客户端的前提下去修改验证代码或者注入证书，因而客户端总是会显示证书错误信息

@gps949 你不能安全实现，攻击者预计可以直接修改你的代码，剥离或者直接魔改加密代码，而且 TLS 的核心在于证书链，要有方法证明证书符合需求，因为你的代码和证书终究也还是通过 http 传输的
（当然你可以说你能给代码加 114514 层混淆，但这么比就没意思了）

确实有办法对一些录制屏幕的 api 排除一些窗口，但是那会直接变黑，因为 windows 决定被盖住的部分就不画了，根本就没有想过数据
或者采用单窗口的录制方式，那个可以录制被盖住的内容，但是显然不能完成全屏录制的需求

@ChatGPTPRO 你不会真按那个答案里的 html-to-canvas 去录制 canvas 了吧。。。这不是绕了一圈吗，肯定浪费了

@ChatGPTPRO 你可以从里面挖出原始 canvas 的啊，再不行直接 document.getElementsByTagName('canvas')