@Reficul
现在还是能唯一识别 6.0

第一个是 /proc 还能找到真实 MAC ，这部分要到 Android N 才会堵上
第二个是 Android ID/GSF ID/seiral(永久的)还能拿到，特别是 seiral 没有保护掉，所以还是能唯一追踪硬件

@xmbaozi

我们一般 ublock/umatrix 屏蔽所有第三方域名内容和第一方脚本， cookie
然后根据需要一点点手工白名单

所以基本上所有的第三方统计代码，和相当程度的第一方统计代码都被优化了

不考虑第三方的或者隐藏的权限管理工具(*)的话，目前只有 Android 6.0 自带交互式的权限系统，这个系统形式上基本和 iOS 的一致。区别在于：

为 Android 6 设计的应用采用这一套做法，为旧版本的应用则(在应用 Android 6 的一些全局约束外)默认按照旧系统的做法放行所有权限，但用户可以随时吊销 protection level 为 dangerous 列表中的任意权限，以及 wirte_settings 和在其它应用上显示两个非 runtime-permission 。

禁掉 wirte_settings 后，应用将不能写入一个系统数据库，似乎还因此导致了别的限制。
很多应用喜欢把设备识别码写到这个数据库。

新权限系统的原型是 Android 4.3 就出现，但不向用户开放界面的 AppOps(*)，在 Android 6 里， AppOps 依然存在，且是新权限系统的基础

@cabbage
6.0 以前的 Android 没有吊销权限的能力


@ericyl
至于本机的 WiFi 与 BT 的 mac
6.0 的处理是一律返回 20:00:00:00:00:00
现在还有一个洞，是通过 /proc 还能获得真实的本机 MAC

外部的 mac 需要获得定位权限系统才会提供

在虚拟机里装 pc 旺旺

手机的话，如果是 Android 6 ，则可以新建一个用户配置，在这个配置文件里装旺旺
Android 5 的非手机主用户配置不允许 adb ，也不允许非 Google Play 来源

you-get

@ilikekindle

所以这个新闻炒热也有好处

VS 的 Androidm 模拟器性能极好？

两个都不哦

@uleh
抠这个字眼的意义在于：

adblock (1)
adblock plus
adblock (for chrome)

是三个不同的东西

adblock plus 是 wladimir palant 负责的项目，最初是 Firefox 的扩展，它的原型工程是 adblock ， adblock 的维护者不干了，就把 adblock 给了他。现在 adblock plus 是 Eyeo 公司的产品， Wladmir palant 是 Eyeo 的创始人 /雇员？

adblock (for chrome)是另一个人开发的，最初是专为 Google Chrome 开发的软件

adblock Edge 是从 adblock plus 开始提供可接受 ad 特性前分裂出来的分支

ublock 是 gorhill 的项目，开发到一定程度后转给了 chrisaljoudi
过了一段时间 gorhill 又想继续写代码了，于是找了某个版本的 ublock ， fork 到了 ublock origin
ublock 和 ublock origin 一开始似乎共享了大多数变动，现在两者之间的距离可能远一些，但两个扩展基本上还是一致的


adblock plus 有这些版本：
adblock plus 浏览器(iOS/Android, Android 版本是一个 Mozilla Firefox 衍生版)
adblock plus(Android 应用)
adblock plus(iOS App Extension, Safari 的 Content blocker)
adblock plus 的 IE 扩展 /Chrome 扩展 /Firefox 扩展，有没有 Opera 和 Safari 的扩展我不清楚

此外有关 adblock 的叙述可能有误
这部分的故事是
wladimir palant 有一天在自己的博客吐槽了 adblock (for chrome)
另外 adblock (for chrome)是 GPLv3 软件，源代码以每个版本打一个包的形式发布，打包包括了 changelog

adblock plus(hg.adblockplus.com)
ublock/ublock origin(项目在 github)
的源代码都公开到完整的代码库乃至整个项目

---------------------------------
此外过滤广告的道德依据是这样的：

1 ，过滤广告继承于(通用的)过滤网页上的内容
2 ，过滤网页上的内容这项功能是浏览器的功能的一项
3 ，使用浏览器的某项功能的权利继承于用户是浏览器的使用者
4 ，用户是浏览器的使用者继承于用户是这台设备(如电脑，手机)的使用者(且所有者)

所以这里任何一环节，投放广告的网站都插不了手
它能表达反对的地方，只能是：
5 ，识别出反广告措施，并给出惩罚措施(如不提供内容，黑屏，提示等，见优酷等视频网站，某些网盘)
这种行为叫 Anti-adblock


因为 2 和 3 ，用户可以做到反对网站的反对
意味着
Anti-Anti-adblock 是可行的
常见的例子就是通过 greasemonkey 表达的 user scripts ，这部分代码的作用通常是让 5 失效

@tmdwex06895
是一回事情啊，所谓自我审查

"哪天苹果在国内开放这个 app 就好了"
这句话不对
因为苹果是被迫不能在国内开放这个 app 的

@uleh adblock 似乎自身就是广告软件(或者是自带用户追踪代码)
注:adblock 不是 Adblock plus 的原型"adblock"

@mdemo

ublock origin 应该是用了一套比 Adblock Plus 更好的算法
似乎 ublock origin(以及 ublock)似乎会在运行时编译已选上的规则， Adblock plus 也是

这两个软件都是 js 代码，需要一个 js 引擎来执行
而且依赖于 WebRerquest 等浏览器 API ，这部分的性能不容易优化

Android 的应用版 Adblock Plus 自带了 Google V8 引擎



Eyeo 的原文在这里：

https://adblockplus.org/blog/content-blocking-in-safari-9-and-ios-9-good-news-or-the-death-knell-of-ad-blocking-on-safari

另外还看到这样的说明：

https://adblockplus.org/blog/adblock-plus-for-ios-9-finally-here-and-pssst-it-s-free

The content blocking API Apple provided only allows for a limited amount of filters; atm including an anti-tracking list would exceed that limit. Here ’ s hoping they expand it …

看样子是有一个“ 50000 rules limitation ”


这里有一篇文章讲 content blocker API 的性能优势：
http://blog.appgrounds.com/content-blockers-beat-adblocking/

@xenme 比方说有没有测试过 blocklist.json 的复杂度(比如条目数量)，会多少程度地影响性能？

举例：
https://github.com/chrisaljoudi/uBlock/wiki/uBlock-vs.-ABP:-efficiency-compared

@mdemo
我猜测
像 cpro.baidustatic.com 这种太常见的域名不太可能没过滤掉的

另外希望求证：
Adblock plus 的开发者 Eyeo GmbH 说 iOS9 的 content block API 性能不佳(和它们跑在浏览器 javascript 引擎上的 adblock plus 相比)，是这样的吗？

此外，很多人也知道有一个性能(比 Adblock Plus)更快的拦截器扩展 ublock origin/ublock

@XuanYuan
仔细看了下
这个应用可以实时查看扩展 /应用执行了哪些动作