浏览器指纹 - HTTP cookie 浏览器指纹 欺诈检测 浏览器id hash 浏览器插件信息 canvas 字体信息

 

详解浏览器cookie和浏览隐私之间的关系
http://www.iefans.net/cookie-yinsi-guanxi/

详解浏览器cookie和浏览隐私之间的关系

浏览器相关 互联网 2013-07-05 阅读(6104)

 

本文所说的"cookie"，指的是浏览器相关的 cookie（也叫"HTTP cookie"）。 浏览器 cookie 的主要功能是：帮助网站保存一些小片断的信息。好比，你曾经在本身的浏览器上登陆过某个论坛，下次你再打开论坛的登陆页面，你会发现用户名已经帮你填好 了，你只须要输入口令便可。那么，这个登陆页面是如何知道你上次登陆用的帐户名捏？奥妙就在于：该网站在你的浏览器端保存了一个 cookie，里面包含了你上次登陆使用的账号名称。

Cookie 的技术实现

本章节面向懂技术的网友。不太懂技术的读者，能够略过本节，直接进入下一章节，以避免浪费时间。

网站如何设置 cookie（写操做）

一、当你在浏览器中点某个书签、或者在浏览器地址栏输入某个网址，浏览器会向对应的网站发起一个 HTTP 请求（术语是 HTTP Request）。 二、而后，网站的服务器收到这个 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 三、浏览器在收到这个指令后，就会在你的电脑中存储该 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/

什么是浏览器指纹？它是如何泄露咱们的隐私？

浏览器 互联网 2014-01-24 阅读(12957)

 

以前跟你们分享了 防范浏览器泄露上网隐私的基本技巧，对于“隐私要求不高而且技术水平也不高”的同窗，看完这篇文章基本上够了。下面继续谈谈浏览器方面的问题， 面向的是那些“对隐私要求较高，同时也具备必定折腾能力”的同窗。今天这篇文章将详解浏览器的“指纹”是如何暴露你的隐私，顺便分享一些防范技巧。

什么是“指纹”？

说到“指纹”可能你们都知道是手指头的纹理，并且每一个人的指纹都是惟一的。 若是你时常接触信息安全领域的一些资料，也会听到“指纹”这个形象的说法（好比：操做系统指纹、网络协议栈指纹、等等）。IT 领域提到的“指纹”一词，其原理跟“刑侦”是相似的——“当你须要研究某个对象的类型/类别，但这个对象你又没法直接接触到。这时候你能够利用若干技术来获取该对象的某些特征，而后根据这些特征来猜想/判断该对象的类型/类别。”

什么是“指纹”的“信息量”？

在 IT 领域有各类各样的特征能够用来充当“指纹”。这时候就须要判断，用哪一个特征作指纹，效果更好。为了讨论这个问题，就得扫盲一下“指纹的信息量”。 为了帮助大伙儿理解，先举一个例子： 假设你要在学校中定位某我的，若是你光知道此人的性别，你是比较难定位的（只能排除 1/2 的人）；反之若是你不知道性别，可是知道此人的生日，就比较容易定位（能够排除掉大约 364/365 的人，只剩大约 1/365 的人）。为何？由于“生日”比“性别”更加独特，因此“生日”比“性别”可以提供更多的信息量。 从这个例子能够看出：某个特征越独特，则该特征的信息量越大；反之亦然。信息量越大的特征，就能够把对象定位到越小的范围。

“指纹”的“信息量”如何度量——关于指纹的比特数？

（本节涉及到中学数学，数学不好的或者对数学有恐惧感的读者，请直接无视） 在 IT 领域中，能够用【比特数】来衡量某个指纹所包含的信息量。为了通俗起见，先之前面提到的“性别”来讲事儿。性别只有两种可能性——“男”或者“女”，而且男女的比例是大体平均的。因此，当你知道了某人的性别，就能够把范围缩小到原先的 1/2。用 IT 的术语来说，就是：“性别”这个特征只包含一个比特的信息量。以此类推：

• 当咱们说：“某特征包含3比特信息量”，意思就是：该特征会有8种大体平均的可能性（8等于2的3次方）。一旦知道该特征，能够把目标定位到八分之一。
• 当咱们说：“某特征包含7比特信息量”，意思就是：该特征会有128种大体平均的可能性（128=2^7）。一旦知道该特征，能够定位到 1/128。

再来讲“生日”。（不考虑闰年的状况下）生日有365种可能性（而且也是平均分布的），因此生日包含的比特数大约是 8.51。为何是 8.51 捏，由于 2 的 8.51 次方 约等于 365。所以，知道了某人的生日就能够把范围缩小到 1/365 经过上述举例，大伙儿对于指纹的信息量，应该有一些粗浅的认识了吧？

多个指纹的综合定位

若是能同时获取【互不相关】的若干个指纹，就能够大大增长定位的精确性。 好比要在某个公司里面定位某人，若是你知道此人的“生日”和“生肖”，那么就能够达到 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”两种身份追踪技术。二者的原理相似——都是利用某些特殊的信息来定位你的身份。二者的本质差别在于：

1. cookie 须要把信息保存在浏览器端，因此会被用户发现，也会被用户清除。
2. 而“浏览器指纹”无需在客户端保存任何信息，不会被用户发觉，用户也没法清除（换句话说：你甚至没法判断你访问的网站到底有没有收集浏览器指纹）。

“浏览器指纹”包含哪些信息？

浏览器暴露给网站的信息有不少种，常见的有以下几种：

User Agent

关于 User Agent 是什么，已经在本系列前面的 博文中有简单的说明，已了解的同窗能够继续往下看。

屏幕分辨率

这个比较通俗易懂。稍微补充一下：这一项不只包括屏幕的尺寸，还包括颜色深度（好比你的屏幕是16位色、24位色、仍是32位色）。

时区

这个也比较通俗。咱们应该都是“东8区”。

浏览器的插件信息

也就是你的浏览器装了哪些插件。 再罗嗦一次：浏览器的“插件”和“扩展”是两码事儿，别搞混了。本系列前面的博文扫盲了二者的差别，连接在“ 这里”。

浏览器的字体信息

和浏览器相关的一些字体信息。 若是你的浏览器安装了 Flash 或 Java 插件，有可能会暴露某些字体信息。因此在“ 如何防范浏览器泄露上网隐私”一文中就警告了浏览器插件的风险。

HTTP ACCEPT

这是 HTTP 协议头中的一个字段。考虑到列位看官大都不是搞 IT 技术的，这里就不深刻解释这项。

其它

以上就是常见的浏览器指纹。固然啦，还有其它一些信息也能够成为“浏览器指纹”，考虑到篇幅就不一一列举并解释了。有兴趣的同窗，请自行阅读 Mozilla 官网的 文档。

如何看本身浏览器的指纹？

关于浏览器指纹致使的隐私问题，多是由“ 电子前哨基金会”（简称 EFF）率先在2010年曝光的。后来 EFF 提供了一个页面，帮助网友看本身浏览器的指纹（请点击“ 这个连接”）。 打开此页面以后，当中有一个大大的，红色的“TEST ME”按钮。点一下此按钮，稍等几秒钟，会显示出一个表格，里面包含你当前的浏览器的指纹信息。 在这个表格中会列出每一项指纹的“信息量”以及该指纹的“占比”。关于“信息量”的含义，本文前面已经扫盲过，此处再也不说明。你只需记住，某项的信息量越大，就说明该项越独特。而越独特的指纹，对隐私的威胁也就越大。 考虑到篇幅有点长，今天先聊到这里。下次跟你们分享如何防范“浏览器指纹”致使的隐私风险。 via： 编程随想的博客

 

 

Fingerprint.js - Browser fingerprinting and fraud detection https://fingerprintjs.com/

 

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:

Entropy of various pieces of browser information

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

 

Filed  bugs.  Hsivonen 09:33, 18 June 2010 (UTC)

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.

Supercookies

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.

Recommend privacy-related addons and services

"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.

See Also

• Chromium's list of client identification mechanisms