跳转到主要内容

标签(标签)

资源精选(342) Go开发(108) Go语言(103) Go(99) angular(82) LLM(75) 大语言模型(63) 人工智能(53) 前端开发(50) LangChain(43) golang(43) 机器学习(39) Go工程师(38) Go程序员(38) Go开发者(36) React(33) Go基础(29) Python(24) Vue(22) Web开发(20) Web技术(19) 精选资源(19) 深度学习(19) Java(18) ChatGTP(17) Cookie(16) android(16) 前端框架(13) JavaScript(13) Next.js(12) 安卓(11) typescript(10) 资料精选(10) NLP(10) 第三方Cookie(9) Redwoodjs(9) LLMOps(9) Go语言中级开发(9) 自然语言处理(9) 聊天机器人(9) PostgreSQL(9) 区块链(9) mlops(9) 安全(9) 全栈开发(8) ChatGPT(8) OpenAI(8) Linux(8) AI(8) GraphQL(8) iOS(8) 软件架构(7) Go语言高级开发(7) AWS(7) C++(7) 数据科学(7) whisper(6) Prisma(6) 隐私保护(6) RAG(6) JSON(6) DevOps(6) 数据可视化(6) wasm(6) 计算机视觉(6) 算法(6) Rust(6) 微服务(6) 隐私沙盒(5) FedCM(5) 语音识别(5) Angular开发(5) 快速应用开发(5) 提示工程(5) Agent(5) LLaMA(5) 低代码开发(5) Go测试(5) gorm(5) REST API(5) 推荐系统(5) WebAssembly(5) GameDev(5) CMS(5) CSS(5) machine-learning(5) 机器人(5) 游戏开发(5) Blockchain(5) Web安全(5) Kotlin(5) 低代码平台(5) 机器学习资源(5) Go资源(5) Nodejs(5) PHP(5) Swift(5) 智能体(4) devin(4) Blitz(4) javascript框架(4) Redwood(4) GDPR(4) 生成式人工智能(4) Angular16(4) Alpaca(4) SAML(4) JWT(4) JSON处理(4) Go并发(4) kafka(4) 移动开发(4) 移动应用(4) security(4) 隐私(4) spring-boot(4) 物联网(4) nextjs(4) 网络安全(4) API(4) Ruby(4) 信息安全(4) flutter(4) 专家智能体(3) Chrome(3) CHIPS(3) 3PC(3) SSE(3) 人工智能软件工程师(3) LLM Agent(3) Remix(3) Ubuntu(3) GPT4All(3) 软件开发(3) 问答系统(3) 开发工具(3) 最佳实践(3) RxJS(3) SSR(3) Node.js(3) Dolly(3) 移动应用开发(3) 编程语言(3) 低代码(3) IAM(3) Web框架(3) CORS(3) 基准测试(3) Go语言数据库开发(3) Oauth2(3) 并发(3) 主题(3) Theme(3) earth(3) nginx(3) 软件工程(3) azure(3) keycloak(3) 生产力工具(3) gpt3(3) 工作流(3) C(3) jupyter(3) 认证(3) prometheus(3) GAN(3) Spring(3) 逆向工程(3) 应用安全(3) Docker(3) Django(3) R(3) .NET(3) 大数据(3) Hacking(3) 渗透测试(3) C++资源(3) Mac(3) 微信小程序(3) Python资源(3) JHipster(3) 大型语言模型(2) 语言模型(2) 可穿戴设备(2) JDK(2) SQL(2) Apache(2) Hashicorp Vault(2) Spring Cloud Vault(2) Go语言Web开发(2) Go测试工程师(2) WebSocket(2) 容器化(2) AES(2) 加密(2) 输入验证(2) ORM(2) Fiber(2) Postgres(2) Gorilla Mux(2) Go数据库开发(2) 模块(2) 泛型(2) 指针(2) HTTP(2) PostgreSQL开发(2) Vault(2) K8s(2) Spring boot(2) R语言(2) 深度学习资源(2) 半监督学习(2) semi-supervised-learning(2) architecture(2) 普罗米修斯(2) 嵌入模型(2) productivity(2) 编码(2) Qt(2) 前端(2) Rust语言(2) NeRF(2) 神经辐射场(2) 元宇宙(2) CPP(2) 数据分析(2) spark(2) 流处理(2) Ionic(2) 人体姿势估计(2) human-pose-estimation(2) 视频处理(2) deep-learning(2) kotlin语言(2) kotlin开发(2) burp(2) Chatbot(2) npm(2) quantum(2) OCR(2) 游戏(2) game(2) 内容管理系统(2) MySQL(2) python-books(2) pentest(2) opengl(2) IDE(2) 漏洞赏金(2) Web(2) 知识图谱(2) PyTorch(2) 数据库(2) reverse-engineering(2) 数据工程(2) swift开发(2) rest(2) robotics(2) ios-animation(2) 知识蒸馏(2) 安卓开发(2) nestjs(2) solidity(2) 爬虫(2) 面试(2) 容器(2) C++精选(2) 人工智能资源(2) Machine Learning(2) 备忘单(2) 编程书籍(2) angular资源(2) 速查表(2) cheatsheets(2) SecOps(2) mlops资源(2) R资源(2) DDD(2) 架构设计模式(2) 量化(2) Hacking资源(2) 强化学习(2) flask(2) 设计(2) 性能(2) Sysadmin(2) 系统管理员(2) Java资源(2) 机器学习精选(2) android资源(2) android-UI(2) Mac资源(2) iOS资源(2) Vue资源(2) flutter资源(2) JavaScript精选(2) JavaScript资源(2) Rust开发(2) deeplearning(2) RAD(2)

category

隐私沙盒是一系列建议,旨在满足第三方使用情况,而无需第三方cookie或其他跟踪机制。

 

总结

 

  • 这篇文章概述了隐私沙盒提案中的API和概念。
  • 提案作者正在邀请社区的反馈,特别是广告领域的反馈(出版商、广告商和广告技术公司),以建议遗漏的用例,并分享如何支持您的商业用例的信息。
  • 您可以通过在下面链接的存储库中提交问题来对提案发表评论。
  • 在这篇文章的末尾有一个建议的词汇表。

网络隐私的当前状态


网站使用其他公司的服务来提供分析、提供视频和做许多其他有用的事情。可组合性是网络的超能力之一。最值得注意的是,广告是通过第三方JavaScript和iframe包含在网页中的。广告浏览、点击和转化通过第三方cookie和脚本进行跟踪。

然而,当你访问网站时,你可能不知道涉及的第三方以及他们对你的数据做了什么。即使是出版商和网络开发人员也可能不了解整个第三方供应链。

广告选择、转化率测量和其他用例目前依赖于建立稳定的跨站点用户身份。从历史上看,这是用第三方cookie完成的,但浏览器已经开始限制对这些cookie的访问。跨站点用户跟踪的其他机制的使用也有所增加,如隐蔽的浏览器存储、设备指纹识别和对电子邮件地址等个人信息的请求。

这对网络来说是一个两难的选择。在不允许跨站点跟踪用户的情况下,如何支持合法的第三方用例?

特别是,网站如何通过允许第三方显示广告和衡量广告表现来资助内容,但不允许对个人用户进行简介?广告商和网站所有者如何在不使用设备指纹等暗模式的情况下评估用户的真实性?

目前的工作方式可能会给整个网络生态系统带来问题,而不仅仅是用户。对于出版商和广告商来说,跟踪身份和使用各种非标准的第三方解决方案可能会增加技术债务、代码复杂性和数据风险。用户、开发者、出版商和广告商应该确信网络正在保护用户的隐私选择。

广告是互联网的核心网络商业模式,但广告必须对每个人都有效。这就引出了隐私沙盒的使命:创建一个繁荣的网络生态系统,尊重用户,默认情况下是私有的。

隐私沙盒介绍


Privacy Sandbox引入了一组隐私保护API,以支持在没有第三方cookie等跟踪机制的情况下为开放网络提供资金的商业模式。

隐私沙盒API要求web浏览器扮演一个新角色。API不是使用有限的工具和保护,而是使用户的浏览器代表用户在本地、设备上进行操作,以在用户浏览网络时保护用户的识别信息。API支持诸如广告选择和转换测量之类的用例,而不会泄露个人隐私和个人信息。从工程的角度来说,沙箱是一个受保护的环境;隐私沙盒的一个关键原则是,用户的个人信息应该受到保护,而不是以允许跨网站识别用户的方式共享。

这是浏览器方向的转变。Privacy Sandbox对未来的愿景是,浏览器提供特定的工具来满足特定的用例,同时保护用户隐私。潜在的网络隐私模型阐述了API背后的核心原则:

  • 建立用户浏览器可以让网站将一个人视为具有单一身份的网络活动范围。
  • 确定信息在不影响身份分离的情况下跨越身份边界的方式。

隐私沙盒建议


为了成功摆脱第三方cookie,隐私沙盒计划需要您的支持。提案解释者需要开发者、出版商、广告商和广告技术公司的反馈,以建议遗漏的用例,并分享如何以隐私安全的方式实现目标的信息。

您可以通过针对每个存储库提交问题来对提案解释者发表评论:


确定用户浏览器可以让网站将一个人视为具有单一身份的网络活动范围。确定信息在不影响身份分离的情况下跨身份边界移动的方式。

 


限制站点可以访问的潜在可识别数据的总量。更新API以减少显示的潜在可识别数据量。使对潜在可识别数据的访问变得可衡量。

 


限制通过访问单个用户的IP地址来识别其身份的能力。

 


启用信任用户的来源,以向其颁发由用户浏览器存储的加密令牌,以便在其他上下文中使用这些令牌来评估用户的真实性。

允许同一实体拥有的相关域名声明自己属于同一第一方。

提供隐私保护机制,以支持各种用例,如通过转换查看、品牌、提升和覆盖范围测量。

通过事件级和聚合报告提供对点击和浏览量的隐私保护测量。

启用基于兴趣的广告,而无需跟踪用户访问的网站。API的设计是根据我们早期FLoC试验的社区反馈进行的,并取代了FLoC提案。

提供了一个重新营销用例的解决方案,其设计使其不能被第三方用来跟踪用户跨网站的浏览行为。
您可以立即深入了解API提案的解释者,在接下来的几个月里,我们将单独发布关于每个提案的帖子。

我们还将添加到我们的五分钟视频播放列表中,对每个API进行简单解释。

用例和目标


度量值转换

 

  • 目标:使广告商能够衡量广告表现。

归因报告API允许测量两个链接在一起的事件:1。出版商网站上的事件,例如用户观看或点击广告1。广告商网站上的后续转换。

此API支持点击式和查看式测量。

此API中的其他功能包括跨设备归因报告和应用程序到web归因报告。

API还提供两种类型的归因报告:

  • 事件级报告将特定的广告点击或视图(在广告端)与转换端的数据相关联。为了保护用户隐私,通过防止用户身份跨站点加入,转换端数据非常有限,并且数据是“有噪声的”(意味着在一小部分情况下,发送随机数据)。作为额外的隐私保护,报告不会立即发送。
  • 聚合报告不与广告端的特定事件绑定。与事件级报告相比,这些报告提供了更丰富、保真度更高的转换数据。加密技术、信任分布和差异隐私的隐私技术相结合,有助于降低跨站点身份加入的风险。

两种报告类型都可以同时使用:它们是互补的。

归因报告介绍详细介绍了这些功能的状态以及如何尝试此API。

选择广告

  • 目标:使广告商能够显示与用户相关的广告。

相关广告对用户更有利,对出版商(运营广告支持网站的人)更有利可图。第三方广告选择工具使广告空间对广告商(在网站上购买广告空间的人)更有价值,这反过来又增加了广告支持网站的收入,并使内容能够被创建和发布。

有许多方法可以使广告与用户相关,包括以下几种:

  • 第一方数据:显示与一个人告诉网站他们感兴趣的主题相关的广告,或一个人以前在当前网站上看过的内容。
  • 上下文:根据网站内容选择显示广告的位置。例如,“把这个广告放在关于针织的文章旁边。”
  • 再营销:向已经访问过你的网站的人做广告,而他们不在你的网站上。例如,“向那些访问过你的商店并在购物车里留下针织物品的人展示这则折扣羊毛广告——而他们正在访问工艺网站。”
  • 基于兴趣:根据用户的浏览历史选择广告。例如,“向浏览行为表明他们可能对针织感兴趣的用户显示此广告”。

第一方数据和上下文广告选择可以在不知道用户在网站内的活动之外的任何其他信息的情况下实现。这些技术不需要跨站点跟踪。

再营销通常通过使用cookie或其他方式来识别网站上的用户:将用户添加到列表中,然后选择特定的广告来显示他们。

基于兴趣的广告选择目前使用cookie来跟踪尽可能多的网站上的用户行为。许多人担心广告选择对隐私的影响。隐私沙盒提出了两种选择,用于重新营销和基于兴趣的选择:

  • FLEDGE:用于重新销售用例。

API的设计使其不能被第三方用来跟踪用户的浏览行为:用户的浏览器,而不是广告商或广告技术平台,存储与用户的浏览器相关联的广告定义的兴趣组。用户的浏览器将兴趣组数据与广告买家/卖家数据和业务逻辑相结合,在用户的设备上本地进行“拍卖”以选择广告,而不是与第三方共享数据。

  • 主题API:面向基于兴趣的受众。

启用基于兴趣的广告,而无需跟踪用户访问的网站。API建议使用机器学习从主机名推断主题,并使用JavaScript API根据最近访问的网站的主机名返回用户当前可能感兴趣的粗粒度主题。

作战指纹

 

  • 目标:减少API显示的潜在可识别数据的数量,并使用户能够控制和可衡量地访问潜在可识别的数据。

浏览器已经采取措施弃用第三方cookie,但识别和跟踪个人用户行为的技术,即指纹识别,仍在不断发展。指纹使用用户不知道也无法控制的机制。

  • 隐私预算提案旨在通过识别JavaScript API或其他“表面”(如HTTP请求头)暴露的指纹数据量,并限制这些数据的访问量,来限制指纹识别的可能性。
  • 用户代理标头等指纹表面的范围将缩小,通过客户端提示等替代机制提供的数据将受到隐私预算限制。其他表面,如设备方向和电池级API,将进行更新,以将信息暴露在最低限度。

IP地址安全

 

  • 目标:控制对IP地址的访问,以减少隐蔽的指纹识别,并允许网站选择不查看IP地址,以免消耗隐私预算。

用户的IP地址是其计算机在互联网上的公共“地址”,在大多数情况下,该地址由用户连接到互联网的网络动态分配。然而,即使是动态IP地址也可能在相当长的一段时间内保持稳定。毫不奇怪,这意味着IP地址是指纹数据的重要来源。

Gnatcatcher提案试图提供一种隐私保护方法,避免消耗隐私预算,同时确保出于防止滥用等合法目的需要访问IP地址的网站可以这样做,但需经过认证和审计。

该提案分为两部分:*故意的IP盲为网站提供了一种方式,让浏览器知道他们没有将IP地址与用户连接起来。*近路径NAT允许用户组通过同一个私有化服务器发送流量,从而有效地向站点主机隐藏他们的IP地址。

打击垃圾邮件、欺诈和拒绝服务攻击

 

  • 目标:验证用户真实性,无需指纹识别。

反欺诈保护对于确保用户安全以及确保广告商和网站所有者能够获得准确的广告性能测量至关重要。广告商和网站所有者必须能够区分恶意机器人和真实用户。如果广告商不能可靠地判断哪些广告点击来自真人,他们就会减少支出,因此网站出版商获得的收入也会减少。许多第三方服务目前使用设备指纹等技术来打击欺诈。

不幸的是,用于识别合法用户和阻止垃圾邮件发送者、欺诈者和机器人的技术与破坏隐私的指纹技术类似。

  • Trust Tokens API提出了一种替代方法,允许在一个上下文(如社交媒体网站)中为用户建立的真实性被传递到另一个上下文,如在新闻网站上运行的广告,而无需识别用户或链接两个身份。

使域属于同一第一方

 

  • 目标:使实体能够声明相关域名归同一第一方所有。

许多组织拥有跨多个域的网站。如果在被视为“第三方”但实际上属于同一组织的网站之间对跟踪用户身份施加限制,这可能会成为一个问题。

第一方集合旨在通过允许多个域声明自己属于同一第一方,使网络对第一方和第三方的概念与现实世界的概念更加紧密地一致。


了解更多信息


隐私沙盒提案解释者


隐私沙盒计划需要您的支持。API提案解释者需要反馈,特别是建议缺失的用例和实现其目标的更私人的方法。


Web的潜在隐私模型列出了API的核心原则。

隐私沙盒


讨论和参与

用例、策略和要求


附录:提案解释者使用的术语表


点击率(CTR)【Click-through rate (CTR)】


点击广告并看过广告的用户比例。(另请参阅印象。)

点击转换(CTC)【Click-through-conversion (CTC)


归因于被“点击”的广告的转换。

转变


之前与广告商的广告互动过的用户在广告商的网站上完成的动作。例如,在点击链接到广告商网站的广告后,购买产品或注册时事通讯。

差异隐私


共享数据集的信息,以揭示行为模式,而不透露个人的私人信息或他们是否属于数据集。

领域


请参阅顶级域和eTLD。

eTLD,eTLD+1


“有效”顶级域由公共后缀列表定义。例如

co.uk
appspot.com
glitch.me


有效的TLD使foo.appspot.com成为与bar.appspot.com不同的网站。在这种情况下,有效的顶级域(eTLD)是appspot.com,整个网站名称(foo.appspot.com,bar.appspot.com)被称为eTLD+1。

另请参见顶级域。

熵【Entropy】


衡量一项数据在多大程度上揭示了个人身份。

数据熵是以比特为单位测量的。数据越能揭示身份,其熵值就越高。

数据可以组合起来识别一个人,但很难弄清楚新数据是否会增加熵。例如,如果你已经知道一个人来自袋鼠岛,那么知道他来自澳大利亚并不会减少熵。

指纹


识别和跟踪个人用户行为的技术。指纹使用用户不知道也无法控制的机制。

指纹表面


可以用来(可能与其他表面结合使用)识别特定用户或设备的东西。例如,navigator.userAgent()JavaScript方法和User-Agent HTTP请求标头提供对指纹表面(用户代理字符串)的访问。

第一方


来自您正在访问的网站的资源。例如,您正在阅读的页面位于网站web.dev上,并包含该网站的资源。另请参见第三方。

印象【Impression


广告视图(另请参阅点击率。)

K-匿名


数据集中的匿名性度量。如果你有k个匿名性,你就无法与数据集中的k-1个其他个体区分开来。换句话说,k个人拥有相同的信息(包括你)。

Nonce


仅在加密通信中使用过一次的任意数字。

起源


请求的来源,包括服务器名称,但没有路径信息。例如https://web.dev.

被动曲面


无论网站是否要求,每个网站都可以使用一些指纹表面,如用户代理字符串、IP地址和接受语言标头。这意味着被动表面可以很容易地消耗网站的隐私预算。

“隐私沙盒”倡议建议用主动的方式来获取特定信息,例如使用“客户端提示”一次性获取用户的语言,而不是为每个服务器的每个响应都设置一个接受语言标头。

出版商


隐私沙盒提案的解释者大多是关于广告的,因此所指的出版商是在其网站上投放广告的出版商。

达到【Reach


看到广告的总人数。

重新营销


向已经访问过您网站的人做广告。例如,在线商店可以向以前在其网站上看过玩具的人展示玩具销售广告。

地点【Site


请参阅顶级域和eTLD。

表面


请参见指纹表面和被动表面。

第三方


从与您访问的网站不同的域提供的资源。例如,网站foo.com可能使用来自google-analytics.com的分析代码(通过JavaScript)、来自use.typekit.net的字体(通过链接元素)和来自vimeo.com的视频(在iframe中)。另请参见第一方。

顶级域(TLD)


顶级域(如.com和.org)列在根区域数据库中。

请注意,有些“站点”实际上只是子域。例如,translate.google.com和maps.google.com只是google.com的子域(即eTLD+1)。

.well-known


在发出请求之前访问主机的策略或其他信息可能很有用。例如,robots.txt告诉网络爬虫要访问哪些页面以及要忽略哪些页面。IETF RFC8615概述了一种标准化的方法,使站点范围内的元数据可以在/.aknowledge/子目录中的标准位置访问。您可以在iana.org/assignments/wellknown-uris/well-known-uris.html上看到这些列表。

感谢所有帮助撰写和审阅这篇文章的人。

 

文章链接