fydpfg

TLDR：压缩文件的规范应该写明密码的编码方式，不然确实可能会有问题。

@mcfog 题主的提问其实完全没有任何问题，题主是在问非 ASCII 的密码本身的编码方式会不会影响解压缩，而不是被压缩的文件的编码方式会不会影响解压缩。

我刚刚用 7-zip 试了一下，7z 格式使用中文密码，在中文 Windows 上压缩，可以正常在 Linux 上解压缩。而 zip 格式不允许非 ASCII 字符作为密码。

题主这个问题的答案其实很简单，压缩文件的格式规范里面规定密码的编码方式就行了，比如规定非 ASCII 密码按 UTF-8 来处理就行。我猜测 7z 格式应该就是规定了一种密码的编码方式（简单搜索了一下没搜到，没去读代码验证）。

除了密码，其实文件名也有这个问题，我之前研究过。对于 7z 压缩包，压缩和解压缩的时候按照标准会统一按 UTF-16-LE 来处理（参见 https://py7zr.readthedocs.io/en/latest/archive_format.html#filename ），所以不会有问题。而 zip 格式根本没规定编码，这样不同默认编码的环境创建出来的压缩包就会不兼容，所以 zip 格式经常有文件名乱码问题。对于 rar 格式，文件名是 UTF-8 编码（参见 https://www.rarlab.com/technote.htm ）。

而对于被压缩的文件，文件本身就是一串字节，压缩的过程跟编码方式无关，所以不会有任何问题。

如果压缩文件的规范里面没有写明密码的编码方式，并且压缩软件的实际实现也忽略了这一点，使用系统的默认编码来把密码文本框里的字符串编码为字节串然后再进行哈希，那确实会导致相同的密码在不同环境下无法正确解压的问题。

还有灯一定要搞成遥控的，屋顶的灯不方便换成智能灯泡的话可以单独搞个台灯

大尺寸的垃圾袋和垃圾桶（物业垃圾袋）
吸尘器
微波炉
100% 全遮光窗帘

@szzys @Zy143L @Senorsen @AkaHanshan @ShikiSuen @tinytian @liveoppo @bksv @morax0xyc 我仔细调研和思考了一下 WebView 通过 SSO 登录这个安全模型，并且跟几个搞安全的朋友讨论了一下。我觉得这种钓鱼方式确实很有迷惑性，但本质上这里苹果的实现是没有安全漏洞的。

具体可以分成两部分讨论，一部分是 WebView 可以通过 SSO 登录是否有问题，第二部分是 SSO 登录是否应该允许绕过 2FA 。

关于第一部分，任意的 app 使用 WebView 加载网页，当网页需要跳转到第三方应用进行登录的时候，进行登录这个行为本身是很正常并且常见的。比方说，你在手机上 [Chrome 浏览器] 应用里面打开 [QQ 空间] 网页的时候，可以点击「通过 QQ 登录」按钮，这时 [QQ] 应用会被唤起，问你「是否使用当前账号来登录 [QQ 空间] 」。这是一个非常标准的 SSO 逻辑。

然后我换成另一个例子，你在手机上下载了一个 [超级单车] app ，然后它的首屏有「通过 QQ 登录」按钮，点击之后 [QQ] 应用被唤起，问你「是否使用当前账号来登录 [腾讯云] 」，你点了确认登录，然后你的腾讯云服务器被盗了。这个例子中问题在哪？在于用户没有意识到正在登录的是腾讯云就进行了授权。这里的 SSO 模型是没有安全漏洞的，唤起 QQ 应用来请求登录腾讯云这件事本来就是每个 app 都能做到的，不应该禁止也没有方便的方案可以禁止。

在本帖的案例中， [菜谱] 应用就是上面例子中的 [超级单车] ， [Apple ID] 就对应 [QQ] ， [appleid.apple.com] 就对应 [腾讯云] 。注意看楼主发的第一张图，写的清清楚楚是「你要通过 Apple ID 登录 appleid.apple.com 吗？」，就跟上面说的「你要使用 QQ 号登录腾讯云吗？」是完全一样的道理。用户没有认真看好登录的目标，就点了确认，这就是 user error ，而并非是苹果 SSO 的安全漏洞。当然，我承认这里对普通用户确实有很高的迷惑性。这里「通过 Apple ID 登录 appleid.apple.com 」其实更像「使用 QQ 号登录网页版 QQ 」，但其内在逻辑跟上面超级单车的例子是一样的。

这里我想强调一点，就是苹果账号在我的讨论中并没有什么特殊之处。就算你禁止了 WebView 来使用 Apple 的 SSO ，接下来就会有恶意 app 内嵌一个淘宝网页，唤起你的支付宝来登录淘宝，甚至唤起你的支付宝来登录支付宝网页版（我不知道实际上有没有这个登录渠道，但这里只是举例子来说明问题，有大量的 app 都有类似逻辑）。对于这种 Apple ID 之外的场景，其实 WebView 也并非必须的组件，恶意应用完全可以在 app 里面模拟登录的过程，甚至在服务器上跑个 headless 浏览器来转发请求都是可以的。

除了 SSO 这种授权登录钓鱼，还有很多类似的钓鱼方法也看起来像是安全漏洞其实不是。例如你下载了一个 [超超级单车] app ，然后 app 要求手机号登录，输入手机号之后，手机收到验证码：「 [腾讯云] 你的登录验证码是 123456 」。如果你输入了验证码，这个 app 理所当然就可以登录你的腾讯云后台，而且这种情形从腾讯云和手机运营商的角度都是无法彻底防止的。如果把 [腾讯云] 换成你不熟悉的 [XX 科技] ，其实还真就不好辨别，说不定这个 app 后台就是在用你的手机号登录某个网贷平台呢。

（题外话：我觉得国内运营商强制平台短信必须有方括号前缀，并且不能伪造前缀，从安全模型角度这是非常好的实践。我之前用 +1 手机号注册一些小众平台的时候，就遇到过没有任何前缀的验证码短信，这种验证码我根本不敢输入，因为理论上它完全有可能把验证码请求 proxy 到了另一个平台的验证码接口，偷偷在用我手机号登录其他平台。另外，我认为所有的人脸验证都应该要求用户读出平台的名字，不然一个恶意应用就可以直接靠 proxy 这种方式在后台偷偷进行另一个平台的人脸验证。感觉绝大部分用了人脸验证的 app 开发者都没有意识到这里的鉴权安全模型问题，可能需要做安全的人来多多宣传一下。）

回到第二个问题，SSO 登录是否应该允许绕过 2FA ？这个问题我看了一下我常用的国内外账号，其实很多账号进行授权登录/扫码登录另一台设备的时候都是不要求输入 2FA 验证码或者（对于国内平台）短信验证码的。我觉得这里确实可以加强一下安全性，但是苹果现在的逻辑显然算不上是安全漏洞或者缺陷。

综上，我个人觉得本帖的问题虽然迷惑性确实很强，但还是应该算 user error ，并非安全漏洞。如果加缓解措施的话，只是缓解了一个特定的钓鱼方式而已，如果用户一直不理解 SSO 授权时应该检查的东西，那么还是不能彻底防止类似问题在其他平台或者其他场景下再次发生。

@abelyao @killva4624 @8355 @paradoxs 稍微了解一些 web 安全的人都知道，在现代浏览器的安全模型下，用户就是可以随便打开不信任的链接的，这并不是用户的问题。如果打开不信任的链接就可以对其他网站产生不好的副作用，那么要么是浏览器的 0day ，要么是其他网站的 0day 。

「不要点击陌生链接、不要打开陌生短信 /邮件」是一种一刀切的说法，基于的假设是很多用户完全没有鉴别 URL 中域名的能力，或者这些用户会被钓鱼从而自己主动输入其他网站的密码 /密钥、直接运行下载的可执行文件等等。

对于了解一些计算机安全知识的人来说，点开不信任的链接 /扫描不信任的二维码本身并不是一件应该批评的事情。

即使二维码指向的域名是可信的，打开之后也完全可能直接自动跳转到不可信的域名。web 的安全性从设计上就不是由用户自己确保别打开不信任的网站来保证的。

另外，各种安全措施如加密、签名校验也不是越多就越好、越少就越不安全。这完全取决于应用的安全模型，有经验的开发者会正确使用密码学来保证协议的安全性。

GV 不行，我是拿 talkatone 生成的虚拟号过的，只要邮箱就能免费用（很久之前是这样，不知道现在还能不能行）。另外也可以试试在 https://eylink.cn/ 这里买？

有办法让本帖标题和标签里的“Chorme”改成“Chrome”吗？

我想把“Chorme”改为“Chrome”，不知道有没有办法实现我这个要求？

感觉用“Chorme”代替“Chrome”不严谨（主要是看着难受）。。

我刚才进行了一系列对比实验，结论是，应用权限的“自启动”只要打开就会正常收到 FCM 推送。如果“自启动”关闭，只有应用在运行的时候才能收到 FCM 推送。
能否收到推送跟“省电策略”和最近任务视图是否“加锁”完全无关，即使“完全禁止后台运行”，也可以正常收到推送。

MIUI 版本：国内最新版本的开发版公测（ MIUI 12 20.8.13 ）
Google 框架是系统内置的，即安装国外 app 时会提示需要启用 Google 框架然后点“确定”，不是自己通过安装器安装的。Google 框架相关的 app 授予了所有权限，包括自启动、不限制后台，除此之外没有进行任何其他设置。

@cdafsd 微信的话在手机上点「电脑微信已登录」那个横幅，里面可以关掉手机静音，这样电脑和手机就都能收到消息