在很久以前的 数字签名 文章中，有介绍过 passkey。当时主要是为了说明【公私钥】。目前很多服务商都支持 passkey 作为【登录】和【多重认证】的手段，于是再重点介绍一下 passkey。

FIDO

FIDO 是 passkey 技术流程的执行标准，明确了使用公私钥认证的方式来实现用户安全登陆。其中，私钥的存储、获取也进行了安全规定的制定。

FIDO（快速身份在线）是指由 FIDO 联盟开发的一套开放标准，用于增强在线身份验证的安全性和便捷性。FIDO 标准主要通过公钥密码学替代传统的密码，以减少欺诈风险并提高用户体验。FIDO 2 是该联盟的最新标准，支持 WebAuthn 和 CTAP，允许用户通过生物识别、安全设备或 PIN 进行无密码认证。

安全终端有哪些

FIDO 约定了私钥的存储和获取。其中，存储必须是对用户不可见、不可导出，即对人类而言，是完全隐秘的黑盒。常见的 passkey 私钥源头是：

1. 手机，如 iPhone、Android
2. 电脑，如 Macos、Windows
3. passkey security key device，专用的移动安全设备，具有 USB 等插口，可以插入电脑中。

All pays

https://stripe.com/zh-sg/payments/payment-methods

Stripe 支持了很多支付方式，可以窥见一些。Stripe 主要对接线上支付，对于很多线下支付的渠道如【nanaco】等电子货币，就看不到了。

japan

动态库 & 静态库，若单独输出并接入主工程，逻辑倒很清晰。如果牵涉到多个 framework 不同类型并且相互依赖，会增加不少复杂度。
以下说明中，动态库使用 DFramework 表示，静态库使用 SFramework 表示。

1 framework

仅需要提供 1 个 framework，直接提供 DFramework 即可。DFramework 优先，必要的时候再提供 SFramework

n framework

因为代码结构分组，可能需要提供多个 framework：

1. DFramework 优先，能不提供 SFramework 就不要提供
   • 有 n 个 DFramework 就提供 n 个。相互之间做好依赖文档，App 需要根据依赖文档 flat 平铺接入所有需要的 DFramework。
   • 如果 b DFramework 仅仅被 a DFramework 依赖，可以将 b 打入 a DFramework 的 frameworks 文件夹中，通过 embed 实现。
     • 这样就可以不再文档中说明 b DFramework 的存在，对外界透明。
     • 这种方案，最终的 app 中 framework 不是 flat 平铺的，而是具有层级结构，如 ：App - a DFramework - b DFramework
   • 如果 b DFramework 同时被 m DFramework 和 n DFramework 依赖，不能将 b 隐藏（打入 m 和 n 中）。
     • 否则，App 集成 m 和 n 的时候，b 会出现多份。如果 b 的版本不一样，将按照打包顺序只使用其中一个。

Mac 系统上，默认没有提供 git、xcodebuild 这些开发者命令。所以当一些终端命令 (brew 等) 被触发后，macos 系统会弹窗提醒用户进行【开发者工具】的安装，即【Command Lines Tools】(下面简称 tools)。
如果安装了不同版本的 xcode，则每个版本都会携带各自 xcode 版本的【tools】。
上面提到的系统弹窗，是不需要安装 xcode 也可以安装【tools】。但这个 tools 版本会比较低，内部的命令数量也会少于 xcode 携带的。即：最新版本的 xcode，携带的 tools 也是最新的。
这里就可以发现有多个 tools 目录了，如下：

1. 非 xcode 携带：/Library/Developer/CommandLineTools
2. xcode:/Applications/Xcode.app/Contents/Developer
3. xcode beta: /Applications/Xcode-16.2.0-Beta.2.app/Contents/Developer

在终端执行 git 、xcodebuild 的时候，一定会使用某一个 tools 中的命令，可具体使用哪一个呢？

今天配置 cloudflare 中站点的 dns，遇到一些关于 cname、tls、cloudflare 代理相关的问题，做了下梳理。重点有下：

1. cname 负责提供目标 ip，在机制上类似【权威域名服务器】
2. 目标 ip 所在的服务如果非自行掌控（比如强行设置一个目标域名），很可能无法工作。
3. cloudflare 设置 cname 的时候有一个【代理】功能。这个设计非常糟糕，完全脱离了 cname 的本意。

以下介绍中，使用 cloudflare 配置 test.yigegongjiang.com 的 cname 为 httpbin.org，默认不配置【代理】。

最近工作上在使用 WebRTC，在公司内部做了技术分享。这里把内容进行脱敏，整理公开。

快速进入 WebRTC

Server-Sent Events（SSE）是一种允许服务器通过 HTTP 连接主动向客户端发送数据的技术。它主要被用于创建实时应用，如消息推送和实时通知。SSE 使用简单的文本格式发送消息，这种格式使得其易于在浏览器中实现和使用。

SSE 注意事项：

1. 通过 HTTP 协议通道 建立单向长连接，即 Client 连接 Server 后，Server 不断开连接，并持续的通过 socket 套接字发送 data 给 Client。
2. 网关等设备会主动关闭 tcp 通道，需要 SSE Server 端增加心跳。很多种场景都会导致 tcp 连接中断，和 IM 心跳一致。这里需要 SSE Server 增加应用层心跳，非 TCP 层心跳。

实际测试结果，虽然 Cloudflare 号称服务部署非常多，但使用 Warp 的 【VPN / 代理】功能，会明显增加网络延迟。（location & ip： Japan）

Cloudflare 提供了 1.1.1.1 DNS 服务，以及 WARP VPN + 代理。

公共 DNS

运营商 DNS 有什么问题？

直接使用运营商的 DNS 服务，有下面两个重要的问题：

1. ISP 会通过 DNS 查询的域名，分析用户访问的网站。（DNS 查询是明文的 UDP）
2. ISP DNS 会有劫持、污染、缓存等

那么公共 DNS 可以解决上面的问题吗？不行。

对于普通用户来说，使用运营商 DNS 没有任何问题，也会加快域名解析的速度。
如果想要安全，避免被运营商做【DNS 查询】分析，公共 DNS 无能为力。不管使用的公共 DNS 是 ipv4、ipv6、DoH，都无法解决。
DoH 是能用到最安全的级别了，但还是有 SNI 泄漏。

换端能力

在移动应用生态中，换端 (App Switching) 是一个常见的需求。同一台设备上，有以下三个端: M(Web网页)、 A(移动应用 app)、 B(待唤端的应用 app)。 当 M 或 A 需要跳转至 B 时，有两种技术方案: URL Scheme 和 Universal Link。

URL Scheme

1. App 端先行验证能力:
   • A 可以通过 canOpen 方法预先判断 B 是否已安装，且此操作不会触发跳转

Bonjour

local net 服务发现。核心是两个 api：NSNetService & NSNetServiceBrowser。

Bonjour 的目的，是希望发现局域网中的设备，包括这些设备的 ip、port 等信息，从而进行下一步业务操作。因为有了 ip、port，就可以精确定位一台设备了，就可以做很多事情了，比如打通 socket 等。

NSNetService 用来发布服务，表明 m 提供了哪些能力，如打印机、http 服务等等。