一个新的HTTP规范建议消除令人讨厌的“饼干横幅”

2018年通过的欧洲联盟＆＃39;常规数据保护条例（GDPR）需要网站在放置饼干之前要求访客同意。由于任何互联网用户现在都意识到，这意味着在每次第一次或潜在的时候访问几乎任何网站时所需的额外步骤，如果您选择不接受cookie。来自您的企业和可持续计算实验室的新提出的HTTP标准将允许用户在浏览器本身内部设置其隐私首选项，并且浏览器与用户访问的任何网站无形地将这些偏好通信。

所提出的标准启用了两种自动偏好传递方法 - 其中直接与托管访问的网站的Web服务器通信，另一个与网站本身通信。

当ADPC直接与Web服务器通信时，它通过HTTP标头 - 将链路标头指向服务器上的JSON文件，用户＆＃39浏览器发出的ADPC标题。当与网站本身通信时，该机制通过JavaScript - 配置将作为对象传递给DOM接口，例如Navigator.DataProtectionControl.request（...）。

在任何一种情况下，用户＆＃39; s的隐私首选项将传送到网站或服务器作为他们同意的请求标识符列表。此列表是在ADPC标题中发送的，以获取基于HTTP的方法，并作为JavaScript方法中DOM接口的最终返回值。

虽然这两个机制都以类似的方式实现了相同的目标，但有很多原因支持两者。基于HTTP的方法可能更有效 - 但它显然需要新版本的Web服务器应用程序，该网页服务器应用程序明确地支持它（或者至少是新的可插拔模块，就像支持它们的Apache等服务器的情况下）。同时，基于JavaScript的机制在没有任何特殊的Web服务器配置的情况下 - 但它为拒绝启用Javascript的用户而赢得＆＃39;

JSON文件位于网站的核心＆＃39; adpc的末端，无论是使用HTTP或JavaScript机制到达它。该同意文件将看起来像这样：

{ ＆＃34;同意咨询＆＃34 ;: { ＆＃34; cookie＆＃34 ;:＆＃34;存储和/或访问您的设备上的cookie。＆＃34 ;, ＆＃34; ADS_Profiming＆＃34 ;:＆＃34;创建一个个性化的广告配置文件。＆＃34; } }

在基于HTTP的ADPC中，WebServer将直接链接到同意文件，以其对HTTP获取的响应：

当Web浏览器检测到此链接时，它可以通过先前用户配置的设置响应或通过弹出对话框请求从用户的答案（最有可能，从浏览器＆＃39生成一个锁定按钮）。一旦用户相应地设置了他们的偏好，浏览器在将来的HTTP GET请求上包含一个ADPC头：

在上面的示例中，我们看到类似于网络防火墙在网络防火墙上看到的配置：默认拒绝以撤回= *，通过特定接受cookie覆盖。因此，对于我们想要设置cookie并创建广告配置文件的网站，授予Cookie请求（允许存储，例如用户身份验证和个人设置），但拒绝广告配置文件。

ADPC方案的另一个好处是用户与自己的浏览器交互，无论网站如何，都有一致的UI。另一个好处是用户可以为用户设置持久的偏好而不需要允许cookie - 这是一个必须通过嵌入网页本身嵌入的横幅询问同意的东西的东西。

最后，Cookie横幅可能经常在我们的测试中显示，流行的广告阻挡插件阻止了许多饼干横幅的显示，包括但不限于监护人＆＃39; s。这种阻塞可能是由于由过于激进的块规则或故意最小化的抵消损坏，以最小化＆＃34;点击疲劳。＆＃34;在任何一种情况下，他们都可以防止用户直接表达同意或拒绝与隐私相关的问题。

重要的是意识到ADPC不是强制执行用户的机制＆＃39; s的隐私权概况 - 它只是一种符合欧盟遵守欧盟的正常化方式＆＃39; s gdpr和类似的方式其他地方的隐私法。

无论如何，无论如何，没有任何假设的ADPC标准的网站要求为用户创建一个广告配置文件，然后拒绝，然后创建该配置文件。但是，合法的网站可以要求同意更加机器可读，一致，较少的用户疲劳方式。

adpc仍然帮助用户处理忽略他们的用户的阴暗网站＆＃39; 偏好 - 在GDPR或其他诉讼，用户＆＃39; 偏好更有可能从自己的系统中记录和读取。 如果用户拒绝通过cookie横幅接受任何cookie，则无法保存它们所表达的首选项，并记录 - 但是ADPC首选项将是。 即使用户与cookie横幅交互接受cookie（但禁用广告分析），那种cookie也更有可能被误解＆＃34;清洁＆＃34; 由用户自己。 那和＃34;清洁＆＃34; 可以在寻求维护隐私甚至解决常见网站的问题。 由于ADPC偏好仅适用于在隐私问题上表达或拒绝同意 - 以来，因此他们被摧毁的原因要少得多。