#Locale Extensions S1

中文标题：区域设置扩展

#目录

• 解释器：区域设置扩展
  • 目录
  • 作者
  • 参与
  • 动机
  • 概述
  • 拟议支持的区域设置扩展组合摘要
  • 指纹识别与国际化
    • 指纹识别缓解
    • 缓解策略概述
  • 示例标签：首选一周的第一天、首选时钟、首选温度计量单位
    • 常用区域设置默认值
    • 示例：从一个地区旅行到另一个地区的人
      • 取决于浏览器本地化的已披露信息
    • 示例：偏好与所有常用区域设置默认值不同的人 'nu' 标签 最佳匹配偏好字符串
  • 机制
    • 代理驱动协商：JavaScript API
      • IDL
      • 拟议语法
    • 使用客户端提示的主动内容协商
      • Client Hint 标头字段
      • 使用示例
  • 关于安全与隐私的最终说明
  • 常见问题

#作者：

• Ben Allen

#参与

• GitHub 仓库
• 问题追踪器

请将反馈发至上述问题追踪器或通过电子邮件发送给 Ben Allen 或 Shane Carr。

#动机

在 Web 平台上，内容本地化仅依赖于用户的语言或地区。这种行为可能会导致某些用户感到烦恼、沮丧、被冒犯，甚至难以理解。本提案解决了用户偏好的区域设置相关定制与区域设置默认值不同的常见情况。请考虑以下问题：

1. 移居美国的人通常希望天气网站以摄氏度而非华氏度显示温度。
2. 在某些区域设置中，多种数字系统被普遍使用。在这些区域设置中寻求内容的用户可能会觉得其中一种或另一种数字系统不易理解，因此需要一种方式来请求他们能阅读的内容。
3. 来自日本的英语用户会收到非本地化的 'en-US' 内容。他们能阅读英语，但更喜欢看到 24 小时制的时钟，以及以周一而非周日作为一周第一天的日历。
4. 更一般地说：'en-US' 目前是软件中典型的未翻译语言，尽管 'en-US' 具有与全球使用不同的特定区域格式模式。因此，带有未翻译 UI 字符串的文本通常会以一种所有说英语的用户都能理解的语言显示，但温度和时间的表示却采用全球不常见的标准。
5. 从一个国家移民到另一个国家的人可能希望将语言方言设置为他们能理解的一种，但更希望日期、时间和数字按照当地标准渲染。

在原生环境中，这些问题很容易解决，因为用户可以在系统设置中指定他们的偏好。然而，在通常充满敌意的 Web 环境中，不可能提供原生环境允许的全部灵活性。这是因为当用户在操作系统设置中指定的偏好不常见，甚至只是非常详细时，泄露这些偏好可能会导致隐私损失。此外，由于用户可能在其所有设备上设置相同的本地化相关偏好，这意味着暴露这些设置可能被用于跨设备跟踪。

本提案定义了一种机制，使 Web 客户端能够从操作系统读取用户偏好，然后将理想情况下安全的偏好子集转发给服务器，同时同样理想地避免发送可能实质上识别用户身份的偏好组合。我们的目标是允许显著更完整——但不一定完美——的本地化，尽可能尊重用户偏好，同时仅暴露关于用户的相对低惊异度信息。

#概述

BCP 47 的 Unicode 扩展可用于将识别区域设置所需的附加信息附加到语言标识符的末尾。启用对精心选择的 BCP 标签子集的有限支持可以帮助解决上述问题。

该提案包括两种将操作系统设置传达给服务器的机制：

对于客户端应用程序，一个浏览器 API，从不同的平台特定 API 获取此信息。

对于服务器端应用程序，一组 Client Hints 请求标头字段。服务器在 Accept-CH 响应标头中指明它们接受的特定主动内容协商标头。

拟议的 API 和 Client Hints 基础设施很直接：该 API 提供了单独访问每个偏好的方法，Client Hints 标头也提供了一种单独请求每个偏好的手段。在两种机制中都没有提供一次请求所有偏好的方法——必须明确请求每个偏好。尽管本提案以 BCP 47 的 Unicode 扩展来讨论首选的本地化定制，但服务器无法一次性请求整个扩展字符串。

以下是可能包含的偏好列表（不完整）：

1. 首选编号系统（天城文、孟加拉文、东阿拉伯文等）。此选项对应于 BCP 47 的 nu Unicode 扩展标签。
2. 首选小时周期（12 小时制或 24 小时制）。此选项对应于 hc 标签。
3. 首选温度计量单位（摄氏度或华氏度）。此选项对应于 mu 标签。
4. 首选日历（公历、伊斯兰历、佛教阳历等）。此选项对应于 ca 标签。
5. 日历的首选一周第一天。此选项对应于 fw 标签。

如前所述，将区域设置偏好传达给服务器的两种机制都很直接。实现此提案所涉及的大部分复杂性在于预先确定哪些偏好组合可以安全地暴露给服务器而不会影响用户隐私，或者哪些偏好组合尽管对用户隐私有影响但仍值得暴露给服务器。

#拟议支持的区域设置扩展组合摘要

我们的目标是为用户提供请求以下类型内容定制的能力：

• 与客户端 Accept-Language 标头中发送的任何一种或多种区域设置的默认设置相匹配的受支持扩展标签值的任何组合。
• 针对每种浏览器本地化，从备选操作系统设置中选取的一到十个备选选项。
• 对于 nu 标签的值，如果不被采用，将导致用户收到无法理解的内容。

最优先考虑的是允许用户在存在多种常用编号系统的语言中指定备选编号系统。另一个关键优先事项是确保为使用常见语言的用户提供的任何灵活性水平也适用于来自较小文化/语言社区的用户。

#指纹识别与国际化

解释器中的标准做法是将关于安全和隐私的部分放在末尾。在本解释器中，我们将其移至几乎开头的位置。这是因为该提案可能暴露 Web 技术栈中其他部分未暴露的敏感用户数据。除非在构建可用选项列表时格外小心，否则这些被揭露的数据可能导致用户容易被指纹识别。

指纹识别允许网站未经用户知晓或同意地跟踪用户，从而严重侵犯用户隐私，而降低指纹识别风险是我们的首要关切。电子前沿基金会 (EFF) 为 Peter Eckersley 2010 年论文你的浏览器有多独特？收集的数据估计，访问 EFF 的“Panopticlick”网站的浏览器中有 83.6% 带有独特的指纹。在随后的几年里取得了一些改进。值得注意的是，Adobe Flash 和 Java 小程序作为 Web 技术的终结，已经阻止了许多潜在的指纹识别攻击，并且已采取大量措施来降低基于字体的指纹识别风险。尽管如此，当今浏览器的可指纹识别程度几乎与 2010 年的浏览器相当。减少 Web 平台上指纹识别可能性的过程必然是一个漫长而缓慢的过程——一个以十年而非几年计的过程——涉及逐步用暴露较少用户信息的技术替换暴露更多信息的技术。

在信息国际化的背景下，指纹识别是一个特别棘手的问题。防止指纹识别的最直接方法是发送较少的信息，或者使得发送罕见的设置组合变得不可能。然而，公平的国际化要求提供较少使用的区域设置的内容访问，并针对所有用户社区适当定制这些内容，无论该社区规模如何——也就是说，它需要容纳多种类型的罕见请求。

使问题更加复杂的是，即使通过请求正确本地化的内容所泄露的信息比特数相对较低，也可能存在安全隐患。这是因为我们泄露的信息可能提供用户所属身份类别的强烈指示，即使整体熵减少不足以让跟踪者完全识别用户，并且因为我们泄露的信息是特定于用户的，而不是他们的设备，因此可用于跨设备跟踪。

#指纹识别缓解

在 Web 规范中缓解浏览器指纹识别 WICG 兴趣组说明，其最佳实践被用作本提案设计的主要框架，指出不存在消除指纹识别的可行方法。我们最多只能缓解指纹识别，要么通过泄露较少的识别信息来减少可用的指纹识别表面，要么通过确保发生的任何指纹识别以某种方式可观察（“主动指纹识别”）而不是对用户不可见（“被动指纹识别”）。通过确保仅有的指纹识别机会需要服务器采取行动，就更容易通过监管手段控制指纹识别。值得注意的是，未经许可使用浏览器指纹跟踪用户在欧盟仅勉强合法。

#缓解策略概述

我们降低指纹识别风险的主要策略如下：

• 确保我们揭示的唯一指纹识别表面是主动指纹识别表面。

我们通过确保希望利用用户操作系统偏好的服务器必须逐一请求这些偏好，而不是一次全部接收来实现这一点。试图获取比实际需要更多偏好相关信息以尝试对客户端进行指纹识别的服务器，至少会以可检测的方式进行。

• 通过 Accept-Language 标头和 navigator.languages 揭示的一种或多种区域设置。

计算通过暴露内容定制偏好而损失的熵并不直接，因为偏好的分布高度不均。因此，确定特定有效选项组合需要大量的用户研究数据。

#示例标签：首选一周的第一天、首选时钟、首选温度计量单位。

Unicode 区域设置扩展标签 fw、hc 和 mu 可用于请求首选的一周第一天、小时周期和温度计量单位。这三个标签值得放在一起考虑。这是因为对于每个标签，都有一个有限的常用选项集：

• 没有区域设置默认时钟是除 h12（1 到 12 小时）或 h23（0 到 23 小时）之外的任何形式。
• 没有区域设置默认 mu 为除 celsius 或 fahrenhe 之外的任何值。
• 没有区域设置默认一周第一天为除 mon、fri、sat 或 sun 之外的任何值，只有一个地区（马尔代夫）默认值为 fri。

因此，对于大多数用户而言，他们对这三个选项的首选设置组合将与数亿甚至数十亿其他人共享。但请注意，所选的组合对于用户的浏览器本地化可能是罕见的，因此可能无法共享。

#常用区域设置默认值

CLDR 的补充数据提供了每个地区这些选项的默认设置信息，以及该地区人口、该地区使用的语言和识字率信息。为了非常粗略地估计——任何真正的估计都需要用户研究——世界上拥有相同 fw、hc 和 mu 设置的人数，我们将每个地区的人口乘以该地区的识字率，并将默认使用这些设置的地区的识字人口相加。

表中很少出现在地区默认值中的三个字符串分别反映了马尔代夫、伯利兹的默认偏好，以及开曼群岛和帕劳的默认偏好。除美国外，所有被列为使用表示偏好华氏度的字符串的地区，仅在与天气相关时使用华氏度。

尽管用户的浏览器区域设置默认值匹配某个特定字符串的可能性不等，但通过揭示其中一个字符串而损失的总熵相对较低。假设我们不允许使用表格底部三个稀有字符串，我们发现此分布具有 2.18 比特的熵，仅略低于掷一个均匀六面骰子所获得的 2.58 比特熵。暴露您选择的偏好字符串似乎是相对安全的——但仅在孤立地看时是这样，因为选择特定偏好字符串的可能性在统计上依赖于其他已知的区域设置相关信息。

#示例：从一个地区旅行到另一个地区的人

考虑一位来自荷兰的学生在芝加哥一所大学学习一年的情况。如果大学的课程目录以 24 小时制而不是美国常见的 12 小时制显示时间，这位学生可以避免烦恼（甚至可能避免错误）。同样，如果日历以周一而非周日作为一周的第一天显示，他们也会更满意。此外，他们不适应这个地区严酷的冬季，有时会使用当地新闻网站上的天气显示来帮助决定穿多少层衣服。他们非常希望避免在将不熟悉的华氏度转换为立即能理解的摄氏度时产生的挫败感和潜在失误。

原生应用程序可以直接读取操作系统中关于首选时钟、一周第一天和温度测量系统的设置。但是，将此信息直接暴露给潜在的恶意 Web 服务器是不安全的，因为如果用户的设置是特殊的，那么这些特殊设置很容易被用来跟踪他们。将操作系统设置为以开尔文显示温度是安全的，但将此事告知任意 Web 服务器是危险的。

该学生的偏好可以用区域设置扩展字符串 -u-fw-mon-hc-h23-mu-celsius 来表示。暴露这种低惊异度的偏好集合本身不会显著减小该学生的匿名集大小。然而，我们不能孤立地考虑预期拥有此偏好集合的原始人数，因为在给定用户其他已知信息的情况下，特定设置的惊异度可能相当高。

#示例：偏好与所有常用区域设置默认值不同的人

fw 和 hc 的每个常用组合都可以与 mu 的值 celsius 组合使用。然而，由于唯一默认 fahrenhe 的大型区域设置是 'en-US'，因此涉及 fahrenhe 但其他方面与 'en-US' 默认值不同的偏好组合不能保证是常用的。尽管如此，仍有许多可能使用 'en-US' 浏览器区域设置但偏好与美国默认值不同的人：

• 在组织中使用 24 小时制工作的人。
• 与使用周六作为每周工作第一天的地区有社交、家庭和文化联系的人。
• 仅仅出于个人偏好喜欢日历每周第一天出现在左侧的人。
• 不在美国或非美国人士，但使用 'en-US' 作为浏览器区域设置的人。

由于使用 'en-US' 作为浏览器区域设置的人数众多且范围广泛，提供这些偏好组合中的大部分可能是安全的，尽管它们不是常用的区域设置默认值。这将需要用户研究。

#'nu' 标签

在某些地区，最著名的是西阿拉伯数字和东阿拉伯数字都普遍使用的地区，如果不能同时支持这两种数字系统，就会导致向某些用户提供无法理解的内容。无法表达对特定数字系统的偏好会造成与文本使用多种文字的区域设置中的用户无法选择他们能看清的文字完全相同的问题。在这些情况下，支持 nu 标签是重中之重——与语言标签本身同等重要——即使支持该标签意味着不支持任何其他区域设置偏好标签。

#最佳匹配偏好字符串

如果给定用户的偏好字符串与允许的字符串之一相对相似，则可以让用户发送与用户完整偏好最匹配的一组允许的偏好。在确定这些最佳匹配字符串时，必须优先考虑直接影响内容可理解性的标签——最著名的是 'nu'。

#表达区域设置偏好的机制

一旦确定了安全的设置组合集，此提案的实现细节相对直接。

#代理驱动协商：JavaScript API

我们通过 navigator.locales 在 JavaScript API 中公开这些扩展的首选选项，或者通过创建一个新的 navigator.localeExtensions 属性。请注意，该 API 不会暴露选择了哪个区域设置扩展字符串，并且必须逐一请求偏好。这一限制是作为额外的指纹识别缓解措施而存在的——如果允许脚本一次获取所有偏好，将更难检测主动指纹识别尝试。通过要求逐一请求选项，例如，在提供内容时请求备选编号系统但该区域设置没有常用备选编号系统的网站将立即被识别为恶意行为者。

我们通过 'navigator.locales' 在 JavaScript API 中公开这些扩展的首选选项，或者通过创建一个新的 'navigator.localeExtensions' 属性：

浏览器在首次以特定区域设置请求内容时执行以下步骤：

1. 浏览器读取操作系统设置。
2. 浏览器将这些设置与可用的区域设置扩展字符串列表进行比较，确定（通过任何方式）哪个与用户偏好最接近，并丢弃所有其他设置。
3. 然后脚本可以请求保留的设置，但只能逐一请求。

#IDL

interface LocaleExtensions localeExtensions {
  readonly attribute DOMString calendar;
  readonly attribute DOMString firstDayOfWeek;
  readonly attribute DOMString hourCycle;
  readonly attribute DOMString temperatureUnit;
  readonly attribute DOMString numberingSystem;
};

interface mixin NavigatorLocaleExtensions {
  readonly attribute LocaleExtensions localeExtensions;
};

Navigator includes NavigatorLocaleExtensions;
WorkerNavigator includes NavigatorLocaleExtensions;

#拟议语法

navigator.localeExtensions['numberingSystem'];
navigator.localeExtensions.numberingSystem;
self.navigator.numberingSystem;
// "deva"

navigator.localeExtensions['hourCycle'];
navigator.localeExtensions.hourCycle;
self.navigator.hourCycle;
// "h23"

#使用 Client Hints 的主动内容协商

HTTP Client Hint 是由 HTTP 客户端发送并用于优化提供给这些客户端的内容的请求标头字段。Client Hints 基础设施定义了一个 Accept-CH 响应标头，服务器可以使用它来宣传他们对特定请求标头用于主动内容协商的使用。这种选择加入机制使客户端能够有选择地发送内容适配数据，而不是将所有这些数据附加到每个出站请求中。

由于服务器必须指定他们有兴趣接收的标头集，因此 Client Hint 机制消除了许多在使用其他方式进行主动内容协商（例如 User-Agent 字符串）时出现的恶意被动指纹识别机会。

每个受支持的扩展都有自己的 Client Hint，这确保服务器必须宣传他们请求了哪些与区域设置相关的偏好。这类似于 JavaScript API 中使用的策略。就像 API 只允许一次请求一个偏好，从而在脚本试图访问不相关偏好作为指纹识别尝试的一部分时使其可见，这里使用的 Client Hint 确保请求不相关的区域设置相关偏好的服务器必须对此公开。

#Client Hint 标头字段

服务器不能被动接收有关区域设置扩展相关设置的信息。服务器而是宣布他们使用扩展的能力，允许客户端选择以其首选的内容定制来响应。

为此，浏览器应引入新的 Client Hint 标头字段，作为 HTTP 的结构化字段值中定义的结构化标头的一部分。

这些标头上使用的 Sec- 前缀可防止脚本和其他应用程序内容在用户代理中设置它们，并将它们标记为浏览器控制的客户端提示，以便在请求中记录和包含它们而不会触发 CORS 预检。有关更多信息，请参阅HTTP Client Hints 第 4.2 节，部署和安全风险。

设计 Client Hints 标头字段需要在指纹识别缓解和使用一组简洁的标头之间进行权衡。最能防止指纹识别的方法是让每个单独的标签都有自己的 Client Hint 标头。由于服务器必须宣传他们的每个标头的使用情况，完全分离标签会使指纹识别尝试更加明显——请求大量 Client Hint 而没有必要的服务器是在公开广播其可能意图使用从客户端收集的额外信息进行指纹识别。然而，如果标头膨胀成为一个主要问题，这些标头中的一些可以被分组。例如，hc、fw 和 ca 可以作为与日期和时间相关的偏好分组在一起，或者 fw、hc 和 mu 可以分组，不是由于概念上的相似性，而是由于它们彼此之间的强相关性，因为遵循美国地区标准的用户可能想要 -u-fw-sun-hc-h12-mu-fahrenhe，而世界其他大部分地区的用户可能想要 -u-fw-mon-hc-h23-mu-celsius。

如果超出可通过 BCP 47 标签表达的自定义设置的能力被纳入本提案，分组将必然会成为一个更紧迫的问题。例如，如果与数字格式相关的其他偏好成为提案的一部分，这些可以与 nu 分组在一起。

#使用示例

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Sec-CH-Locale-Extensions-NumberingSystem

GET / HTTP/1.1
Host: example.com
Sec-CH-Locale-Extensions-NumberingSystem: "deva"

#关于安全与隐私的最终说明

在 Web 规范中缓解浏览器指纹识别 确定了以下指纹识别缓解的关键要素：

1. 减少指纹识别表面
2. 增加匿名集
3. 使指纹识别可检测（即用主动方法替换被动指纹识别方法）
4. 可清除的本地状态

为所有用户保留相对较大的匿名集是我们的核心策略，以尽可能降低指纹识别风险，同时确保为广大用户的本地化体验带来实质性改善。

正如在 HTTP Client Hints RFC 的安全注意事项 部分所述，Client Hints 架构的一个关键好处是它允许主动内容协商，而不会暴露被动指纹识别向量，因为服务器必须主动宣传他们对特定 Client Hints 标头的使用。这使得移除预先存在的被动指纹识别向量并用相对容易检测的主动向量替换它们成为可能。在 Web 规范中缓解浏览器指纹识别 的可检测性部分描述了对服务器宣传其使用特定数据实行要求的最佳实践，并提到 Client Hints 作为实施此实践的工具。在没有 Client Hints 的情况下，至少客户端可以检测到 JavaScript API 的使用。在任何情况下，本提案都不允许任何新的被动指纹识别向量。例如，尝试在提供不包含任何备选方案的内容时请求编号系统偏好的网站将立即被视为恶意行为者：一旦遇到服务器出现此行为，浏览器可以向用户发出警告。

使用 'Sec-' 前缀禁止从 JavaScript 访问包含 'Locale Extensions' 信息的标头，并将它们标记为浏览器控制的客户端提示，以便在请求中记录和包含它们而不会触发 CORS 预检。

JavaScript API 禁止通过一次调用检索多个偏好的约束有助于更容易地进行指纹识别检测。

与 Client Hints 的所有使用一样，当清除站点数据、浏览器缓存和 Cookie 时，用户代理必须清除选择加入的 Client Hints 设置。

#常见问题

#未被 BCP 47 的 Unicode 扩展捕获的选项

还存在其他与本地化相关的自定义，这些自定义对于站点可理解性很有用——最著名的是数字分隔符和数字模式。支持这些选项的常用子集是可能的，特别是在它们与有效的区域设置扩展字符串的特定组合强相关的情况下。

#添加和移除其他区域设置扩展字符串

在添加，尤其是在移除可用的区域设置扩展字符串时，应采取保守的方法。这是为了避免出现（例如）用户不确定给定温度所在的刻度，或者之前被允许使用其首选编号系统的用户不再能够访问它的情况。

#每种区域设置将支持多少种可能的区域设置扩展字符串？

负责任地回答这个问题需要用户研究。在大多数情况下，用户较少的浏览器本地化将拥有较少的可用偏好字符串，因为在使用较少见的本地化时，识别不常见浏览器的用户所需的惊异度比特数将更低。

#为什么指纹识别缓解在此上下文中如此重要？

1. 指纹识别缓解通常是种最佳实践
2. 我们通过此机制揭示的特定数据可能是敏感的，因为它可能表明用户是边缘化或受威胁身份类别的成员
3. 我们通过此机制揭示的特定数据是特定于用户的，而不是他们的设备，因此可用于跨设备跟踪
4. 由于数据是从操作系统设置中读取的，用户可能没有意识到他们正在发送它