@wuhao #2 图床的链接是公开的，没有额外的鉴权机制（如果有的话 Obsidian 估计也显示不出图片来），所以你担心互联网上的任何人都可以看到你的图片？

比如说有一张图片的 URL 是 https://example.com/blahblahblahblahblahblah_a_very_looooooooooooooooooooong_path_blahblahblahb 的话，
如果这个 URL 的路径足够长、服务器端又有 rate limit 等防范机制, 已经足够安全了。这个超长的 URL 的密码学强度可能比你的用户名 + 密码 + SSH 密钥还高（？非专业人士，随口说的）。你如果不主动把这个 URL 给别人的话，别人也不可能猜到啊（ Unguessable ）。

关于其安全性，The Verge 在 2015 年有过一篇文章解释： https://www.theverge.com/2015/6/23/8830977/google-photos-security-public-url-privacy-protected

我用 Google Photos 做自己笔记的图床，网页版里直接右键 Copy Image Address 就可以。创建共享链接或者共享相册也可以。

----
当然话说回来，包含敏感个人信息的图片我会直接放在 Obsidian 的 attachments 夹里。我只用图床存储那些我会在笔记里引用，但不太涉及隐私的图片。

@7gugu #83 大人已经在墙外发帖了。
我以为是大人出于其他的什么考虑而不希望在小孩子使用的设备上搞翻墙。

@shuiguomayi #23 目前普通渠道应该是还可以注册 outlook.com 和 hotmail.com 。不过 hotmail.com 也算是历史存量域名了，以后主推的应该是 outlook.com.

推荐注册微软账号，但理由是以后用电脑什么的大概率会用到微软系的服务（ Windows ，Office 等）；仅评价邮箱功能的话，我觉得微软的邮箱很一般。垃圾邮件过滤算法很容易误杀，收发稳定性不如 Gmail 。

不知道您出于什么考虑把选择限制在不翻墙的邮箱。如果去掉这个限制，Gmail/Google 账号是更好的。

@lovelylain #5 香港的主流银行（汇丰、中银、恒生、渣打等等等等）在 2019 年 7-8 月前后都取消了基本账户（非高端理财户口）的小额管理费。

至少有香港身份证的话是这样。不知道对纯香港境外（包括大陆）身份的客户有没有什么幺蛾子收费政策。应该……没有吧？

@NoInternet #9 找一个类似 gfwlist 的在线规则，作为 rule-provider 最好支持 behavior: “domain” 的，可以不写 no-resolve

现在 GitHub 上用的人比较多的那些规则好像大多都考虑到这个问题了。国外网站一般都是域名规则，不会随便包含无“no-resolve”标记的 IP 规则

在任何 CIDR 规则之前先把（主流的需要代理的）国外网站用域名规则匹配，这样（至少提前被域名匹配的这部分网站）不会触发本地 DNS 查询导致 DNS Leak ，可以部分解决问题

例如

- RULE-SET,gfwlist,PROXY,no-resolve
- RULE-SET,cncidr,DIRCET
- MATCH,PROXY

@excit #8 我的 Recovery Key 是 2021 年设置的，2022 年才开启的 ADP （ iOS 16.2 推出），当时开启 ADP 的时候还验证了一下我 2021 年设置的 Recovery Key ，验证通过才成功打开 ADP 。（以上内容是我记录在密码管理器里的笔记）

你说的重新开关 ADP 导致 Recovery Key 改变有两种情况，一是发生在关闭 ADP 时，二是发生在打开 ADP 时。

1. 如果打开 ADP 会导致 Recovery Key 改变，结合我自己的笔记来看，这个操作确实是非常反直觉的，那我的数据也危险了，我现在的 Apple ID 实际生效的 Recovery Key 可能已经不是 2021 年我设置的那个了（感觉不太可能）

2. 自 2022 年初次打开后以后我倒是没再关过 ADP ，所以我暂时不能验证“关闭 ADP”这个操作是否会导致原 Recovery Key 一起失效，等我有时间再试试。

另外，如果如果关闭并重开 ADP 会导致 Apple ID 后台静默改变 Recovery Key 而且不提示不显示（不给你复制、抄写的机会），那确实是非常严重的 bug

OP 遇到的问题确实有点奇怪，有好多细节与我之前的理解不太一样，其中关键的一点是

Recovery Key 这个东西比 Advanced Data Protection 出现得早，这两个应该是互相独立的功能，前者管的是如何恢复 Apple ID (regain access to your account)，后者管的是 iCloud 数据是否端到端加密（就像 ADP 和 Physical Keys 也是相互独立的功能）。

当然，开启 ADP 的 [前提] 是 [已经] 开启 Recovery Key 功能，这是我理解的这两个功能唯一的联系了。所以照理说开关 ADP 应该不会改变另一个安全功能设置的 Key 吧。

如果「 adp 每次关闭再开启都会更新恢复密钥」的话那情况就大不一样了。OP 可以发一下你查的相关资料的链接吗？

@google2020 #22 还有 ThinkPad 京东自营旗舰店、ThinkPad 京东自营官方旗舰店、ThinkBook 京东自营旗舰店，3 家不同的店😄

@mschultz #28 勘误：Apple 的 App Store **美国区**（非 Apple Store ）只接受美国发行的银行卡支付
漏掉了区域

另补充：说到 App Store ，如果有了香港银行卡及香港手机号，你可以充值一些香港当地电子钱包或者申请虚拟银行卡（大多会给你 VISA/Mastercard 虚拟卡），然后有 N 种方法做到合法绑定港区 App Store （好歹算个「外区」），这算是香港银行卡在支付功能上比大陆银行卡间接优越的一点吧。

@xiaoyutongxue #26,27 仅就境外支付功能而言，如果不考虑各行信用卡的优惠活动，一般而言香港银行卡并不比内地银行卡有多少优势。且香港多数传统银行默认办出来的所谓「银行卡」是银联「提款卡」，在支付功能上非常受限。还不如在内地办一张 VISA/Mastercard 的信用卡支付方便。

至于你提到的 Netflix 、ChatGPT 、YouTube 之类能否支付，关键在于那家服务商是否限制付款卡的地区。例如 ChatGPT 不接受中国大陆**及**香港银行发行的银行卡； Apple 的 App Store （非 Apple Store ）只接受美国发行的银行卡支付。（不管卡组织是 VISA/Mastercard 。主要检查发卡行所属国家/地区）

Netflix 及 YouTube 似乎宽松一些，除了在个别地区（比如印度）可能受政策限制外，一般可以接受全球各地发行的 VISA/Mastercard 信用卡。

@naminokoe #1 说明 OP 可能在使用黑名单规则（即只有确定被墙的部分域名使用代理，其他情况默认直连）🤣

@mschultz #9 5. 补充：极少数网站使用的是私有的 TOTP 算法，比如 #8 楼提到的 Steam 。
不过有人说你想折腾的话其实也是可以实现支持的。推荐阅读： https://type.cyhsu.xyz/2023/12/fosspwman/

5. 2FA 字面意义上是一种安全机制，不是一个具体的方法/算法。这里假定你指的是常见的 TOTP 算法（就是一般 6 位数字，30 秒变一次），这个算法是标准化的（ RFC6238 ），基本原理就是一个函数 HOTP(K, T)，其中 K 是密钥，T 是一个随着时间递增的整数，然后这个函数通过一些内部 Hash 之类的运算最后输出 6 位数字。

一个密码管理器所谓支持保存 TOTP 两步验证码，其实就是帮你保存那个密钥（在网站上设置 2FA 时生成的，经常以二维码的形式给你展示一次，让你用密码管理器去扫），然后支持在任意时刻把这个函数计算的 6 位数字显示出来。由于是标准化的，相当多的密码管理器（包括 Bitwarden 客户端 + Vaultwarden 服务端的组合）都支持这个功能，通用的，你自己写点代码也能实现这么一个输出 6 位验证码的函数出来。

另 Vaultwarden, 1Password 这些服务近年来也开始支持 Passkey 。

3. Bitwarden 官方本身就有开源服务端自建方案（ https://bitwarden.com/help/install-on-premise-linux/ ），不过对 Server 的性能要求较高。一般使用小内存 VPS 的玩家会选择 Vaultwarden 。Vaultwarden 是官方服务端自建方案的「平替」，占用资源较小，兼容 Bitwarden 官方的 API 。所以 Vaultwarden 用户在各平台客户端（包括浏览器插件）方面都是用 Bitwarden 官方的。Bitwarden 官方客户端在登录的时候可以选择连接官方服务（ bitwarden.com ）还是 Self-Hosted 服务（自己的域名）。

原来项目叫 Bitwarden_RS ，顾名思义就是 Bitwarden 服务端的一个第三方 Rust 实现，后来为避免商标争议和误导改名 Vaultwarden 。

4. Vaultwarden 的数据存储文件组织结构比较简单，主要就是一个 SQLite 和一个附件文件夹（如无附件可忽略），文档里有关于备份策略的详细说明： https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault 多个月前我试过一次直接导入我备份的 sqlite 文件到新部署的 Vaultwarden 中，似乎没啥问题，数据都在。

硬要解释数学/物理意义的话，虚岁计算的是「一个人自出生以来经历的农历年份数量」，即 #24 @param 的说法。程序来说是一个 「 SELECT COUNT(*) FROM "农历年份表" WHERE "我已出生=True" AND "农历年序号 <= 今年"」的操作。

Wikipedia: https://zh.wikipedia.org/wiki/%E8%99%9A%E5%B2%81

每个讨论虚岁的帖子下面都会有很多玩「娘胎起算」梗的，我觉得是玩错梗、偏题了（引用 #1 @NewYear 说的，「就像很多帖子里的梗，有的人看着很有趣，我看着只想打人。」🤣🤣）。

「娘胎起算」的算法本质上和周岁是一样的，只是起算点不同。除了玩梗，现实世界中绝少见到有人真的用「娘胎起算」法。
而虚岁则完全是另一种算法，传统上被广泛使用。

Email spoofing: https://en.wikipedia.org/wiki/Email_spoofing
另，Google 搜索「伪造发件人地址」也有很多科普文章。

所以情况大概是：1.这个邮件是群发的诈骗邮件，可以忽略它； 2.骗子可能用自动化程序，对某个（某些）以前泄露的数据库/社工库里面的邮箱都发了这种勒索邮件； 3.骗子并没有登录你的 163 邮箱，发件地址是伪造的

一些建议：
1.使用密码管理器，不同网站使用不同密码，能开 2FA 的开 2FA
2.除非你现有的 163 邮箱地址已经广泛用于工作或亲友等现实世界通信，暂不好放弃，其他使用场景下建议逐渐换用口碑更好、垃圾邮件识别更有效的邮箱服务，例如 Gmail 。

@changnet #127 至今还在讨论的原因是：1.新税法虽最合理，但新税法下很多人税负增加了，还不如用那个有问题的算法。
2.官方允许老算法继续应用到 2027 年。现行的政策就应该容许批评的声音。
3.这个补丁算法虽然是比更老的算法优惠，但人们永远希望它能更优惠。诶，它不是长得有点儿像超额累进税率吗？人们希望它真的是。毕竟那样又可以交更少的税咯。啊，仔细一看原来不是啊，遗憾，批判一下。

“如何让自己少交点钱” 这个话题别说 2024 年，4202 年也可以热烈讨论啊，如果那时候人类还没灭亡的话

@snw #119 你说问题的本质是「（应该）摊到每月收入上再超额累进」，我可不可以进一步解读为「月度收入高的人，其年终奖的税率应该更高一些；月度收入低的人年终奖税率也低一些」。也就是说，新税法的做法最接近问题本质。

只是 19 年前财税界电算水平不高，「最大的问题在于（每个人月度工资不同，所以在快捷计算上）没有实操性。」，所以才实行国税发〔 2005 〕 9 号补丁。

这个补丁其实做了一个隐含的、非常粗糙的假设：就是年终奖越高的人，他的平时工资大概也越高，如果将年终奖均摊到 12 个月（本质算法），均摊过来的这部分更可能直接适用高税率。

因此，年终奖直接适用「全额累进税率」更接近问题的本质。现行方案约等于在全额累进税率的基础上做了一定的「扣除数」补偿。

====
那么现在剩下的主要问题是：这个「扣除数」补偿的*数值选择* 和 *名词选择* 极具误导性，给补偿的解释也挺牵强的。不排除是官方刻意误导（？）。最后也免不了挨骂，这个帖子里那么多回复就是例子。