Loading... # HSBC 邮件追踪像素事件技术分析 # 一、事件概述 ## 1. 事件背景 2025 年 9 月，HSBC 银行向一位客户发送实体信函，声称发送给该客户的邮件被「退回且无法送达」，要求客户更新账户中的电子邮件地址。然而，客户实际上一直正常接收银行的所有邮件。 ## 2. 核心问题 HSBC 使用追踪像素来监控客户是否阅读邮件，但该技术被隐私保护工具拦截，银行错误地将「无法追踪」理解为「邮件未送达」。 ## 3. 事件严重程度 - **用户影响**：误导性通知导致客户困扰 - **安全风险**：使用未加密 HTTP 传输追踪像素 - **隐私问题**：未经同意的邮件阅读监控 # 二、事件经过 ## 1. 初始阶段：收到误导性信函 客户收到 HSBC 实体信函，内容如下： - 声称发给客户的邮件被「退回且无法送达」 - 要求客户更新在线银行账户中的电子邮件地址 - 标注为「需要采取行动」 然而，客户的邮箱中实际上正常存放着来自 HSBC 的最新邮件。 ## 2. 在线验证阶段 客户按照信函指示登录银行账户，发现： - 账户中记录的电子邮件地址完全正确 - 无需进行任何更新 ## 3. 客服沟通阶段 ### A. 在线客服回应 通过银行应用程序与客服代表 Ankitha 进行长达一小时沟通后，对方坚持表示： > 「如果银行发送了这封信，您就必须更新电子邮件地址」 ### B. 电话客服回应 直接致电客户服务部门后获得不同答复： > 「如果您的电子邮件地址已经正确，则可以忽略我们的来信」 # 三、技术分析 ## 1. 追踪像素工作原理 HSBC 在其邮件底部嵌入了追踪像素代码： ```html <img src="http://www.email1.hsbc.co.uk:8080/Tm90IHRoZSByZWFsIEhTQkMgcGF5bG9hZA==" width="1" height="1" alt="" style=""> <img src="http://www.email1.hsbc.co.uk:8080/QWxzbyBub3QgcmVhbCBIU0JDIHBheWxvYWQ=" width="1" height="1" alt="" style=""> ``` ### A. 追踪像素是什么 追踪像素是 1×1 像素的微小图片，通常为透明或白色，用于秘密追踪邮件阅读行为。 ### B. 工作机制 ```mermaid sequenceDiagram participant B as 银行服务器 participant E as 邮件服务器 participant C as 客户端 participant T as 追踪服务器 B->>E: 发送含追踪像素的邮件 E->>C: 投递邮件 C->>C: 用户打开邮件 C->>T: 请求加载追踪图片 T->>B: 记录阅读事件 ```  ### C. 追踪像素与传统回执的区别 | 特性 | 传统邮件回执 | 追踪像素 | |------|-------------|----------| | 用户知情 | 需要用户同意 | 完全隐藏 | | 信息内容 | 已读状态 | 阅读时间、频率、次数 | | 可靠性 | 依赖用户选择 | 依赖客户端设置 | | 隐私保护 | 有用户控制 | 无用户控制 | ## 2. 问题根因分析 ### A. 直接原因 客户使用隐私保护工具拦截了追踪像素，导致 HSBC 无法收到阅读确认。 ### B. 深层原因（5 Whys 分析） **为什么 HSBC 认为邮件未送达？** - 因为追踪像素未被触发 **为什么追踪像素未被触发？** - 因为客户的隐私保护工具拦截了追踪请求 **为什么 HSBC 依赖追踪像素确认送达？** - 因为监控资本主义已普遍化，银行假设追踪技术 100% 可靠 **为什么银行不使用更可靠的验证方式？** - 因为便利性和隐蔽性优先于准确性 **为什么会产生系统性误判？** - 因为监控资本主义已透明化，银行无法想象用户会拒绝被监控 ### C. 核心矛盾 追踪像素的设计初衷是秘密监控，而不是确认送达。两者存在本质区别： - **确认送达**：邮件成功到达收件箱 - **追踪像素**：收件人打开了邮件（且未拦截追踪） # 四、安全问题 ## 1. 未加密传输风险 HSBC 使用 HTTP 而非 HTTPS 协议传输追踪像素，导致以下风险： ### A. 网络监听风险 当客户在公共 WiFi（如咖啡馆）打开银行邮件时： - 同一网络的其他人可看到追踪请求 - 攻击者可获知客户使用的银行 - 攻击者可知道客户正在查看银行邮件 ### B. 中间人攻击风险 未加密连接允许攻击者： - 注入恶意内容到邮件底部 - 篡改追踪像素参数 - 执行其他攻击行为 ## 2. 隐私侵犯问题 ### A. 超范围数据收集 追踪像素可记录： - 阅读时间戳 - 阅读次数 - 阅读频率 - 可能的 IP 地址和设备信息 ### B. 未经同意的监控 - 未征求用户同意 - 未提供关闭选项 - 违反隐私设计原则 # 五、系统性问题分析 ## 1. 监控资本主义普遍化 问题的核心在于监控资本主义已变得如此普遍，以至于： - 银行假设追踪技术 100% 可靠 - 银行无法想象用户会拒绝被监控 - 银行将「无法追踪」等同于「无法送达」 ## 2. 邮件系统的设计原则 电子邮件最初设计的核心原则： - 发送方无法知道收件人是否已读邮件 - 收件人完全控制阅读行为 - 隐私保护是内置特性 追踪像素破坏了这些原则，引入了: - 发送方监控能力 - 未经用户同意的数据收集 - 隐私侵犯机制 # 六、改进建议 ## 1. 技术层面改进 ### A. 最低要求：使用加密连接 - 将所有追踪像素从 HTTP 改为 HTTPS - 防止网络监听和数据泄露 - 降低中间人攻击风险 ### B. 停止依赖不可靠的代理 - 认识到追踪像素不等于送达确认 - 建立更可靠的邮件验证机制 - 接受隐私保护是用户的合法选择 ### C. 最佳实践：停止邮件监控 - 尊重用户隐私权 - 遵循「最小必要」数据收集原则 - 实践银行自身发布的数据伦理原则 ## 2. 流程层面改进 ### A. 准确的信函模板 原模板错误之处： - 声称邮件「退回且无法送达」 - 标注「需要采取行动」 - 威胁要求更新电子邮件地址 改进后的模板应说明： - 「需要确认您能收到我们的邮件」 - 「请检查您是否收到我们的邮件」 - 「请验证账户中的电子邮件地址是否正确」 ### B. 真实的验证机制 不使用追踪像素，而是： - 发送明确的验证邮件 - 要求用户点击链接确认收到 - 在验证过程中进行身份认证 - 获得用户的知情同意 ### C. 客服培训一致性 - 统一不同渠道的回应标准 - 培训客服理解技术限制 - 建立问题升级机制 ## 3. 政策层面改进 ### A. 遵循隐私原则 银行应实践其公开声明的原则： - 仅收集适当用途的数据 - 在设计和审批流程中嵌入隐私考虑 - 向客户透明公开数据使用方式 ### B. 错误透明化 当系统出现误判时： - 承认系统限制 - 透明解释问题根因 - 避免误导性陈述 # 七、经验总结 ## 1. 技术教训 ### A. 追踪技术的局限性 - 追踪像素不是可靠的送达确认机制 - 隐私保护工具会干扰追踪 - 系统设计应考虑这些限制 ### B. 安全设计原则 - 所有网络通信应使用加密 - 不应假设用户会接受监控 - 隐私保护应是默认设置 ## 2. 流程教训 ### A. 一致性问题 - 不同客服渠道给出矛盾建议 - 信函模板与技术现实不符 - 需要建立一致的沟通标准 ### B. 用户体验问题 - 误导性信函导致用户困扰 - 客服无法有效解决问题 - 需要改进问题处理流程 ## 3. 系统性反思 ### A. 监控资本主义的透明化 当监控技术变得如此普遍，以至于服务提供方无法想象用户会拒绝被监控，这标志着监控资本主义已变得「透明化」——它已成为系统设计的默认假设。 ### B. 隐私与便利的平衡 - 服务方希望获得尽可能多的数据 - 用户希望保护个人隐私 - 需要在两者之间找到平衡 ### C. 用户的主动防御 - 使用隐私保护工具是合法选择 - 用户有权拒绝被监控 - 服务方应接受并适应这一现实 *** ## 参考资料 1. [That's Not How Email Works, HSBC – Dan Q](https://danq.me/2026/01/28/hsbc-dont-understand-email/) 最后修改：2026 年 01 月 29 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏