详解浏览器cookie和浏览隐私之间的关系
http://www.iefans.net/cookie-yinsi-guanxi/
详解浏览器cookie和浏览隐私之间的关系
Cookie 的技术实现
本章节面向懂技术的网友。不太懂技术的读者，可以略过本节，直接进入下一章节，以免浪费时间。网站如何设置 cookie（写操作）
1、当你在浏览器中点某个书签、或者在浏览器地址栏输入某个网址，浏览器会向对应的网站发起一个 HTTP 请求（术语是 HTTP Request）。 2、然后，网站的服务器收到这个 HTTP 请求之后，会把相应的内容（比如网页、图片、等）发回给浏览器（这称为 HTTP 响应，术语是 HTTP Reponse）。 如果网站想设置 cookie，就在发回的 HTTP Response 中，包含一个设置 cookie 的指令。举例如下：Set-Cookie: user=xxxx; Path=/; Domain=www.example.com上述这个例子中，设置了一个 cookie。这个 cookie 的"名"是 user；cookie 的"值"是 xxxx；cookie 绑定的域名是 www.example.com 3、浏览器在收到这个指令后，就会在你的电脑中存储该 cookie 的信息。
网站如何获取 cookie（读操作）
假设过了几天之后，你再次访问上述的 www.example.com 网站（在上次的访问中，已经被设置过 cookie 了）。这时候，浏览器发现该网址已经有对应的 cookie，就会把 cookie 的信息放在 HTTP Request 中，然后发送到网站服务器。具体的指令如下：Cookie: user=xxxx网站服务器拿到这个 HTTP Request 之后，就可以通过上述信息，知道 cookie 的"名"和"值"。
Cookie 的特点
存储信息量小
cookie 在洋文中的意思就是：小甜饼、曲奇饼。这个单词其实已经暗示了 cookie 技术所能存储的信息量是比较小滴。 从刚才的技术实现机制可以看出，cookie 只能用来存储纯文本信息，而且存储的内容不能太长——因为 Cookie 的读写指令受限于 HTTP Header 的长度。 但是，cookie 的信息量虽小，能耐却很大哦。请看下面的例子。 举例 比如某个网站上有很多网页，每个网页上有很多广告。该网站想要收集：每一个访客点击了哪些广告。 由于这些信息量比较大，直接存储在 cookie 里可能放不下。所以，网站通常是在 cookie 中保存一个唯一的用户标识。然后把用户的点击信息（包括在哪个时间点击哪个广告）都存储在服务器上。 下次你再访问该网站，网站先拿到 cookie 中的用户标识，因为这个标识具有唯一性，那么就可以根据该标识，从网站服务器上查出该用户的详细信息。绑定到域名和路径
从上述的实现机制可以看出，cookie 是跟 HTTP Request 对应的网址（域名和路径）相关的。 所以，不同域名的网站设置的 cookie 是互相独立的（隔离的）。这一点由浏览器来保证，以确保安全性。 补充一下：cookie 绑定的域名可以是小数点开头的。举例如下：Set-Cookie: user=xxxx; Path=/; Domain=.example.com这个指令设置的 cookie，可以被 example.com 的所有下级域名读取（比如 www.example.com 或 ftp.example.com）。
Cookie 的类型
第一方 Cookie VS 第三方 Cookie
首先来说说"第一方"和"第三方" Cookie 的区别，因为这跟隐私的关系比较密切。 要说清楚 "第一方 Cookie" 和 "第三方 Cookie" 的差别，俺来举个例子。 举例 打个比方，你上新浪去看新闻，并且新浪的网页上嵌入了阿里巴巴的广告（假设新浪的页面和嵌入的广告都会设置 cookie）。那么，当你的浏览器加载完整个页面之后，浏览器中就会同时存在新浪网站的 cookie 和 阿里巴巴网站的 cookie。这时候，新浪网站的 cookie 称为"第一方 Cookie"（因为你访问的就是新浪嘛），相对的，阿里巴巴的 cookie 称为"第三方 Cookie"（因为你访问的是新浪，阿里巴巴只是不相干的第三方）内存型 VS 文件型
根据存储方式的不同，分为两类：基于内存的 Cookie 和 基于文件的Cookie。基于内存的 cookie，当浏览器关闭之后，就消失了；而基于文件的 cookie，即使浏览器关闭，依然存在于硬盘上。和隐私问题相关的 cookie，主要是第二类（基于文件的Cookie）。Cookie 有啥正经用途？
今年的315晚会，央视猛烈抨击了 cookie 的隐私问题，搞得好像 cookie 是洪水猛兽一般。央视对 cookie 的宣传，典型是用来吓唬不懂技术的外行。其实捏，cookie 是有利有弊的。cookie 之所以应用这么广泛，因为它本身确实是很有用的。请看下面的几个例子。举例1——自动登录
目前很多基于 Web 的邮箱，都有自动登录功能。也就是说，你第一次打开邮箱页面的时候，需要输入用户名和口令；过几天之后再来打开邮箱网页，就不需要再次输入用户名和口令了（比如 Gmail 和 Hotmail 就是这样的）。 为啥邮箱可以做到自动登录，就是因为邮箱的网站在你的浏览器中保存了 cookie，通过 cookie 中记录的信息来表明你是已登录用户。举例2——提供个性化界面
比如某个论坛允许匿名用户设置页面的字体样式和字体大小。那么，该论坛就可以把匿名用户设置的字体信息保存在 cookie 中，下次你用同一个浏览器访问该论坛，自动就帮你把字体设置好了。小结
一般来说，有正经用途的 cookie，大都是"第一方 Cookie"；至于"第三方 Cookie"，大部分是用来收集广告信息和用户行为的。Cookie 如何泄漏隐私？
cookie 就像一把双刃剑，有很多用途，但也有弊端。一个主要的弊端就是隐私问题。举例1
假如你同时使用 Google 的 Gmail 和 Google 的搜索（很多 Google 用户都这么干）。当你登录过 Gmail 之后，cookie 中会保存你的用户信息（标识你是谁）；即使你在 Gmail 中点了注销（logout），cookie 中还是会有你的用户信息。之后，你再用 Google 的搜索功能，那么 Google 就可以通过 cookie 中的信息，知道这些搜索请求是哪个 Gmail 用户发起的。 可能有些同学会问，Gmail 和 Google 搜索，是不同的域名，如何共享 cookie 捏？俺前面有介绍过，某些 cookie 绑定的域名是以小数点开头的，也就是说，这类 cookie 可以被所有下级域名读取。因为 Gmail 的域名是 mail.google.com，而 Google 搜索的域名是 www.google.com。所以这两者都可以读取绑定在 .google.com 的 cookie！ 注：俺拿 Google 来举例是因为俺博客的读者，大部分都是 Google 用户。其实不光 Google 存在此问题，百度、腾讯、阿里巴巴、奇虎360、等等，都存在类似问题（这几家都有搜索功能，也都有自己的一套用户帐号体系）。举例2
很多网站会利用 cookie 来追踪你访问该网站的行为（包括你多久来一次，每次来经常看哪些页面，每个页面的停留时间），这样一来，网站方面就可以根据这些数据，分析你的个人的种种偏好（这就涉及到个人隐私）。 请注意：利用 cookie 收集个人隐私的把戏有很多，俺限于篇幅，仅列出上述两例。始终用隐私浏览模式
关于"隐私浏览模式"，在本系列的前一篇已经介绍过了，此处不再啰嗦。 在隐私浏览模式下，浏览器关闭之后，期间所有的 cookie 都消失。 但是，这样设置也可能带来一些不方便之处（安全性和方便性通常是截然对立）。你可能要先尝试一段时间，看看自己能否忍受这种模式。小结
刚才介绍的几招，都是针对单个浏览器 。大部分情况下是够用了。但是某些特殊情况，还是会搞不定。 比如：你经常用 Gmail，而且依赖于 Gmail 的自动登录。这时候，你就不能禁用 .google.com 域名下的 cookie（禁用了就无法自动登录 Gmail）。 但是，你在用 Google 搜索的时候，又不希望让 Google 知道你是谁。咋办捏？请听下回分解——用多浏览器搭配不同的招数。 via：编程随想的博客什么是浏览器指纹？它是如何泄露我们的隐私？
http://www.iefans.net/liulanqi-zhiwen-ruhe-xielou-yinsi/
什么是浏览器指纹？它是如何泄露我们的隐私？
什么是“指纹”？
说到“指纹”可能大家都知道是手指头的纹理，而且每个人的指纹都是唯一的。 如果你时常接触信息安全领域的一些资料，也会听到“指纹”这个形象的说法（比如：操作系统指纹、网络协议栈指纹、等等）。IT 领域提到的“指纹”一词，其原理跟“刑侦”是类似的——“当你需要研究某个对象的类型/类别，但这个对象你又无法直接接触到。这时候你可以利用若干技术来获取该对象的某些特征，然后根据这些特征来猜测/判断该对象的类型/类别。”什么是“指纹”的“信息量”？
在 IT 领域有各种各样的特征可以用来充当“指纹”。这时候就需要判断，用哪个特征做指纹，效果更好。为了讨论这个问题，就得扫盲一下“指纹的信息量”。 为了帮助大伙儿理解，先举一个例子： 假设你要在学校中定位某个人，如果你光知道此人的性别，你是比较难定位的（只能排除 1/2 的人）；反之如果你不知道性别，但是知道此人的生日，就比较容易定位（可以排除掉大约 364/365 的人，只剩大约 1/365 的人）。为什么？因为“生日”比“性别”更加独特，所以“生日”比“性别”能够提供更多的信息量。 从这个例子可以看出：某个特征越独特，则该特征的信息量越大；反之亦然。信息量越大的特征，就可以把对象定位到越小的范围。“指纹”的“信息量”如何度量——关于指纹的比特数？
（本节涉及到中学数学，数学很差的或者对数学有恐惧感的读者，请直接无视） 在 IT 领域中，可以用【比特数】来衡量某个指纹所包含的信息量。为了通俗起见，先以前面提到的“性别”来说事儿。性别只有两种可能性——“男”或者“女”，并且男女的比例是大致平均的。所以，当你知道了某人的性别，就可以把范围缩小到原先的 1/2。用 IT 的术语来讲，就是：“性别”这个特征只包含一个比特的信息量。以此类推：- 当我们说：“某特征包含3比特信息量”，意思就是：该特征会有8种大致平均的可能性（8等于2的3次方）。一旦知道该特征，可以把目标定位到八分之一。
- 当我们说：“某特征包含7比特信息量”，意思就是：该特征会有128种大致平均的可能性（128=2^7）。一旦知道该特征，可以定位到 1/128。
多个指纹的综合定位
如果能同时获取【互不相关】的若干个指纹，就可以大大增加定位的精确性。 比如要在某个公司里面定位某人，如果你知道此人的“生日”和“生肖”，那么就可以达到 1/4380（1/4380 = 1/12 * 1/365） 的定位精度。因为综合定位之后，比例之间是【乘法】的关系，所以范围就被急剧缩小了。 为什么要特别强调“互不相关”呢？假如你同时知道的信息是“生日”和“星座”，那么定位的精度依然是 1/365——因为生日的信息已经包含了星座的信息。所以，只有那些相互独立的特征（所谓的相互独立，数学称为“正交”），在综合定位的时候才可以用【乘法】。什么是“浏览器的指纹”？
当你使用浏览器访问某个网站的时候，浏览器【必定会暴露】某些信息给这个网站。为什么强调“必定”呢？因为这些信息中，有些是跟 HTTP 协议相关的（本章节说的 HTTP 协议是广义的，也包括 HTTPS）。只要你基于 HTTP 协议访问网站，浏览器就【必定】会传输这些信息给网站的服务器。 再罗嗦一下：HTTP 协议是 Web 的基石。只要你通过浏览器访问 Web，必定是基于 HTTP 协议的。因此，Web 网站的服务器必定可以获取到跟你的浏览器相关的某些信息（具体是哪些信息，下面会说到）。“浏览器指纹”如何暴露隐私？
“浏览器指纹”的机制跟 cookie 有点相似。关于 cookie 的作用，建议那些健忘的同学先去“前面的博文”复习一下。 对于“浏览器指纹”导致的隐私问题，这里举2个例子来说明其危害。对于无需登录的网站
如果你的浏览器允许记录 cookie，当你第一次访问某网站的时候，网站会在你的浏览器端记录一个 cookie，cookie 中包含某个“唯一性的标识信息”。下次你再去访问该网站，网站服务器先从你的浏览器中读取 cookie 信息，然后就可以根据 cookie 中的“唯一标识”判断出，你之前曾经访问过该网站，并且知道你上次访问该网站时，干了些什么。对付这种 cookie 很简单，你只需要在前后两次访问之间，清空浏览器的 cookie，网站就没法用 cookie 的招数来判断你的身份。 但是“清空 cookie”这招对“浏览器指纹”是无效滴。比如说你的浏览器具有非常独特的指纹，那么当你第一次访问某网站的时候，网站会在服务器端记录下你的浏览器指纹，并且会记录你在该网站的行为；下次你再去访问的时候，网站服务器再次读取浏览器指纹，然后跟之前存储的指纹进行比对，就知道你是否曾经来过，并且知道你上次访问期间干了些什么。对于需要登录的网站
假如网站没有采用“指纹追踪”的技术，那么你可以在该网站上注册若干个帐号（马甲）。当你需要切换身份的时候，只需要先注销用户，清空浏览器的 cookie，然后用另一个帐号登录。网站是看不出来的。 一旦网站采用“指纹追踪”的技术，即使你用上述方式伪造马甲，但因为你用的是同一个浏览器，浏览器指纹相同。网站的服务器软件可以猜测出，这两个帐号其实是同一个网民注册的。“浏览器指纹”比“cookie”更隐蔽，更危险
刚才对比了“浏览器指纹”和“cookie”两种身份追踪技术。两者的原理类似——都是利用某些特殊的信息来定位你的身份。两者的本质差异在于：- cookie 需要把信息保存在浏览器端，所以会被用户发现，也会被用户清除。
- 而“浏览器指纹”无需在客户端保存任何信息，不会被用户发觉，用户也无法清除（换句话说：你甚至无法判断你访问的网站到底有没有收集浏览器指纹）。
“浏览器指纹”包含哪些信息？
浏览器暴露给网站的信息有很多种，常见的有如下几种：User Agent
关于 User Agent 是什么，已经在本系列前面的博文中有简单的说明，已了解的同学可以继续往下看。屏幕分辨率
这个比较通俗易懂。稍微补充一下：这一项不仅包括屏幕的尺寸，还包括颜色深度（比如你的屏幕是16位色、24位色、还是32位色）。时区
这个也比较通俗。我们应该都是“东8区”。浏览器的插件信息
也就是你的浏览器装了哪些插件。 再罗嗦一次：浏览器的“插件”和“扩展”是两码事儿，别搞混了。本系列前面的博文扫盲了两者的差异，链接在“这里”。浏览器的字体信息
和浏览器相关的一些字体信息。 如果你的浏览器安装了 Flash 或 Java 插件，有可能会暴露某些字体信息。所以在“如何防范浏览器泄露上网隐私”一文中就警告了浏览器插件的风险。HTTP ACCEPT
这是 HTTP 协议头中的一个字段。考虑到列位看官大都不是搞 IT 技术的，这里就不深入解释这项。其它
以上就是常见的浏览器指纹。当然啦，还有其它一些信息也可以成为“浏览器指纹”，考虑到篇幅就不一一列举并解释了。有兴趣的同学，请自行阅读 Mozilla 官网的文档。如何看自己浏览器的指纹？
关于浏览器指纹导致的隐私问题，可能是由“电子前哨基金会”（简称 EFF）率先在2010年曝光的。后来 EFF 提供了一个页面，帮助网友看自己浏览器的指纹（请点击“这个链接”）。 打开此页面之后，当中有一个大大的，红色的“TEST ME”按钮。点一下此按钮，稍等几秒钟，会显示出一个表格，里面包含你当前的浏览器的指纹信息。 在这个表格中会列出每一项指纹的“信息量”以及该指纹的“占比”。关于“信息量”的含义，本文前面已经扫盲过，此处不再说明。你只需记住，某项的信息量越大，就说明该项越独特。而越独特的指纹，对隐私的威胁也就越大。 考虑到篇幅有点长，今天先聊到这里。下次跟大家分享如何防范“浏览器指纹”导致的隐私风险。 via：编程随想的博客fingerprint hash 187c8e293354eb2d15d9363a6f52f393
index.js:42 userAgent = Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safa
index.js:42 language = zh-CN
index.js:42 colorDepth = 24
index.js:42 deviceMemory = not available
index.js:42 hardwareConcurrency = 2
index.js:42 screenResolution = 800,1280
index.js:42 availableScreenResolution = 800,1227
index.js:42 timezoneOffset = -480
index.js:42 timezone = Asia/Shanghai
index.js:42 sessionStorage = true
index.js:42 localStorage = true
index.js:42 indexedDb = true
index.js:42 addBehavior = false
index.js:42 openDatabase = true
index.js:42 cpuClass = not available
index.js:42 platform = Win32
index.js:42 plugins = com.sogou.sogoupdfviewer,,application/pdf,pdf,Native Widget Plugin,This plugin allow you to use the
index.js:42 canvas = canvas winding:yes,canvas fp:data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAB9AAAADICAYAAACwGnoBAAAgA
index.js:42 webgl = not available
index.js:42 webglVendorAndRenderer = undefined
index.js:42 adBlock = false
index.js:42 hasLiedLanguages = false
index.js:42 hasLiedResolution = false
index.js:42 hasLiedOs = false
index.js:42 hasLiedBrowser = false
index.js:42 touchSupport = 0,false,false
index.js:42 fonts = Arial,Arial Black,Arial Narrow,Calibri,Cambria,Cambria Math,Comic Sans MS,Consolas,Courier,Courier N
index.js:42 audio = 124.04344752358156
time 361
index.js:37 fingerprint hash b303b5c23680c363a36afc5764f3a275
index.js:42 userAgent = Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109
index.js:42 language = en-US
index.js:42 colorDepth = 24
index.js:42 deviceMemory = 8
index.js:42 hardwareConcurrency = 2
index.js:42 screenResolution = 800,1280
index.js:42 availableScreenResolution = 800,1227
index.js:42 timezoneOffset = -480
index.js:42 timezone = Asia/Shanghai
index.js:42 sessionStorage = true
index.js:42 localStorage = true
index.js:42 indexedDb = true
index.js:42 addBehavior = false
index.js:42 openDatabase = true
index.js:42 cpuClass = not available
index.js:42 platform = Win32
index.js:42 plugins = Chrome PDF Plugin,Portable Document Format,application/x-google-chrome-pdf,pdf,Chrome PDF Viewer,,ap
index.js:42 canvas = canvas winding:yes,canvas fp:data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAB9AAAADICAYAAACwGnoBAAAgA
index.js:42 webgl = data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAASwAAACWCAYAAABkW7XSAAAKcUlEQVR4Xu2dDYhlYxjH77uiiFBEbT
index.js:42 webglVendorAndRenderer = Google Inc.~ANGLE (Mobile Intel(R) 4 Series Express Chipset Family Direct3D9Ex vs_3_0 ps_3_0)
index.js:42 adBlock = false
index.js:42 hasLiedLanguages = false
index.js:42 hasLiedResolution = false
index.js:42 hasLiedOs = false
index.js:42 hasLiedBrowser = false
index.js:42 touchSupport = 0,false,false
index.js:42 fonts = Arial,Arial Black,Arial Narrow,Calibri,Cambria,Cambria Math,Comic Sans MS,Consolas,Courier,Courier N
index.js:42 audio = 124.0434474653739
Fingerprinting - MozillaWiki https://wiki.mozilla.org/Fingerprinting
Overview
The EFF published an excellent study in May, detailing some of the various methods of fingerprinting a browser. See http://www.eff.org/deeplinks/2010/05/every-browser-unique-results-fom-panopticlick. They found that, over their study of around 1 million visits to their study website, 83.6% of the browsers seen had a unique fingerprint; among those with Flash or Java enabled, 94.2%. This does not include cookies! They ranked the various bits of information in order of importance (i.e. how useful they are in uniquely identifying a browser): things like UA string, what addons are installed, and the font list of the system. We need to go through these, one by one, and do what we can to reduce the number of bits of information (entropy) it provides. In their study, they placed a lower bound on the fingerprint distribution of 18.1 bits of entropy. (This means that, choosing a browser at random, at best one in 286,777 other browsers will share its fingerprint.)
Data
The following data is taken from the published paper, https://panopticlick.eff.org/browser-uniqueness.pdf:
| Variable | Entropy (bits) |
| plugins | 15.4 |
| fonts | 13.9 |
| user agent | 10.0 |
| http accept | 6.09 |
| screen resolution | 4.83 |
| timezone | 3.04 |
| supercookies | 2.12 |
| cookies enabled | 0.353 |
In all cases, data was either collected or inferred via HTTP, or collected by JS code and posted back to the server via AJAX.
Plugins
The PluginDetect JS library was used to check for 8 common plugins on that platform, plus extra code to estimate the Acrobat Reader version. Data sent by AJAX post.
IE does not allow enumeration via navigator.plugins[]. Starting in Firefox 28 (bug 757726), Firefox restricts which plugins are visible to content enumerating navigator.plugins[]. This change does not disable any plugins; it just hides some plugin names from enumeration. Websites can still check whether a particular hidden plugin is installed by directly querying navigator.plugins[] like navigator.plugins["Silverlight Plug-In"].
This code change will reduce browser uniqueness by "cloaking" uncommon plugin names from navigator.plugins[] enumeration. If a website does not use the "Adobe Acrobat NPAPI Plug-in, Version 11.0.02" plugin, why does it need to know that the "Adobe Acrobat NPAPI Plug-in, Version 11.0.02" plugin is installed? If a website does need to know whether the plugin is installed or meets minimum version requirements, it can still check navigator.plugins["Adobe Acrobat NPAPI Plug-in, Version 11.0.02"] or navigator.mimeTypes["application/vnd.fdf"].enabledPlugin (to workaround problem plugins that short-sightedly include version numbers in their names, thus allow only individual plugin versions to be queried).
For example, the following JavaScript reveals my installed plugins:
for (plugin of navigator.plugins) { console.log(plugin.name); }
"Shockwave Flash"
"QuickTime Plug-in 7.7.3"
"Default Browser Helper"
"Unity Player"
"Google Earth Plug-in"
"Silverlight Plug-In"
"Java Applet Plug-in"
"Adobe Acrobat NPAPI Plug-in, Version 11.0.02"
"WacomTabletPlugin"
navigator.plugins["Unity Player"].name // get cloaked plugin by name
"Unity Player"
But with plugin cloaking, the same JavaScript will not reveal as much personally-identifying information about my browser because all plugin names except Flash, Shockwave (Director), Java, and QuickTime are hidden from navigator.plugins[] enumeration:
for (plugin of navigator.plugins) { console.log(plugin.name); }
"Shockwave Flash"
"QuickTime Plug-in 7.7.3"
"Java Applet Plug-in"
In theory, all plugin names could be cloaked because web content can query navigator.plugins[] by plugin name. Unfortunately, we could not cloak all plugin names because many popular websites check for Flash or QuickTime by enumerating navigator.plugins[] and comparing plugin names one by one, instead of just asking for navigator.plugins["Shockwave Flash"] by name. These websites should be fixed.
The policy of which plugin names are uncloaked can be changed in the about:config pref plugins.enumerable_names. The pref’s value is a comma-separated list of plugin name prefixes (so the prefix "QuickTime" will match both "QuickTime Plug-in 6.4" and "QuickTime Plug-in 7.7.3"). The default pref cloaks all plugin names except Flash, Shockwave (Director), Java, and QuickTime. To cloak all plugin names, set the pref to the empty string "" (without quotes). To cloak no plugin names, set the pref to magic value "*" (without quotes).
Fonts
System fonts collected by Flash or Java applet, if installed, and sent via AJAX post. Font list was not sorted, which provides a bit or two of additional entropy. We can ask Adobe to either limit this list by default; or ask them to implement an API such that we can provide the list to them; or (made possible by OOPP) replace the OS API calls they use to get the font list, and give them our own. None of these things are easy, but given that this is #1, we should definitely do something here. The fastest option is probably to hack the OS API calls ourselves.
Font lists can also be determined by CSS introspection. We could perhaps reduce the available set to a smaller number of common fonts; and back off (exponentially?) if script attempts to brute-force the list. Could require that sites provide unusual fonts via WOFF?
User Agent
Detected from HTTP header. Pretty simple fix, but has the potential for breakage (as with any UA change!). For instance: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7. Remedies: remove the last point digit in the Firefox and Gecko versions, and the Gecko build date; for Linux, remove distribution and version; possibly remove CPU. Windows is actually the least unique since the OS version string only identifies the major version (e.g. XP), and by far the majority of users are on it.
Remove language and "Firefox" as well?
Boris Zbarsky points out that most parts of the UA lead to bad sniffing. Irish "ga-IE" and "Minefield" get detected as IE. Sites incorrectly sniff based on OS. Sites sniff for Gecko years rather than Gecko versions. Going from 3.0.9 to 3.0.10 probably breaks things. And quite a few sites sniff for "Firefox", which is a threat to the continued freedom of the web. So removing things from the UA string has a long-term positive effect on compatibility as well as privacy.
- There is another issue with UA spoofing. For some reason, Components.classes and Components.interfaces exist in the content-window javascript namespace. Gregory Fleischer used this to test for the existence of ephemeral interfaces to fingerprint both OS and Firefox version, down to the minor revision (FF3.5.3 was the latest release at the time). He has a number of other fingerprinting demos you should investigate as well. -- mikeperry
HTTP ACCEPT
Example: text/html, */* ISO-8859-1,utf-8;q=0.7,*;q=0.7 gzip,deflate en- us,en;q=0.5. Not sure we can do much here?
Screen resolution
Example: 1280x800x24. Can't mess with this, except perhaps to always report "24" for the color depth -- of dubious value.
- Mapping "32" to "24" or vice versa in the color depth would reduce entropy by ~0.9 bits. May be worthwhile.
- Torbutton takes two countermeasures with respect to screen resolution: quantising AvailWidth and AvailHeight, and setting Width and Height to the values of AvailWidth and AvailHeight. Torbutton currently errs in not doing this if the window is maximised. These measures might be appropriate in private browsing mode. -- Pde 03:12, 15 June 2010 (UTC)
Timezone
Too useful to break.
The reported entropy includes only whether the following were enabled: DOM localStorage, DOM sessionStorage, and (for IE) userData. It did nottest Flash LSOs, Silverlight cookies, HTML5 databases, or DOM globalStorage. We can't do anything to prevent testing whether these are enabled, but we can lock them down for third parties, as we will with cookies.
For Flash and Silverlight we need to pressure them to implement better APIs for controlling and clearing stored data. This is undoubtedly more important than anything else on this list, though it was ignored in this study since it does not fit within their definition of fingerprinting. We could be aggressive here by using the new Flash API for private browsing mode very liberally; or do something with the OS APIs as mentioned above.
Cookies enabled
Irrelevant due to low amount of entropy.
Extra credit
Other fingerprinting methods were mentioned, but not included, in the study. A Gartner report on fingerprinting services was referenced in the study, which will undoubtedly be interesting to read.
Examples:
Other data acquired via plugins
Undoubtedly Flash and Java provide other interesting tidbits. ActiveX and Silverlight, for example, allow querying the "CPU type and many other details". More study needed here.
Clock skew measurements
"41st Parameter looks at more than 100 parameters, and at the core of its algorithm is a time differential parameter that measures the time difference between a user’s PC (down to the millisecond) and a server’s PC." We can't break the millisecond resolution of Date.now, but we could try adding a small (< 100ms) offset to it. This would be generated per-origin, and would last for some relatively short time: life of session, life of tab, etc. Would have to be careful that it can't be reversed.
- Clock skew measurement isn't really a browser issue; it tends to be exposed by the operating system at the TCP level. It would be appropriate to assume that an attacker can obtain 4-6 bits of information about the identity of a host by this method. -- Pde 02:55, 15 June 2010 (UTC)
- This is not 100% correct. According to RFC 1323 sections 3.2 and 4.2.2, timestamps may only be used if the initial syn packet (not syn+ack) contains a timestamp field. This is a property of the client OS, and may be controllable on some platforms. The timestamp value is also not absolute, but is typically some arbitrary number of milliseconds with no specific reference point. TLS also has a timestamp, but this value is fully controlled by Firefox. -- mikeperry
- Agree that one could turn off the TCP RTTM option at the OS layer. My naive intuition is that all modern OSes have this turned on, and turning it off would be a radical intervention bad for congestion avoidance and possibly fingerprintable itself. Note that clock skew is a function of how fast a clock ticks, not of what time the clock has. An arbitrary reference point is sufficient for measuring clock skew. -- Pde08:23, 9 December 2010 (PST)
- Note also that it's not just clock skew, but also clock precision that can allow for fingerprinting - both in terms of how long certain operations take on a system and in terms of user action. For example, Scout Analytics provides software to fingerprint users based on typing cadence. One can also imagine tight loops of timed javascript that fingerprint users based on certain resource-intensive calls. One possibility might be to quantize Date values to the second, and then add random, monotonically increasing amounts of milliseconds to subsequent calls during private browsing mode. -- mikeperry
TCP stack
"ThreatMetrix claims that it can detect irregularities in the TCP/IP stack and can pierce through proxy servers". Not sure what this means yet.
- nmap's host fingerprinting options (and source code) are the first place to start for understanding the TCP/IP stack issues. Again, there's not much the browser can do about that.
- As for "pierce through proxy servers", my best guess is that they use the raw socket infrastructure provided by Flash, which does not respect the browser's proxy settings, in order to learn the client's IP. Not sure if Java and Silverlight have similar problems. -- Pde 02:58, 15 June 2010 (UTC)
JS behavioral tests
Can be used to gather information about whether certain addons are installed, exact browser version, etc. Probably nothing we can do here.
"TorButton has evolved to give considerable thought to fingerprint resistance [19] and may be receiving the levels of scrutiny necessary to succeed in that project [15]. NoScript is a useful privacy enhancing technology that seems to reduce fingerprintability."
"We identified only three groups of browser with comparatively good resistance to fingerprinting: those that block JavaScript, those that use TorButton, and certain types of smartphone."
We should study what TorButton does, and see if we can integrate some of its features. We can also recommend it, NoScript, and Flashblock to users. We could suggest improvements to relevant addons, such as providing options for blocking third party but not first party content. (This doesn't strictly solve anything, but makes gathering the data more difficult, since the third party now relies on the first party to collect it.)
- Unfortunately Flashblock does not appear to prevent Flash from reading and writing LSOs, so it's doubtful it can be relied upon to protect against fingerprinting. -- Pde 03:00, 15 June 2010 (UTC)
User interface
Things like geolocation, database access and such require the user to grant permission for a given site. For geolocation, this is done with an infobar. We should do everything we can to make it clear to users what they're providing, and give them centralized control of those permissions in the privacy panel. This is what the UX privacy proposals seek to do.
HTML5 Canvas
"After plugins and plugin-provided information, we believe that the HTML5 Canvas is the single largest fingerprinting threat browsers face today." - Tor Project. Original research: Pixel Perfect: Fingerprinting Canvas in HTML5, demo: HTML5 Canvas Fingerprinting.