Who Filters the Filters: Understanding the Growth, Usefulness and Eiciency of Crowdsourced Ad Blocking
Peter Snyder Antoine Vastel Benjamin Livshits Brave Soware University of Lille / INRIA Brave Soware / Imperial College USA France London [email protected] [email protected] United Kingdom [email protected] ABSTRACT 1 INTRODUCTION Ad and tracking blocking extensions are popular tools for improv- As the web has become more popular as a platform for information ing web performance, privacy and aesthetics. Content blocking and application delivery, users have looked for ways to improve the extensions generally rely on lter lists to decide whether a web privacy and performance of their browsing. Such eorts include request is associated with tracking or advertising, and so should popup blockers, hosts.txt les that blackhole suspect domains, be blocked. Millions of web users rely on lter lists to protect their and privacy-preserving proxies (like Privoxy 1) that lter unwanted privacy and improve their browsing experience. content. Currently, the most popular ltering tools are ad-blocking Despite their importance, the growth and health of lter lists are browser extensions, which determine whether to fetch a web re- poorly understood. Filter lists are maintained by a small number of source based on its URL. e most popular ad-blocking extensions contributors who use undocumented heuristics and intuitions to are Adblock Plus 2, uBlock Origin 3 and Ghostery 4, all of which determine what rules should be included. Lists quickly accumulate use lter lists to block unwanted web resources. rules, and rules are rarely removed. As a result, users’ browsing Filter lists play a large and growing role in making the web pleas- experiences are degraded as the number of stale, dead or otherwise ant and useful. Studies have estimated that lter lists save users not useful rules increasingly dwarf the number of useful rules, with between 13 and 34% of network data, decreasing the time and re- no aenuating benet. An accumulation of “dead weight” rules sources needed to load websites [3, 17]. Others, such as Merzdovnik also makes it dicult to apply lter lists on resource-limited mobile et al. [15] and Gervais et al. [4], have shown that lter lists are im- devices. portant for protecting users’ privacy and security online. Users is paper improves the understanding of crowdsourced lter rely on these tools to protect themselves from coin mining aacks, lists by studying EasyList, the most popular lter list. We measure drive-by-downloads [11, 24] and click-jacking aacks, among many how EasyList aects web browsing by applying EasyList to a sample others. of 10,000 websites. We nd that 90.16% of the resource blocking ough lter lists are important to the modern web, their con- rules in EasyList provide no benet to users in common browsing struction is largely ad hoc and unstructured. e most popular scenarios. We use our measurements of rule application rates to lter lists—EasyList, EasyPrivacy, and Fanboy’s Annoyance List— taxonomies ways advertisers evade EasyList rules. Finally, we are maintained by either a small number of privacy activists, or propose optimizations for popular ad-blocking tools that (i) allow crowdsourced over a large number of the same. e success of EasyList to be applied on performance constrained mobile devices these lists is clear and demonstrated by their popularity. Intuitively, and (ii) improve desktop performance by 62.5%, while preserving more contributors adding more lter rules to these lists provide over 99% of blocking coverage. We expect these optimizations beer coverage to users. to be most useful for users in non-English locals, who rely on However, the dramatic growth of lter lists carries a downside in supplemental lter lists for eective blocking and protections. the form of requiring ever greater resources for enforcement. Cur- rently, the size and trajectory of this cost are not well understood. ACM Reference format: We nd that new rules are added to popular lter lists 1.7 times arXiv:1810.09160v3 [cs.CR] 21 May 2020 Peter Snyder, Antoine Vastel, and Benjamin Livshits. 2016. Who Filters the more oen than old rules are removed. is suggests the possibility Filters: Understanding the Growth, Usefulness and Eciency of Crowd- that lists accumulate “dead” rules over time, either as advertisers sourced Ad Blocking. In Proceedings of ACM Conference, Washington, DC, adapt to avoid being blocked, or site popularity shis and new sites USA, July 2017 (Conference’17), 13 pages. come to users’ aention. As a result, the cost of enforcing such lists DOI: 10.1145/nnnnnnn.nnnnnnn grows over time, while the usefulness of the lists may be constant or negatively trending. Understanding the trajectories of both the costs and benets of these crowdsourced lists is therefore important Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed to maintain their usefulness to web privacy, security and eciency. for prot or commercial advantage and that copies bear this notice and the full citation on the rst page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permied. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specic permission and/or a fee. Request permissions from [email protected]. 1hp://www.privoxy.org/ Conference’17, Washington, DC, USA 2hps://adblockplus.org/ © 2016 ACM. 978-x-xxxx-xxxx-x/YY/MM...$15.00 3hps://github.com/gorhill/uBlock DOI: 10.1145/nnnnnnn.nnnnnnn 4hps://www.ghostery.com Conference’17, July 2017, Washington, DC, USA Peter Snyder, Antoine Vastel, and Benjamin Livshits
is work improves the understanding of the eciency and 2 BACKGROUND trajectory of crowdsourced lter lists through an empirical, longitu- 2.1 Online tracking dinal study. Our methodology allows us to identify which rules are useful, and which are “dead weight” in common browsing scenarios. Tracking is the act of third parties viewing, or being able to learn We also demonstrate two practical applications of these ndings: about, a users’ rst-party interactions. Prior work [2, 10, 23] has rst in optimally shrinking lter lists so that they can be deployed shown that the number of third-party resources included in typical on resource-constrained mobile devices, and second, with a novel websites has been increasing for a long time. Websites include these method for applying lter list rules on desktops, which performs resources for many reasons, including monetizing their website 62.5% faster than the current, most popular ltering tool, while with advertising scripts, analyzing the behavior of their users using providing nearly identical protections to users. analytics services such as Google analytics or Hotjar, and increasing their audience with social widgets such as the Facebook share 1.1 Research questions buon or Twier retweet buon. While third-party resources may benet the site operator, they For two months, we applied every day an up-to-date version of oen work against the interest of web users. ird-party resources EasyList to 10,000 websites, comprising both the 5K most popular can harm users’ online privacy, both accidentally and intentionally. sites on the web and a sampling of the less-popular tail. We aimed is is particularly true regarding tracking scripts. Advertisers to answer the following research questions: use such tracking tools as part of behavioral advertising strate- (1) What is the growth rate of EasyList, measured by the num- gies to collect as much information as possible about the kinds ber of rules? of pages users visit, user locations, and other highly identifying (2) What is the change in the number of active rules (and rule characteristics. “matches”) in EasyList? (3) Does the utility of a rule decrease over time? 2.2 Defenses against tracking (4) What proportion of rules are useful in common browsing Web users, privacy activists, and researchers have responded to scenarios? tracking and advertising concerns by developing ad and tracker (5) Do websites try to stealthily bypass new ad-blocking rules, blocking tools. Most popularly these take the form of browser and if so, how? extensions, such as Ghostery or Privacy badger.5 ese tools share (6) What is the performance cost of ”stale” lter rules to users the goal of blocking web resources that are not useful to users, but of popular ad-blocking tools? dier in the type of resources they target. Some block advertising, others block trackers, malware or phishing. ese tools are popular 1.2 Contributions and growing in adoption [14]. A report by Mozilla stated that in In answering these questions, we make the following primary con- September 2018, four out of the 10 most popular browser extensions tributions: on Firefox were either ad-blockers or tracker blockers. Adblock Plus, the most popular of all browser extension, was used by 9% of (1) EasyList over time: we present a 9-year historical anal- all Firefox users 6. ysis of EasyList to understand the lifetime, insertion and Ad and tracking blockers operate at dierent parts of the web deletion paerns of new rules in the list. stack. (2) EasyList applied to the web: we present an analysis of the usefulness of each rule in EasyList by applying EasyList • DNS blocking relies on a hosts les containing addresses to 10,000 websites every day for over two months. of domains or sub-domains to block, or similar information (3) Advertiser reactions: we document how frequently ad- from DNS. is approach can block requests with domain vertisers change URLs to evade EasyList rules in our dataset or sub-domain granularity, but cannot block specic URLs. and provide a taxonomy of evasion strategies. Examples of domain-blocking tools include Peter Lowe’s 7 8 9 (4) Faster blocking strategies: we propose optimizations, list , MVPS hosts or the Pi-Hole project . based on the above ndings, to make applying EasyList • Privacy proxies protect users by standing between the performant on mobile devices, and 62.5% faster on desktop client and the rest of the internet, and ltering out unde- environments, while maintaining over 99% of coverage. sirable content before it reaches the client. Privoxy is a popular example of an intercepting proxy. 1.3 Paper organization • Web browsers can aempt to prevent tracking, either through browser extensions or as part of the browser directly. ese e remainder of this paper is organized as follows. Sections 2 tools examine network requests and page renderings, and and 7 provides a brief background about tracking and ad-blockers use a variety of strategies to identify unwanted resources. as well as a discussion of the related work. Section 3 presents a Some tools, such as Privacy Badger use a learning-based 9-year analysis of EasyList’s evolution. Section 4 presents how EasyList rules are applied on websites. Section 5 studies how our ndings can improve ad-blocking applications on iOS and proposes 5hps://www.e.org/fr/node/99095 6 two new blocking strategies to process requests faster. Finally, in hps://data.refox.com/dashboard/usage-behavior 7hp://pgl.yoyo.org/adservers/ Section 6 we present the limitations, and we conclude the paper in 8hp://winhelp2002.mvps.org/hosts.htm Section 8. 9hps://pi-hole.net/ Who Filters the Filters: Understanding the Growth, Usefulness and Eiciency of Crowdsourced Ad BlockingConference’17, July 2017, Washington, DC, USA
approach, while most others use lter lists like EasyList 10 or EasyPrivacy 11.
2.3 EasyList Network rules EasyList, the most popular lter list for blocking advertising, was 12 created in 2005 by Rick Petnel. It has been maintained on Github 47.3% since November 2009. EasyList is primarily used in ad-blocking extensions such as Adblock Plus, uBlock origin and Adblock, and has been integrated into privacy oriented web browsers13. Tools also exist to convert EasyList formats to other privacy tools, like 44.1% Privoxy 14, Element rules EasyList consists of tens-of-thousands of rules describing web 8.6% resources that should be blocked or hidden during display. e format also includes syntax for describing exceptions to more gen- eral rules. EasyList uses a syntax similar to regular expressions, Exception rules allowing authors to generalize on paerns used in URLs. EasyList provides two categories of benet to users. First, Ea- syList describes URLs that should be blocked, or never fetched, Figure 1: Distribution of rules by type in EasyList. in the browser. Blocking resources at the network layer provides both performance benets (e.g. reduced network and processing costs) and privacy improvements (e.g. reduction in number of par- ties communicated with or removal of ngerprinting script code). 3.1 Methodology Second, EasyList describes page elements that should be hidden EasyList is maintained in a public repository on GitHub. We use Git- at rendering time. ese rules are useful when blocking at the Python 15, a popular Python library, to measure commit paerns network layer is not possible. and authors in the EasyList repository over the project’s 10-year Element hiding rules can improve the user experience by hiding history. unwanted page contents, but cannot provide the performance and privacy improvements that network layer blocking provides. 3.1.1 Measurement frequency. For every commit in the EasyList ere are three types of rules in EasyList: repository, we record the author and the type and number of rules modied in the commit. (1) Network rules, that identify URLs of requests that should First we grouped commits by day. We then checkout each day be blocked. commits and measure which rules have been added and removed (2) Element rules, that indicate HTML elements that should since the previous day. We use this per-day batching technique to be hidden. avoid artifacts introduced by git diff, which we found causes (3) Exception rules, that contradict network rules by ex- over-estimations of the number of rules changed between commits. plicitly specifying URLs that should not be blocked, even though they match a network rule. 3.1.2 Accounting for changes in repository structure. e struc- Figure 1 shows the constitution of EasyList in February 2019. Of ture of the EasyList repository has changed several times over the the 71,217 rules making up EasyList, 33,703 (47.3%) were network project’s history. At dierent times, the list has been maintained rules, 6,125 (8.6%) were exception rules, and 31,389 (44.1%) were in one le or several les. e repository has also included other element rules. distinct-but-related projects, such as EasyPrivacy. We use the fol- lowing heuristics to aribute rules in the repository to EasyList. 3 COMPOSITION OF EASYLIST OVER TIME When the repository consists of a single easylist.txt le, we check to see if the le either contains references (e.g. URLs or le is section measures how EasyList has evolved over its 9-year paths) to lists hosted elsewhere, or contains only lter rules. When history, through an analysis of project’s public commit history. e the easylist.txt le contains references to other lists, we treat section proceeds by rst detailing our measurement methodology, EasyList as the union of all rules in all referenced external lists. along with our ndings that EasyList has grown to comprise nearly When easylist.txt contains only lter rules, we treat EasyList 70,000 rules and that it is primarily maintained by a very small as the content of the easylist.txt le. number of people. e section concludes by showing that most When the repository consists of anything other than a single rules stay more than 3.8 years in EasyList before they are removed, easylist.txt le, we consider EasyList to be the content of all the suggesting a huge accumulation of unused rules. les matching the following regular expression ’easylist *.txt’ and that are located in the main directory or in a directory called 10hps://easylist.to/pages/about.html easylist. 11hps://easylist.to/easylist/easyprivacy.txt 12hps://github.com/easylist/easylist 13hps://brave.com/ 14hps://projects.zubr.me/wiki/adblock2privoxy 15hps://gitpython.readthedocs.io/en/stable/index.html Conference’17, July 2017, Washington, DC, USA Peter Snyder, Antoine Vastel, and Benjamin Livshits
1.0 120,000 Insertions Deletions 100,000 Number of rules 0.8
80,000 0.6
60,000 0.4 40,000
0.2 insertions / deletions Fraction of Rules (0-1)
Cumulative number of 20,000
0 0.0 0 2 4 6 8
2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 Rule Lifetime (year)
Figure 2: Evolution of the number of rules in EasyList. Over Figure 3: Cumulative distribution function of the lifetime a 10-year period, EasyList grew by more than 70,000 rules. of the rules in EasyList. Half of the rules stay more than 3.8 years in EasyList.
3.2 Results 4 EASYLIST APPLIED TO THE WEB 3.2.1 Rules inserted and removed. Figure 2 presents the change is section quanties which EasyList rules are triggered in com- in the size of EasyList over time. It shows the cumulative number mon browsing paerns. We conducted this measurement by ap- of rules inserted, removed, and present in the list over nine years. plying EasyList to 10,000 websites every day for two months, and Rules are added to the list faster than they are removed, causing recording which rules were triggered, and how oen. EasyList to grow larger over time. Over a 9-year period, 124,615 is section rst presents the methodology of a longitudinal, rules were inserted and 52,146 removed, resulting in an increase online study of a large number of websites. We then present the of 72,469 rules. EasyList’s growth is mostly linear. One exception results of this measurement. We nd that over 90% of rules in is the sharp change in 2013, when “Fanboy’s list”, another popular EasyList are never used. We also show that on average, 29.8 rules lter list, was merged into EasyList. were added to the list every day, but that these new rules tend to 3.2.2 Modification frequency. We analyzed the distribution of be less used than rules that have been in EasyList for a long time. the time between two commits in EasyList and observed that Ea- e section concludes by categorizing and counting the ways syList is frequently modied, with a median time between commits advertisers react to new EasyList rules. We detect more than 2,000 of 1.12 hours, and a mean time of 20.0 hours. situations where URLs are changed to evade rules and present a taxonomy of observed evasion strategies. 3.2.3 EasyList contributors. Contributors add rules to EasyList in two ways. First, potential contributors propose changes in the 4.1 Omitting element rules 16 EasyList forum. Second, contributors can post issues on the e results presented in this section describe how oen, and under EasyList Github repository. what conditions, network and exception rules apply to the web. ough more than 6,000 members are registered on the EasyList However, as discussed in Section 2.3, EasyList contains three types forum, we nd that only a small number of individuals decide of rules: network rules that block network requests, exception rules what is added to the project. e ve most active contributors are that prevent the application of certain network rules, and element responsible for 72,149 of the 93,858 (76.87%) commits and changes. rules that describe parts of websites that should be hidden from the 65.3% of contributors made less than 100 commits. user for cosmetic reasons. We omit element rules from our measurement for three reasons. 3.2.4 Lifetime of EasyList rules. Figure 3 presents the distribu- First, our primary concern is to understand how the growth and tion of the lifetime of rules in EasyList. e gure considers only changes in EasyList aect the privacy and security of Web browsing, rules that were removed during the project’s history. Put dier- and element rules have no eect on privacy or security. In all ently, the gure shows how much time passed between when a rule modern browsers, hiding page elements has no aect on whether was added to EasyList, and when it was removed, for the subset those elements are fetched from the network and, in the case if of rules that have been removed. We observe that 50% of the rules