支持一波！

这些都可以问。但安全是要在满足需求的前提下匹配成本的，脱离条件谈安全没有意义。

这个软件特别好用，当时拿它打游戏挺爽的。

目前再用 cryptomator 体验只能说还行吧，但这差不多也是这类工具的巅峰了。好处是：

1 、开源而且被审计过。
2 、所有平台包括手机端都有，ios 甚至还适配了 Files 。
3 、这款工具很多年了基本上可靠，webdav 虽然性能差但很少出问题，fuse 性能好毛病多，特别是现在 macos 装 fuse 很麻烦，当然了这不是 cryptomator 的问题。

还有 https://mountainduck.io/ 这款一体化集成 cryptomator 的多网盘同步客户端，如果同步可靠的话将是绝杀，可惜我自己用下来同步大量文件的时候容易出问题。。。

此外还有 E2EE 的网盘，体验最好的是 Tresorit ，价钱也是最贵的。mega.nz 的问题是虽然开源但没见人审计过，不过功能上据说还可以，我没认真用过。sync.com 早期很简陋性能也差，拿来工作是不行的。

至于开源的支持 E2EE 的像是 nextcloud 或者 seafile ，加密功能设计的都很简陋基本图一乐，而且自己部署这种东西风险跟收益完全不成比例。

QQ 在我手机上每次切过去必卡，五成概率卡崩溃，QQ 和微信属实一对卧龙凤雏。

@mlboy 本质上是一样的

@DOLLOR 然后未成年只能节假日 18-20 点用一个小时？好耶 (doge

这样做的话，真正的密钥实际上就是原密钥拆分的方法以及镶嵌的位置。我们可以把原密钥拆分的位置按顺序记录为一个 N 位数组，镶嵌的位置按顺序记录为另一个 N 位数组，这样就完全确定了一个 2N 位的新密钥。

所以实际上这是一个固定密钥的加密，考虑到被加密文件的大小，以及密钥长度，新密钥的熵可能很有限（一些组合数的求和），所以不如直接：

openssl enc -aes-256-gcm -k fixedpassword

搜索关键字里 -AKXXXX 不行么

导入过多的自定义短语会导致卡顿。我曾经妄想通过这种方法增大词库，结果这玩意效率极低。

主要风险还是被 D 吧，53 端口就算云服务器也没几个开放的。另外很多人用的话得注意性能，这玩意不是设计给那么多人用的。自己用的话可以考虑 DOH ，前面套一个反代，然后采取 https://xxx.xxx/<random-generated-uuid> 地址格式进行验证，即可无碍使用。

以防万一，最好能在 docker 里运行。

@skfu 1P 官网被脱裤，暴力破解还需要 secret key ，这也是 secret key 的主要作用。本地备份与他们官网服务器存档还是不一样的，具体可以看他们的安全白皮书。

另外，实际加密的密钥也应该不会直接使用主密码（或主密码+secret key ），而是密钥导出算法给出的。除非预先知道一些主密码的信息（社工），否则暴力破解也没那么容易。

@ZE3kr 这也是我知道的 1P 数据库最完整的备份方法，不过 1P8 应该不能这样干了。

1. 当以级数形式表示时，此无穷级数表达的是极限的结果而非过程。
2. 实数本身由实数公理给出。实数的十进制表示可以看作是符号 '[0-9]','.','-' 生成的自由群到实数的映射。0.999...=1 说明这个映射不是单值的。其实任何进制表示都有这个现象。
3. 有人提到超实数。非标准分析我不熟，但即便在非标准分析框架下，也应该不会影响此断言的正确性。非标准分析把标准公理系统嵌入（一阶）到一个更大的系统中。虽然新系统确实有更多的对象，但“嵌入”即要求原有的断言到新系统上仍然正确 (concurrent relation).

买个 yubikey，slot 2 设置成静态密码。每次插入 USB 长按即可，slot 1 还能继续用于 2FA 。

首先我也同意，在这俩的选择上，SoC 不是首要因素。

但比较 SoC 的话，A15 和 M1 的 CPU 部分同频 IPC 基本一致，但 M1 频率更高而且大核数量也多，性能肯定是更好的，当然了 4+4 比较 2+4 肯定更费电。GPU 部分 A15 的 GPU 架构可能是新的，但架不住 M1 GPU 规模更大。视频编解码器支持两者基本一致（ M1 似乎不支持 VP8 编码？）至于神经网络，ISP 之类的就不清楚了......

总之，除去功耗 M1 基本上完胜。但两个平板的定位不同，还是应该多考虑其他因素。

@Gehrman 可以看我最近的回复，找到有人测数据了。这种事情就是很无奈，只要法律不要求，厂家就不会说。

Ok, 接上楼。找到有人测了：

Mod% in iPhone 13 Pro is (almost always) 16, sometimes it’s 30, but not 100.

From IEEE 1789 (for frequencies between 90 Hz and 1250 Hz):

Mod% < 0.08x(flicker frequency) for Low-Risk Level
and
Mod% < 0.0333x(flicker frequency) for NOEL (no observable effect level)

For 480 Hz we have:
Mod% should be < 38.4 for low-risk and
Mod% should be < 15.984 for NOEL
.

Ref:
https://forums.macrumors.com/threads/iphone-13-pro-screen-pwm-flicker-at-all-brightness.2312862/post-30352367
https://youtu.be/lCh62q4qdPI
http://www.bio-licht.org/02_resources/info_ieee_2015_standards-1789.pdf

. 按此数据，对照 IEEE 推荐标准，13 的眼睛健康风险和 12 应是和相当，且都在 Low Risk 范围内。

@Gehrman 目前没有看到有人测 iphone 13 的波动深度和频闪指数，但有看到 iphone 12 和 11 的频闪指数：

Brightness level - pulsation coefficient (may be better translation from Russian is flicker index)

Iphone 12 Pro
1. 100 % - 6.8 %
2. 75 % - 7.7 %
3. 50 % - 8.6 %
4. 25 % - 10.0 %
5. 0 % - 8.3 %

Iphone 12
1. 100 % - 6.8 %
2. 75 % - 7.7 %
3. 50 % - 8.9 %
4. 25 % - 9.5 %
5. 0 % - 8.3 %

For comparison:

11 Pro Max
1. 100 % - 6.8 %
2. 75 % - 7.8 %
3. 50 % - 8.3 %
4. 25 % - 80.2 %
5. 0 % - 71.1 %

8 Plus
1. 100 % - 0.7 %
2. 75 % - 0.7 %
3. 50 % - 0.8 %
4. 25 % - 0.8 %
5. 0 % - 0.9 %

,Ref: https://forums.macrumors.com/threads/eye-strain-while-using-iphone-x.2085427/page-125.

我个人的看法是，假设频闪确实对视力有影响，那么频率、频闪百分比以及频闪指数应该都是重要因素。