license agreements – Ben Edelman

September 6, 2016February 23, 2018

Exploring and Assessing Google’s Practices in Mobile

Since its launch in 2007, Android has become the dominant mobile device operating system worldwide. In light of this commercial success and certain disputed business practices, Android has come under substantial attention from competition authorities. In a paper Damien Geradin and I posted this week, we present key aspects of Google’s strategy in mobile, focusing on Android-related practices that may have exclusionary effects. We then assess Google’s practices under competition law and, where appropriate, suggest remedies to right the violations we uncover.

Many of Google’s key practices in mobile are implemented through Mobile Application Distribution Agreements, confidential contracts that became available to the public through Oracle litigation and are available, to this day, only on my site. But we also evaluate Google restrictions embodied in other documents including Google’s Anti-Fragmentation Agreement as well as supplemental contracts with device manufacturers and mobile carriers providing for exclusive preinstallation of Google search.

If one accepts our conclusion that certain Google practices violate competition laws, it’s important to turn to the question of remedies–what changes Google must make. The natural starting point is to end Google’s contractual ties, allowing device manufacturers to install Google apps in whatever configurations they find convenient and in whatever way they believe the market will value. One might expect to see low-cost devices that feature Yahoo Search, MapQuest maps, and other apps that vendors are willing to pay to distribute. Other developers would retain a “pure Google” experience, foregoing such payments from competing app makers but offering apps from a single vendor, which some users may prefer.

Beyond that, remedies might seek to affirmatively restore competition. Because much of Google’s dominance in mobile seems to come from its powerful app store, Google Play, an intervention might seek to shore up other app stores–for example, letting them copy in Google’s APK’s so that they can offer Google apps to users who so choose. A full remedy would also attempt to restore competition for key apps. Just as Europe previously required Microsoft to show a screen promoting five different web browsers when a user booted Windows for the first time, a similar screen could provide users with a genuine choice of Android apps in each area where Google has favored its own offering. We suspect some users would favor a more privacy-protecting location service if that were prominent and easily available. Other users would probably find competing local services, such as TripAdvisor and Yelp, more trustworthy than Google’s offerings. These developments would increase choices for both users and advertisers, reduce the sphere of Google’s dominance, and begin to restore a competitive marketplace in fundamental mobile apps.

Our working paper:

Android and Competition Law: Exploring and Assessing Google’s Practices in Mobile

(Updated October 26, 2016: This article, as revised, is forthcoming in the European Competition Journal.)

May 31, 2016March 25, 2018

How Uber Uses API Restrictions to Block Price Comparison and Impede Competition updated June 3, 2016

Popular as Uber may be, it isn’t the only way to summon a car for a ride across town. In most US cities, Lyft is a strong number two. Here in Boston, Fasten touts lower fees to drivers, promising cheaper rides for passengers and greater revenue to drivers. Drivers often run multiple apps, and passengers switch between them too. If these apps competed fiercely, Uber might be forced to lower its fee, reducing or eliminating profit. So what justifies Uber’s lofty $68+ billion valuation?

For years, Uber has tried to use its API as a potential barrier against competition. Uber invites third-party developers to connect to its servers to get real-time information about vehicle location (how many minutes until a vehicle can pick up a passenger at a given location) and the current level of surge pricing. But there’s a catch: To access data through Uber’s API, developers must agree not to include Uber API data in any tool that Uber deems competitive.

Uber encourages app developers and the general public to think this API restriction is Uber’s right—that Uber’s data is for Uber to use or restrict as it chooses. But the restriction is calculated and intended to block competition—a purpose considered improper under competition laws, and a special stretch for Uber in light of the company’s positions on related issues of competition and regulation.

Uber’s API restrictions

Uber’s API Terms of Use explains Uber’s purpose in remarkable simplicity:

Be a strong, trustworthy partner to Uber. Please do not:

Compete with Uber or try to drive traffic away from Uber.

…

Aggregate Uber with competitors.

Uber’s API Terms of Use then instruct:

In general, we reserve the sole right to determine whether or not your use of the Uber API, Uber API Materials, or Uber Data is acceptable, and to revoke Uber API access for any Service that we determine is not providing added benefit to Uber users and/or is not in the best interests of Uber or our users.

The following are some, but not all, restrictions applicable to the use of the Uber API, Uber API Materials, and Uber Data:

…

You may not use the Uber API, Uber API Materials, or Uber Data in any manner that is competitive to Uber or the Uber Services, including, without limitation, in connection with any application, website or other product or service that also includes, features, endorses, or otherwise supports in any way a third party that provides services competitive to Uber’s products and services, as determined in our sole discretion.

Uber’s developer documentation specifically warns:

Using the Uber API to offer price comparisons with competitive third party services is in violation of § II B of the API Terms of Use. Please make sure that you familiarize yourself with the API Terms of Use to avoid losing access to this service.

Assessing Uber’s API restrictions

The most favorable reading of Uber’s API restrictions is that Uber alone controls information about the price and availability of its vehicles. From Uber’s perspective, accessing Uber’s API is a privilege, not a right. Indeed, some might ask why Uber might be expected, let alone required, to assist a company that might send users elsewhere. A simple contract analysis shows no reason why the restriction is improper; if Uber prominently announces these requirements, and developers willingly accept, some would argue that there’s no problem.

A strong counterargument begins not with the contract but with Uber’s purpose. One might ask why Uber seeks to ban comparisons with other vehicle dispatch services. Uber doesn’t ban aggregators and price comparison tools because it believes these tools harm passengers or drivers. On the contrary, Uber bans aggregators and price comparison tools exactly because they help passengers and drivers but, potentially, harm Uber by directing transactions onto other platforms. Uber’s purpose is transparently to impede competition —to make it more difficult for competing services to provide relevant and timely offers to appropriate customers. Were such competitors to gain traction, they would push Uber to increase quality and reduce its fees. But blocking competing services positions Uber to retain and indeed increase its fees.

Consider a competitor’s strategy in attempting to compete with Uber: Attract a reasonable pool of drivers, impose a lower platform fee than Uber, and split the savings between drivers and passengers. If Uber’s current fee is, say, 20%, the new entrant might charge 10%—yielding savings which could be apportioned as a 5% lower fare to passengers and a 5% higher payment to drivers.

Crucially, aggregators help the entrant reach passengers at the time when they are receptive to the offer. Every user at an aggregator is in the market for transportation, not just generally but at that very moment, making them naturally receptive to an entrant’s offer. Furthermore, a user who visits an aggregator has all but confirmed his willingness to try an alternative to Uber. So aggregators are the most promising way for an entrant to reach appropriate users.

At least as important, aggregators help an entrant gain momentum despite a small scale of operations. At the outset, a new entrant wouldn’t have many drivers. So if a consumer installs the entrant’s app and opens it to check vehicle availability, the entrant’s proposed vehicle would often be further away, requiring that passengers accept longer wait times and that drivers accept longer unpaid trips to reach paid work. Notably, an aggregator helps the entrant reach users already close to the available vehicles—providing an efficient way for the entrant to begin service.

In contrast, without aggregators, entrants face inferior options for getting started. They could advertise in banners or on billboards to attract some users. But those general-purpose ad channels tend to reach a broad swath of users, only a portion of whom need Uber-style service, and even fewer of whom are ready to try a new service. Meanwhile, any users found through these channels will tend to have diverse requirements for ride timing and location; there is no way for an entrant to reach only the passengers interested in rides at the times and places where the entrant has available drivers. With a low density of drivers and passengers, the entrant’s passengers will face longer wait times and drivers will face longer unpaid positioning trips. Some users may nonetheless be willing to try the entrant’s service. But they’ll have to open the entrant’s app to check, for each trip, whether its availability and pricing meet expectations—extra steps that impose delay and will quickly come to seem pointless to all but the most dedicated passengers. As a whole, these factors reduce the likelihood of the new service taking off. Indeed, small transport services have famously struggled. Consider, for example, the 2015 cessation of Sidecar.

Uber might have tried to explain away its API restrictions with pretextual purposes such as server load or consumer protection. These arguments would have been difficult: Price comparison requests are not burdensome to Uber’s servers; Uber nowhere limits the quantity of requests for other purposes (e.g. through an API fee or through throttling). Nor is there any genuine contention that price comparison services are, say, confusing to users; the difference between an Uber and a Lyft ride can be easily communicated via an appropriate logo, on-screen messaging, and the like. But in any event Uber hasn’t attempted these arguments; as Uber itself admits in the rules quoted above, the API restrictions are designed solely to advance the company’s business interests by blocking competition.

The relevant legal principles

One doesn’t readily find antitrust cases about APIs or facilitating price comparison. But Uber’s API partners act as de facto distributors—telling the interested public about Uber’s offerings, prices, and availability. A long line of cases takes a dim view of dominant firms imposing exclusivity requirements on their distributors. Areeda and Hovenkamp explain the tactic, and its harm, in their treatise (3d ed. 2011, ¶1802c at 76):

[S]uppose an established manufacturer has long held a dominant position but is starting to lose market share to an aggressive young rival. A set of strategically planned exclusive-dealing contracts may slow the rival’s expansion by requiring it to develop alternative outlets for its product, or rely at least temporarily on inferior or more expensive outlets. Consumer injury results from the delay that the dominant firm imposes on the smaller rival’s growth.

Most recently, the FTC brought suit against McWane, the dominant US pipe fitting supplier, which had controversially required distributors to sell only its products, and not products from competitors, by threatening forfeiture of rebates and perhaps loss of access to any McWane products at all. The FTC found that McWane’s exclusionary distribution policy maintained its monopoly power; the Eleventh Circuit upheld the FTC’s finding; and the Supreme Court declined to hear the case. McWane thus confirms the competition concerns resulting from exclusive contracts from distributors. In relevant respects, the parallels between Uber and McWane are striking: Both companies use contracts to raise rivals’ costs to prevent them from growing into effective competitors. Compared to McWane, Uber’s API restrictions are in notable respects more aggressive. For example, McWane’s first response to a noncompliant distributor was to withhold rebates, and in litigation McWane protested that its practice was not literally exclusive dealing but rather a procompetitive inducement (through rebates yielding lower prices). Putting aside McWane’s failure in these arguments, Uber could make no such claims, as its API restrictions (and threats to UrbanHail, discussed below) exactly implement exclusive dealing, expelling the noncompliant app or site from access to Uber’s API as a penalty for including competitors.

More generally, Uber’s conduct falls within the general sphere of exclusionary conduct which has been amply explored through decades of caselaw and commentary. The Department of Justice’s 2009 guidance on Single-Firm Conduct Under Section 2 of the Sherman Act is broadly on point and usefully surveys relevant doctrines. As the DOJ points out, the essential question for exclusionary conduct cases is whether a given tactic is appropriate, aggressive competition (which competition policy sensibly allows) versus a practice intended to exclude competition (more likely to be prohibited under competition law). After considering several alternatives, the DOJ favorably evaluates a "no-economic-sense test" that asks whether the challenged conduct contributes profits to the firm apart from its exclusionary effects. In Uber’s case, no such profits are apparent. Indeed, the API restrictions require Uber to turn down referrals from apps that violate the API restrictions—foregoing short-term profits in service of the long-term exclusionary purpose.

The DOJ ultimately offers its greatest praise for an "equally efficient competitor test," asking whether the challenged conduct is likely in the circumstances to exclude a competitor that is equally efficient or more efficient. Uber’s restrictions fare poorly under this test. Consider a more efficient competitor—one with, perhaps, lower general and administrative costs that allow it to charge a lower fee on top of payments to drivers. Uber’s restrictions prevent such a competitor from effectively reaching the consumers who would be most receptive to its offer.

Separately, the DOJ notes the promise of conduct-specific tests that disallow specific practices. While the caselaw on APIs, data access, and price comparison is not yet well-developed, one might readily imagine a conduct-specific test in this area. In particular, if a company offers a standardized and low-burden mechanism for consumers, intermediaries, and others to check its prices and availability, the company arguably ought not be able to withhold access to that information for the improper purpose of blocking competition.

Relatedly, the DOJ points out the value of considering the scope of harm from the challenged conduct, impact of false positives and false negatives, and ease of enforcement. Uber’s restrictions fare poorly on these fronts too. Uber would face little burden in being required to provide data about its prices and availability to comparison services; Uber has already built the software interface to provide this data, and the servers are by all indications capacious and reliable. Enforcement would be easy: Require Uber to strike the offending provisions from its API Terms and Conditions. Uber need not create any new software interfaces or APIs in order to comply; only Uber’s lawyers, but not Uber’s developers, would need take action.

Uber might argue that it is one of many transportation services and that the Sherman Act should not apply given Uber’s small position in a large transport market. Indeed, Sherman Act obligations are predicated on market power, but Uber’s size and positioning leave little doubt about the company’s power. As the leading app-based vehicle dispatch service, Uber would certainly be found a dominant firm in such a market. In a broader market for hired transport services, including taxis and sedans, Uber surely still has market power. For example, analysis of expense reports indicates that business travelers use Uber more than taxis.

Experience of transport comparison services and the case of UrbanHail

As early as August 2014, analysts had flagged Uber’s restriction on developers promoting competing apps. Indeed, the subsequent two years have brought few apps or sites that help consumers choose between transportation platforms—some with static data or general guidance, but no widely-used service with up-to-the-minute location-specific data about surges and vehicle availability. Uber’s API restrictions seem to be working in exactly the way the company hoped.

An intriguing counterexample comes from UrbanHail, an app which promises to present "all of your ridesharing and taxi options in one click to help you save time and money [and] frustration." (UrbanHail was created by five Harvard Business School MBA students as their semester project for the required FIELD 3 course. As part of my academic duties as a HBS faculty member, I happen to teach FIELD 3, though I was not assigned these students. I advised them informally and have no official academic, supervisory, or other affiliation with the students or UrbanHail.)

UrbanHail prompted a response from Uber the same day it launched. In a first email, Uber’s Chris Messina (Developer Experience Lead) wrote:

Hey guys, my name is Chris Messina and I run Developer Experience for Uber. Chris Saad [CC’ed] is the PM of the API.

We wanted to congratulate on your recent press as we love seeing folks innovating in the transit space, but wanted to let you know that your use of our API is in violation of section II B of our terms of use.

We’re more than happy for you to continue developing your app, but ask that you remove any features that list Uber’s prices next to our competitors.

Please let us know if you have any questions. Thanks!

Three weeks later, he followed up:

Hey guys,

I haven’t heard back from you, so I wanted to follow up.

Unfortunately, UrbanHail is still violating the agreements you entered with Uber, including not only the API Terms of Use which I mentioned in my previous email, but also Uber’s rider terms (which prohibit scraping or making Uber’s services available for commercial use).

I’d like to highlight that not only are these conditions found in the legal text, but the spirit of our terms are summarized in plain english at the top of that document. Further, a specific warning to not create a price comparison app is provided in-line in the technical reference for the price estimates API.

Thousands of developers around the world use the Uber API to build new, interesting apps. To preserve the integrity of the Uber experience, we require these apps to stay within the guardrails we’ve created, and are set forth in our terms. Despite our efforts to make these terms and policies clear and transparent, you chose to act against them.

All that being said, we very much value the time and energy that developers like you invest in building with the Uber API, and we actively support and encourage them to be creative and innovate with us.

If you build something that complies with our Terms of Use, we would love to reward your effort in a number of ways. Here are just some of the things we can offer:

* A post on our blog featuring your app

* A listing in our showcase

* Affiliate revenue for referring new Uber riders to us

* Access to our "Insiders Program" which offers office hours with the Uber Developer Platform team and exclusive developer events

Please let me know when you’ve taken UrbanHail out of the App Store and removed any related marketing materials so we can start working on a new opportunity together.

Please note, however, if I don’t hear from you by May 31, I’ll be forced to revoke your client ID’s access the Uber API.

Chris

Today, May 31, is Chris’s deadline. I’ll update this post if Chris follows through on the threat to disable UrbanHail’s API access and prevent the app from including Uber in its price comparison.

Update (June 3): UrbanHail reports that Uber terminated its API access, preventing Uber from appearing within Urbanhail’s results page.

Special challenges for Uber in imposing these restrictions

Uber styles itself as a champion of competition. Consider, for example, CEO Travis Kalanick’s remarks to attendees at TechCrunch Disrupt in 2012. His bottom line: "Competition is good." Uber takes similar positions in its widespread disputes with regulators and incumbents transportation providers—styling its offering as important competition that benefits consumers. Against that backdrop, Uber struggles to restrict third-party services that promise to enhance competition.

Indeed, media coverage of Uber’s dispute with UrbanHail has flagged the irony of Uber criticizing competition from other services. The Boston Globe captioned its piece "New app gives Uber a little disruption of its own," opening with "Uber Technologies Inc. built a big business by pushing past regulations that limit competition with taxis. But the tech-industry darling isn’t always happy with smaller companies trying similar tactics." Boston.com was in accord: "Uber rankled by app that compares ride-hailing prices," as was BostInno: "Uber is trying to shut down this Boston price-comparison app."

Twitter users agreed: Henry George: "@Uber Do you find it the least bit ironic that you’re complaining about ride competition with @urbanhail? Don’t try legal BS, innovate!" Michael Nicholas: "The irony of @Uber complaining @urbanhail is breaking the rules’ of api usage is breathtaking." Gustavo Fontana: "@Uber should leave them alone. It’s fair game."

Uber may dispute whether it has the market power necessary to trigger antitrust law and Sherman Act duties. But Uber’s general position on competition is clear. Uber struggles to chart a path that lets it compete with taxis without the permits and inspections required in many jurisdictions—but doesn’t let comparison shopping services compare Uber’s prices with taxis, Lyft, and other alternatives.

Moreover, Uber’s professed allies are equally difficult to reconcile with the company’s API restrictions. For example, Uber this month announced an advisory board including distinguished ex-competition regulators. Consider Neelie Kroes, formerly the European Commission’s Commissioner for Competition who, in that capacity, oversaw the EC’s €497 million sanctions against Microsoft. Having overseen European competition policy and subsequently digital policy for fully a decade, Kroes is unlikely to look favorably on Uber’s efforts to foreclose entry and reduce competition.

Special challenges for Uber’s developer team in imposing these restrictions

A further challenge for Uber is that its key managers—distinguished experts on software architecture—have previously taken positions that are difficult to reconcile with Uber’s efforts to restrict competition.

Best known for creating the hashtag, Chris Messina (Uber’s Developer Experience Lead) boasts a career espousing "openness." In his LinkedIn profile, he notes a prior position as an "Open Web Advocate" and a board member at the "Open Web Foundation." Describing his work at Citizen Agency, he says he "appl[ied] design and open source principles to consulting." Wikipedia disambiguates Messina from others with the same name by calling him an "open source advocate," a phrase repeated in the first sentence of Wikipedia’s article. Wikipedia also notes a 2008 article entitled "So Open It Hurts" about Messina and his then-girlfriend, describing their "public and open relationship." Google reports 1,440 different pages on Messina’s personal site, factoryjoe.com, mentioning the word "open." While the meaning of "open" varies depending on the context, the general premise is a skepticism towards restrictions and limitations—be they requirements to pay for software, limits on how software is used, or, here, restrictions on how data and APIs are used. It’s a world view not easily reconciled with Uber’s restriction on price comparisons.

Chris Saad (Uber’s API Product Manager) has been similarly skeptical of restrictions on data. His LinkedIn page notes that he co-founded the DataPortability Project which he says "coined and popularized the phrase "data portability"; and led "an explosion of conversation[s] about open standards and interoperability." That’s a distinguished background—but here, too, not easily reconciled with Uber’s API restrictions.

It’s no coincidence that Uber’s developer team favors openness. Openness is the natural approach as a company seeks to connect to external developers. But in limiting how other companies use data, Uber violates key tenets of openness, restricting the flow and use of data that partners and consumers reasonably expect to access.

Looking ahead

Uber faces a looming battle to retain its early lead in smartphone-based vehicle dispatch. But as the dominant firm in this sector—with the largest market share and, to be sure, a category-defining name and concept—Uber is rightly subject to restrictions on its methods of competition. Cloaking itself in the aura of competition as it seeks to avoid regulations that apply to other commercial vehicles, Uber is poorly positioned to simultaneously oppose competition from other app-based services.

Uber is not alone in limiting the ways users can access data. In 2008, I flagged Google’s AdWords API restrictions, which impeded advertisers’ efforts to use other ad platforms as well as Google. Google defended the restrictions, but competition regulators agreed with me: Even as the FTC declined to pursue other aspects of early competition claims against Google, FTC pressure compelled Google to withdraw the API restrictions in January 2013. In Europe, these same restrictions were among the EC’s initial objections to Google’s conduct. Google has yet to resolve this dispute in Europe, and may yet face a fine for this conduct (in addition to substantial fines for other challenged practices). Uber’s API restrictions risk similar sanctions—perhaps even more quickly given Uber’s many regulatory proceedings.

What comes next? If Uber follows through on its threat to UrbanHail, as Messina said it soon would, there will again be no app or site to compare prices and availability across Uber and competitors. Uber won’t need to go to court to block UrbanHail; it can simply withdraw the security credentials that let UrbanHail access the Uber API. From what I know of UrbanHail’s size and stature, it’s hard to imagine UrbanHail filing suit; that would probably require resources beyond UrbanHail’s current means.

Nonetheless, Uber is importantly vulnerable. For example, transport is highly regulated, and Uber needs regulatory approval in most jurisdictions where it operates. This approval presents a natural and easy way for policy makers to unlock Uber’s API restrictions: As a condition of participation in a city’s transit markets—using the public roads among other resources—Uber should be required to remove the offending API restrictions, letting aggregators use this information as they see fit. Once one city establishes this requirement, dozens more would likely follow, and Uber’s API restrictions could disappear as suddenly as they arrived.

February 13, 2014November 21, 2024

Secret Ties in Google’s "Open" Android

Disclosure: I serve as a consultant to various companies that compete with Google. That work is ongoing and covers varied subjects, most commonly advertising fraud. I write on my own—not at the suggestion or request of any client, without approval or payment from any client.

Google claims that its Android mobile operating system is “open” and “open source”—hence a benefit to competition. Little-known contract restrictions reveal otherwise: In order to obtain key mobile apps, including Google’s own Search, Maps, and YouTube, manufacturers must agree to install all the apps Google specifies, with the prominence Google requires, including setting these apps as default where Google instructs. It’s a classic tie and an instance of full line forcing: If a phone manufacturer wants any of the apps Google offers, it must take the others also.

In this piece, I present relevant provisions from key documents not previously available for public examination. I then consider the effects on consumers, competitors, and competition, and I compare these revelations to what was previously known about Google’s mobile rules. I conclude by connecting Google’s mobile practices to Google’s use of tying more broadly

The Mobile Application Distribution Agreement

To distribute Google’s mobile applications—Google Search, Maps, YouTube, Calendar, Gmail, Talk, the Play app store, and more—a phone manufacturer needs a license from Google, called a Mobile Application Distribution Agreement (MADA). Key provisions of the MADA:

“Devices may only be distributed if all Google Applications [listed elsewhere in the agreement] … are pre-installed on the Device.” See MADA section 2.1.

The phone manufacturer must “preload all Google Applications approved in the applicable Territory … on each device.” See MADA section 3.4(1).

The phone manufacturer must place “Google’s Search and the Android Market Client icon [Google Play] … at least on the panel immediately adjacent to the Default Home Screen,” with “all other Google Applications … no more than one level below the Phone Top.” See MADA Section 3.4(2)-(3).

The phone manufacturer must set “Google Search … as the default search provider for all Web search access points.” See MADA Section 3.4(4).

Google’s Network Location Provider service must be preloaded and the default. See MADA Section 3.8(c).

These provisions are confidential and are not ordinarily available to the public. MADA provision 6.1 prohibits a phone manufacturer from sharing any Confidential Information (as defined), and Google labels the MADA documents as “Confidential” which makes the MADA subject to this restriction.

I know, cite, and quote these provisions—and I am able to share them with the public—because two MADA documents became available during recent litigation: In Oracle America v. Google, the HTC MADA and Samsung MADA were admitted as Trial Exhibit 286 and 2775, respectively. Though both documents indicate in their footers that they are “highly confidential – attorney’s eyes only,” both documents were admitted in open court (the clerk’s minutes indicate no admission under seal), and court staff confirm that both documents are available in the case records in the court clerk’s office. (However, the documents are not available for direct download in PACER. Instead, PACER docket number 1205 references “five boxes of trial exhibits placed on overflow shelf.”)

Effects on Consumers, Competitors, and Competition

These MADA provisions serve both to help Google expand into areas where competition could otherwise occur, and to prevent competitors from gaining traction.

Consider the impact on a phone manufacturer that seeks to substitute an offering that competes with a Google app. For example, a phone manufacturer might conclude that some non-Google service is preferable to one of the listed Google Applications—perhaps faster, easier to use, or more protective of user privacy. Alternatively, a phone manufacturer might conclude that its users care more about a lower price than about preinstalled Google apps. Such a manufacturer might be willing to install an app from some other search engine, location provider, or other developer in exchange for a payment, which would be partially shared with consumers via a lower selling price for the phone. Google’s MADA restrictions disallow any such configuration if the phone is to include any of the listed Google apps.

Tying its apps together helps Google whenever a phone manufacturer sees no substitute to even one of Google’s apps. Manufacturers may perceive that Bing Search, Duckduckgo, Yahoo Search, and others are reasonable substitutes to Google Search. Manufacturers may perceive that Bing Maps, Mapquest, Yahoo Maps, and others are reasonable substitutes to Google Maps. But it is not clear what other app store a manufacturer could preinstall onto a smartphone in order to offer a comprehensive set of apps. Furthermore, a manufacturer would struggle to offer a phone without a preinstalled YouTube app: Without the short-format entertainment videos that are YouTube’s specialty, a phone would be unattractive to many consumers—undermining carriers’ efforts to sell data plans, and putting the phone at heightened risk of commercial failure. Needing Google Play and YouTube, a manufacturer must then accept Google Search, Maps, Network Location Provider, and more—even if the manufacturer prefers a competitor’s offering or prefers a payment for installing some alternative.

In principle, the MADA allows a phone manufacturer to install certain third-party applications in addition to the listed Google Applications. For example, the phone manufacturer could install other search, maps, or email apps in addition to those offered by Google. But multiple apps are duplicative, confusing to users, and a drain on limited device resources. Moreover, in the key categories of search and location, Google requires that its apps be the default, and Google demands prominent placements for its search app and app store. These factors sharply limit users’ attention to other preloaded apps, reducing competitors’ willingness to pay for preinstallation. Thus, even if phone manufacturers or carriers preload multiple applications in a given category, the multiple apps are unlikely to significantly weaken the effects of the tie.

These MADA restrictions suppress competition. Thanks to the MADA, alternative vendors of search, maps, location, email, and other apps cannot outcompete Google on the merits; even if a competitor offers an app that’s better than Google’s offering, the carrier is obliged to install Google’s app also, and Google can readily amend the MADA to require making its app the default in the corresponding category (for those apps that don’t already have this additional protection). Furthermore, competitors are impeded in using the obvious strategy of paying manufacturers for distribution; to the extent that manufacturers can install competitors’ apps, they can offer only inferior placement adjacent to Google, with Google left as the default in key sectors—preventing competitors from achieving scale or outbidding Google for prominent or default placement on a given device.

These MADA restrictions harm consumers. One direct harm is that competing app vendors face greatly reduced ability to subsidize phones through payments to manufacturers for preinstallation or default placement; Google’s rules leave manufacturers with much less to sell. Furthermore, these restrictions insulate Google from competition. If competing vendors were nipping at Google’s heels, Google would be forced to offer greater benefits to consumers—perhaps fewer ads or greater protections against deceptive offers. Instead, the MADA restrictions increase Google’s confidence of outmaneuvering competitors—insulating Google from the usual competitive pressures.

One might reasonably compare these MADA restrictions to other recent Google rules — also secret — apparently requiring phone manufacturers to install only a recent version of Android if they want to install Google apps (even if the apps run on earlier versions, which in general they do). But there are plausible pro-consumer benefits for Google to require that manufacturers move to the latest version of Android, including facilitating upgrades and coordinating platform usage on the latest version of Android. In contrast, there are no plausible pro-consumer benefits to the Google MADA restrictions I analyze above. For example, consumers do not benefit when Google prevents phone manufacturers from installing apps in whatever combination consumers prefer.

Little Prior Public Understanding of Google’s Restrictions on Phone Manufacturers

To date, these MADA restrictions have been unknown to the public. Meanwhile, Google’s public statements indicate few to no significant restrictions on use of the Android operating system or Google’s apps for Android—leading reasonable observers and even industry experts to conclude, mistakenly, that Google allows its apps to be installed in any combination that manufacturers prefer.

For example, on the “Welcome to the Android Open Source Project!” page, the first sentence touts that “Android is an open source software stack.” Nothing on that page indicates that the Android platform, or Google’s apps for Android, suffer any restriction or limitation on the flexibility standard for open source software.

Moreover, senior Google executives have emphasized the importance of Google’s openness in mobile. Google SVP Jonathan Rosenberg offered a 4300-word analysis of the benefits of openness for Google generally and in mobile in particular. For example, Rosenberg argued: “In an open system, a competitive advantage doesn’t derive from locking in customers, but rather from understanding the fast-moving system better than anyone else and using that knowledge to generate better, more innovative products.” Rosenberg also argued that openness “allow[s] innovation at all levels—from the operating system to the application layer—not just at the top”—a design which he said helps facilitate “freedom of choice for consumers” as well as “competitive ecosystem” for providers. Rosenberg says nothing about MADA provisions or restrictions on what apps manufacturers can install. I see no way to reconcile the MADA restrictions with Rosenberg’s claim of “allow[ing] innovation at all levels” and claimed “freedom of choice for consumers.”

Andy Rubin, then Senior Vice President of Mobile at Google, in 2011 claimed that “[D]evice makers are free to modify Android to customize any range of features for Android devices.” He continued: “If someone wishes to market a device as Android-compatible or include Google applications on the device, we do require the device to conform with some basic compatibility requirements [hyperlink in the original]. (After all, it would not be realistic to expect Google applications—or any applications for that matter—to operate flawlessly across incompatible devices).” Rubin’s post does not explicitly indicate that the referenced “basic compatibility requirements” are the only requirements Google imposes, but that’s the natural interpretation. Reading Rubin’s remarks, particularly in light of his introduction that Android is “an open platform,” most readers would conclude that there are no significant restrictions on app installation or search defaults.

Google Chairman Eric Schmidt offered particularly far-reaching remarks on Google’s rules about mobile apps and search defaults. After a 2011 Senate hearing about competition in online search, Senator Kohl asked Schmidt (question 8.a):

Has Google demanded that smartphone manufacturers make Google the default search engine as a condition of using the Android operating system?

Schmidt responded:

Google does not demand that smartphone manufacturers make Google the default search engine as a condition of using the Android operating system. …

One of the greatest benefits of Android is that it fosters competition at every level of the mobile market—including among application developers. Google respects the freedom of manufacturers to choose which applications should be pre-loaded on Android devices. Google does not condition access to or use of Android on pre-installation of any Google applications or on making Google the default search engine. …

Manufacturers can choose to pre-install Google applications on Android devices, but they can also choose to pre-install competing search applications like Yahoo! and Microsoft’s Bing. Many Android devices have pre-installed the Microsoft Bing and Yahoo! search applications. No matter which applications come pre-installed, the user can easily download Yahoo!, Microsoft’s Bing, and Google applications for free from the Android Market.

Schmidt’s response to Lee (question 15.b), to Franken (question 7), and to Blumenthal (question 7) were similar and, in sections, verbatim identical.

Taken on its own, Schmidt’s statement seems to offer a categorical denial that Google in any way restricts what apps manufacturers and carriers install. But in fact Schmidt’s statement is much narrower. For example, reread Schmidt’s assertion that “Google does not condition access to or use of Android on pre-installation of any Google applications or on making Google the default search engine.” The natural interpretation is that no Google rule requires manufacturers to preinstall any Google app or make Google the default search. But Schmidt actually leaves open the possibility that some other Google-granted benefit, other than permission to use Android, imposes exactly these requirements. Indeed, the above-referenced documents reveal that Google imposes these requirements if a manufacturer seeks any of the listed Google apps. But Schmidt’s statement indicates nothing of the sort.

Similarly, notice the ambiguity in Schmidt’s statement that “Manufacturers can choose to pre-install Google applications on Android devices, but they can also choose to pre-install competing search applications like Yahoo! and Microsoft’s Bing.” The clear implication is that manufacturers can pre-install Google, Yahoo, Microsoft, and other applications in any combination they choose. But her too, Schmidt’s carefully-worded response is narrower. Specifically, Schmidt indicates that manufacturers can install Google apps or they can install competitors’ apps. With the benefit of the above-referenced MADA, we see the gaps in Schmidt’s representation—leaving open the possibility that, as the MADA reveals, the choice is all-or-nothing. Yet ordinary readers have no reason to suspect the possibility of an all-or-nothing choice, and Schmidt’s response does nothing to suggest any such requirement. Schmidt’s statements—at best incomplete, and I believe affirmatively misleading—gave the senators and the general public a mistaken sense that Google apps and competing apps could be installed in any combination.

Even when industry experts have inquired, they have struggled to uncover Google’s true rules for mobile app preinstallations. Consider the September 2012 post entitled Google Doesn’t Require Google Search On Android by Danny Sullivan, arguably the web’s leading search engine expert. In that analysis, Sullivan consults publicly available sources to attempt to determine whether Google allows Android manufacturers to change Android default search while installing other Google apps. Finding no prohibition in any available document, Sullivan tentatively concludes that such changes are permitted. Sullivan clearly recognizes the difficulty of the question—he resorts to four separate postscripts as he consults additional sources. But with no document indicating that Google imposes any such restriction, Sullivan has no grounds to conclude that such a restriction exists. As it turns out, Sullivan’s conclusion is manifestly contrary to the plain language of the MADA: Sullivan concludes, for example, that a carrier could configure phones to “use the Android app store if [the carrier] made Bing [Search] the default.” In fact, a manufacturer must accept a MADA in order to obtain App Store access, and MADA Section 3.4(4) then imposes the requirement that Google Search be the default search at all web access points. But Sullivan had no access to a MADA, and MADA provision 6.1 prohibited manufacturers from telling Sullivan about MADA terms. No wonder Sullivan concluded there was no such restriction.

Similarly, when tech journalist Charles Arthur examined “why Google Android software is not as free or open-source as you may think,” he had to resort to unnamed sources and inferences from publicly-available materials. Arthur’s hypothesis was correct. But by keeping MADA’s secret, Google prevented Arthur from substantiating his allegations.

In principle, the public could have learned about MADA provisions through periodic company disclosures of key supplier contracts. Indeed, in 2011 Motorola circulated a redacted MADA as an exhibit to an SEC filing. But Motorola removed crucial provisions from the public version of this document. For example, the redacted Motorola MADA removes the most important sentence of MADA section 2.1—leaving only a placeholder where the original document stated “Devices may only be distributed if all Google Applications … are pre-installed.” Thus, even if a reader is savvy enough to find this SEC filing, the MADA’s key provisions remain unavailable.

MADA secrecy advances Google’s strategic objectives. By keeping MADA restrictions confidential and little-known, Google can suppress the competitive response. If users, app developers, and the concerned public knew about MADA restrictions, they would criticize the tension between the restrictions and Google’s promise that Android is “open” and “open source.” Moreover, if MADA restrictions were widely known, regulators would be more likely to reject Google’s arguments that Android’s “openness” should reduce or eliminate regulatory scrutiny of Google’s mobile practices. In contrast, by keeping the restrictions secret, Google avoids such scrutiny and is better able to continue to advance its strategic interests through tying, compulsory installation, and defaults.

Relatedly, MADA secrecy helps prevent standard market forces from disciplining Google’s restriction. Suppose consumers understood that Google uses tying and full-line-forcing to prevent manufacturers from offering phones with alternative apps, which could drive down phone prices. Then consumers would be angry and would likely make their complaints known both to regulators and to phone manufacturers. Instead, Google makes the ubiquitous presence of Google apps and the virtual absence of competitors look like a market outcome, falsely suggesting that no one actually wants to have or distribute competing apps.

Tying to Benefit Google’s Other Services

If a phone manufacturer wants to offer desired Google functions without close substitutes, the MADA provides that the manufacturer must install all other Google apps that Google specifies, including the defaults and placements that Google specifies. These requirements are properly understood as a tie: A manufacturer may want YouTube only, but Google makes the manufacturer accept Google Search, Google Maps, Google Network Location Provider, and more. Then a vendor with offerings only in some sectors—perhaps only a maps tool, but no video service—cannot replace Google’s full suite of services.

I have repeatedly flagged Google using its various popular and dominant services to compel use of other services. For example, in 2009-2010, to obtain image advertisements in AdWords campaigns, an advertiser had to join Google Affiliate Network. Since the rollout of Google+, a publisher seeking top algorithmic search traffic de facto must participate in Google’s social network. In this light, numerous Google practices entail important elements of tying:

If a ___ wants ___	Then it must accept ___
If a consumer wants to use Google Search	Google Finance, Images, Maps, News, Products, Shopping, YouTube, and more
If a mobile carrier wants to preinstall YouTube for Android	Google Search, Google Maps (even if a competitor is willing to pay to be default)
If an advertiser wants to advertise on any AdWords Search Network Partner	All AdWords Search Network sites (in whatever proportion Google specifies)
If an advertiser wants to advertise on Google Search as viewed on computers	Tablet placements and, with limited restrictions, smartphone placements
If an advertiser wants image ads	Google Affiliate Network (historic)
If an advertiser wants a logo in search ads	Google Checkout (historic)
If a video producer wants preferred video indexing	YouTube hosting
If a web site publisher wants preferred search indexing	Google Plus participation

Looking at Google’s dominance, many critics focus on Google’s power in search and search advertising. But this table shows the breadth of Google’s dominant services and the many ways in which Google uses its dominant services to cause usage of its less popular offerings.

I do not claim that tying always makes Google’s products succeed. Weak offerings, strong competition, and competitors’ network effects can all still stand in the way. But by tying its offerings in these ways detailed above, Google increases the likelihood that its offerings will succeed. One might reasonably ask, for example, what chance Google Checkout should have had: Reaching users a decade after Paypal and competing with Paypal’s huge user base, by ordinary measures Checkout should have been entirely stillborn. Indeed Checkout’s growth has been slow. But what would have happened if, rather than featuring a special logo only for AdWords advertisers who joined Checkout, Google had shown such logos for all popular payment intermediaries? Surely equal treatment of Checkout versus competitors would have reduced Checkout’s adoption and harmed Checkout’s relative prospects. Yet equal treatment would have provided consumers with timely and actionable information, and would have facilitated genuine competition on the merits.

Google used a similar technique in its 2003 launch of AdSense. At the time, advertisers largely sought Google’s AdWords placements within Google’s search engine. Upon launching AdSense, Google required advertisers to accept placements through Google’s new contextual network. These placements offered additional exposure which some advertisers surely valued. But publishers have an obvious incentive to commit click fraud—increasing the amount that Google pays to advertisers, but at the same time inflating advertisers’ costs. Furthermore, some publishers present material that advertisers would not want to be associated with (such as adult material and copyright infringement). Many advertisers would have declined to participate in the contextual network had they been asked to make a decision one way or the other. By insisting that advertisers accept such placements, Google gave itself instant scale—hence ample resources to pay publishers and outbid other networks seeking space on publishers’ sites. In contrast, competing ad platforms had to recruit skeptical advertisers through long sales pitches, performance guarantees, and lower prices—yielding fewer advertisers, lower payments to publishers, and a weaker competitive position. No wonder AdSense achieved scale while competitors struggled—but Google’s success should be attributed as much to the tie as to the genuine merits of Google’s offering.

In a forthcoming article, I’ll explore these and other contexts in which Google ties its services together. Applicable antitrust law can be complicated: Some ties yield useful efficiencies, and not all ties reduce welfare. But Google’s use of tying gives it a leg up in numerous markets that would otherwise enjoy vibrant competition. Given Google’s dominance in so many sectors, this practice deserves a closer look.

January 7, 2013November 21, 2024

The Right Remedies for Google’s AdWords API Restrictions

Last week the FTC closed its 21-month investigation of Google after Google made several small concessions, among them dropping certain restrictions on use of Google’s AdWords API — rules that previously limited how advertisers and tool-makers may copy advertisers’ own data from Google’s servers. Removing the restrictions is a step forward for advertisers and for competition. But the FTC could and should have demanded more from Google in order to address the harm resulting from seven years of these restrictions.

I first flagged Google’s AdWords API restrictions in my June 2008 senate testimony and in greater detail in PPC Platform Competition and Google’s “May Not Copy” Restriction. In short, the restrictions prohibited making and sharing tools to quickly copy and synchronize ad campaigns across multiple ad platforms — effectively compelling small to midsized advertisers to use Google only, for lack of tools to manage their campaigns on multiple platforms. Google enforces this prohibition with a system of tool passwords and audits — letting Google swiftly and completely disable any tool that Google deems impermissible. Indeed, any tool-maker found offering a noncompliant tool would immediately lose all access to Google’s AdWords API, as to all of its tool-using subscribers, a devastating blow that kept tool-makers under Google’s thumb.

As I pointed out, these AdWords API restrictions let Google charge prices higher than competing platforms: Thanks to these restrictions, a small to midsized advertiser would struggle to buy some placements from Yahoo or Microsoft, even if those vendors offered lower prices. Higher advertising costs directly harm advertisers, and higher prices get passed to consumers (according to the relative elasticity of supply and demand). I also pointed out harms to others in the advertising ecosystem: Competing ad platforms struggle to attract advertisers, hence showing less relevant advertising (discouraging users from clicking ads) and enjoying less auction pressure to push prices upward. Meanwhile, I noted, the AdWords API restrictions give Google that much more leverage in its negotiations with publishers: by weakening other ad platforms’ monetization, Google can more easily win deals for publishers’ inventory, granting publishers lesser compensation for the content they post.

Strikingly, Google has never seriously defended the AdWords API restrictions. In June 2008, Doug Raymond, Product Manager for AdWords API, argued that advertisers are free to export their data in other ways, e.g. as a CSV text file. But that far-inferior manual export is ad-hoc, time-consuming, and error-prone — a poor fit for high-priced online advertising. Indeed, this manual approach is a sharp contrast from a modern automation API, and a far cry from what Google offers in other contexts.

By all indications, competition regulators share my concerns. In a November 2010 press release, the European Commission flagged “restrictions on the portability of online advertising campaign data” as its fourth concern in reviewing Google’s conduct, a concern most recently reiterated in December 2012 remarks by EC Competition Commissioner Joaquín Almunia. Last week’s statement by FTC Chairman Leibowitz is in accord: “Some Commissioners were concerned by the tendency of Google’s restrictions to raise the costs of small businesses to use the power of internet search advertising to grow their businesses.”

So everyone but Google agrees that the AdWords API restrictions are improper, and even Google has little to say in its defense. Indeed, despite abandoning most other aspects of its investigation, the FTC did pursue this matter. But the FTC reports only that Google is to remove AdWords API restrictions and that, the FTC indicates, ends the FTC’s concern on this subject. I am surprised by such a narrow remedy. The AdWords API restrictions have been in place for more than five years. Were it not for these restrictions, advertisers for five years would have enjoyed lower prices. For five years, third-party publishers would have received higher payment for their ad space. For five years, consumers would have seen more relevant ads at competing ad platforms, perhaps helping to increase competitors’ market shares and put a check on Google’s dominance. Moreover, for five years competing ad platforms would have enjoyed higher advertising revenues and higher ad click-through rates. It’s all well and good for Google to remove the API restriction going forward. But that does nothing at all to address past harm to advertisers and others.

Three Appropriate Remedies

What remedies would be appropriate for Google’s seven years of improper AdWords API restrictions? Let me offer three suggestions:

First, after years of improper conduct in this area, Google should expect to pay monetary damages. Google’s AdWords API restrictions inflated the prices charged to advertisers. Google should disgorge these ill-gotten gains via pro-rata refunds to advertisers.

Second, Google’s changes should be formal binding commitments formalized in a consent agreement. The 1969 Report of the American Bar Association Commission to Study the Federal Trade Commission recognized that voluntary commitments were ineffective, and the FTC largely discontinued voluntary commitments after that report. Indeed, FTC Commissioner Rosch last week noted that the FTC’s voluntary commitment approach lets Google offer a statement of its current intent, which Google could reverse or alter at any time. Moreover, an order would have required the FTC to take a clearer position on whether Google’s conduct violated the law: An order would have required the FTC to file a complaint, which in turn requires a finding by the FTC that there is reason to believe a violation has occurred. This formality would offer a useful confirmation of the FTC’s view — either the FTC believes a violation occurred, or it does not, but the voluntary commitment process lets the FTC avoid a public statement on this subject. Finally, orders are also vetted with third parties to make sure they will be effective. Microsoft’s Dave Heiner immediately offered several gaps in the FTC’s approach on AdWords API restrictions. I would have offered additional feedback had I been asked.

Finally, the FTC’s investigation surely found documents or records confirming the intent and effect of Google’s AdWords API restrictions. The FTC should at least describe those documents — if not release them in full. Describing or releasing these documents would let concerned parties determine what private claims they may have against Google. If the documents confirm meritorious claims, victims can pursue these claims through private litigation (here too, as Commissioner Rosch suggested).

Google’s AdWords API restrictions were a direct assault on competition — indefensible rules serving only to hinder advertisers’ efforts to efficiently use competing search engines, without any plausible pro-competitive justification. On this clear-cut issue, the FTC should have pursued every remedy permissible under its authority. Fortunately it’s not too late for state attorneys general and the European Commission to insist on more.

July 10, 2008November 21, 2024

Competition among Sponsored Search Services

Edelman, Benjamin. “Competition among Sponsored Search Services.” U.S. House of Representatives, Committee on the Judiciary, Task Force on Competition Policy and Antitrust Laws, 2008. (Hearing cancelled.) (Reprinted in Working Knowledge: Google-Yahoo Ad Deal is Bad for Online Advertising.)

Last month I was asked to testify to the United States House of Representatives Committee on the Judiciary Task Force on Competition Policy and Antitrust Laws about competition among paid search providers, particularly the proposed Google-Yahoo partnership.

At the last minute, the hearing was cancelled, and I won’t be able to testify at the rescheduled session. Rather than let my draft written statement languish, I’m taking this opportunity to post the prepared testimony I had planned to offer:

Competition among Sponsored Search Services.

June 27, 2008November 21, 2024

PPC Platform Competition and Google’s "May Not Copy" Restriction

By all indications, Google AdWords features far more advertisers than competing PPC platforms such as Yahoo Search Marketing and Microsoft adCenter. (Consider: Search for “thinkpad x60 power supply” at Google, and there are six relevant ads from vendors who actually sell that product. Search at Yahoo Search or Microsoft Live Search, and there are various ads from indexers and aggregators, but only one or two from vendors directly selling the product. Other searches for offbeat, unusual or region-specific keywords show similar patterns.)

Why do more advertisers choose Google? Because more users search at Google, Google can offer wider ad distribution than any single competitor. So if an advertiser had to choose just one ad platform, Google would be the natural choice.

But in principle advertisers can easily use multiple ad platforms. Ads are trivially small plaintext data, and In principle ads can be copied from platform to platform without restriction. So why don’t more Google advertisers use Yahoo, adCenter, and others too?

One possible answer comes from a little-noticed Google AdWords API Terms & Conditions restriction which substantially hinders advertisers’ efforts to use multiple providers — exactly prohibiting software vendors from helping advertisers copy AdWords campaigns to competing platforms. In this article, I identify the restriction at issue, analyze its effects on advertisers and competing ad platforms, critique response from Google, and compare this restriction with Google’s commitment to “data portability” in other contexts.

The Restriction at Issue

To use the Google AdWords API, a software developer must accept Google’s AdWords API Terms & Conditions. The T&C’s include the following requirement:

“Any information collected from an input field used to collect AdWords API Campaign Management Data may be used only to manage and report on AdWords accounts. Similarly, any information or data used as AdWords API Campaign Management Data must have been collected from an input field used only to collect AdWords API Campaign Management Data. For example, the AdWords API Client may not offer a functionality that copies data from a non-AdWords account into an AdWords account or from an AdWords account to a non-AdWords account.” (emphasis added)

Sure enough, searching the web for commercial tools to synchronize PPC campaigns or to export data from Google to competing platforms, I found none.

The “May Not … Cop[y] Data” Prohibition: Effect on Advertisers

The quoted restriction prevents advertisers from easily exporting ads from Google to a competing paid search provider. Consider: The essence of an export procedure is to copy data from an AdWords account to a non-AdWords account — exactly what the restriction prohibits.

Indeed, available export procedures are strikingly complex. For example, to import a Google AdWords campaign into Microsoft adCenter, Microsoft offers a 17-step procedure (with some steps made more complicated by the presence of multiple sub-steps).

Microsoft’s procedure is necessarily convoluted because Google’s “may not … cop[y]” restriction prevents Microsoft, or any other vendor, from writing a tool that connects to the Google API, downloads an advertiser’s ads, and uploads those ads directly to, e.g., Microsoft adCenter. Instead, advertisers must download data manually, reformat it to match adCenter’s requirements, and upload it to Microsoft — just as Microsoft’s lengthy procedure specifies.

For many advertisers, Google’s restrictions on data export impose an ongoing burden even beyond the advertiser’s initial signup with a competing PPC provider. Consider an advertiser that changes its ads or keywords often — perhaps selling seasonal merchandise, or experimenting with alternative advertising strategies. Such an advertiser would typically prefer to make changes in one place, and have the changes automatically propagate to all the advertiser’s PPC platforms. If Google remains the advertiser’s primary PPC provider, the advertiser would probably want to make changes in Google’s interface, then have other PPC platforms optionally automatically copy those changes. But Google’s “may not … cop[y]” restriction applies equally to ongoing resynchronizations. If an advertiser made daily changes to its Google campaigns, it would have to daily repeat the manual export/import process — a task that would be both time-consuming and prone to error.

In short, the net effect of the quoted restriction is to reinforce the tendency of small to medium-sized advertisers to “single-home” — to use only Google AdWords, to the exclusion of competing platforms.

At their peril do advertisers rely solely on Google: If advertisers get stuck using only Google, for lack of any easy and efficient way to buy some traffic elsewhere, Google can charge prices higher than competing platforms. Of course Google can’t raise prices infinitely; at some point, advertisers would overcome the lock-in, accept manual export, and copy ads to competitors. But Google’s “may not copy” restriction increases the costs of multi-homing — letting Google charge that much more than competitors, without advertisers facing compelling incentives to look elsewhere.

The “May Not … Cop[y] Data” Prohibition: Effect on Competing Ad Platforms, on Publishers, and on Users

By encouraging small to medium-sized advertisers to advertise only with Google AdWords, Google’s API restriction reduces the number of advertisers using competing ad platforms. This harms competing platforms in two distinct ways. First, it reduces competitors’ coverage — preventing competitors from featuring relevant ads that pertain to obscure user searches. (Consider the power supply example from the first paragraph of this piece — better and more useful ads at Google.) With fewer relevant ads, the competing platform offers users an inferior service — inviting users to look elsewhere, and reducing the likelihood of a paid click that would earn the platform an advertising fee.

Second, by reducing the number of advertisers bidding for advertising positions at other platforms, the quoted provision dramatically reduces revenue at those platforms. My December 2006 Optimal Auction Design in a Multi-unit Environment estimates the revenue benefits of additional advertisers based on publicly-available data and estimates of market fundamentals. The intuition is straightforward: When many advertisers seek positions for a given search term, they must bid higher to avoid being outbid and receiving inferior listing position. Conversely, when only a few advertisers seek positions, prices can be strikingly low since even a low bid earns a prominent position.

Google’s API restriction also reduces the value of advertising inventory held by third-party publishers. Consider a publisher seeking to sell its sponsored search or other text ad inventory to a provider of sponsored search services. In general, Google can afford to pay more because Google’s revenue per search is higher than competitors’. But how much will Google offer? Google maximizes profits by narrowly outbidding competitors; anything higher is waste. So the weaker competitors become, the lower Google can bid — and the less revenue publishers receive for the traffic they sell. Google’s “may not copy” API restriction serves a role in weakening competing platforms — keeping advertisers using Google alone, and hence reducing competing ad platforms’ ability to pay for publishers’ inventory.

End users also suffer from Google’s restriction on copying ads. Were it not for Google’s restriction, more advertisers would sign up to use competing ad platforms — increasing the usefulness of Yahoo Search and Microsoft Live Search for the users who choose those services.

Google’s Response

I forwarded these concerns to Google in March, and I managed to get in touch with Doug Raymond, product manager for AdWords API. Doug offered three rationales for the restriction. The list below summarizes his arguments (black) and my responses (blue).

Google: The quoted provision only applies to third-party developers. Individual advertisers remain free to write software that exports their Google campaigns.
- Small to medium-sized advertisers don’t want to be developers. Rather, they want to use code that others write. That’s exactly why the AdWords API offers a concept of developers, rather than requiring that every advertiser write its own code.
- As a leading provider of centralized computing services, as distinguished from small programs individual users build themselves, Google well knows the benefits of rigorous design by competent professionals.
Google: Advertisers can extract their data in other ways, e.g. a comma-separated-value (CSV) file.
- Manual export is convoluted, slow, and error-prone. API-based access would be faster, easier, and more reliable.
- The existence of an inferior alternative does not justify imposing restrictions that prohibit superior implementations.
- In other contexts (detailed below), Google has made strong requests for, and commitments to, data portability.
- In other contexts, Google emphasizes the benefits of streamlined, automated data transfer — never viewing convoluted manual procedures as an acceptable alternative.
Google: Third-party developers ought not have free access to advertiser data.
- Google’s AdWords API already offers an appropriate security model to limit developers to serving those AdWords advertisers that have specifically granted such permission. In short, a developer needs a password to access an advertiser’s account.

Google’s Position on Data Portability in Other Contexts

Google’s prohibition on AdWords API data export stands in sharp contrast to Google’s position on data portability in other contexts. Indeed, Google has previously taken a firm position in favor of data portability. Some specific examples: In a November 2006 interview at the Web 2.0 Summit, Schmidt specifically promised that “We [Google] would never trap user data.” Schmidt added that “If users can switch it keeps us honest.” Just last month, Google CEO Eric Schmidt called for open access to (and indexing of) social network data — telling IBM’s Business Partner Leadership Conference “People should be able to move from place to place, and their data is available everywhere” and “open is best for the consumer.” Well-known Google blogger Matt Cutts summarized Google’s commitment to data openness with the catchy title “Not trapping users’ data = GOOD” and a long list of Google products that support data export.

I credit that Schmidt’s statements refer to other kinds of data — search engines’ records of users’ search history, and a wide assortment of data held by social networks. But the same principles plainly apply to access to search ads: Just as consumers benefit from being able to move their data as they see fit, so too do advertisers benefit from flexibility.

Moreover, it strains credibility for Google to ask social networks to share their data with Google, while Google simultaneously imposes contractual roadblocks preventing others from accessing Google data.

Next Steps and Google’s Other Restrictions

Google already faces antitrust scrutiny for its striking growth and market share. In that context, it’s particularly hard to defend the restriction at issue — a barrier to competition, without any apparent pro-competitive purpose. Regulators might reasonably require that Google remove the quoted provision — letting third-party developers export and synchronize AdWords data if advertisers so desire. This would be a trivially straightforward requirement — just a sentence to be stricken from Google’s AdWords API T&C’s. Because Google’s existing APIs already provide the required data, Google would not need to add any new code or any new API functions.

Other AdWords API restrictions also deserve scrutiny. For example, Google insists that advertising tools collect AdWords instructions through separate fields not used for other ad platforms — blocking simplification via a single interface to streamline advertisers’ decisions. Google prohibits advertising tools from storing Google data in a single relational database along with data for other ad platforms — increasing the complexity of designing a system to manage campaigns on multiple platforms. And Google prohibits reports that compare Google ad performance data (e.g. costs and profits from advertising at Google) with data from other ad platforms — hindering advertisers’ efforts to evaluate competitors’ offerings. I gather Google defends these restrictions on the grounds that they purportedly prevent advertiser confusion. Perhaps — but their more obvious effect is to increase the costs and complexity of using competing ad platforms. Perhaps I’ll consider these restrictions in greater detail in a future article.

Meanwhile, I’m struck by Google’s calls for data portability in other contexts. With Google’s ongoing request that other companies provide data to Google, perhaps Google will return the favor by abandoning its “may not copy” restriction — ideally promptly and unilaterally, without requiring that regulators force Google’s hand.

November 15, 2005December 2, 2023

What Claria Doesn’t Disclose (Any More)

Now that Claria no longer comes bundled with powerhouse distributors Kazaa and Grokster, and now that Claria has even terminated its fake-user-interface banner ads, one might reasonably wonder: How does Claria get onto users’ PCs? Last month I showed an example of Claria soliciting installations via banner ads served through other vendors’ spyware (which in turn had become installed without consent). But even Claria’s ordinary installations still fail to tell users what users reasonably need to know in order to make an informed choice. In particular, Claria’s current installations omit prominent mention of the word “pop-up” — the key word users need to read in order to understand what Claria is offering, and to decide whether to agree.

Claria’s Current Installation Procedure

Claria’s installations often begin with an innocuous-looking popup or popunder like the image below. These ads don’t mention Claria by name, don’t mention pop-ups or privacy consequences, and don’t mention any material adverse effects whatsoever. So it’s no surprise that users respond favorably to these offers.

Clicking one of Claria’s “free screensaver” ads yields a screen like that shown below. Users are specifically encouraged to click “yes.” Once a user presses “yes,” the user has no further opportunity to cancel installation of Claria’s software.

It’s well-known that users hate pop-up ads. But, tellingly, Claria currently fails to use the word “pop-up” anywhere in its on-screen disclosures. Claria calls its advertising “GAIN-branded ads,” conveniently omitting the one word — “pop-up” — that best and most concisely describes its ads. Interestingly, Claria’s omission of the word “pop-up” reflects a change from its prior installation practice. Compare the two screenshots below, showing the prompt I observed in April 2005 (left) versus Claria’s current installation prompt (right). Notice inclusion of the word “pop-up” in the left prompt only.


April 2005		November 2005

Claria’s Compliance with Applicable FTC Rules

In an August 2004 interview, Claria chief privacy officer Reed Freeman set out Claria’s disclosure duties. “Material terms, as defined by the FTC, are those that are likely to affect a consumer’s conduct with respect to a product or service,” Freeman explained, adding that existing law requires that “material terms have to be disclosed prior to a consumer [installing software].” Let’s accept Freeman’s statement of this rule. Surely the presence of extra pop-ups would deter a consumer from accepting Claria’s offer. If so, under Freeman’s own statement of existing law, Claria must disclose that it will show pop-ups.

Claria may try to defend its installations by noting that the word “pop-ups” appears in the “Final Step to download your free screensaver” screen, above. But in the default arrangement of windows, as they appeared on my ordinary SVGA screen, the “p” and “o” of “pop-up” were hidden behind the ActiveX popup, such that only the letters “p-ups” were visible. Hidden text cannot satisfy a FTC disclosure requirement. So this covered disclosure does not provide the kind of information that FTC rules require.

Claria may try to defend its installations by noting that it subsequently shows a “software utility user information” screen. Scrolling through this screen will ultimately lead to information about Claria’s pop-ups. But the document is lengthy, and typical users will not see the section that discusses pop-ups specifically. Furthermore, the document is shown only after users press Yes to install Claria; by the time users see this document, they can’t cancel the Claria installation. So this subsequent text cannot satisfy the requirement that disclosure occur “prior to a consumer installing software” (emphasis added).

Claria may try to defend its installations by noting its plan to move away from popups, in favor of ads embedded within partner web sites. But the Claria software I tested — the result of the installation shown and discussed above — still showed pop-ups, including a popup delivered mere minutes after I finished installation. These pop-ups are a material effect, under Freeman’s own statement of FTC rules. So whatever Claria’s future plans, Claria’s current pop-ups should be disclosed as such.

Some advertisers apparently stand ready to defend their use of advertising systems like Claria’s, and Claria counts as customers some of the country’s largest advertisers. But advertisers should demand better. If advertisers are prepared to show their ads in pop-ups, let them first obtain user consent — not vague consent to “ads,” but specific consent to “pop-ups.” Until Claria improves its installation procedures to provide this information, users who run Claria software can’t reasonably be claimed to know what they were getting into.

January 4, 2005December 2, 2023

Claria’s Practices Don’t Meet Its Lawyers’ Claims

Among the highlights of my winter holiday reading was a MediaPost interview of Reed Freeman, chief privacy officer of Claria. Freeman makes a series of claims about Claria’s practices — setting out high standards that he claims Claria already meets. As it turns out, his claims are in multiple instances verifiably false.

Removing Claria Programs – Neither “Intuitive” Nor “Standard”

Freeman claims that Claria has “the intuitive and standard Windows uninstall process.” I disagree.

Install Claria software in a bundle with Kazaa, and there will be no “Claria,” “Gator,” or “GAIN” listing in Control Panel’s Add/Remove Programs. Same for the other programs that bundle Gator (like DivX and Grokster). Instead, users who want to remove Gator are required to figure out that they need to select the “Kazaa” entry in Add/Remove Programs. That’s neither intuitive nor standard.

Claria admittedly sometimes tells users about its unusual removal procedure. Five pages (370+ words) into Claria’s license (as shown by Kazaa), Claria mentions “If you would like to stop receiving GAIN-branded advertisements, you will need to remove all GAIN-Supported Software on your computer using … Add/Remove Programs.”

Screen-shot showing that when Zango comes with Secret Chamber, Zango receives a separate entry in Add/Remove Programs. Claria’s Gator, in contrast, lacks such an entry.

But Freeman doesn’t claim that Claria’s uninstall process is well-documented. He claims it’s “standard.” To the contrary, when other programs come in bundles, they generally include separate entries in Add/Remove Programs. For example, when RealPlayer comes with Google Toolbar, each program gets a separate Add/Remove listing. Even among so-called “adware” programs (that monitor users’ web browsing and show advertisements), Claria’s approach is unusual. When 180solutions Zango comes bundled with other programs (like Zango Games’ Secret Chamber), Zango has its own entry in Control Panel. See screen-shot at right.

Neither is Claria’s uninstall procedure “intuitive.” The intuitive way to remove an unwanted program is to find it, by name, in Add/Remove Programs. Claria makes the process harder by forcing users to figure out which programs bundled which — an unnecessary procedure that is not “intuitive.” The process becomes even more difficult when Claria cross-promotes its various products: Once a user receives Claria’s advertising-display software, Claria often shows pop-ups that encourage installation of other Claria programs, such as clock synchronizers and weather monitors. As a result, many Claria users run multiple “Gator-supported” applications, each of which must be separately identified and removed to complete Claria’s so-called “intuitive” uninstall.

Also nonstandard is Claria’s prohibition on using “unauthorized” removal methods (namely, removal tools like Ad-Aware and Spybot). See my earlier Gator’s EULA Gone Bad.

One-Step Install, Harder Uninstall

A Claria drive-by installer, installing Claria software (without any further request for consent) if users press Yes.

Freeman later reports “The FTC has long taken the position that consumers should be able to get out of the bargain just as easily as they got into it.” Turning to Claria’s practices, he claims “you can get into our bargain by responding to an ad, and you can get out of our bargain by responding to an ad.”

Freeman makes it sound like removing Claria is as easy as getting Claria, but that’s just not the case. Claria software can become installed after only a single click on a single “Yes” button in a Claria “drive-by” ActiveX pop-up (like the one at right).

Claria uninstallation screen, adding additional steps to attempts to remove Claria software.

In contrast, removing Claria requires a longer procedure. At best, click Start – Settings – Control Panel – Add/Remove Programs, then find the installed Claria or third-party program, press Remove, and press Next twice (eight clicks total) . The final two clicks are necessary to decline Claria’s pleas to remain installed. (See the screen-shot at left.) Through this procedure, Claria requires triple confirmation before its software can be uninstalled, even though Claria had requested no extra confirmation to get onto users’ PCs.

So users can receive Claria by clicking once on a single ad, but removing Claria requires many more steps. This design seems like a clear violation of the “get out … as easy as … got in” rule Freeman attributes to the FTC. Why not place a one-click uninstall button on every Claria ad, so users can remove Claria as easily as they got it?

Telling Users What Claria Really Does

Freeman further notes the importance of disclosing what a program will do before that program is installed on a user’s PC. Freeman explains:

“The law is that material terms have to be disclosed prior to a consumer’s taking action. … Material terms, as defined by the FTC, are those that are likely to affect a consumer’s conduct with respect to a product or service. … In my view, the key terms that consumers should know–those that consumers would be unhappy if they didn’t know–are that we will track your online behavior and serve you advertising. Those key material terms are disclosed in every download process … in a way that is unavoidable prior to the consumer taking action “

I applaud Freeman’s emphasis on timely disclosures. But here too, Claria’s actual practices fall short.

Claria’s prominent disclosures say nothing of transmission or storage of users’ activities. The first page of Claria’s license (as shown by the Kazaa installer) mentions that advertisements are “selected in part based on how you surf the Web.” From this disclosure, users could reasonably conclude that Claria’s software chooses ads by mere monitoring of users’ activities — observing a user at one travel site, then showing a pop-up ad for another.

But as it turns out, Claria does more. Claria transmits users’ activities to its servers, then stores this information in a huge database. A November 2003 eWeek article reported that Claria’s then-12.1 terabyte database was already the seventh largest in the world — bigger than Federal Express, and rivalling Amazon and Kmart. A recent Oracle press release touted Claria as “one of the the world’s largest Oracle Data Warehouse … deployments.”

Claria’s license fails to prominently disclose transmission and storage of users’ activities. That advertisements are “selected in part based on how you surf the web” says nothing of any central Claria database recording who goes where. Only at page 11 of 63, 950 words into its 5,900+ word license, does Claria finally explain its true design — transmitting user activities to Claria servers — by admitting that “we do know … some of the web pages viewed” (emphasis added).

Screen-shot showing the disclosure shown by Zango when bundled with Secret Chamber. Zango prominently discloses that it “collects” information about users’ web site visits.

Here again, Claria’s disclosure is inferior to its competitors. 180solutions software is sometimes installed without any notice or consent at all — for example, through security holes. (video) But when 180 requests permission to install, it offers a more forthright description of its intended activities. For example, when installed with the Secret Chamber video game, 180 prominently discloses: “Zango collects … information about the websites a user visits.” (screenshot)

A user who receives 180’s disclosure learns that 180 will not only monitor online behavior, but also collect this data. That’s a fact 180 seems to regard as relevant — worth bringing to users’ attention, beyond fine print midway through a long license agreement. It’s a fact of likely interest to many users — who may not want their data stored, perhaps permanently, on Claria’s servers. So this transmission and collection is, in Freeman’s words, a fact consumers “would be unhappy if they didn’t know.” By Freeman’s own standard, then, this fact ought to be more prominently presented in Claria’s disclosure — on page one, not page eleven.

November 29, 2004December 2, 2023

Gator’s EULA Gone Bad

Gator has recently taken steps to portray itself as a model citizen among what it calls “adware” companies. Gator proudly announced support for California’s new anti-spyware law. (But see my criticism of the law as ineffective.) Earlier this year, Gator hired a former FTC staff attorney to serve as Gator’s chief privacy officer, participated (PDF) in the FTC‘s spyware workshop, and even joined CDT‘s “consumer software working group” committee. (See recommendations document (PDF) signators list, final page.)

Has Gator turned over a new leaf? For insight, I turned to Gator’s license agreements, to see how Gator currently presents itself to ordinary users.

Table of Contents

Prohibition on automated removal tools
Prohibition on investigating transmissions
License formatting: headings, search, print
What the license doesn’t say

It’s not often that I sit down to read Gator’s license agreements. At 5,936 words, the license stretches to 63 on-screen pages as presented by the current Kazaa installer (bundling Gator). (See screen-shots of the Gator license as presented in June 2004, then requiring 56 on-screen pages.) Here are some notable sections of the license:

Prohibition against automated removal tools

Nearly three thousand words into its license, Gator proclaims:

You agree that you will not use, or encourage others to use, any unauthorized means for the removal of the GAIN AdServer, or any GAIN-Supported Software from a computer.”

Gator proceeds to list the “authorized means” for removing Gator — prominently failing to authorize use of popular tools, such as Ad-Aware, Spybot, and Web Sweeper, which millions of users count on to remove unwanted software from their PCs.

In recent press releases, Gator has claimed to favor “consumer … choice” and has argued that what occurs on users’ computers is “users’ choice.” So long as consumers are (supposedly) choosing to run Gator software, Gator vigorously defends user choice. But when a consumer chooses to use third-party software to remove Gator, Gator instead specifically prohibits that choice.

If Gator were easy to uninstall, users might not need to resort to third-party removal programs. But Gator makes its software hard to remove. Browse to Add/Remove Programs on a computer with Gator installed, and there’s often no entry for Gator. Instead, users are required to identify, find, and remove all programs that bundle Gator, and only then is Gator’s software designed to uninstall. This unusual removal procedure — unique among all programs I’ve ever encountered — makes Gator difficult for users to remove.

Removing Gator becomes even harder, using Gator’s official removal procedure, as a result of Gator’s cross-promotion of its various products. After a user receives Gator’s GAIN advertising-display software, Gator often shows pop-ups that encourage installation of other Gator programs, such as clock synchronizers and weather monitors. As a result, many users run multiple “Gator-supported” applications, each of which must be separately identified and removed in order to use Gator’s official removal procedure. Facing Gator’s lengthy and complicated removal procedure, it’s no wonder many users look to third-party removal programs for help.

Prohibition against viewing or recording what Gator software says about its users over users’ own Internet connections

About four thousand words through its license, Gator demands:

“Any use of a packet sniffer or other device to intercept or access communications between GP and the GAIN AdServer is strictly prohibited.”

Network structure for monitoring

As shown in the diagram at right, network monitors (or “packet sniffers”) are devices that inspect and report Internet transmissions from a local network. Sniffers are the ordinary and usual method of observing what data test computers send to and from the Internet. The transmissions from Gator’s software to its servers are sent from users’ PCs over users’ own Internet connections. But according to Gator’s license, users cannot take steps to observe what data Gator is collecting about them. Users must take Gator at its word as to Gator’s privacy policy, because users would violate Gator’s license agreement if they monitored Gator’s transmissions to confirm what data Gator sends.

Beyond constraining ordinary users, this license provision also blocks legitimate academic research. In “Measurement and Analysis of Spyware in a University Environment” (PDF), three University of Washington computer scientists used packet sniffers to measure the prevalence of Gator software and to detect security holes in Gator software. If Gator’s then-current license was as quoted above, their research would seem to constitute a violation. My own past work might also be prohibited, because I have used packet sniffers in multiple projects testing Gator software: In comments to the FTC (PDF, pages 4-6), I reported the precise personal information transmitted by Gator. I previously built a system to report what ads Gator shows where, simply by repeating the format of requests made by ordinary Gator software. (See Documentation of Gator Advertisements and Targeting.)

Gator might be pleased to stop users and researchers from knowing the personal information Gator transmits, tracking the prevalence of Gator’s software, finding Gator’s security holes, and analyzing what ads Gator shows where. But should Gator be able to achieve these results merely by adding an extra sentence to its license agreement?

Getting Gator’s license

A Claria drive-by download prompt — allowing the user to press ‘Yes’ and have software installed, without first seeing Claria’s license agreement.

It’s not always easy to read Gator’s license. For one, some Gator ActiveX “drive-by download” installers include defective license agreements. I have repeatedly observed (and have preserved in video recordings) Gator installers where a user’s specific request for the Gator license (by clicking on the “after accepting our agreements…” hyperlink) yields no license at all. In other instances, the license request yields only the first few lines of a license, presented in a web page that lacks scroll bars with which to view the rest of the license. In these circumstances, even users who specifically ask for Gator licenses do not receive them.

The Kazaa bundle also makes it difficult to review Gator’s license. For example, the current license agreement is longer than ever: The license takes 63 screens to display, compared to 56 in my screenshots of earlier this year.

The ‘printable version’ link, present in old Kazaa installers but no longer available.

Gator has also made its license less accessible by removing one-click access to the full text of the license. In the past, Kazaa’s Gator install screen included a “Printable Version” link (see inset at right and screenshot) which opened the license in a separate text viewer, complete with print, search, and resize functions. However, the “Printable Version” link is omitted from Kazaa’s current Gator installer (screenshot). Users wanting a printable version of Gator’s license have no obvious direct way to get it.

In addition, Gator’s current license merges section headings with body text, making the license harder to read. Gator’s license (as shown by Kazaa earlier this year) previously included nearly three dozen section headings, each using bold type and/or blank lines to help separate and identify a license section. The left screen shot below depicts one such heading. But the current license (right image below) eliminates all but one instance of bold type and also omits the line breaks following all but four (of 37) section headings. With Gator’s section headings effectively indistinguishable from the license text, even determined users can’t readily find the sections of particular interest.

Representative image from Gator’s June 2004 Kazaa installer
(with section headings) (red highlighting added)

The corresponding section of today’s Gator/Kazaa installer
(note section heading merged into body text)

What the License Doesn’t Say

In 5,900+ words of text, there’s no shortage of space for Gator to describe itself in terms that ordinary users can understand. But a search of the license shows Gator has failed even to mention the words and phrases most users associate with Gator’s products.

Although Gator is in the pop-up advertising business, Gator uses these terms infrequently. The license first mentions the word “pop-up” at page 18 of 63. The phrase “pop-up ad” appears only once in the license, at page 27, where the phrase is used to refer to pop-up surveys from Gator’s Feedback Research division. Gator’s pop-up ads are repeatedly described not as “advertisements” but, euphemistically, as “pop-up windows” and “floating images on top other windows” (sic). Nowhere in Gator’s license does Gator use the phrase “pop-up ad” to refer to the Gator pop-ups that cover web sites with advertisements for the sites’ competitors.

Gator calls itself an “adware” company, while critics often call Gator spyware. But neither “adware” nor “spyware” appears anywhere in Gator’s license agreement.

And On and On

I don’t claim to have found all the nuggets of controversy in Gator’s license agreement; there are surely additional problematic sections. Send suggestions for addition to this page.