@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 。不过这个功能好像也需要运营商支持。

需使用香港发行的银行卡。

@Guino #15
@Delbert #13

我感觉可能还是根据协议，同一种协议（比如 FeliCa or not ）同时只能开启一张。

对于「基于位置信息判断弹出哪张卡」这一点，有一个反例，那就是深圳地铁 4 号线「福田口岸」站付费区内，有一个「港铁特惠站」，也是港铁唯一设置在香港境外的港铁特惠站，其不仅地理上在内地，其周围的电磁环境（如蜂窝基站、Wi-Fi 等）也全都是内地的；但若手持「同时开启深圳交通联合 + 八达通快捷交通卡」的 iPhone 过去拍卡，能够自动弹出八达通。

而距离该特惠站仅几十米远的深圳地铁出入闸机，则可自动激活深圳交通卡。

不知道 hotlink protection 能不能解决你的问题 https://developers.cloudflare.com/support/more-dashboard-apps/cloudflare-scrape-shield/understanding-cloudflare-hotlink-protection/

非港澳自由行城市户口办的团队旅游（ L ）签注与个人旅游已经没区别，前几天（ 2023-08 月内）朋友亲测，直接走快捷通道（内地）+ 访客 e 道（香港）通关，没问题。
即使是人生第一次访港也可以走 e 道，只需满足 (1) 满 11 周岁 及 (2)在内地公安局申请港澳通行证时已授权港澳有关部门读取指纹信息）。

@ryd994 #5 不止这样，如果整个账户总资产只有 2 万的话，实际综合利率只有 0.483%，即宣传利率的十分之一。

因为 IB （ 1 ）只计算 1 万以上部分的利息 （ 2 ）该部分利率 = <账户总资产> / 100,000 美元 * 4.83%，按比例计算的

@liudongdd #17 可以（一般外卡在内地漫游都是走原运营商出口的，例如港卡在内地漫游，流量还是回香港，出口还是香港 IP ），但是要买漫游流量（ Club Sim 在 7-11 买的默认套餐不包含任何香港之外的流量），按天算，不算便宜。

就外卡在中国内地漫游而言，目前 V 站比较流行其他套餐方案。

之前陪朋友开中银的卡，预约了，然后我们比预约的时间晚到了十几分钟，然后发现大堂经理已经按照预约时间提前帮我们取号排队了🤣

@yyzh #4 （截至目前）港版也不能说完全没有，只是在 emoji 键盘里隐藏了。与国行的限制程度不同。港版正常显示没问题，iOS 自带输入法通过汉字联想打出该 emoji 也没问题。

@kaikai5601 #3
@StuPYX #10
https://support.microsoft.com/en-us/office/changes-to-microsoft-365-email-features-and-storage-e888d746-61e5-49e3-9bd1-94b88e9be988

> Starting November 30, 2023, Microsoft 365 Personal or Microsoft 365 Family subscribers will no longer be able to create a new email address for any personalized domain associated with their Outlook.com mailbox.

「不信任任何云提供商的服务了」+「找一个 Web 版的 Calendar 应用」+「多设备查看」，这有点儿矛盾啊。

满足需求的就…… 买个 NAS ，比如群晖的 Synology Calendar ？或者 NextCloud 之类的自建 CalDAV 服务。
自建的话你也总要找个服务器（不管是 VPS 还是 NAS ）托管，感觉这一套下来服务的靠谱程度不见得比得上 Google Calendar 这种大厂吧？

个人觉得比较靠谱的方法是 Google Calendar + 定期/不定期备份/Google Takeout 。这样总不会导致你 10 年日历全部丢失。日历这东西很好备份的，导出的 ics 文件是纯文本，迁移自由。

Google Voice 暂时还活着