Ted Dziuba has penned a humorous and sharp-tongued piece for The Register about last week’s Adblock vs. NoScript fiasco.  For those of you who aren’t Firefox junkies, a nasty public spat broke out between the makers of these two very popular Firefox Browser extensions (they are the #1 and #3 most popular downloads respectively).  To make a long and complicated story much shorter, basically, NoScript didn’t like Adblock placing them on their list of blacklisted sites and so they fought back by tinkering with the NoScript code to evade the prohibition.  Adblock responded by further tinkering with their code to circumvent the circumvention!  And then, as they say, words were exchanged.

Thus, a war of words and code took place.  In the end, however, it had a (generally) happy ending with NoScript backing down and apologizing. Regardless, Mr. Dzuiba doesn’t like the way things played out:

The real cause of this dispute is something I like to call Nerd Law.  Nerd Law is some policy that can only be enforced by a piece of code, a public standard, or terms of service. For example, under no circumstances will a police officer throw you to the ground and introduce you to his friend the Tazer if you crawl a website and disrespect the robots.txt file. The only way to adjudicate Nerd Law is to write about a transgression on your blog and hope that it gets to the front page of Digg. Nerd Law is the result of the pathological introversion software engineers carry around with them, being too afraid of confrontation after that one time in high school when you stood up to a jock and ended up getting your ass kicked.

Dziuba goes on to suggest that “If you actually talk to people, network, and make agreements, you’ll find that most are reasonable” and, therefore, this confrontation and resulting public fight could have been avoided. They “could have come to a mutually-agreeable solution,” he says.

But no. Sadly, software engineers will do what they were raised to do. And while it may be a really big hullabaloo to a very small subset of people who Twitter and blog their every thought as if anybody cared, to the rest of us, it just reaffirms our knowledge that it’s easy to exploit your average introvert.  After all, what’s he gonna do? Blog about it?

OK, so maybe the developers could have come to some sort of an agreement if they had opened direct channels of communications or, better yet, if someone at the Mozilla Foundation could have intervened early on and mediated the dispute.  At the end of the day, however, that did not happen and a public “Nerd War”  ensued.  But I’d like to say a word in defense of Nerd Law and public fights about “a piece of code, a public standard, or terms of service.”

What we had here was a code war that, despite some nastiness, was resolved reasonably well and on a reasonably timely basis.  Now, imagine if this sort of dispute had gone legal, or worse yet, been subjected to a federal regulatory proceeding.  Can you imagine the Federal Communications Commission being asked to adjudicate such a thing!  Next time you hear of a major dispute coming before the commission, start your stopwatch and pray that it doesn’t die before the FCC finally gets around to rendering its judgment on the matter at hand. Worse yet, sit back and watch as entire forests will fall from the resulting paperwork war as both sides hire teams of lawyers, economists, and consultants to file an endless stream of indecipherable documents with the Commission.

What got me thinking about all this is that recently I’ve been critiquing Lessig’s “code-is-law” thesis and pointing out that code really doesn’t have the same force as law, and thank God it doesn’t!  Precisely because it does not have the coercive capacity of actual law or regulation it means that code developers must use other means to persuade competitors or the public to side with them in disputes.  It means that code developers must find ways to innovate around problems, sometimes even creating messy code wars in the process.  And yes, it sometimes means that, when that process goes badly, a war of words may take place online.  But still, isn’t that better than the legal alternative or a regulatory approach?

And, so, when Mr. Dziuba suggests that “The only way to adjudicate Nerd Law is to write about a transgression on your blog and hope that it gets to the front page of Digg,” I guess I just don’t see as much of a downside to that approach as he does.  I share his belief that it would be nice to get both sides to a table to talk and hopefully to hammer out an agreement, but sometimes that doesn’t always happen in cyberspace or in realspace for that matter. What’s going on here is the same game that companies and unions have been playing for years:  Push the envelope in public by any means necessary to drive a better bargaining position when you eventually must come to the table and reach an agreement.  Athletes and sports clubs do the same thing.

Thus, I am rather fond of “Nerd Law,” or “Code Wars” or whatever you want to call it. (Perhaps “hard-nosed public negotiations” is the better umbrella term).  Let coders have their fights and air their dirty laundry in public because, at the end of the day, that process will likely reach a better conclusion than if they took a highly legalistic or regulatory approach to things.  I do not mean to suggest that law or regulation never has a place in resolving disputes. Rather, I am suggesting that the sheer cost of the legal / regulatory route — in terms of time, money, lost innovation opportunities, etc — makes is generally sub-optimal when compared to relying on non-legal means of dispute resolution.

So, let the coders have their Nerd Wars, I say.  And let the best code win.

As a means of introducing myself to TLF readers, this is an article that I wrote for the PFF blog in September that has not been previously mentioned on the TLF. Most of my other PFF blog posts have been cross-posted by Adam Thierer or Berin Szoka, but I’ve taken ownership of those posts so they appear on my TLF author page.

This is the first in a series of articles that will focus directly on technology instead of technology policy. With an average age of 57, most members of Congress were at least 30 when the IBM PC was introduced in 1981. So it is not surprising that lawmakers have difficulty with cutting-edge technology. The goal of this series is to provide a solid technical foundation for the policy debates that new technologies often trigger. No prior knowledge of the technologies involved is assumed, but no insult to the reader’s intelligence is intended.

This article focuses on cookies–not the cookies you eat, but the cookies associated with browsing the World Wide Web. There has been public concern over the privacy implications of cookies since they were first developed. But to understand them , you must know a bit of history.

According to Tim Berners Lee, the creator of the World Wide Web, “[g]etting people to put data on the Web often was a question of getting them to change perspective, from thinking of the user’s access to it not as interaction with, say, an online library system, but as navigation th[r]ough a set of virtual pages in some abstract space. In this concept, users could bookmark any place and return to it, and could make links into any place from another document. This would give a feeling of persistence, of an ongoing existence, to each page.”[1. Tim Berners-Lee, Weaving The Web: The Original Design and Ultimate Destiny of the World Wide Web. p. 37. Harper Business (2000).] The Web has changed quite a bit since the early 1990s.

Today, websites are much more dynamic and interactive, with every page being customized for each user. Such customization could include automatically selecting the appropriate language for the user based on where they’re located, displaying only content that has been added since the last time the user visited the site, remembering a user who wants to stay logged into a site from a particular computer, or keeping track of items in a virtual shopping cart. These features are simply not possible without the ability for a website to distinguish one user from another and to remember a user as they navigate from one page to another. Today, in the Web 2.0 era, instead of Web pages having persistence (as Berners-Lee described), we have dynamic pages and “user-persistence.”

This paper describes the various methods websites can use to enable user-persistence and how this affects user privacy. But the first thing the reader must realize is that the Web was not initially designed to be interactive; indeed, as the quote above shows, the goal was the exact opposite. Yet interactivity is critical to many of the things we all take for granted about web content and services today.

Stateful Sessions

On the original World Wide Web designed by Berners-Lee (Web 1.0), Web servers responded to each client request without relating that request to previous requests. There was no need to remember what other pages the user had requested because the requests were for static pages. But if you’ve used a Web-based email system like Gmail, Hotmail, Yahoo! Mail, etc., you know that once you log in, the service remembers who you are as you click from message to message. When a website can keep track of a user as they move from page to page within a site it is called a “stateful session.” The website doesn’t necessarily need to know anything about the user, it just needs to be able to distinguish that particular user from all other users. For example, if you go to an online store and place a few items in your virtual shopping cart, the site still does not know your name, email address, or billing information. But it does know what you’ve placed in your cart–or more precisely, it knows what someone using your browser has placed placed in a particular cart. If you leave the site before buying anything and then go back an hour later, it’s possible that the site will have completely forgotten about you. In that case, the unique identifier persists during your “session” on the site, but it doesn’t persist between sessions.

URLs and HTTP Requests

Web 1.0 sites achieve Web page persistence by having a unique address or Uniform Resource Locator (URL) for each Web page, which is displayed in the address bar at the top of your browser as you browse the web. For example, http://www.pff.org/about/ is a simple URL pointing to a specific Web page. Every user that visits the PFF site at www.pff.org and clicks on the “About” link will be taken to the exact same page.

URLs can also store information about the user. For example, if you search for “test” on Google, the URL of the resulting page may look like the following: http://www.google.com/search?q=test&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a.[2. http://googlesystem.blogspot.com/2006/07/meaning-of-parameters-in-google-query.html] The URL contains a number of different pieces of data, separated by ampersands. There is the search query (“q=test”), the character encoding of the input (“ie=utf-8”), the character encoding of the output (“oe=utf-8”), the type and language of the client (“rls=org.mozilla:en-US:official”), and the Web browser used (“client=firefox-a”). None of this information can be used to uniquely identify the user, but this basic example illustrates how URLs can be used to specify more than simply static Web pages–and how some information can be remembered as a user navigates a website even without using cookies. Knowing how this works, you can create your own advanced searches or change the way the results are formatted (e.g., changing the language).

So how did Google know I speak English and use Firefox? That information is included in the HTTP request that my Web browser sends to the Google Web server when it requests a page. HTTP requests specify (among a few other more technical things) the desired language and a “User-Agent” field that includes the name of the browser and sometimes your operating system. This information allows websites to customize their content for different Web browsers (e.g., to ensure that it displays properly). HTTP requests also include your IP address so the Web server knows where to send its response, and geotagging allows Web servers to associate an IP address with a geographic area (though the area is rarely more accurate than the country or state). HTTP requests can also contain HTTP cookies.

HTTP Cookies

URLs can be used to uniquely identify individual users and allow stateful sessions, but unless a user bookmarks the URL containing their unique identifier, there is no way for the site to associate the same unique identifier with the same user on subsequent visits. Another option is to have users create an account and then log in each time they access the site. The website could then include the user’s unique ID in the URL on subsequent pages, so that the user only needs to log in once per session. Having to bookmark or create an account on every site you want to remember you would quickly become unmanageable. It would be nice if mapping and weather websites, for example, just remembered your location. It would be nice if the blogs you follow remembered what post you last read and displayed only unread posts when you next visit their site. What was needed at this point in the Web’s evolution was a way for websites to automatically store a unique identifier on the user’s computer and send it back to the website automatically[3. A site could also try to uniquely identify users by the IP address of their computer, but this is unreliable as there can be many computers behind a firewall sharing a single IP address.]—which is precisely what a cookie does.

To quote Wikipedia,

“HTTP cookies, or more commonly referred to as Web cookies, tracking cookies or just cookies, are parcels of text sent by a server to a Web client (usually a browser) and then sent back unchanged by the client each time it accesses that server. HTTP cookies are used for authenticating, session tracking (state maintenance), and maintaining specific information about users, such as site preferences or the contents of their electronic shopping carts.”

A cookie can contain one or more pieces of data, a description and/or URL for an online description of the cookie, how long the Web browser should store the cookie, and the domain, path, and port that the cookie should be limited to. Cookies can be set to expire after a specified interval, or can be “session cookies” that will expire when the Web browser is closed. When a cookie expires, it is deleted by the Web browser. Unexpired cookies are automatically sent back to the originating Web server when the Web browser makes any subsequent requests to the same server (the same domain, path, and port).

Neither Web servers nor Web browsers are required to support cookies, but a server may refuse to work with a Web browser that does not return the cookie(s) it sends. Cookies do not contain any executable code and are extremely small in size. They only contain data sent by the website and the data is not changed by the client computer, so there generally should be no privacy concerns about sending a cookie back to the website that created it (“First-party cookies”).

First-Party and Third-Party Cookies

Cookies are normally only sent to the server setting them or a server in the same domain ( e.g., a cookie set by mail.google.com could be shared with calendar.google.com). These are called first-party cookies because they’re set by the site displayed in the address bar of the Web browser. These cookies are typically used to tailor the website for the user. Third-party cookies, on the other hand, are typically used by advertising networks to track users across multiple Web sites where the networks have placed advertising–which allows the advertising network to target subsequent advertisements to the user’s presumed interests and also to limit the number of times a user is shown a particular ad. This targeting allows the delivery of “smarter” advertising that is less annoying and more informative to the user–and therefore more valuable to the advertiser, who will be willing to pay websites more for their ad space. However, this targeting also raises privacy concerns.

It is trivial for a Web page to contain images or other components stored on servers in other domains (“third-party elements”). In fact, it is often easier to link to an image already hosted online elsewhere than it is to host an image on your own Website.

Examples:

• Typical first-party embedded image:
• Typical third-party embedded image:

Whenever a Web browser loads a Web page or component of a Web page, it will include in its request for that component any cookies already stored on the user’s computer that are associated with the domain hosting the content. The Web server, in turn, can send a cookie or update a cookie already existing on the user’s computer.

Although your Web browser will not send a third-party cookie to the first-party Web server (and it won’t send a first-party cookie to the third-party Web server), the first-party Web server can send information to the third-party Web server by embedding it in the URL for the third-party content. The most common form of this communication between the sites you visit and the sites they rely on for content or ads is called a “web bug”–a small (usually 1 pixel by 1 pixel) graphic not meant to be noticed by the user. Its purpose is to cause the user’s Web browser to load the third-party embedded content from the external Web server, which will allow the third party (usually an advertising network) to track the user.

• Example third-party embedded web bug:

While this all may seem scary and invasive,the fact that a website or ad network can uniquely identify your browser does not mean that they have any clue who you are. Even if you provide your name, email address, or other personally-identifiable information to the first-party Web site, most sites’ privacy policies state that they will not share this information with their advertising partners. To use a real-world analogy, third-party advertising is equivalent to a marketer in a mall watching you come out of a music store and then offering you a flyer for a concert: The marketer may know that you’re interested in music (because you were shopping at the music store), but they have no idea who you are. And as my colleagues Adam Thierer and Berin Szoka explained in their post on Adblock Plus, websites (especially smaller independent websites) depend on advertising as a source of revenue and to cover their overhead costs.

Alternatives to Cookies

Cookies are not the only way websites can do stateful sessions. As has already been mentioned, Websites can put unique identifiers in URLs. But custom URLs don’t last between sessions. Websites that need to remember users ( e.g., websites that charge a fee for access) can require users to create an account and log into the site every time they use it.

But most websites do not require users to create an account and log in every time. And more and more users are configuring their Web browsers to delete all cookies when they close the browser. In response, Web site operators have found other methods to uniquely identify users by storing a unique identifier on users’ computers.

The cookie alternatives listed below are not any more or less invasive of privacy than cookies if the user is aware of them and manages them the same way they manage cookies. But most Web browsers don’t give users the same amount of control over cookie alternatives that they do over cookies, and few users know about these alternatives.

Per-session cookie alternatives – These cookie alternatives are not saved to disk and thus are not accessible after you close your Web browser.

• Hidden form fields – Web pages can contain hidden Web forms that submit data back to the Web server when an on-screen button is pressed. This method is quite limited because it requires the user to click a specific button, and there is no method for saving data after you’ve navigated away from the site. Beyond these limitations, the only way to detect hidden form fields is to inspect the HTML code for a page. There is also no easy way to block hidden form fields.
• window.name – JavaScript embedded in a Web page can set or read the this internal value that’s not really used for anything else. The value can be up to 32 megabytes in size and once set a value can be accessed by any Web site. Although the only way to detect this is to inspect the HTML code for a page, you can disable JavaScript.

Persistent cookie alternatives – These cookie alternatives are like cookies in that they are saved on your computer and can be accessed even after you’ve closed your Web browser.

• Flash Cookies – Also known as Local Shared Objects, Flash cookies require Adobe Flash to be installed on your computer. Whereas HTTP cookies are limited to 4 kilobytes, Flash cookies can contain up to 100 kilobytes by default and can contain an unlimited amount of data if the user desires. To view and delete the Flash cookies stored on your computer, go to this page (although accessed via a Web page, the Flash cookies shown are stored on your computer). You can also permanently disable Flash cookies on that page.
• DOM Storage – DOM storage was designed specifically to allow Web 2.0 applications to work offline, saving data locally when they are unable to access the host website and to save data that would otherwise be lost if a page is accidentally reloaded. DOM storage is currently only implemented in Firefox (and Internet Explorer 8 Beta). If cookies are disabled, DOM storage is also disabled. Users can also manually disable DOM storage even when cookies are enabled.
• userData behavior – The userData behavior does for Internet Explorer what DOM storage does for Firefox. Each “document” is limited to 128 kilobytes of storage, with a per-domain limit of 1024 kilobytes. The data is stored in Internet Explorer’s cache and are deleted when you delete cookies using the Delete Browsing History dialog box.

Conclusion

This article should give you a better sense of what cookies are used for and how they work. You should now see that per-session cookies and cookie alternatives are completely harmless. Persistent cookies (and cookie alternatives) can make your Web browsing a bit easier, but deleting them will not (in most cases) cause any problems. If you are concerned about your privacy, you will need to do a bit more than just delete cookies–you also need to delete or disable the above-mentioned cookie alternatives.

By Adam Thierer & Berin Szoka

The goal of our “Privacy Solution Series,” as we noted in the first installment, is to detail the many “technologies of evasion” (i.e., user-empowerment or user “self-help” tools) that allow web surfers to better protect their privacy online—and especially to defeat tracking for online behavioral advertising purposes.  These tools and methods form an important part of a layered approach that, in our view, provides an effective alternative to government-mandated regulation of online privacy.

In this second installment in this series, we will highlight Adblock Plus (ABP), a free downloadable extension for the Firefox web browser (as well as for the Flock browser, though we focus on the Firefox version here).

Purpose: The primary purpose of Adblock Plus is to block online ads from being downloaded and displayed on a user’s screen as they browse the Web.  In a broad sense, this functionality might be considered a “privacy” tool by those who consider it an intrusion upon, or violation of, their “privacy” to be “subjected” to seeing advertisements as they browse the web.  But if one thinks of privacy in terms of what others know about you, Adblocking is not so much about “privacy” as about user annoyance (measured in terms of distracting images cluttering webpages or simply in terms of long download times for webpages).  In this sense, ABP may not qualify as a “technology of evasion,” strictly speaking.  But, as explained below the fold, ABP does allow its users to “evade” some forms of online tracking by blocking the receipt of some, but not all, tracking cookies.

Cost: Like almost all other Firefox add-ons, both the ABP extensions and the filter subscriptions on which it relies (as described below) are free.

Popularity / Adoption: While there are a wide variety of ad-blocking tools available, Adblock Plus is far and away the leader.  ABP has proven enormously popular since its release in November 2005 as the successor to Adblock, which was first developed in 2002 and reached over 10,000,000 downloads before being abandoned by its developer and even today garners nearly 40,000 downloads a week.  This history of Adblock provides further details.

ABP was named one the 100 best products of 2007 by PC World magazine and is now the #1 most downloaded add-on for Firefox with over 500,000 weekly downloads, up significantly for just a few months.  In a blog post last month, ABP creator Wladimir Palant estimated that “no more than 5% of Firefox users have Adblock Plus installed,” but that percentage is bound to grow larger as more people discover Adblock.  As one indicator of ABP’s popularity, the number of Google searches for “Adblock” has nearly eclipsed the number of searches for “identity theft,” which seems like a far more serious concern than having to look at web ads.

Of course, not every Firefox user would chose to use Adblock even if they were aware of it.  For example, one of us (Berin) finds it indispensable and leaves it on all the time.  The other (Adam) almost never turns it on, preferring to see what sort of ads are being served on each page he visits.  For those users primarily concerned with having their browsing tracked, there are other tools more effective than ABP for that purpose, as future entries in this series will describe.

This raises a point we make in our upcoming paper on online advertising and privacy:  Internet users all have different preferences and sensitivities when it comes to ads and online privacy.   Some of us find ads annoying, intrusive, and potentially privacy-violating.  Others of us just don’t care or even find some informational benefit in seeing them—especially when they are tailored to our particular interests.  Fortunately, tools like Adblock Plus let us each decide for ourselves what sort of browsing experience and privacy protections to use—rather than relying on the heavy, clumsy hand of Big Government to impose sweeping regulations that make a one-size-fits-all determination for everyone.

How Adblock Plus Works: Adblock Plus on its own offers nothing more than the capability to filter certain elements (images, external scrips, frames, Flash, etc.) sent to the user’s computer when they attempt to download the contents of a webpage.  Unbeknownst to many users, the HTML code of most webpages includes instructions to download images and other content (such as ads) stored on that website or on third party sites.  ABP does not recognize ad images as such, so it cannot automatically distinguish ads from non-ad content.  Instead, ABP relies on a blacklist of terms that the keeper of the list has determined correspond to parts of a URL used to load ads.  The following screenshot illustrates how ABP works:

The user here (Berin) subscribed to EasyList USA, the most commonly-used U.S. “filter” (blacklist + whitelist) when he first installed AdBlock.  (Additional filter subscriptions are available here.)  The “filter rules” are ranked by “Hits” or number of ads blocked since the filter was installed (in May 2008).  Shown here are only the top examples of effective filters, such as any URL that begins with “http://ad.” or contains “/ads/”.  Also shown here are three custom ad filters created by Berin.  This clip (click on “Show me how this is done”) illustrates how users can block images to create their own custom ad filter.  Last, the green text is just the most commonly-applied filter rule contained in EasyList’s white list of terms that should not be blocked, trumping black list filters.  For example, htttp://wikimedia.org/wikipedia/ads/… would normally be blocked because of the “/ads/” filter rule in the blacklist, but the green white list filter rule in our example trumps that rule to make sure that all URLs containing “htttp://*.wikimedia.org/wikipedia” (where * is a wild card operator) will not be blocked.

As mentioned above, ABP can block the downloading of some tracking cookies by preventing the user’s computer from attempting to download an element (usually an image) associated with that cookie—called “web bugs” or “web beacons.”  As Wikipedia explains:

Originally, a Web bug was a small (usually 1×1 pixel) transparent GIF or PNG image (or an image of the same colour of the background) that was embedded in an HTML page, usually a page on the Web or the content of an e-mail. Modern Web bugs also use the HTML IFrame, style, script, input link, embed, object, and other tags to track usage. Whenever the user opens the page with a graphical browser or e-mail reader, the image or other information is downloaded. This download requires the browser to request the image from the server storing it, allowing the server to take notice of the download. As a result, the organization running the server is informed when the HTML page has been viewed.

Larger Implications: As you can imagine, advertising networks and advertisers are less than thrilled about the idea of users blocking their ads, but it is website operators that have thus far objected most strongly to ad-blocking, because it threatens what is for many websites the only source of revenue.  Even amateur sites that do not have to pay for content production often rely on advertising revenue to cover other costs, such as hosting.  It’s not hard to imagine why many site operators might want to discourage or thwart ad-blocking to maintain the quid pro quo of the online economy:  Users get free content and services from websites in exchange for looking at advertising, which websites can sell through ad networks to advertisers.  This dilemma is not unique to the online world, of course.  In the offline context, television advertisers have responded to ad-skipping via DVRs through increasing reliance on product placement.

But because web-browsing is an essentially interactive experience between the user’s browser and the website, website operators may have greater leverage in the relationship with a user who wants to block ads.  In particular, the website may be able to detect the use of ABP, at least indirectly through the pattern of page element blocking caused by ABP’s use. (Prior to June 2008, websites could directly detect whether a browser was using ABP by noticing the presence of an API interface designed to allow ABP to work with other extensions, but this feature was removed in a recent update to ABP.)

Thus, once adblocking rises above a certain “acceptable loss” threshold, a website could respond in at least three distinct ways:

1. Moral exhortation – websites might display this kind of pop-up notice to ABP users:

   

2. “Blocking” adblocking – Because ABP’s relies on relatively crude keyword filters to distinguish ad elements of a page from content elements, websites can confuse these filters by making advertisements less easily distinguishable from content.  On the one hand, websites might attempt to “embed” advertisements a la television product placement.  On the other, we may see ad networks rely more on distributing ads through websites directly, rather than from ad network servers, so that adblocking filters cannot easily identify ads by the source referenced in their URL.
3. Tying website functionality to the acceptance of tracking cookies – As mentioned above, Adblock will block some “tracking cookies” by blocking the downloading from ad network servers of web beacons—which is often how such cookies are placed on the uer’s computer in the first place.   By requiring the downloading of those cookies to access the full functionality of the site, websites might be able to require users to accept tracking cookies in exchange for full access to the site.

As is so often the case, this will likely result in a war of “spy v. spy,” whereby the user community develops better evasive measures, and the websites community develops better countermeasures, and so on–as illustrated in this scene from the 1998 Marky Mark cult-classic film, The Big Hit: (Warning: Includes foul language).

Related Reading & Links

• Download Adblock Plus for Firefox (ver. 0.7.5.5)
• Adblock for Flock browser
• Adblock Plus main page (English language version)
• Adblock Plus blog
• How to disable Adblock Plus on your bookmarked pages (i.e., create a whitelist for accepted ads)
• Wikipedia entry
• Interview with Adblock creator Wladimir Palant
• New York Times article: Noam Cohen, “Whiting Out the Ads, but at What Cost?” New York Times, September 3, 2007.
• Nick Carr on Adblock: “What Would Jesus Do?” (and Wladimir Palant’s response to such criticisms)
• YouTube demo videos:
http://www.youtube.com/v/RAYtLA1ZKW0&hl=en&fs=1 http://www.youtube.com/v/vl4_NEiyVIk&hl=en&fs=1