续：AdBlock 官网对这件事的回应和 ABP 后续回复

[题外话] Adblock Plus 的作者质（pao）疑 （hong）Chrome 另一个扩展 AdBlock 这篇文章发表后，AdBlock 在官方博客发表了文章进行回应，解释了他们所做的一切的原因，ABP 作者在回复中继续质疑。我应邀又翻译了一下，有些保留英文是因为拿捏不准。

AdBlock 官网博文：http://blog.getadblock.com/2014/07/adblock-and-privacy.html


AdBlock 和隐私


昨天 Adblock Plus 的 Wladimir Palant 突然在其个人博客发表了一篇文章将矛头指向我们，里面有提到这段话：

AdBlock 项目组只是假装关注用户的隐私。从他们的所作所为上看，很显然他们在做决定时绝无考虑任何隐私问题。

我从没见过 Adblock Plus 团队，所以我不想就他们发表任何意见。我见过运作 Adblock Plus 的公司 Eyeo 的 CEO - Till Faida，他很有魅力，也富有洞察力。但哪怕我认为他是一个混蛋，我也不会擅自揣测他或他团队的想法。

我赞同 Wladimir 所说的应该增加一个隐私策略声明（我们也正在做这件事），我们的代码中也确实有一个 bug（现在已经修复）。Beyond that, Wladimir takes our attempts to do right by our users with a small team, and paints an incorrect picture.

这篇文章太长了，一般人懒得看，但如果你有兴趣继续了解，那就一起来看看 Palant 是怎么说的：

AdBlock 起初是一个开放的项目，托管在 Google Code 上，任何人都可以查看和贡献代码。然而他们却在 2013 年 8 月关闭了代码库并在项目描述中引导用户去下载他们的源代码包。尽管源代码仍可见，但要想提取出所有的变动，你得花费不少的精力。

AdBlock 还是一个开源的 GPLv3 项目，代码公开在 code.getadblock.com。从 Google 移走托管项目是因为我们很少收到那里来的补丁，而且既要用来汇报 bug
又要提供技术支持也很不利于我们服务好几百万个不太懂技术的用户。所以我们转移到了 Tender 来提供技术支持，并且新开了一个 Github 私人代码库写代码。我认为从一个小团队继续服务用户角度来说这么做很对。代码原来是可读的，并且注释完整，但我也是才发现 Wladimir 说移走后查看代码变动变得不方便了。

总结： AdBlock 偷偷的改变了原来的公开开发模式，对用户隐瞒他们所有的变动，而且既不告诉用户他们的决定也不解释原因。将源代码存档留在那里也仅仅是为了假装 AdBlock 还是一个开源项目，关键是你还很难找到，很明显项目负责人是希望没人能从中提取出任何的变动。他们隐瞒了什么？

Palant 这番说法在我看来有些失态。

我们就新点子邀请用户参与调查本来就不是什么秘密，当然其中一个原因也确实是和 Disconnect 合作有关，但绝没有什么阴谋。事实上，AdBlock 代码里面就有这样的一行：
path: ‘/partnership_analytics.json?’

真没那么神秘！再说一次：它就在 AdBlock 的源代码里面，谁都可以看到。

另外， Disconnect 的那些人一直都致力于保护隐私。他们的反跟踪扩展每周都有一百多万人使用，而且一直以来都有大量新闻媒体对他们在保护互联网隐私方面所做的事情进行报导。

我们很高兴自己也被新闻媒体用同样的话提到。

AdBlock 现在不仅仅是发送唯一用户 ID 到他们的服务器，他们还会发送用户是否允许显示 Google 搜索广告的设置。

用户 ID 是随机生成的，并且不会在计算机、浏览器之间或重新安装时保留，也不和用户个人信息相关联（我们也不想要这些个人信息）。我们主要是用它来收集一些显示粗略用户规模的匿名数据，比如有多少法语用户在使用，大多数用户需要多久才会更新到最新版本，用户会否经常开启“我愿意显示 Google 广告”功能之类的。

所有的广告还是会默认屏蔽掉。至今，AdBlock 的收入都还完全来自捐助。我们让用户参与调查是想了解他们是否赞成我们通过其他方式获取资金。如果大家有什么想法，欢迎随时告诉我们！

还有一件有趣的事是当用户每次访问 getadblock.com 时上面提到的唯一用户ID 都会被发送到这个网站，甚至如果他们访问的是 getadblock.com.malicious.com 或任何包含 getadblock.com 这几个字的网站，也一样会发送。如果我是一个以广告收入为生的站长，我会利用这个 bug 在每个网页中都插入一个隐藏的帧框架来跟踪用户。也许哪个网站已经想到了吧？而更新日志是怎么描述这个变动呢？--“就调查表进行 Beta 测试”。是的，没错。

这就是为什么 AdBlock 主页会知道是否 AdBlock 已经安装了，也是我们对付信用卡诈骗的一种方法。的确这方面的文档几乎没有，但我们的本意是不想给骗子可乘之机。那个 “getadblock.subdomain.com” 的 bug 也确实存在，不过我们已经修复了。

AdBlock 2.6.21-2.6.27: Disconnect.me 的功能已经深入其中了，看过去是 Disconnect 的开发者亲自对功能进行改动，比如实现了试用和付费的会员功能，Disconnect 搜索广告的白名单也有所变化。按更新日志的说法，这些变化还是“就调查表进行 Beta 测试”。

我们只在很小范围内对用户进行调查，问他们是否愿意在 AdBlock 里使用 Disconnect 的功能以及对付费的看法。当然这就需要增加一些代码来让所调查用户对功能进行试用。我再重申一次，我们这么做是要保证所有获取资金的方式都必须得到用户的认可。这对我们来说很重要。

“AdBlock 自定义过滤规则”（AdBlock 默认推荐并安装的专属过滤规则）添加了一系列过滤规则白名单允许在 AdBlock 网站使用 Mixpanel 跟踪用户。

MixPanel 是一个类似于 Google Analytics 的工具，用来帮助我们记录信用卡诈骗犯的信息（见上文）并改进安装以后显示的页面。

总结：如果某个项目突然决定隐藏起来开发，通常就会发生一些不好的事儿了。就 AdBlock 这件事来说，就是指和 Disconnect.me 合伙利用用户来赚钱，还不让用户知道。一旦有用户注意到并提出疑问，他们就试图淡化这件事的影响。

我觉着 Palant 在他文章很多地方都力求不倾向任何一方，但很明显他的断言解释了为什么他要说这篇文章与官方博客无关。

“利用用户来赚钱”和“还不让用户知道” 这两个用语很容易让人在脑海里出现一幅 AdBlock 的用户被偷偷变成美元符号的画面。实际上我们所做的正是征求用户关于 AdBlock 未来发展方向的意见。到现在为止 AdBlock 的唯一收入来源还是捐助，询问用户其他获取资金的渠道和我们移走 Google 托管项目这两件事之间毫无关系。

总结：AdBlock 项目组只是假装关注用户的隐私。从他们的所作所为上看，很显然他们在做决定时绝无考虑任何隐私问题。

我从没见过 Wladimir Palant，我只知道他是一个见多识广的开发者。但从他文章最后两段看的出来他也是一个深思熟虑的家伙。在隐私和用户 ID 方面，他在文章中像哲学家一样说出了一些建设性的观点，结果 Hacker News 讨论帖反而出现了很多有趣的评论。

大家知道吗？我们的确需要一份隐私策略声明。大家知道为什么直到去年年中 AdBlock 才有了自己的主页吗？是的，Chrome 和 Safari 浏览器最受欢迎的扩展在2013 年以前居然还没有自己的主页，甚至除了 Michael 以外没有一个全职的开发者，但我们仍然有足够的时间发布比 FAQ 更正规的隐私说明。所以我们还会继续做这件事。


发表自 Gabriel Cubbage

共 7 条评论：

Wladimir Palant July 31, 2014 at 2:16 PM
Gabriel，我不太同意你所说的观点。

AdBlock 还是一个开源的 GPLv3 项目

是的，从技术上来说它还是开源的，但却不是我所说的那种开源项目。从你们将代码库设为私有，更新日志与实际变动不符开始，其他人就很难确认你们在干什么了。
  
请注意我显然没有批评你们在问题跟踪上有所隐藏，所以我不知道你为何要对此进行辩解。就算你们在最终用户支持方面做得更到位了（我们也是），我仍然觉得一
个开源项目还是得让用户看到他们如何跟踪问题，让整个决策过程更加透明。但你们也不是非得这么做。

事实上，AdBlock 代码里面就有这样的一行：
...
真没那么神秘 ！

我不是真的在说这行代码的事儿，再说这行指向 https://goldenticket.disconnect.me/goldenticket/ticket/fetch 的代码非常不起眼。我们没必要这么挑剔。但请问，有多少人注意到了这行代码然后问你们怎么回事？你有在哪里说过你已经和 Disconnect 合作，或者对用户解释过这会有什么影响吗？

另外， Disconnect 的那些人一直都致力于保护隐私。

没错，但隐私完全是建立在信任的基础上。当用户安装了AdBlock，他们会被问到是否相信 AdBlock 项目，他们在相信的同时却想不到他们也选择了相信 Disconnect。正如我所说的，Disconnect 的隐私策略很棒，甚至因为这个才走到今日。但每个人都应该自己来决定相信什么。我想再说的是如果你们宣布这个合作伙伴，那就没任何问题了。

用户 ID 是随机生成的，并且不会在计算机、浏览器之间或重新安装时保留。

是的，就像是 cookies，你本应该用 cookies 来代替。但不一样的是用户 ID 在清除历史记录以后还在，哪怕用户开启了隐私浏览模式。

你还记的当初 Chrome 刚出来时最被诟病的功能是哪个吗？没错，就是安装时指派给用户唯一客户 ID，当然当时这么做有很多好处。没过多久 Google 最终还是决定去掉那玩意儿，但至少人家一开始就有文档说明啊。

所有的广告还是会默认屏蔽掉。

嗯，Disconnect 搜索广告只有在“隐私搜索”功能开启（似乎是选择性开启）的情况下才会添加到白名单。难道选择开启时用户不应该事先得到提醒吗？

当然 MixPanel 跟踪不属于广告，所以我猜默认添加为白名单也没什么大不了。

这就是为什么 AdBlock 主页会知道是否 AdBlock 已经安装了

没必要使用用户 ID，只要简单的 "yes, AdBlock here" 就够了。

大家知道为什么直到去年年中 AdBlock 才有了自己的主页吗？

我不知道。adblockforchrome.com 在 2012 年三月就已经创立了，你的 Google+ 页面最早发表于 2011 年，甚至这里的博客在 2011 年就有文章发表了。所以如果你想说你之前没法和用户交流的话，我是不认同的。在我看来，2013 年只是 adblockforchrome.com 功能转移到getadblock.com 的时间点。


所以，你们所计划要实现的仅仅只是一个隐私策略这么简单吗？



上面的回复有3条评论：

Michael MastAugust 3, 2014 at 10:32 PM

Palant 先生，那为什么我应该转而使用 Adblock Plus呢？您的项目是如何获取资金的？几乎我的客户都不在意你提出的观点，他们只关心是不是看不到任何广告。这方面您的项目有什么优势吗？（不是讽刺，我是真有兴趣了解）


Wladimir PalantAugust 4, 2014 at 8:43 AM
如果你只关心所使用的功能，那确实没有什么理由非要你从 AdBlock 转到 Adblock Plus 或从后者转到前者。就像我文章里面说的，两个产品都很好用，主要看个人喜好。只是 Adblock Plus 会鼓励你允许显示某些广告以便支持这些网站，而这项功能很容易关闭（事实上初次运行的页面就已经解释过了）。  
如果真有什么区别，那就是隐私和用户控制方面。Adblock Plus 致力于保持透明并让用户主导。AdBlock 似乎不是这样，至少没我们做的好。在不在乎这点完全得由你自己来决定。


Dojan5August 4, 2014 at 1:56 PM
据说 AdBlock Plus 项目最近有在暗地里通过放行某些广告来收钱，有这回事吗？加上你突然批评 AdBlock 让我难以接受。
这几年我一直换着使用这两个产品，我始终觉得 AB 更好用。加上最近几个星期媒体上关于 ABP 的各种流言蜚语，我不太愿意再次尝试和推荐 ABP。




AdBlock 没声音，WP 继续说：
Wladimir PalantJuly 31, 2014 at 2:38 PM
抱歉，我在前一个评论当中弄错了域名，AdBlock 项目之前用的域名是chromeadblock.com，创建于2009 年。


对此有人说：

Alan ColonAugust 6, 2014 at 12:31 AM

"在我看来，2013 年只是 adblockforchrome.com 功能转移到getadblock.com 的时间点。"    

http://web.archive.org/web/20090715000000*/http://chromeadblock.com    
从技术上说，这个域名的功能是一个重定向，原来是重定向到 AdBlock 的 chrome 应用商店，而现在是重定向到它的新主页。所以功能上其实是一样的，没有“转移”到任何地方，唯一的变化是它指向哪里。要争论的话，这件事也和 chromeadblock.com 的年龄没什么关系。


WP 不甘寂寞，又说：

 Wladimir PalantAugust 4, 2014 at 5:10 PM
看起来很少有人会去读这篇文章（我之前回复时也没看到任何指向这篇文章或这个博客的链接），所以我还是在这里继续评价一下你其余的观点吧。

我也不会擅自揣测他或他的团队的想法

我当然也不知道 AdBlock 团队在实现某些”功能”时到底在想什么（我希望我知道）。我至今只和 Michael Gundlach 有过交流，他看过去是一个有能力的开发者，不是什么卑鄙小人。但很不幸，你们损害隐私的行为以及自相矛盾的承诺最后只能归结为不怀好意（malice）或不称职（incompetence）。假设 Michael 现在还在参与这个项目（似乎他还在），你们也还是不称职（incompetence doesn’t cut it）。

我们主要是用它来收集一些显示粗略用户规模的匿名数据。

直到现在，AdBlock 网站仍然宣称 “AdBlock 绝不会保存或获取您的个人浏览习惯或信息，哪怕有任何超越正常使用本身的理由。”
从你博客的文章来看，似乎你还没发现你的错误。难道让 AdBlock 运行就必须要获取这些信息（包括用户 ID）吗？还是你们打算修改这句话？

我们只在很小范围内对用户进行调查，问他们是否愿意在 AdBlock 里使用 Disconnect
的功能以及对付费的看法。当然这就需要增加一些代码来让所调查用户对功能进行试用。

好吧，就假设你们的更新内容只是一份“调查表”吧，我们甚至可以假设如果用户说“不，我不喜欢”，你们就可以移除所有这些代码，哪怕你们为此已经投入了很
多精力。但你们实现了两种调查表功能还是显得很奇怪，一个是通过你们自己的服务器，另一个则是通过 Disconnect 的（很显然后者对隐私有影响）。好吧，我们就称之为“不称职”。

甚至在这些假设条件下，AdBlock 2.6.20 版本也完成了调查表功能的添加，但 AdBlock 2.6.21 到 AdBlock 2.6.27 期间所有的变动都只涉及到 Disconnect
 的功能。难道你们想说既然这些变动是“就调查表进行 beta 测试”，那就不必提及 Disconnect 了吗？

“利用用户来赚钱”和“还不让用户知道” 这两个用语很容易让人在脑海里出现一幅 AdBlock
的用户被偷偷变成美元符号的画面。实际上我们所做的正是征求用户关于 AdBlock 未来发展方向的意见。

坦白说，我不知道会有多少用户看到这段话和了解这段话的意思。这个调查表不在你们的源代码当中，所以你们也不用费心去建立关于它的文档。你们的观点也不是
在吹嘘，只是事情应该像这样子来做。

我所知道的是在调查表功能正式出现之前的测试过程当中，就有一些 AdBlock 用户被打开了 Disconnect 功能，我也知道用户在打开 Disconnect 功能时会被推荐使用 Disconnect 的付费会员机制同时自动将其广告添加到白名单，而后者也没有提供任何通知，用户根本不知道广告会显示，也无法禁用这个白名单。你们确信合作伙伴在赚钱的同时，这种暗中进行的做法又不会造成用户流失。从逻辑上来说，结果要么是已经一起赚钱，要么就是在这项功能正式发布给 Adblock 用户以后再一起赚钱。如果不是这样，我很有兴趣听听是怎么一回事。

我还想回 无法回复呢

嗯  看完了 感觉这场嘴仗还会有后续

pcxfirefox：我还想回 无法回复呢回到原帖

两个帖子，怕有人插楼，所以锁定以后编辑。担心不多余，你差点插楼。

文科：嗯  看完了 感觉这场嘴仗还会有后续回到原帖

那肯定的，AB 也在赚钱，而且势头很好，影响了 ABP 的财路，因为 ABP 不是唯一的选择。ABP 肯定要打击一下竞争对手。如果是 ABP 公司的话会有人质疑，如果是 ABP 作者个人的话会好很多。于是。。。

好长……我居然看完了……不过他们打嘴炮去吧，我该用啥还是用啥，更多用户也只会关心哪个更简单更易于获取吧

最近试了 chrome 的 uBlock，发现它的确省内存点。它隐藏元素采用了 2 种方式：直接修改 DOM，让它 display:none 和插入样式表。所以某个 iframe 很多的测试网站，uBlock 就不会像 ABP 一样占用内存高达 1.7G。

hzzhaiqi：最近试了 chrome 的 uBlock，发现它的确省内存点。它隐藏元素采用了 2 种方式：直接修改 DOM，让它 display:none 和插入样式表。所以某个 iframe 很多的测试网站，uBlock 就不会像 ABP 一样占用内存...回到原帖

估计是因为插入的样式表小，abp插入的样式表规则太多，而且很多都是通用杀伤力强的规则。目前来看，是用内存换取过滤效果。如果要效果又好，内存又省，估计算法必须有极大改进。

自从用了外部过滤软件以后，完全不怀念abp。外部过滤有效性同abp比较 可谓各有千秋，前者因为能进行文本替换，更加强大，能对付abp无可奈何视频广告和js内部修改，后者则基于浏览器而有HTTPS支持（说实话，这个就是google的一些文字广告）。效率方面外部软件都是用C或者C++写的，性能比abp好得多，实际表现无论内存占用还是页面的打开速度都比扩展类优秀

meat：自从用了外部过滤软件以后，完全不怀念abp。外部过滤有效性同abp比较 可谓各有千秋，前者因为能进行文本替换，更加强大，能对付abp无可奈何视频广告和js内部修改，后者则基于浏览器而有HTTPS支持（说实话，这个就是google的一些文字广...回到原帖

你用的是什么外部过滤软件啊？

P.S. 既然独立软件和浏览器扩展各有千秋，如果前者融合后者，拦截效果应该更出众。

meat：自从用了外部过滤软件以后，完全不怀念abp。外部过滤有效性同abp比较 可谓各有千秋，前者因为能进行文本替换，更加强大，能对付abp无可奈何视频广告和js内部修改，后者则基于浏览器而有HTTPS支持（说实话，这个就是google的一些文字广...回到原帖

外部软件和ABP，AB 存在一样的问题，都需要合适的隐私策略，都应该小心信息被收集。

fang5566：估计是因为插入的样式表小，abp插入的样式表规则太多，而且很多都是通用杀伤力强的规则。目前来看，是用内存换取过滤效果。如果要效果又好，内存又省，估计算法必须有极大改进。回到原帖

uBlock 的效果也很好，基本上跟 ABP 的一样。不知道为什么 ABP 不采用这种混合的方式，个人感觉这种混合的方式不错，能有效减少内存占用。

hzzhaiqi：最近试了 chrome 的 uBlock，发现它的确省内存点。它隐藏元素采用了 2 种方式：直接修改 DOM，让它 display:none 和插入样式表。所以某个 iframe 很多的测试网站，uBlock 就不会像 ABP 一样占用内存...回到原帖

在我看来
如果直接使用样式（display:none）无论内联或者外联，是隐藏不了一些用js动态修改display的广告的。
另外，
ABP中使用了XBL binding来隐藏广告，网页端几乎没机会再将广告显现。
而ADB的只是（好像ABP for Chrome的也是） display:none，
对于后者广告商只要给广告设置一个定时器，定时设置其display:block!imporatnt; 值就能简单破解。

lonely_8：在我看来
如果直接使用样式（display:none）无论内联或者外联，是隐藏不了一些用js动态修改display的广告的。
另外，
ABP中使用了XBL binding来隐藏广告，网页端几乎没机会再将广告显现。
而ADB的只是（好...回到原帖

长见识了，我说查看新浪新闻隐藏广告的时候， ABP 怎么是 -moz-binding 的。但好像 ADB 等工具也能正常隐藏广告，难道都没用定时器？