获取已安装相关应用 API

社区组报告草案,

本版本:
https://wicg.github.io/get-installed-related-apps/spec/
问题跟踪:
GitHub
规范内联
编辑者:
(Google)

摘要

Get Installed Related Apps API 允许 Web 应用检测当前设备上是否安装了相关应用。

本文档状态

本规范由 Web 平台孵化器 社区组发布。 它不是 W3C 标准,也不在 W3C 标准轨道上。 请注意,根据 W3C 社区 贡献者许可协议 (CLA),存在有限的退出权,并适用其他条件。 了解更多关于 W3C 社区和商务组的信息。

1. 引言

随着 Web 能力的增长,Web 应用的功能开始与相应原生应用的功能相匹配。用户在同一设备上同时安装 一个 Web 应用和相应原生应用的情况将变得更加常见,并且这些应用的功能集将会趋同。

允许网站检测某个应用是否已安装(无论是原生应用还是 Web 应用)非常重要,这样它们就可以 禁用应由另一个应用提供的功能。

1.1. 示例

const installedApps = await navigator.getInstalledRelatedApps();
const nativeApp = installedApps.find(app => app.id === 'com.example.myapp');

if (nativeApp && doesVersionSendPushMessages(nativeApp.version)) {
  // 有一个已安装的原生应用负责发送推送消息。
  // 不需要执行任何操作。
  return;
}

// 创建一个推送订阅。

在上面的示例中,doesVersionSendPushMessages 是一个由开发者定义的函数。

2. 隐私考虑

此 API 仅在安全的顶级上下文中启用。这确保网站不能被伪造,并且站点与应用之间的关联是有效的。

Web 应用与其对应应用之间的关联是双向的,这意味着 Web 应用必须声明它与相关应用的关联, 并且相关应用也必须声明它与该 Web 应用的关联。这可以防止恶意网站对用户进行指纹识别, 并获取他们已安装应用的列表。

用户代理可以限制要匹配的相关应用数量,以限制指纹识别。

用户代理在隐私保护模式下运行时不得返回已安装的应用,例如 Chrome 中的无痕模式或 Firefox 中的隐私浏览模式。

3. 基础设施

3.1. 平台

平台是一个特定于 OS 的概念,用于将同一类别的应用组合在一起。 它由 USVString 表示。

一个 OS 具有已安装 应用,这是一个 映射,其中键为平台, 值为列表,列表项为已安装应用

3.2. 已安装应用

已安装应用表示安装在用户设备上的 应用。

已安装应用由以下内容组成:

已安装应用还具有一个关联的 平台

4. 算法

4.1. 匹配已安装应用

要为 relatedApp(一个 ExternalApplicationResource) 和 manifestURL(一个 URL匹配已安装 应用,运行以下步骤:
  1. platformrelatedAppplatform

  2. 如果已安装 应用[platform] 不存在,返回 null。

  3. installedApps已安装应用[platform]。

  4. installedApps 中的每个 installedApp

    1. 如果 relatedAppid 不等于 installedAppid,并且 relatedAppurl 不等于 installedAppid,则继续

    2. 如果存在,则令 minVersionrelatedAppmin_version, 否则为空字符串。

    3. 如果 minVersion 不是空字符串,且 minVersion 大于 installedAppversion,返回 null。

      注:“greater”是一个特定于平台的概念,用于 对应用版本进行排序。它不必是字典序。

    4. 如果存在,则令 fingerprintsrelatedAppfingerprints, 否则为空列表

    5. fingerprints 中的每个 fingerprint

      1. 如果 installedAppfingerprints包含 fingerprint,返回 null。

    6. 如果 installedApprelatedURLs包含 manifestURL,返回 null。

    7. 返回 installedApp

  5. 返回 null。

5. API

dictionary RelatedApplication {
    required USVString platform;
    USVString url;
    DOMString id;
    USVString version;
};

每个 RelatedApplication 表示一个已安装应用, 该已安装应用与从 WebAppManifest 提供的 ExternalApplicationResource 相匹配。

5.2. Navigator 的扩展

[Exposed=Window]
partial interface Navigator {
  [SecureContext] Promise<sequence<RelatedApplication>> getInstalledRelatedApps();
};
getInstalledRelatedApps() 方法在被 调用时,运行以下步骤:
  1. relevantBrowsingContext上下文 对象相关设置对象负责浏览上下文

  2. 如果 relevantBrowsingContext 不是顶级浏览上下文,则返回一个以 InvalidStateError DOMException 拒绝的 promise。

    是否 应移除此限制?(#11

  3. promise一个新的 promise

  4. 并行地运行以下步骤:

    1. manifestmanifestURL获取 manifest 的结果。如果失败,则以一个空列表resolve promise,并中止这些步骤。

    2. relatedApplicationsmanifestrelated_applications

    3. 可选地:

      1. maxRelatedApps 为用户代理确定的数字。

      2. 如果 relatedApplications大小大于 maxRelatedApps,则将 relatedApplications 截断为 maxRelatedApps大小

      注:这会限制网站能够知道多少个原生应用已安装。 额外项目需要被截断,以便每次都返回相同的 ExternalApplicationResource

    4. installedApps 为空列表

    5. relatedApplications 中的每个 relatedApplication

      1. matchedApp 为使用 relatedApplicationmanifestURL 运行匹配 已安装应用所得的结果。

      2. 如果 matchedApp 为 null,则继续

      3. installedApp 为一个新的 RelatedApplication, 其具有:

        platform

        relatedApplicationplatform

        url

        relatedApplicationurl

        id

        relatedApplicationid

        version

        matchedAppversion

      4. installedApp追加installedApps

    6. installedAppsresolve promise

  5. 返回 promise

一致性

文档 约定

一致性要求通过描述性断言 和 RFC 2119 术语的组合来表达。 本文档规范性部分中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、 “MAY” 和 “OPTIONAL” 应按 RFC 2119 中所述进行解释。 但是,为了可读性, 这些词在本规范中并不全部以大写字母出现。

本规范的所有文本均为规范性内容, 明确标记为非规范性的章节、示例和注释除外。 [RFC2119]

本规范中的示例以 “for example” 这样的词语引入, 或者通过 class="example" 与规范性文本区分开, 如下所示:

这是一个资料性示例的例子。

资料性注释以 “Note” 一词开头, 并通过 class="note" 与规范性文本区分开, 如下所示:

注:这是一个资料性注释。

一致性 算法

作为算法一部分以祈使句表述的要求 (例如 “strip any leading space characters” 或 “return false and abort these steps”) 应按引入该算法时所使用的关键词 (“must”、“should”、“may”等) 的含义进行解释。

以算法或具体步骤表述的一致性要求 可以以任何方式实现, 只要最终结果等价即可。 特别是,本规范中定义的算法 旨在易于理解, 而非旨在高性能。 鼓励实现者进行优化。

索引

本规范定义的 术语

通过引用定义的 术语

参考文献

规范性参考文献

[APPMANIFEST]
Marcos Caceres; et al. Web Application Manifest. 2021 年 3 月 5 日。WD。URL: https://www.w3.org/TR/appmanifest/
[DOM]
Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]
S. Bradner. 用于 RFC 中表示要求级别的关键词。1997 年 3 月。 Best Current Practice。URL: https://tools.ietf.org/html/rfc2119
[URL]
Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
[WebIDL]
Boris Zbarsky. Web IDL. 2016 年 12 月 15 日。ED。URL: https://heycam.github.io/webidl/

IDL 索引

dictionary RelatedApplication {
    required USVString platform;
    USVString url;
    DOMString id;
    USVString version;
};

[Exposed=Window]
partial interface Navigator {
  [SecureContext] Promise<sequence<RelatedApplication>> getInstalledRelatedApps();
};

问题索引

是否应移除此限制?(#11