Extension storage、Interest groups 和 Shared storage 简介-浏览器缓存之【隐私沙盒与扩展专用存储】

〇、前言

前文已经介绍了*,单击查看全部系列文章:缓存Storage,*那么本文再介绍另一新的类别:隐私沙盒与扩展专用存储。

隐私沙盒与扩展专用存储,涵盖 Extension storage、Interest groups 和 Shared storage。

  • Extension storage 专为浏览器扩展设计,支持跨会话持久化和同步;
  • Interest groups 用于广告相关场景,记录用户对特定内容的兴趣分组;
  • Shared storage 则允许不同源之间安全共享少量数据,用于跨站点的隐私保护型功能协作。这些存储机制均服务于特定生态或隐私合规需求,普通网页开发较少直接使用。

下面来详细介绍下。

一、什么是 Extension storage?

1.1 简介

浏览器扩展存储(Extension Storage)是一套专为扩展程序设计的数据存储方案,其核心优势在于能跨浏览器会话持久保存数据,并可选择性地在用户所有登录的设备间自动同步。它通过提供比网页标准存储更可靠、更强大的 API,解决了传统方式在扩展场景下的局限性。

首选 Extension Storage 的场景:在开发扩展时,应优先使用 chrome.storage API,而非 localStorage 或 Cookie,以确保数据的持久性和可靠性。

几个需要特别注意的点:

合理选择存储区域: 将需要跨设备同步的核心用户数据存入 sync,将大文件或纯本地数据存入 local,将临时数据存入 session。

遵守配额限制: 特别是对于 sync 存储,要精简数据,避免存储大量文本或二进制数据。

**做好错误处理:**异步操作可能失败(如配额超限),务必使用 try/catch 或检查回调中的 lastError 来妥善处理异常情况。

1.2 与传统存储的区别:为何扩展需要专属存储?

首先,Extension Storage 与网页常用的 localStorage 或 Cookie 有本质区别:

作用域与隔离性:localStorage 是基于网页域名(Origin)隔离的,一个域名无法访问另一个域名的数据。而 Extension Storage 是基于扩展程序本身隔离的,扩展内的所有部分(如:后台脚本、内容脚本、弹出页)都能直接、无缝地共享同一份数据。

持久化保障:这是最关键的区别。当用户清除浏览器历史或缓存时,许多浏览器(如:Firefox)会一并清除通过 localStorage 存储的扩展数据。而使用 Extension Storage 的 local 或 sync 区域存储的数据则会被保留,确保了用户设置和状态的可靠性。

操作方式:localStorage 是同步 API,操作会阻塞主线程。Extension Storage 则是异步 API(基于回调或 Promise),不会影响扩展的响应性能。

1.3 核心机制:三种存储类型

现代浏览器扩展(基于 Chromium 的 chrome.storage API)通常提供三种存储区域,以满足不同场景的需求:

存储类型 特点 用途
storage.local 本地永久保存 重启浏览器数据依然存在,直到扩展卸载或手动清除。 存储大量无需跨设备同步的本地数据,如缓存、日志、本地配置等。
storage.sync 同步存储 通过浏览器账户自动加密同步至所有登录设备;若未开启同步则退化为本地存储。 存储核心偏好设置、书签等需多端保持一致的关键数据。
storage.session 会话临时存储 仅在当前浏览器会话有效,数据存于内存,关闭所有窗口后自动清除。 存储无需长期保留的临时状态,如表单草稿、一次性令牌等。

1.4 工作原理与使用示例

Extension Storage 的工作流程非常直观:

1)声明权限:在扩展的 manifest.json 文件中声明 "storage" 权限。

2)调用 API:在扩展的 JavaScript 代码中,通过 chrome.storage (或 browser.storage for Firefox) 对象调用 get, set, remove, clear 等方法。

3)监听变化:可以通过监听 storage.onChanged 事件,在数据发生变化时执行相应逻辑。

以下是使用 storage.sync 存储和读取用户偏好的 JavaScript 代码示例:

复制代码
// 【存储数据(popup.js 或 background.js)】
// 使用 Promise 风格 (现代浏览器)
async function saveUserPreference(theme) {
  try {
    await chrome.storage.sync.set({ 'userTheme': theme });
    console.log('主题偏好已保存');
  } catch (error) {
    console.error('保存失败:', error);
  }
}
// 或者使用回调函数风格
function saveUserPreferenceWithCallback(theme) {
  chrome.storage.sync.set({ 'userTheme': theme }, function() {
    if (chrome.runtime.lastError) {
      console.error('保存失败:', chrome.runtime.lastError);
    } else {
      console.log('主题偏好已保存');
    }
  });
}

// 读取数据(popup.js, content-script.js 等)
async function loadUserPreference() {
  try {
    const result = await chrome.storage.sync.get(['userTheme']);
    const theme = result.userTheme || 'light'; // 默认值
    console.log('加载的主题偏好:', theme);
    return theme;
  } catch (error) {
    console.error('加载失败:', error);
    return 'light'; // 出错时返回默认值
  }
}

二、什么是 Interest groups?

2.1 简介

Interest groups(兴趣分组)是广告技术中的核心概念 ,它通过系统性地记录和分析用户对特定内容的兴趣,将用户划分为不同的群体,从而实现广告的精准投放。这本质上是一个将用户兴趣数据化、标签化并应用于营销的过程

兴趣分组其实就是基于兴趣的广告投放(Interest-Based Advertising)的基础。

其核心目的是通过分析用户的行为、偏好和人口统计学特征,将其归入不同的兴趣类别,以便广告商能够向最有可能对其产品或服务感兴趣的用户群体展示广告,从而提高广告的相关性和转化率

2.2 兴趣分组的运作机制:从数据到标签

兴趣分组的实现依赖于一套完整的用户画像构建体系,其运作流程如下:

1)数据来源:多渠道信息采集

平台通过多种渠道收集用户数据,以构建全面的用户画像。主要数据来源包括:

行为数据 :用户的点击、浏览、购买、收藏、搜索记录等。

人口学信息 :年龄、性别、地域、职业等。

社交数据 :在社交平台的互动、分享、评论等。

偏好数据:关注的品牌、产品类型、消费场景等。

2)标签构建:从数据到"兴趣分组"

收集到的原始数据会经过处理,最终形成"兴趣"标签。主要方式有:

统计类标签: 直接从数据中统计得出,如:"男性"、"25岁"、"北京"。

规则类标签: 基于预设规则生成,如:"近30天活跃天数>15"被定义为"活跃用户"。

**机器学习标签:**通过算法模型挖掘用户的潜在兴趣,例如:根据用户的长期行为预测其为"数码爱好者"。

3)分组应用:指导广告投放

**构建好的用户兴趣标签体系会直接应用于广告系统。**广告商在投放时,可以选择一个或多个"兴趣分组"作为目标受众。例如,一个运动品牌可以选择"户外爱好者"、"跑步爱好者"等分组进行定向广告投放。

2.3 主流广告平台的应用实例

不同的广告平台对"兴趣分组"有不同的实现方式和命名,以下是两个典型案例:

1)Google Ads:Affinity Segments(兴趣相似细分)

Google 通过分析用户跨网站、跨 App 的行为,将其归入约 150 个不同的兴趣相似细分中,如:"户外爱好者"、"美食家"、"科技早期采用者"等。

这些细分被组织在"生活方式与爱好"、"媒体与娱乐"、"技术"等大类下,供广告主选择,主要适用于品牌认知和用户获取阶段的广告活动。

2)Meta (Facebook/Instagram):Interest Targeting(兴趣定位)

Meta 会根据用户在平台上的互动(点赞、评论、分享、关注的主页等)为其分配成千上万个兴趣标签。

广告主在创建广告时,可以在"详细定位"中输入关键词来选择相关的兴趣标签。例如:为宠物用品店投放广告时,可以选择"狗"、"猫"、"宠物护理"等标签。

注意:出于隐私保护的考虑,Meta 已移除了部分敏感话题的兴趣标签,如:政治、宗教、性取向等。

2.4 两组概念的对比

基于兴趣的广告(Interest-Based)vs. 基于意图的广告(Intent-Based)

兴趣广告关注的是用户的长期偏好和身份(如"健身爱好者"),目的是在用户可能感兴趣但未必有即时购买需求时,进行品牌曝光和培育。

意图广告则关注用户的即时、短期行为(如搜索"附近健身房"),目的是捕捉用户当前的购买意向并促成转化。两者常结合使用,形成营销组合拳。

兴趣分组(Interest Groups)vs. 行为定向(Behavioral Targeting)

兴趣分组通常是行为定向的一个子集或高级形式。行为定向的范围更广,包含所有基于用户行为的定向方式,如:重定向(Retargeting)。兴趣分组更侧重于从行为中提炼出用户的稳定兴趣偏好。

2.5 隐私保护趋势下的挑战

随着全球对数据隐私的重视和法规(如GDPR、CCPA)的完善,基于广泛的用户数据收集来构建兴趣分组的模式正面临挑战。平台方正在探索新的解决方案,例如:

限制敏感数据使用,如:Meta 已移除部分敏感的兴趣标签。

发展隐私保护技术,如:利用联邦学习、差分隐私等技术,在不直接获取用户个人数据的情况下进行广告效果评估和定向。

依赖第一方数据,鼓励广告主使用自己的客户数据(如邮箱列表)进行精准定位和拓展。

"Interest groups"是连接用户兴趣与广告内容的关键桥梁,它是一个涉及数据采集、分析、标签化和应用的复杂系统。

在未来,如何在尊重用户隐私的前提下,更高效、更负责任地进行兴趣分组,将是广告技术发展的重要方向。

三、什么是 Shared storage?

Shared Storage 是一个在"后第三方 Cookie"时代探索中诞生的、旨在实现隐私保护型跨源数据共享的实验性技术。

然而,它最终未能成为主流方案,并已被其主要推动者 Google 官方弃用。因此,对于普通网页开发者而言,无需关心或学习这项技术

在当前和未来的开发中,您应该继续使用标准的 Web Storage(localStorage, sessionStorage)和 IndexedDB 来满足常规的客户端存储与缓存需求。

四、小小的总结

Extension storage:专为浏览器扩展设计 ,支持跨会话持久化与多设备同步,分为`local`(本地持久)、`sync`(同步核心数据)、`session`(临时存储)三种类型。开发扩展时优先使用,需注意权限声明、配额限制及异步错误处理,确保数据可靠性与扩展稳定性。

Interest groups:基于用户行为数据构建兴趣标签,将用户分组以实现精准广告投放 ,涉及数据采集、标签化及隐私合规挑战。随着隐私法规加强,未来将依赖隐私保护技术(如联邦学习)和第一方数据,逐步转型为更负责任的广告定向方案。

Shared storage:用于跨站点安全共享少量数据的实验性技术,聚焦隐私保护型协作(如:广告测量、A/B测试),但已被弃用,未来开发中无需关注,应继续使用标准Web存储方案。

三者均服务于特定生态(扩展开发、广告合规),普通网页开发较少直接使用,日常仍以`localStorage`、`sessionStorage`、`IndexedDB`等标准存储为主。

相关推荐
漂流瓶jz2 小时前
理解Webpack插件机制:从插件使用、各类编译对象、Tapable到自定义插件与钩子开发
前端·javascript·webpack
梦帮科技12 小时前
GRAVIS v4.0:基于Web的极速套利架构设计与实时数据流实现
前端·人工智能·rust·自动化·区块链·智能合约·数字货币
爱勇宝12 小时前
办公资料反复修改、补传、交接混乱,我做了个桌面工具来解决这件事
前端·后端·程序员
微信开发api-视频号协议13 小时前
企业微信外部群开发自动化实践过程
java·前端·微信·自动化·企业微信·ipad
甲维斯13 小时前
Fable5:20美金的顶级设计师!
前端·人工智能
kyriewen13 小时前
我同时用了 Claude Code、Cursor 和 Codex,说说三个工具的真实差距——2026 年选错工具比不用 AI 更浪费时间
前端·ai编程·claude
Jackson__14 小时前
为了拯救我的腰椎和颈椎,我做了款浏览器插件!
前端·javascript·开源
闲猫14 小时前
Python FastAPI + SQLAlchemy 入门教程:从零搭建你的第一个 Web 应用
前端·python·fastapi
林小帅14 小时前
NestJS v11 + Prisma v7 ESM 迁移配置解析
前端·javascript·后端