prominent disclosure and consent requirements 明确地提示用户并征得同意：
尽管获取了此权限，但并不读取 IMEI 码，因此也不会向任何服务器传输。
并同时写在 PP 里

@bewareofbears 改 PP
最后一段六行跟你说改 PP 就能过，你看不懂就没辙了

@tulongtou 查 celery error 111 都是 rabbitmq 的问答……

@alphatoad 那就是上面说的自写客户端。
但其实你并不能保证这个客户端没有被篡改
最终走线下，其实就是 PGP TrustNet 了
第二个问题是设问句，设问句一般也不需要回答。

`SELECT 金额,日期时间 FROM 用户表 WHERE 用户名 = 'a'` 取出来有多少个？

@no1xsyzy 手滑，防旁听不防中间人
要真有可能，说说为什么 HOSTS 方法越壁必须 HTTPS ？
Google 没这实力，你有？

@alphatoad 问题在于 HTTPS 没有其他渠道分发证书的话也是不可靠的，何况你网页本身就是不安全的
先把 #113 的给过了再说，装个 mitmproxy
mitmdump -s mitm_keyboard_recorder.py 然后把浏览器代理设置过去
或者 mitmdump -ns mitm_keyboard_recorder.py 来 iptable 抓所有流量
不用 https 的话你写什么有用？

你其实就是实现了一个机会加密，然而机会加密防旁听不防

@type 你是说不管用户如何解密先加个密？
那和 cat /dev/urandom 有什么区别吗？（笑哭

延伸说下去，其实如果真有中间人要从开头开始搞你，也不是问题，连你的浏览器可能都是被中间人替换的
你说浏览器安装程序被系统签名确认了？被包管理器公钥验证了？你的系统也可能被中间人替换了
如果说真深究下去，你连 CPU、内存、主板、甚至你的示波器是否有后门都不知道。
说不定你自己焊电路接 LED 来看都可能不能保证发现问题：你怎么知道这个电烙铁没有后门在特定的时机虚焊导致你的检测电路失效？你怎么知道这个 LED 没有后门可以被远程控制亮灭？
你怎么知道你的弱电知识没被中间人替换？
或者哪天物理定律失效？
听起来有点杞人忧天，但确实如此不是？

现实没有 “保证”，只有 “风险控制”。

花了一个小时，搜索中间人方案、下载（包括 pip 安装失败 —— brotli 当场编译需要 VS，那为什么打包 whl ？）、安装、看样例改代码，随手写了个中间人键盘记录器
https://gist.github.com/no1xsyzy/1b342ed48b09bb2c22d368b161cb351d
结合前端录屏审计工具就无敌了
其实这个想法早前就有人实现过了，有人发现自己的网站用某些网访问的时候，登录会同时以明文 query 带账号密码请求一张图片，但远端没有收到这个请求 —— 很显然是 ISP 方面干的。
如果只是靠加密一层防监听数据，防的叫旁听人攻击，而不是中间人攻击。

@VensonEEE 直接插 js 录键鼠屏
都直接知道你密码了还有什么不知道的？

@lucifer9 但到现在大众判断的 “第一之前” 还是 第负一
就是第一楼和负一楼间有其他楼层的，也叫做“底楼” ground floor 而不是 零楼
好像理解 base 0 算是入门编程的一个槛

@lucifer9 公元零年在什么时候？

中间人面前都是徒劳
对付所有办法，直接插个前端录屏的审计工具（这个我记得有人发过分享创造）
有中间人，只要你访问一个没 HTTPS 的网页并且点击页面内任何位置，连剪贴板都给你挖出来
（所以其实我第一次知道剪贴板竟然是应用程序自己任意决定何时读取何时写入的时候是震惊的）

@xuanbg 无非是重放攻击？
那为什么还要中间人？旁听人不就行了？

提升效率就能不加班 ✘
提升效率只能不加班 ✔

先食雕三月啦（

@amiwrong123 文件结构都变了就不要指望 make 解决了吧……
而且你大概是 rm -rf out ？本来这就是偷懒用法，正经办法是
rm out/A
rm out/B
rm out/C
rm -f out
因为你不知道除了 ABC 以外是否有一些用户文件在里面

不怕熊孩子炸服可以选择发 mcbbs ……