Web技术

Post Message API的替代方案

Channel Messaging API是PostMessage API的一个非常好的替代方案，具有某些优势，如速度和易用性。因此，如果您想跨上下文传输大型JavaScript对象，您可能需要考虑使用Channel Messaging API。如果你想看的话，我有一篇很好的文章和一个演示。

将数据从一个上下文发送到另一个上下文

使用JavaScript，您可以在上下文（即主窗口）之间向iframe传递数据，反之亦然。如果您的主窗口打开了一个新选项卡，您可以将数据从主窗口发送到新选项卡，即使用postMessage（）和Channel Messaging API进行跨窗口通信和数据传输。在这篇文章中，我们将只讨论postMessage API。

让我们现实一点——一些上下文之间交流的例子和所有可能的上下文列表

1.从父窗口向子iframe发送数据：

让我们看看如何将一些数据从父窗口发送到子iframe。

目录

实验：这是一项实验技术
在生产中使用之前，请仔细检查浏览器兼容性表。

fencedframe API提供了用于控制<fencedframe>元素中嵌入的内容的功能。

概念和用法

网络上隐私和安全问题的一个主要来源是嵌入<iframe>元素中的内容。历史上，<iframe>被用于设置第三方cookie，该cookie可用于跨站点共享信息和跟踪用户。此外，<iframe>中嵌入的内容可以与其嵌入文档进行通信（例如，使用Window.postMessage（））。

嵌入文档还可以使用脚本从<iframe>中读取各种形式的信息——例如，从src属性中读取嵌入的URL可能会获得重要的跟踪/指纹数据，尤其是当它包含URL参数时。<iframe>还可以访问嵌入上下文的DOM，反之亦然。

大多数现代浏览器都在研究对存储进行分区的机制，这样cookie数据就不能再用于跟踪（例如，请参阅cookie具有独立分区状态（CHIPS）或Firefox状态分区）。

安全上下文：此功能仅在安全上下文（HTTPS）、某些或所有支持的浏览器中可用。

凭证管理API使网站能够创建、存储和检索凭证。凭证是使系统能够做出身份验证决定的项目：例如，决定是否将用户登录到帐户。我们可以将其视为用户向网站提供的一项证据，以证明他们真的是他们所声称的那个人。

概念和用法

中心接口是CredentialsContainer，它可以通过navigator.credentials属性访问，并提供三个主要功能：

• create（）：创建一个新凭据。
• store（）：在本地存储一个新凭据。
• get（）：检索一个凭据，然后可以使用该凭据登录用户。

API支持四种不同类型的凭证，它们都表示为凭证的子类：

网站包含几种不同类型的信息。其中一些是非敏感的，例如公共页面上显示的副本。其中一些是敏感的，例如客户用户名、密码和银行信息，或者内部算法和私人产品信息。

敏感信息需要得到保护，这是网络安全的重点。如果这些信息落入坏人之手，可能会被用来：

• 通过与竞争对手共享信息，使公司处于竞争劣势。
• 禁用或劫持他们的服务，再次导致他们的操作出现严重问题。
• 将客户的隐私置于危险之中，使他们容易受到分析、定位、数据丢失、身份盗窃甚至经济损失的影响。

现代浏览器已经有几个功能来保护用户在网络上的安全，但开发人员也需要谨慎地采用最佳实践和代码，以确保他们的网站是安全的。即使是代码中的简单错误也会导致漏洞，坏人可以利用这些漏洞窃取数据并控制他们没有授权的服务。

本文介绍了网络安全，包括有助于您了解网站易受攻击的方面以及如何保护网站的信息。

安全与隐私的关系

安全和隐私是不同的主题，但它们也密切相关。了解两者之间的区别以及它们之间的关系是值得的。

本文解释了什么是第三方cookie，描述了与它们相关的问题，并解释了如何解决这些问题。

什么是第三方cookie？

cookie与特定的域[domain ]和方案[scheme ]（通常为https）相关联，如果设置了“设置cookie域”属性，则也可能与子域相关联。

• 如果cookie域和方案与用户正在查看的当前页面（浏览器地址栏中显示的URL）匹配，则cookie被认为与页面来自同一网站，并被称为第一方cookie。
• 如果域和方案不同，则cookie不被视为来自同一网站，并被称为第三方cookie。

注意：第三方cookie有时被称为跨站点cookie。这可以说是一个更准确的名称，因为第三方cookie意味着第三方公司或组织的所有权。然而，无论您是否拥有所有相关网站，行为和潜在问题都是相同的。例如，一个网站可能会访问来自其拥有的不同域的资源，例如图像。

当用户第一次访问页面、跟随到同一网站上的另一页面的内部链接或请求驻留在同一网站的资源（例如，嵌入式图像、网页字体或JavaScript文件）时，可以设置第一方cookie。

Web开发人员可以使用多种技术将数据存储在用户的浏览器中（即，存储在用户用于查看网站的设备的本地磁盘上）。

浏览器允许网站存储的数据量以及在达到该限制时删除数据的机制因浏览器而异。

本文介绍了可用于存储数据的网络技术，浏览器限制网站存储过多数据的配额，以及它们在需要时删除数据的机制。

浏览器如何将数据从不同的网站中分离出来？

浏览器将来自网站的数据存储在不同的地方，也称为bucket，以降低用户在网络上被跟踪的风险。在大多数情况下，浏览器按每个来源【per origin】管理存储的数据。

因此，术语起源对于理解这篇文章非常重要。源由方案（如HTTPS）、主机名和端口定义。例如，https://example.com和https://example.com/app/index.html属于同一个源，因为它们具有相同的方案（https）、主机名（example.com）和默认端口。

Web存储API提供了一些机制，浏览器可以通过这些机制以比使用cookie更直观的方式存储密钥/值对。

概念和用法

Web存储中的两种机制如下：

• sessionStorage为每个给定的源维护一个单独的存储区域，该存储区域在页面会话期间可用（只要浏览器选项卡打开，包括页面重新加载和恢复）。
• localStorage也做同样的事情，但即使浏览器关闭并重新打开，它也会持续存在。

这些机制可通过Window.sessionStorage和Window.localStorage属性获得。调用其中一个将返回存储对象的实例，通过该实例可以设置、检索和删除数据项。会话存储和本地存储分别使用不同的存储对象作为每个源——它们分别起作用并受控制。

要了解使用API的可用存储量，以及超过存储限制时会发生什么，请参阅存储配额和驱逐(Storage quotas and eviction criteria.)标准。

共享Web标识

网络的身份模型包含了两种交互浏览器功能的隐含结果：

• 每个域的状态，尤其是cookie，它使eTLD+1能够保持访问者身份的一致性。由于3p cookie、iframe中的存储等原因，此身份扩展到顶级网站。
• 在浏览器中，在网页上共同出现的各方之间传递信息（通过DOM或JS中的共享状态、HTTP重定向或postMessage等机制）。

这种组合导致了广泛共享的跨站点身份，从而实现了对个人浏览活动进行全网跟踪的能力。全局静态标识符（如设备指纹识别，或由浏览者提供或秘密获取的PII）也提供了一条通往全局身份的独立路径。对cookie、指纹识别和其他浏览器状态的限制都旨在降低创建或访问全局身份的能力。

一方面，全球身份产生了将一个人的大部分浏览历史记录编织在一起的能力，这是当今网络的核心隐私问题。浏览器可以通过对暴露给开发人员的底层功能施加限制来对这个问题采取行动。另一方面，全球身份在当今的网络广告生态系统中也发挥着重要作用。如果浏览器没有满足生态系统的合法需求，那么对这些技术能力施加限制的浏览器可能会直接影响出版商的经济生存能力（更多细节！）并鼓励变通办法。

饼干最好是新鲜的，那么有什么最新的食谱可以确保你仍然可以在没有任何变质饼干的情况下享受诡异的季节呢？

我们正在逐步淘汰网络平台上的第三方cookie。这是解决跨站点跟踪问题的一个重要里程碑，但这是相当漫长的旅程的一部分。让我们来看看我们已经走了多远，未来会有什么美食…

从表面上看，cookie提供了一个在浏览器和服务器之间发送的简单键值存储。这可以在网站上提供有用的功能，例如保存首选项：theme=bats或存储已登录用户的会话ID。