SharedWorker和用户隐私

本文深入分析了IE浏览器不支持SharedWorker的原因,指出其担忧隐私隐患,并提出了限制方式和改进建议,旨在保护用户信息的同时,促进Web技术的发展。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近做实时聊天,用到SharedWorker。目前为止,IE和Safari一直没有支持SharedWorker。过去可以认为是微软人品有问题,不过现在IE10、IE11在支持标准方面做得其实也不差。那么为什么IE不支持SharedWorker?我查了一下,发现这个2011年的讨论:[url]http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/thread.html#msg269[/url]。

简单说,微软的人认为SharedWorker存在隐私隐患。根据spec,如果两个不同域的网站都包含相同的第三方域在iframe中,这两个iframe可以发起SharedWorker来互相通讯(从而可能泄漏用户信息,如知道同一个用户访问了这两个域的网站)。

读了讨论两遍并大致思考后,总结如下:

1. 嵌入相同域的iframe,则iframe本来就可以干许多事情,比如连接服务器。但是光能连服务器是不够的。要获得用户信息,必须有标识client身份的方式。比如cookie、localStorage、IndexedDB等机制。

2. 浏览器厂商可以或已经对上述机制做了隐私增强。比如IE的禁止第三方cookie追踪。

3. SharedWorker的问题在于它提供了一种新的用户关联机制。

4. 一种可能的限制方式是,如果iframe的嵌套链路的origin有不匹配,就不允许连接到原先的SharedWorker,而是新建一个Worker。

5. SharedWorker本身应增加cross-origin的能力,这样不需要通过iframe来曲线救国。

6. iframe可能需要更多限制方式,比如限制iframe请求不发送referrer。

7. 微软还是比较扯淡,因为其实可以实现出来并加以限制,而不用一直不实现。


以上。
<think>好的,我现在要回答用户关于SharedWorkerWeb Worker之间联系的问题。首先,我需要回顾一下这两者的基本概念,以及它们在Web开发中的应用场景。 我记得Web Workers是HTML5的一部分,用于在浏览器后台运行脚本,避免阻塞主线程。而SharedWorker可能是一种特殊类型的Web Worker,允许不同的浏览器上下文共享同一个worker实例。不过,我需要确认这些信息是否正确,并深入理解它们之间的具体联系区别。 接下来,我应该先分别定义Web WorkerSharedWorker。Web Worker分为专用Worker(Dedicated Worker)共享Worker(Shared Worker)。专用Worker只能被创建它的脚本访问,而SharedWorker可以被多个不同的窗口、iframe甚至其他Worker访问,只要它们同源。这说明SharedWorker是Web Worker的一种扩展类型,提供更高级的共享能力。 然后,我需要比较它们的联系。首先,两者都用于在后台线程执行任务,防止主线程阻塞。其次,它们都通过消息传递与主线程通信,使用postMessageonmessage机制。不过,SharedWorker允许多个上下文共享同一个实例,这意味着不同的标签页或窗口可以共享同一个Worker,从而共享数据状态。而专用Worker只能服务于一个页面实例。 在实现方面,创建SharedWorker的语法与专用Worker不同,需要使用SharedWorker构造函数,并且需要通过port属性来建立连接通信。这可能是一个需要注意的细节,容易出错的地方。例如,专用Worker直接使用new Worker(),而SharedWorker需要处理port的打开消息监听。 应用场景方面,SharedWorker适合需要多个页面协同工作的场景,比如共享WebSocket连接、同步用户状态或共享缓存数据。而专用Worker更适合单个页面内的复杂计算任务,如图像处理、大数据分析等。 我还需要确认它们的浏览器支持情况。SharedWorker的支持可能不如专用Worker广泛,特别是在移动浏览器上可能存在兼容性问题,这也是开发者需要考虑的因素。 最后,总结它们的联系:SharedWorker是Web Worker的一种,扩展了Worker的功能,使其能够在多个上下文中共享。两者都基于相同的底层技术,但设计目标应用场景不同。</think>SharedWorker(共享Worker)与Web Worker(通常指专用Worker)都是浏览器提供的多线程解决方案,它们之间的联系区别可以按以下结构理解: --- ### 一、核心联系 1. **同源技术基础** - 两者均基于HTML5 Web Workers规范 - 使用相同的消息通信机制:`postMessage`发送消息,`onmessage`接收消息 2. **后台线程执行** - 均能独立于主线程运行JavaScript代码 - 避免阻塞UI渲染,提升复杂计算的执行效率 3. **受限的DOM访问** - 均不能直接操作DOM(与主线程隔离) --- ### 二、关键区别 | 特性 | Web Worker (专用Worker) | SharedWorker (共享Worker) | |---------------------|--------------------------------|----------------------------------| | **作用域** | 仅服务于创建它的页面实例 | 可被同源下的多个页面/iframe共享 | | **生命周期** | 随页面关闭终止 | 依赖所有关联页面的关闭才会终止 | | **通信方式** | 直接通过`worker.postMessage` | 需通过`port`对象建立连接 | | **典型应用场景** | 单页面内耗时任务(如数据分析) | 多标签页共享数据(如实时聊天室) | --- ### 三、代码示例对比 1. **专用Worker** ```javascript // 主线程 const worker = new Worker('dedicated.js'); worker.postMessage('开始计算'); worker.onmessage = (e) => console.log(e.data); // dedicated.js self.onmessage = (e) => { const result = heavyCalculation(); self.postMessage(result); }; ``` 2. **SharedWorker** ```javascript // 主线程 const sharedWorker = new SharedWorker('shared.js'); sharedWorker.port.start(); // 必须显式启动端口 sharedWorker.port.postMessage('同步状态'); // shared.js self.onconnect = (e) => { const port = e.ports[0]; port.onmessage = (e) => { const data = processSharedData(e.data); port.postMessage(data); }; }; ``` --- ### 四、选择建议 - 使用 **专用Worker** 当: - 单个页面需要独立的后台任务 - 无需跨页面共享数据或状态 - 使用 **SharedWorker** 当: - 多个标签页需要共享同一后台进程(如实时协作应用) - 需要维护跨页面的持久化状态(如用户登录信息同步) --- ### 五、注意事项 - **兼容性**:SharedWorker在部分移动端浏览器支持较差 - **调试**:Chrome DevTools中可通过`chrome://inspect/#workers`查看SharedWorker实例 - **安全限制**:遵循同源策略,且无法访问`LocalStorage`等存储API
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值