这是一篇论文的读书笔记“I DO Not Know What You Visited Last Summer: Protecting Users from Third-party Web Tracking With TrackingFree Browser”原文链接
overview
因为该作者致力于解决网站跟踪问题，首先得明确什么是网站跟踪，请参考博客：个人之前博客 本文作者希望解决的主要是第三方跟踪问题，而跟踪者利用浏览器漏洞获取用户的隐私数据则不在本文考虑之内。
三方跟踪中三方分别是：用户、目标站点和追踪站点（第三方追踪）。当用户访问目标站点时，目标站点中包含第三方的元素，那么在浏览器解析HTML时，会向第三方（追踪站点）发送请求，其中在HTTP request中包含目标站点的信息（URL、时间 etc）。当我们向更多的目标站点访问时，如果这些目标站点中都包含同一追踪站点，那么将会从各个不同的目标站点向追踪站点发送信息。
而追踪站点利用之前在客户端设置的cookie来确定唯一用户。这样，将导致追踪站点获取到用户的浏览历史、浏览习惯等等私人信息。
所以，这里的关键也就看到了，tracker是根据唯一的ID号来标示是否为同一用户，那么换句话说，如果让这个唯一的ID号不唯一了，就能做到anti-tracking了。如何让它不再唯一？那如果让一个浏览器变成N个浏览器，那就不唯一了。这就带来一种思想：如果我将浏览器内部隔离开来，变成一个个实体（principal，我理解是容器）。而且实体的个数是由浏览器内核来动态控制的。那就相当于构造出了一个动态个数的浏览器。
由上图可知，上层由很多独立的principal组成，每个principal中有local history manager，以及独立的存储。所有的principal之间的通信要通过principal kernel interface和Message policy enforcer.
系统整体架构
整个浏览器由两部分组成：隔离单元（web principal）和内核（kernel）。每个隔离单元有隔离的存储，因此在不同principal内的第三方tracker无法共享相同的ID号。
除了隔离机制，另外一个关键因素是内容分配机制，由principal manager决定怎样分配内容进入不同实体。不同实体之间的关系由principal backend来维护。这里比较抽象，什么是内容分配机制。简单的说，当我打开一个页面时，浏览器内核要决定把页面分配到哪个实体中去（因为现在实体是浏览器的最小单位），是新建一个，还是分配到现有的实体中？这部分决策由principal manager来决定，而决策依据，更具体的说，不同实体之间的关系（图）有principal backend来维护。
主体之间的通信也是很重要的（不能因为隔离，影响基本功能不是），主体间的通信大概归为两类：确定通信（explicit communication）和模糊通信（implicit communication），其中确定通信主要利用浏览器的API（典型的如HTML5中的postMessage）来与确定的页面通信。而模糊通信包括了共享历史记录、共享书签等等信息。在本浏览器中，这两部分工作分别有message policy enforcer和public history manager完成。前者限制了通信的范围，而后者则提供了一条安全的历史共享通道。
在上一篇博客中，我们提到过，网站跟踪最原始的目的是在于提高用户体验和做市场调研等等，那么如果完全限制隔绝网络跟踪，在某种程度上会影响用户体验。为此，作者又引入了DDM(domain data manager)的概念。DDM允许减少实体数量，并在特定实体之间共享数据。
由上面的介绍可以知道，整套系统最核心的思想就是隔离性，也就是principal概念的提出，而在系统中的其他部分，更多的是使隔离性与现有的web系统兼容
下面将对系统中各个组成部分的主要功能和作用做一简单介绍。
内容分配机制
前面提到过内容分配由principal manager来完成，那他是根据什么样的方法实现的呢？它的系统由两部分组成：初始内容分配和派生内容分配。
初始内容是指直接由用户触发的，比如说导航页，比如说在浏览器地址栏中输入的www.baidu.com，也就是说，在一个图里面，是由此去派生其他节点的，而它是根节点，我们称为初始内容。
派生内容与初始内容相反，它是由初始内容生成的，比如弹出的窗口或者页面中嵌入的iframe等。
- 初始内容分配：对于初始内容分配，总是将它们归为一个相同的principal，当且仅当它们有相同的parent domain，比如，www.google.com和mails.google.com。
- 派生内容分配：该浏览器将所有非用户触发的子帧都放在它父帧的principal中（父帧此时肯定已经存在在某个principal中了），而对所有用户触发的且跨站子帧移动到其他实体或新建一个实体（principal switch，有点象交换机）。
主体交换
主体交换（principal switch）主要解决这样一个问题：即新生成的子帧是存在于与父帧相同的principal中（no switch），还是交换到其他主体或者新建一个主体（switch out）。这里它将运行下面这个算法。
这个交换算法的主体思想是：查看是否是跨站请求以及是否是用户触发该请求，如果是，switch out。如果新生成的子帧要替换主帧并且是跨站请求，switch out。其他情况下都留在本principal中。
（主帧（main frame）是指每个主体的第一个帧）
主体交换算法保证了最小switch out，减少了开销并保证了可用性，并且将比较危险的容易泄露信息的情景交换出去
主体选择
如果说principal switch返回一个bool，那么主体选择就要选择一个合适的主体，我们之前提到过principal backend来维护一个主体有向图。其中每个节点都是一个主体。AB边的生成是指至少有一次在AB之间的主体选择发生过。
浏览器配置了一个最大为2的入度，强制要求任何主体的父节点数不能超过这个数。这个数决定了tracker的跟踪能力。一般来说，当限制了最大为2的入度后，tracker能跟踪的最大网站不超过3个。（有个公式，但不知道怎么来的）
算法描述的很清楚，这里就不再赘述了。
主体通信
主体通信（principal communication）包括确定通信和模糊通信，前面已经大致描述了一下这两种。
显然，对于确定通信而言，它利用浏览器的内核API来传递信息。这在某种程度上将使隔离性失效。为了解决该问题，trackingfree限制了它的使用范围：
- 一个主体中的第三方元素只能与本主体中的第一方元素进行通信。
- 第一方元素只能与它邻居主体的第一方主体通信（邻居的概念是由有向图来得出的）
- 所有的其他通信渠道都是不被允许的。
对于模糊通信而言，也有两种形式：安全历史共享（secure history sharing）和通过导航栏通信（communication through navigation）。
- 安全历史共享：隔离机制也会同时将用户的历史相关数据，如浏览历史、下载历史和书签等信息也隔离掉。我们知道，隔离是有意义的。如果每个主体都能查阅到所有的浏览历史，那前面所做的所有工作都没有意义了。 但是，我们也会看到这样很不方便，就是当用户在浏览器中按返回键时，是希望浏览上个页面，而不是该主体中的上一个页面。为了解决该问题，浏览器内核使用public history manager来维护一个公共历史列表。每当主体local history有更新时，将会通知public history manager来更新公共历史记录。 注意，主体对于public history只能写不能读。也就保护了私有信息。
- 通过导航栏通信：前面提到过principal switch，这其实是给principal间通信开了一扇门，如果被交换的子帧的URL中带有ID号，那相当于将子帧传播到了另外一个principal中，那如果该principal也被tracker控制，那么它很容易获取ID号并关联。这里，对于URL中的ID号，本浏览器是无能为力，因为难度极大。但是对于在HTTP request中的referer字段中的数据，浏览器可以对此进行过滤。
兴趣配置
兴趣配置（preference configure）和上面提到的public history manager很类似。因为每个principal中都要preference，但是因为principal之间是隔离的。无法之间通信。这时引入了preference configure，通过监控每个principal中preference的变化来更新全局preference。然后使用广播机制告诉各个principal更新preference。
域数据管理器
域数据管理器（Domain Data Manager）的目的在于提高用户的体验，为此，可以允许一些基本信息泄露。DDM由两部分组成：domain data migration 和 domain data synchronization。
- domain data migration：允许用户为每个regular principal（它的域为*.com）创建一临时主体，其中临时主体没有域属性等其他基本信息。临时主体中的数据是regular principal中的拷贝。临时主体的作用在于为regular principal去做一些额外的请求。而在临时主体中的请求不再进行principal switch而只存在于临时主体中。
文章中描述了这样一个使用SSO例子：当使用用户的google的账户登陆sears.com时，将会产生一系列的重定向（跨越四个不同的域，sears.com\shld.net\google.com\youtube.com）将产生四个主体，而如果domain data migration激活时，主体的数量将会变成2。工作流程如上图所示。 - domain data synchrnization: 允许多个主体来共享客户端数据（cookie、HTML5 local storage）此时，这些主体之间再也不能抵抗跟踪，但是其他主体将不受影响。
文章到这里就结束了，论文剩余的部分主要是描述这套系统的实现，以及在通常的网络应用中的可用性，以及理论与实践都证明该浏览器能够有效的抵抗网站的追踪。
