大家好,我叫依查。
最近小编一直在关注谷歌官方浏览器。 就在前段时间,谷歌团队正式发布了历经六年磨练的浏览器。 它利用现代 GPU 的计算能力来加速图形和计算,并允许在 Web 上提供高性能 3D 图形和数据。 并行计算。 当时业界一片哗然——大新闻!谷歌正式发布
这次接连发布了113和114两个版本,都提到了访问方式的变化:
113 首方套装
114:独立分区(CHIPS)
为什么小编特意把上面两张官方图剪掉了呢? 因为这两项都是对接入方式的重大调整,为了应对三方即将全面放弃。 两年前就打算彻底弃用Fang,因为这个改动对现在的网站影响很大。 如果直接弃用,可能会导致大量网站的正常功能无法运行。
另外,也会对自身的广告业务造成非常大的影响,所以不得不一拖再拖,才能推出不会对现有业务造成很大影响的解决方案,保证顺利迁移的用户,保护用户的隐私。 。
目前看来,随着第一方设置和独立分区能力的稳定引入,彻底禁用第三方的日子似乎已经不远了。 这两个改变确实可以解决大部分平时使用第三方的业务场景,但是读取方式可能需要大调整。
今天小编就带大家提前解读一下这两项重大调整。 大家也必须提前准备好迁移和应对策略,以确保未来第三方被禁用后网站能够避免受到影响。
首先了解如何生成、分类、使用、生命周期
有两种生命周期,一种是整个会话,另一种是永久的。 换句话说,一个是暂时的。 如果用户关闭浏览器,这个就失效了。 一种是永久的,可以继续存在。 一般来说,网站分析工具使用后者。
一千个字也无法用一张完整的图来解释:
第一方和第三方的区别
属于一方还是三方只取决于两个因素:
第一方和第三方都是网站在客户端存储的小块数据。 它们都存储在某个域中,并且只能由该域访问。 它们之间的区别其实不是技术上的区别,而是使用上的区别。
比如访问本网站时,本网站通过set-设置了1,只能被该域名下的网页读取。 这是第一次聚会。
如果您仍然访问该网站,网页中会有该网站的图片。 浏览器请求图片的时候,通过set-设置了一个,那么这个只能这个域访问,但是不能被这个域访问,因为对于我们来说,访问这个网站的时候,其实是设置在一个域下的,所以称为第三方。
第一方优势及应用
第一方最大的优势就是接受率高。 一般主流浏览器都会有隐私设置,允许用户设置是否接受以及接受哪些。
除了根本不接受这个设置之外,其他情况下,第一方都会被用户接受(如果不接受的话,那一小块数据是没有办法保存的)。
因此,如果没有特殊要求,使用第一方会比第三方更准确,我们通过分析工具得到的数据也会更准确。
第三方的优势及应用
第三方的接受率不如第一方(不过主流浏览器默认也接受带有P3P协议的第三方,我的经验是接受率可以达到90%甚至95%以上),但是在一些具体情况 在这种情况下,可以实现甲方无法实现的功能。
例如,当我们有多个域名的网站需要跟踪时,我们希望知道用户点击一个广告到达A域名下的网页,然后浏览任意域名下的页面,最后完成B. 条件:在网页上注册域名。 A域名下的网页可以追踪广告,B域名下的网页可以追踪注册。
如果我们使用第一方,我们会为域名A创建一个,为域名B创建另一个。它们可以关联各自域名下网页上的行为,但它们不能关联。 使用第三方的时候,无论有多少个域名,都只有一个,一个属于第三方域名。 网站下的所有域都可以共享此信息,所有行为都可以关联和分析。
三方到底出了什么问题?
我们的网站不可能只调用同一个网站域名的接口。 调用其他域名的接口很正常,所以三方也很正常。 我们也利用三方来满足很多正常的需求拦截谷歌浏览器广告插件,比如日志管理、单点登录等。 、广告转化分析等。那为什么要禁止呢? 主要是因为用户隐私问题。
例如,我们目前在抖音上观看视频,但抖音经常会加载很多来自第三方广告商的请求。 这些第三方广告商可以通过第三方记录一些用户行为。 那么下次你访问淘宝的时候,你可能会再次加载到这个广告商,因为这个时候第三方广告已经通过第三方记录了你很多的用户行为,已经知道你喜欢什么,所以你会收到一些准确信息。 广告推送,你的隐私已在无形中被泄露。
在国外,保护用户隐私是一件非常正确的事情,所以两大浏览器都被迫禁用了第三方。 也就是说,如果你在这两个浏览器上访问这个网站,那么就发送这个域名的请求。 是不能种植的。
目前仅剩一人还在苦苦支撑。 毕竟现在浏览器市场份额是最大的,直接禁止它老大的广告业务也会产生巨大的影响。 因此,我们需要等待大家都能接受的替代方案出现后再禁用它。
为了增强在线隐私,浏览器供应商正在计划或已经实施了对跨站点跟踪的限制。 这包括逐步取消对向顶级文档站点以外的站点发送请求的第三方的支持,从而使服务器能够跟踪不同顶级站点之间的用户行为。
之前:浏览器访问,它有一个可以设置的嵌入框架。 当浏览器导航到时,框架可以访问上的设置。
您可能会遇到问题的两种情况
对于我们普通开发者来说,其实有很多场景可能会受到影响,我们在禁用之前必须做出相应的改变,比如下面两个场景。
三方
第一种情况是我们需要与三个嵌入方共享状态。 假设我们现在开发一个通用的聊天服务,它的域名是.chat.,我们有很多商业网站(比如.)想通过这种方式嵌入这个聊天框。 嵌入式聊天服务可能依赖于保存用户交互的历史记录。 因为我们嵌入的域名和当前网站都属于第三方,所以我们种植的东西也属于第三方。
如果无法设置跨站点第三方,我们的聊天服务.chat。 可能需要更多地依赖父站点来主动将一些标识符传递到其第一方会话。 由于此类聊天服务通常是通用的,因此每个网站都嵌入了 .chat。 聊天服务需要额外的设置来传递状态,这大大增加了开发和接入成本。
或者,我们可能会在我们的网站页面上允许聊天服务.chat.。 但这会带来很大的安全风险,并不是一个可靠的方法。 您可能遇到的类似场景包括:
第三方网站
还有一种情况,根据不同的域名来定义第三方有点太狭隘了。 毕竟,一家公司不能只有一个域名:
比如我们上面提到的,虽然抖音和抖音的域名不同,也都叫三方,但是明眼人都可以看出,抖音属于字节,这两个域名属于同一个家族。
如果三方被禁用,则无法使用公司不同域名下的正常共享能力,这将对正常业务需求产生很大影响。 一个常见的场景是单点登录。 我们常常在登录一个公司的不同网站时只需要登录一次。 这是因为用户的个人信息存储在公共登录服务上。 如果禁用第三方,则无法共享登录信息。 下面我们就来看看如何解决以上两个问题。
独立分区(CHIPS)
首先我们看114默认为所有用户启用的独立分区(CHIPS),它是用来解决三方共享状态的问题的。
如何解决问题?
(CHIPS) 具有独立的分区状态,允许开发人员选择“分区”存储,每个顶级站点都有单独的 jar。
官方是这样描述的:CHIPS是帮助服务顺利过渡到没有第三方的未来的重要一步。
CHIPS 引入了一个新属性: ,它允许顶级上下文决定要分区的内容。
比如我们在A站点嵌入一个站点C,一般情况下,如果第三方被禁用拦截谷歌浏览器广告插件,C站点就无法访问A站点。
如果 C 上指定了属性,则会将其保存在特殊的分区 jar 中。 只有当A站点嵌入C站点时才会生效,并且浏览器会确定只有顶级站点是A时才会发送。
当用户访问一个新站点时,例如站点B,如果它还嵌入了站点C,则站点B下的站点C无法访问之前在站点A下设置的站点。
如果用户直接访问C站点,则无法访问该站点。
这样就解决了三方共享的问题,同时保护了用户隐私。
如何使用?
实现也非常简单。 上面说了,如果想保留当前网站需要共享的三方,只需要在种这个的时候添加一个属性即可。 另一个先决条件是您必须具有属性:
Set-Cookie: name=ConardLi; SameSite=None; Secure; Path=/; Partitioned;
实施细节
该属性实际上改变了存储分区的机制,使分区更加严格。 在上面的示例中,我们在页面上嵌入了一个。 启用之前,分区的唯一标识符为:.chat.,启用后,分区的唯一标识符变为(“https”,“.”)+.chat.。
在其ETP严格模式和隐私浏览模式下,默认对所有第三方进行分区,因此所有跨站点都会默认按照顶级站点进行分区。 但是,在没有第三方选择加入的情况下进行分区可能会导致一些意想不到的问题,因为在某些情况下也可能会使用未分区的第三方。
之前也尝试过一些分区机制,但最终都被放弃了。 目前,三方已被彻底封锁。 原因之一是开发人员可能会感到困惑。 。 但现在看来,一些分区的实验又开始了。
目前我觉得提供的启发式划分思想还是蛮有用的。 不仅解决了跨站追踪的问题,也在一定程度上满足了用户的需求。 希望其他浏览器可以借鉴。
第一方套装
上面我们解决了三方状态共享的问题,而下面我们提到的First-Party Sets就是用来解决自定义集合的问题的,也就是说它提供了一种有选择的将一些从三方改为一方的方式。
如何解决问题?
正如我们前面提到的,很多组织或公司都会有多个域名,因此仅仅使用不同的域名来区分属于第一方还是第三方是过于严格的。
First-Party Sets相当于给了网站开发者一个机会。 虽然有些是基于域名的第三方,但您可以选择指定其中一些并将它们放在一个集合中。 此集合中的所有三方都可以按照一种特殊的形式来阅读。
换句话说,虽然这两个域名属于同一个组织,但是你可以通过将它们放在一个集合中来判断这些不同的域名属于同一个组织。
如何使用?
根据上述解题思路,实现First-Party Sets需要两个步骤:
在早期的提案中,添加了一个新属性。 可以通过这个属性告诉浏览器哪些需要三方共享,然后共享的域名集合需要放到网站的部署目录下。
不过这个方法的限制有点太宽松了。 网站又可以轻松实现三方共享,且共享策略不够透明。 因此,决定放弃这个解决方案,实现更复杂的方法。
首先,你需要给出一个JSON文件,并在这个文件中声明哪些域名需要共享。 然后你需要通过 Pull 将这个 JSON 文件提交到提供的仓库:
并且JSON文件的格式必须符合规范。 这是一个例子:
{
"primary": "https://primary.com",
"associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com", "https://associate4.com"],
"serviceSites": ["https://servicesite1.com"],
"rationaleBySite": {
"https://associate1.com": "An explanation of how you clearly present the affiliation across domains to users and why users would expect your domains to be affiliated",
"https://associate2.com": "An explanation of how you clearly present the affiliation across domains to users and why users would expect your domains to be affiliated",
"https://associate3.com": "An explanation of how you clearly present the affiliation across domains to users and why users would expect your domains to be affiliated",
"https://serviceSite1.com": "An explanation of how each domain in this subset supports functionality or security needs."
},
"ccTLDs": {
"https://associate1.com": ["https://associate1.ca", "https://associate1.co.uk", "https://associate1.de"],
"https://associate2.com": ["https://associate2.ru", "https://associate2.co.kr", "https://associate2.fr"],
"https://primary.com": ["https://primary.co.uk"]
}
}
这里面有几个关键概念:
提交 PR 后,团队会在每周二中午 12 点手动合并这些 PR。 (不知道团队在这里是怎么想的……等以后网站多了,每天肯定会有很多PR,这种维护方式真的可行吗??)
你的JSON配置被团队合并后,并不意味着你可以随意分享给这些域名下的三方。 您还需要使用特殊的 API (SAA)。 这是一个演示代码:
#!/第一方集
让我们来分解一下。 首先判断浏览器是否支持该API:
/*
* 通过 UA 判断浏览器版本
*/
if (navigator.userAgentData.brands.some(b => { return b.brand === 'Google Chrome' && parseInt(b.version, 10) >= 108 })) {
// Supported
} else {
// Not supported
}
/*
* 判断 SAA 和 rSAFor API 是否可用
*/
if ('requestStorageAccess' in document) {
// SAA available
} else {
// SAA not available
}
if ('requestStorageAccessForOrigin' in document) {
// rSAFor available
} else {
// rSAFor not available
}
判断用户是否授予第三方访问权限并访问所有可读取的内容:
if ('requestStorageAccess' in document) {
document.requestStorageAccess().then(
(res) => { console.log('权限请求通过', res) },
(err) => { console.log('拒绝', err) }
);
}
通过以下方式读取指定域名下共享的三方:
if ('requestStorageAccessForOrigin' in document) {
document.requestStorageAccessForOrigin('https://first-party-sets.glitch.me');
location.reload();
} else {
window.alert('document.requestStorageAccessForOrigin not enabled.');
}
终于
一台电脑,一个键盘,智慧生活; 几行数字,几个字母,精心书写生活的美好;
一个灵感、一个方案,推动科技进步,推动社会发展。
创作并不容易。 如果您喜欢,请关注、点赞、打赏。 我们会不时更新有用的信息和技术相关信息。 请速速收藏。 谢谢你! 您的一个小举动,是对小编的认可,也是创作的动力。
版权保护: 本文由 浏览器之家-浏览器下载,浏览器插件,浏览器教程 原创,转载请保留链接: /gugelanqi/8522.html
- 上一篇: 谷歌浏览器控件加载失败解决办法
- 下一篇: 取代某雷、替代IDM,这款下载器免费且速度还很快