mschultz

系统自带的那个 /usr/bin/java 并不是真正的 JDK, 它只是一个 wrapper 或者说 proxy 或者说 picker ，指向 /Library/Java/JavaVirtualMachines 中（默认为空）某个 JDK 的 java executable.

Stack Exchange: https://apple.stackexchange.com/questions/269588/how-does-usr-bin-java-work-on-mac

@dudewei #26 我没有说这些用户个人资料不重要，我是说如果这些基本信息 E2EE 了，就无法正常进行业务了。

所以要靠内审机制或者内部制度设计。不过即然靠内部制度设计，总可能会有不守规矩的（即使概率较低）。

@stamhe #23 账户资料这个见仁见智吧。我个人觉得对 Apple 或者任何服务商（不限于互联网）来说，这些 Metadata 账户元数据都是它们提供服务的依据，是不会 E2EE 的。（这里的 E2E 的两个 End 都是指用户的设备，也就是说，如果 真正实现 E2EE ，那么厂商根本就无法解密这些资料，也就无法为你提供服务）

就像银行知道你的手机号、身份证号；淘宝也知道你的手机号、收件人地址等。

这些账户资料是你为了获取相应服务而提供的，和「你存储在网盘中的文件 / Key 」性质还不太一样。

即然不 E2EE ，那么就难以从技术上 100% 杜绝内部员工查看这些资料，也就不能 100% 杜绝「员工因为私人恩怨开盒用户」的事情发生。只能靠内审机制尽可能避免吧。

@stamhe 😂怎么说呢，你的担忧是有道理的：因为 Apple 的系统是闭源的，公众没办法证实它是否遵守宣传和承诺，完整实现了敏感数据的端到端加密（你说的 Apple 作为开发商中间人劫持之类，就属于 Apple 它虚假宣传、事实上没有实现真正的 E2EE ）。

由这种担忧，其实可以推广到：不要相信任何闭源的云服务商所宣称的加密机制。因为你没法证实它真的实现了。

====

但是，话说回来，大家在网上的讨论都是基于一些（可能不那么严谨的）假设，否则容易陷入绝对怀疑主义然后怀疑一切、觉得一切都可能是不真实的或者有漏洞，然后讨论终止。

在这个帖子里很多人的 <心理假设> 就是，Apple 自己宣称的对敏感数据的 E2EE 是真的实现了。在这个假设下（再强调一遍，这是假设，当然不强迫每个人接受）再看你在 #2 的发言，直接就把「工程师都能看看你的私钥」当一个确定性结论，这确实就有点儿没道理了😂

#8 给出的链接也意义不明，只说了苹果的员工可以看到用户的邮箱、地址、电话等资料，但这些账户资料 Apple 本来就没说端到端加密。但是 Passkey / Keychain 的存储 <宣称> 是 E2EE 的。你给的那个链接里完全没提到这些 <宣称> E2EE 的资料存在泄露情况。
所以很多人选择相信 Apple/Google <宣称> 的 E2EE ，我觉得也完全可以理解啊。

对续航这一点，我的方案是，减少使用手机的时间🐶

平时工作用电脑；通勤、吃饭等时候以发呆/看风景/闭目养神等代替刷手机。更多地观察大自然和身边的人和事。
工作通讯方面也极少使用微信等 App ，主要在电脑端用邮件（这一点每个人可能工作处境不同）。

手机主要是作为一个生活辅助（通话、支付、点餐等）的工具，不很必要就不拿出来刷。这个用法，甚至 iPhone SE 的电量都能坚持一天。虽然知道大屏新品会更爽，但是仔细想想如果习惯了轻度使用手机，升级的欲望并不太高。（电子产品阳痿了）

只有长途出行或去不熟悉的地方时才带充电宝以防万一。因为频率不高，所以可以接受。

登录信息一般是存储在 macOS Keychain 里的吧（我没就 QQ Music 这一具体应用进行验证，但的确有不少软件是这么做的）

@aero99 #14
@greatHair #15

Changes to this payment information will apply to your Apple account and will affect your Apple Online Store purchases.

香港（英文） Apple Store 登录后，编辑 Payment 页面原话是这样。我也不知道怎么解读，贴在这里先🤔️

@jlak #6 你的服务器上跑什么服务？如果是一般的网站（ HTTP/HTTPS ），那么用 Cloudflare ZeroTrust 的 Tunnel （就是 4 楼梯道的 tunnel ），要点如下：

0. 假设你服务器上的一个 Web 程序，比方说 Nginx ，监听服务器的 127.0.0.1:80 端口

1. 在 Cloudflare Zero Trust 的面板 - Access - Tunnels 中设置 Tunnel ，跟着向导和文档来，它会让你在服务器上安装一个 cloudflared 程序（ connector ），一般是用 systemd 管理的。安装并认证好了之后，相当于你服务器上就有一个长期运行的 Cloudflare connector 一直主动保持与 Cloudflare 的通信（由于是这个通信是主动出站，不需要你服务器防火墙开放任何入站规则）。

2. 然后，回到 Cloudflare 网页版的 Tunnel 设置页面，设置「 Public Hostname 」，基本上就是设置一个域名到 IP:端口的映射，例如你设置 a.yourdomain.com -> 127.0.0.1:80

那么大致效果就是（下面的用词可能不专业，领会下精神😂）：

a. a.yourdomain.com 解析出来是 Cloudflare 的地址
b. 当有人访问 a.yourdomain.com 时，Cloudflare 发现这是一个 Tunnel 里面配置的 Hostname ，于是将请求导向对应的 connector 所在机器的 127.0.0.1:80 ，正好就是你服务器上 Nginx 监听的那个端口

====

以上就实现了你服务器防火墙不开放任何入站端口（自己用于 SSH 啥的除外），但能通过 Cloudflare Tunnel 正常对外开放网页服务。

@Raynard 基本和你说的一样。eSIM 换卡的具体操作/费用和运营商有关。

我个人之前经验里最典型的一种情况就是：
1. 我有某家运营商的账号，可以通过手机号/邮箱 + 密码，在网页或 App 登录运营商网站
2. 登录后可以申请 eSIM 二维码
3. 支持 eSIM 的手机扫码即可
4. 换手机后重复 1 - 3 步即可。有的运营商会收换卡手续费，有的不会。

另外，iOS 也内置一个可以在两台机器之间转移 eSIM 卡的向导，参见： https://support.apple.com/zh-hk/HT212780 eSIM Quick Transfer 。不过这个功能好像也需要运营商支持。