Year: 2016

Posted on

Assessing Airbnb’s Prospects in its San Francisco Litigation with Nancy Leong

Last week the Internet buzzed with news of Airbnb’s lawsuit against San Francisco. Dissatisfied with a new ordinance updating and enforcing 2014 regulations of short-term rentals, Airbnb filed suit against the city, arguing that the new ordinance violated both federal law and the federal constitution.

In today’s piece, Nancy Leong and I assess Airbnb’s arguments in its San Francisco complaint — finding some validity but, on the whole, considerable weakness.

Assessing Airbnb’s Prospects in its San Francisco Litigation – Yale Journal of Regulation – Notice & Comment

Posted on

Refunds for Minors, Parents, and Guardians for Purchases of Facebook Credits

On May 26, 2016, the U.S. District Court for the Northern District of California approved the settlement of a class action against Facebook involving in-app purchases of Facebook Credits by minor children. The case was maintained on behalf of a class of children who were Facebook users (“child users”) below the age of 18 from whose Facebook accounts Facebook Credits were purchased. The case was filed by two minor children through their parents on February 23, 2012. The two children and the class were represented by attorneys Brooks Cutter and John R. Parker of the Cutter Law Firm in Sacramento, California; Daniel B. Edelman of the firm of Katz, Marshall & Banks in Washington, D.C.; and Benjamin Edelman, an associate professor at the Harvard Business School. On March 10, 2015, the Court certified the case as a class action for purposes of declaratory and injunctive relief on behalf of all minor children who were users of Facebook from whose Facebook accounts Facebook Credits were purchased at any time between February 23, 2008 and the date of the certification order, March 10, 2015. At the same time, the Court declined to certify a class action for purposes of class-wide monetary relief.

During the period covered by the suit, hundreds of thousands of child users purchased Facebook Credits for use in playing Facebook-based games and applications. To make such purchases, child users generally used credit cards, debit cards or other payment instruments that belonged to their parents or other responsible adults. Facebook made a practice of retaining the payment information provided at the time of the child user’s initial purchase for easy use in later purchases. Facebook advised that purchases by children were to be made only with the permission of the parent or guardian. Facebook did not, however, require evidence that any of the purchases was actually authorized by the parent, guardian or owner of the payment instrument. In many instances, the child user did not have authorization to use the card or other payment instrument to purchase Facebook Credits. Facebook specified in its terms of use that all transactions are “final”. It later stated that all transactions are “final except as otherwise required by law”.

Facebook’s Terms of Use state that purchase transactions are governed by the law of California. The Family Code of California provides that contracts with minors are voidable by the minor at any time before attaining the age of 18 or within a reasonable time thereafter. The court applied that principle to this case: “The law shields minors from their lack of judgment and experience and under certain conditions vests in them the right to disaffirm their contracts. Although in many instances such disaffirmance may be a hardship upon those who deal with an infant, the right to avoid his contracts is conferred by law upon a minor for his protection against his own improvidence and the designs of others. It is the policy of the law to protect a minor against himself and his indiscretions and immaturity as well as against the machinations of other people and to discourage adults from contracting with an infant.” (MTD decision, October 25, 2012, at pp. 11-12.) The court continued: “[O]ne who provides a minor with goods and services does so at her own risk.” (Id. at p.12.)

Facebook defended the claims in part by arguing that kids had received and used the electronic goods they paid for. The court specifically rejected this reasoning, finding that kids are entitled to refunds even for items they used. “Under California law, a minor may disaffirm all obligations under a contract, even for services previously rendered, without restoring consideration or the value of services rendered to the other party.” (MTD Decision at p.14, internal quotation marks omitted)

Prior to the settlement, Facebook provided an online procedure for refund requests in various specific circumstances such as fraudulent use of a user’s account by a third-party. Facebook’s refund procedure did not include an option to request a refund on the ground that the purchase was made when the user was a minor.

The settlement requires Facebook to apply refund practices and policies with respect to U.S. minors that comply with the California Family Code.

The settlement further requires Facebook to “add to its refund request form for In-App Purchases for U.S. users a checkbox or substantially similar functionality with accompanying text such that users are able to indicate that the In-App Purchases for which they are seeking a refund was made when the user was minor.”

The settlement additionally requires Facebook to “implement a dedicated queue within Facebook to address refund requests in In-App Purchases, made by U.S. Minors subject to verification of minority. The employees staffing the dedicated queue will receive further training regarding how to analyze and process such refund requests in accordance with applicable law.”

If you or your minor child were charged for Facebook credits purchased from an account belonging to someone age 17 or younger, you may be entitled to obtain refunds for such purchases through the use of the dedicated queue established by Facebook as a result of the settlement. Both minor account holders and the parents and guardians of such minors are entitled to claim such refunds. Claim refunds via the Facebook refund tool.

Free access to selected case documents via Archive.org.

Posted on

Aviation Consumer Protection – Research and Complaints

Air travelers often trust that airlines will treat them fairly, in accordance with law and regulation. In fact, problems abound. I have gathered my research on aviation consumer protection matters, including findings of impropriety as well as complaints to the US Department of Transportation. I also include selected significant complaints by others. My tabulation:

Aviation Consumer Protection – Research and Complaints

Posted on

Preventing Discrimination at Airbnb

In January 2014, Mike Luca and I posted a study finding that black hosts on Airbnb face discrimination: by all indications, guests are less willing to stay at their properties, forcing them to lower their prices to attract guests. More recently, Mike Luca, Dan Svirsky, and I contacted hosts using test guest accounts that were white and black, male and female, showing that black guests are less likely to be accepted by hosts. Both findings are troubling: The Internet has the power to make markets fairer and more inclusive, but Airbnb designed its platform to make race needlessly prominent, all but inviting discrimination.

Initially Airbnb responded to our research by framing discrimination as a problem that has "plagued societies for centuries" and emphasizing that the company "can’t control all the biases" of its users. After a barrage of media coverage, Airbnb CEO Brian Chesky this month admitted that discrimination is a "huge issue" and said the company "will be revisiting the design of our site from end to end to see how we can create a more inclusive platform." Indeed, today Airbnb convenes an invitation-only summit in Washington to discuss the situation and, perhaps, design improvements.

While I applaud Airbnb’s new interest in fighting discrimination on its platform, I can’t agree with Chesky’s subsequent claim that preventing discrimination on Airbnb is "really, really hard." Quite the contrary, the solution is apparent and has been known for years. In today’s piece, I renew my longstanding proposal that would substantially fix the problem, then offer two smaller adjustments that are appropriate under the circumstances.

The solution: Limit the distribution of irrelevant information that facilitates discrimination

Online environments make it easy to limit the information that guests and hosts reveal. If certain information causes discrimination, the natural remedy is to conceal that information so customers do not consider it when making booking and acceptance decisions.

Names and photos typically indicate the races of Airbnb guests and hosts. But names and photos are not necessary for guests and hosts to do business. Hosts and guests can amply assess one anothers’ trustworthiness using the significant other information Airbnb already collects and presents. For these reasons, I contend that the Airbnb site should not reveal sensitive race information until a transaction is confirmed. If guests and hosts don’t see names and photos in advance, they simply won’t be able to discriminate on that basis.

The proposal is a smaller change than it might at first appear. In fact, Airbnb has long limited information flows to advance its business interests. Airbnb’s revenue depends not just on introducing hosts to guests, and vice versa, but on transactions actually flowing through Airbnb’s platform so Airbnb can charge booking fees. Airbnb’s revenue would drop if guests and hosts could contact each other directly and agree to pay via Paypal, cash on arrival, or similar. To prevent hosts and guests from going around Airbnb, the company withholds email addresses and phone numbers while the users are still discussing a possible stay — letting each user examine the other’s profile, reviews, verifications, and more, but intentionally withholding the two pieces of information that would undermine Airbnb’s revenue. But Airbnb doesn’t just limit information presented in profiles and request templates; it also affirmatively filters messages between guests and hosts. Airbnb provides a text message system to let users ask questions and share more details, but it doesn’t want the messages to be used to cut Airbnb out of the transaction. So Airbnb’s servers examine each message and blocksanything that looks like an email address or a phone number. In short, there’s ample precedent for Airbnb withholding information — when it wants to.

I anticipate several objections to the proposed change:

  • Trust and safety. Certainly trust issues are central to Airbnb’s business — letting strangers stay in your home when you’re not there to supervise; staying in a stranger’s home when you’re at your most vulnerable (asleep). In that context, some might argue that every possible piece of additional information is important and should be provided. But I question what information the names and photos truly add. Airbnb already validates users’ identities, including checking driver’s license photographs and asking identity verification questions that impostors would struggle to answer. Airbnb reports linked Facebook and LinkedIn profiles, and Airbnb presents and tabulates reviews from prior transactions. Plus, all Airbnb transactions are prepaid. As a result, a host considering a guest’s request learns that the prospective guest has (say) a verified phone number and email, verified identity, verified Facebook and LinkedIn profiles with two hundred connections in total, and five favorable reviews from other Airbnb stays within the last year. A name and photo reveal race, gender, and age, but they provide little information about genuine trustworthiness. Whatever information the name and photo provide, that information comes more from (potentially inaccurate) stereotypes than from the name and photo themselves.
  • Perhaps users would be confused by communications without names. But "Airbnb Guest" and "Airbnb Host" make fine placeholders. Alternatively, Airbnb could move to a username system, letting users choose their own nicknames to use before a transaction is confirmed. eBay follows exactly that approach, and it works just fine. Airbnb would still organize a host’s messages with a given guest into a single page, and vice versa.
  • Some hosts want to see guest photos before accepting a request, and vice versa for guests choosing hosts. But if a homeowner is particularly concerned about strangers visiting his property, perhaps he shouldn’t be running a de facto hotel.
  • Photos help guests and hosts recognize each other. Airbnb’s David King, Director of Diversity and Belonging, in April 2016 told NPR: "The photos are on the platform for a reason. … You want to make sure that that guest that shows up at your door is the person that you’ve been communicating with." But nothing in the proposed change would prevent a host and guest from recognizing each other. After a booking is confirmed, they’d still see names and photos just as they do now. The change is to timing — revealing names and photos only after the booking is final.

In principle, Airbnb’s approach to names and photos could vary based on the type of listing. For example, names and photos might be viewed with special skepticism when a guest is renting the entire property. After all, when a guest occupies a property exclusively, the guest and host will have limited interaction. Indeed, they may never meet in person at all, exchanging keys via a doorman or lockbox. Then the specific identity of guest and host are all the less important. Conversely, it’s somewhat easier to see a proper role for photos and names when a host is truly "sharing" a property with a guest, jointly using common property facilities (perhaps a shared kitchen) or otherwise interacting with each other.

Allow testing

After our study, several users ran their own tests to assess possible discrimination. For example, after being rejected by a host, a black guest might create a new account with a "white-sounding" name and a photo of a white person — then use that new account to reapply to the same host. Multiple users have tested for discrimination via this methodology. (Examples: 1, 2)

Crucially, Airbnb prohibits such testing. Airbnb’s compulsory Terms of Service forbids all test accounts, instead requiring that users "agree to provide accurate, current and complete information during the registration process." Furthermore, Airbnb specifically insists that each user "may not have more than one (1) active Airbnb Account," and Airbnb claims the right to entirely eject any person who creates multiple accounts. But if each a user is limited to a single account, in the user’s true name, most testing procedures are unworkable.

Airbnb rigorously enforces its prohibitions on test accounts and follows through on its threats to exclude users with multiple accounts. Indeed, during the testing for my second article about Airbnb discrimination, the company closed my personal account — even removing my reputation and reviews accumulated from prior stays. I requested that Airbnb reopen my account but have received no reply, and my account remains disabled to this day.

Airbnb has no proper reason to penalize those who test its services. It would be intolerable for a car dealership to post a sign saying "No testers allowed" in hopes of concealing prices that vary prices based on a buyer’s race. Nor should Airbnb be able to conceal discrimination on its platform through contractual restrictions and penalties.

Normalize dispute resolution

The standard American approach to dispute resolution is the legal system — judge and jury. Dissatisfied hosts and guests — such as those who think they’ve faced discrimination — ordinarily could go to court to explain the problem and try to articulate a violation of applicable law. But Airbnb specifically prohibits users from filing a standard lawsuit. In particular, Airbnb’s Terms of Service instead demand that "any dispute, claim or controversy arising out of or relating to … the Services or use of the Site … will be settled by binding arbitration."

For guests and hosts, arbitration presents several key problems. For one, Airbnb chose the arbitration service, so anyone pursuing a grievance might naturally worry that the arbitrator will favor Airbnb. Furthermore, arbitration results are confidential — so even if some users prevail against Airbnb, the interested public would never find out. Arbitration also provides little to no ability for complainants to get the documents they need to prove their case, for example by searching Airbnb’s records to learn what the company knew, who else complained, and what alternatives it considered. Nor does arbitration provide an appeals process appropriate for exploring new or complex questions of law. Most of all, Airbnb requires that each dispute proceed solely on an individual basis, and "the arbitrator may not consolidate more than one person’s claims." But individual complaints are inevitably small, with value too low to justify the top-notch attorneys and experts who would be needed to prove discrimination and explore Airbnb’s responsibility.

Courts, not arbitrations, are the proper way to resolve these important disputes. The appearance of legitimacy would be much improved if decisions were rendered by a judge and jury chosen through formal government processes. With access to Airbnb documents and records as provided by law, aggrieved users would be able to search for information to support their claims — giving them a fair chance to assemble the evidence they need. With appeals, a series of judges would assess the situation and correct any errors in legal reasoning. And with a single case assessing the rights of a group of similar users, economies of scale would allow users to get the specialized assistance they need to have a real shot.

I don’t know that aggrieved guests or hosts would prevail against Airbnb on matters of discrimination. In some respects, such a case would break new ground, and Airbnb would forcefully argue that it is individual hosts, not Airbnb itself, whose actions are out of line. But Airbnb should face such complaints on the merits, not hide behind a contract that prevents users from bringing suit.

Airbnb told the New York Times that "these [arbitration] provisions are common." Certainly many companies require that customers arbitrate any disputes. But Airbnb’s service is special, raising persistent and serious concerns about discrimination (among other issues). These heightened sensitivities call for a different approach to dispute resolution — and a dispute system that works for credit cards and cell phone plans may not be right for questions of race, equality, and justice.

Airbnb also told the Times that "we believe ours [our arbitration agreement] is balanced and protects consumers." But it’s hard to see the balance in a contract that only takes rights away from users. Were the contract silent on dispute resolution, users could sue in any court authorized by law to hear the dispute, but instead Airbnb insists that not a single court, in any jurisdiction nationwide, can adjudicate any dispute pertaining to users’ relationships with Airbnb.

The incomplete benefits of Instant Book

Airbnb hosts are able to discriminate against disfavored guests because Airbnb’s standard process gives hosts discretion as to which guests to accept. Airbnb’s Instant Book feature thus offers a potential mechanism to reduce discrimination: When hosts pre-promise to accept any interested guest who agrees to pay, there’s much less opportunity to discriminate. Nonetheless, Instant Book addresses only a portion of the problem.

The biggest weakness of Instant Book is that only a fraction of properties offer this feature. A guest who wants to use Instant Book to avoid discrimination is thus accepting a much narrower range of properties. Airbnb periodically encourages hosts to try Instant Book, and it seems the proportion of properties with Instant Book is increasing, but slowly. That’s unsatisfactory: Guests shouldn’t have to choose between fair treatment and a full range of properties.

A second problem with Instant Book is that it serves only to protect guests from discrimination by hosts, but not to protect hosts from discrimination by guests. My research indicates that both problems are real, and Instant Book does nothing about the second.

A final concern is the prospect of cancellations that undo the anti-discrimination benefits of Instant Book. In principle a host could invoke Airbnb’s cancellation feature to reject a disfavored guest whose request was automatically confirmed by Instant Book. That’s exceptionally disruptive to the guest, taking away a booking which had already been paid in full and presented, to the guest and in Airbnb records, as confirmed. These problems are more than speculative; among others, the racist North Carolina host who canceled a black guest’s confirmed reservation had initially accepted that reservation via Instant Book.

To its credit, Airbnb requires a host to provide a reason when cancelling an Instant Book reservation, and Airbnb limits such cancellation to three per year. But the cancellations are penalty-free without any charge to hosts or any indication on a host’s profile page. (In contrast, when non-Instant Book hosts cancel reservations, they are charged fees and are penalized in profiles and on search results.) Moreover, three cancellations may suffice for many hosts to implement discriminatory preferences. If a host receives only occasional requests from the guests it seeks to discriminate against, the host could cancel those guests’ Instant Book stays with relative impunity.

Looking forward

Airbnb co-founder Joe Gebbia recently explained the site’s widespread use of photos of guests and hosts: "[A]nytime we could show a face in our service, we would … – in search results, on profiles, on the actual homepage.” Certainly photos are visually appealing and add some information. But the risk of discrimination appears to be unavoidable when photos are presented before a transaction is confirmed. No one would tolerate a hotel that required prospective guests to submit photos — nor a traditional bed-and-breakfast that did so. Nor should this approach be used online. The risk of discrimination is just too great relative to any benefit the photos may provide.

In January 2014, Mike Luca and I suggested the changes Airbnb should make to prevent discrimination:

[T]here is no fundamental reason why a guest need s see a host’s picture in advance of making a booking — nor does a guest necessarily even need to know a host’s name (from which race may be infered…). Indeed, Airbnb itself prohibits (and run s software to prevent) hosts and guests from sharing email addresses or phone numbers before a booking is made, lest this information exchange let parties contract directly and avoid Airbnb fees. Given Airbnb’s careful consideration of what information is available to guests and hosts, Airbnb might consider eliminating or reducing the prominence of host photos: It is not immediately obvious what beneficial information these photos provide, while they risk facilitating discrimination by guests. Particularly when a guest will be renting an entire property, the guest’s interaction with the host will be quite limited, and we see no real need for Airbnb to highlight the host’s picture.

Two and a half years later, the proposal remains appropriate, easy, and effective. Airbnb CEO Brian Chesky says the company "needs help solving" discrimination on Airbnb . Perhaps our longstanding proposal can be of assistance.

Posted on

Disintermediation in Two-Sided Marketplaces (teaching materials) with Philip Hu

Edelman, Benjamin, and Philip Hu. “Disintermediation in Two-Sided Marketplaces.” Harvard Business School Technical Note 917-004, June 2016. (Revised March 2017.) (educator access at HBP. request a courtesy copy.)

Two-sided marketplaces often risk disintermediation: users may rely on the marketplace to find each other but then perform related future transactions—or even the current transaction—without the platform’s involvement and without paying any fees the platform may charge. This technical note assesses which marketplaces are most vulnerable to disintermediation and offers a set of strategies marketplaces can implement in order to reduce their vulnerability.

Posted on

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.

Posted on

FCC Comment on Expanding Consumers’ Video Navigation Choices

Disclosure: I serve as a consultant to various companies that compete with Google. I filed the underlying FCC comment at the request of the Future of TV Coalition. But no client directed my comment or had the right to revise it before submission.

Today I filed comments in the FCC’s ongoing proceeding Expanding Consumers’ Video Navigation Choices. The FCC calls the initiative "unlock the box" — allowing consumers to buy set-top boxes from any of a variety of competitive manufacturers, not just leasing from their cable companies.

On one hand, the FCC’s proposal benefits from favorable experience three decades ago. It’s hard to overstate the benefits of the 1982 FCC rule that granted consumers the right to supply their own telephone equipment — crucially including fax machines and modems.

But in the context of set-top boxes, the FCC’s approach would have implications far beyond hardware design and user interface. As I point out in my comment, alternative set-top boxes might add new forms of advertising — not just in channel guides, but in prerolls, superimposed panels, and even insertions within commercial breaks. Meanwhile alternative set-top boxes could even remove existing advertising — a particularly serious intrusion into the advertising-based model of most television programming. These tactics would undermine the basic business model and value exchange of advertising-supported video programming. What advertiser would pay top dollar to advertise in a television show if widely-used alternative set-top boxes remove the ad and substitute other ads for, no doubt, the advertiser’s direct competitors?

As it turns out, the FCC is well aware of these problems. In the FCC’s February 18, 2016 Open Commission Meeting, Ars Technica’s Jon Brodkin asked FCC Chairman Tom Wheeler about advertising issues. Their exchange:

Q: I want to ask about the issue of advertising in third-party set top boxes. You said nothing will change that. What prevents a set top box maker from putting advertising in? …

A: The rule will prohibit it. You need to have the sanctity of the content. Nobody is going to insert ads into it. Nobody is going to make a split screen where they’re putting ads next to it. Nobody is going to say it’s a frame around it, where you can say “Go to Joe’s Auto Repair.” It’s going to require the sanctity of the content be passed through unchanged.

Q: Does that include the neighborhood agreements?

A: Programming agreements are included. Programming agreements are part of the sanctity of the content. … That’s still there.

Q: So the rule will specifically prohibit extra advertising?

A: Yes sir.

(See minute 129 of the meeting video.)

Despite the clarity of Wheeler’s response, the FCC’s NPRM provides no such assurance — zero protection whatsoever against extra advertising or, for that matter, removal of existing advertising. One might that hope principles of copyright would disallow those tactics. But copyright law has struggled to address intermediaries that insert and remove advertising. (Consider a decade of adware cases, where advertisers’ ads often covered their competitors’ sites.) So if the FCC is silent on the permissibility of adding, removing, or changing advertising, it’s likely that new boxes will attempt all those methods.

Relatedly, the FCC’s proposal offers disproportionate benefits to Google, whose dominance is at this point beyond dispute. For one, Google could offer an alternative set-top box that delivers advertisements targeted based on users’ activities in Google Search, Gmail, Maps, and more. Furthermore, Google’s lawyers have taken expansive views of fair use — making them particularly well-positioned to argue the permissibility of removing other companies’ advertisements and inserting their own. To date, television has been one of the few electronic advertising spheres where Google is not dominant — so if the FCC’s approach helps Google grow there, advertisers dissatisfied with the company would have even fewer alternatives.

My bottom-line: Whatever innovations and cost-savings might result from alternative set-top boxes, I don’t see how they can outweigh the clear concerns in advertising, copyright, program integrity, and competition.

Further details in my full comments to the FCC:

Comment on Expanding Consumers’ Video Navigation Choices – Benjamin Edelman – May 23, 2016.

Posted on

Uber Overcharges, Spring 2016

While claiming price advantages over taxis, Uber overcharges consumers by withholding promised discounts and credits. In today’s post, I examine a set of Uber pricing guffaws — each, a breach of the company’s own unambiguous written commitments — that have overcharged consumers for months on end. Taken together, these practices call into question Uber’s treatment of consumers, the company’s legal and compliance processes, and its approach to customer service and dispute resolution.

A "free ride" or a $15 discount?

Uber offers 'free rides' when users refer friends. Uber offers "free rides" when users refer friends.

Uber specifically confirms that the friend's 'first ride' is free, while the existing user gets 'a free ride (up to $15).'Uber specifically confirms that the friend’s "first ride" is free, while the existing user gets "a free ride (up to $15)."

Uber asks existing users to refer friends — promising significant sign up bonuses to both new and existing users for each referral. First, the existing user activates the Free Rides function in the Uber app, revealing the offer and a code that the new user must enter so Uber can track the referral. Quoting from the first screenshot at right (emphasis added):

Share your invite code [placeholder]. Send friends free rides and you’ll get one too, worth $15! Details. INVITE FRIENDS.

A user who taps "Details" sees two additional sentences (quoting from the second screenshot at right):

Share your promo code with friends and they’ll get their first ride free. Once they’ve tried Uber, you’ll automatically get a free ride (up to $15) the next time you use Uber. CLOSE.

Neither screen provides any menu, link, button, or other command offering more details about other requirements or conditions. The text quoted above is the entirety of Uber’s offer.

Uber’s promise is clear — a "first ride free" for the new user, and a "free ride (up to $15)" for the existing user. But Uber’s actual practice is quite different. Most notably, the new user’s "free ride" is also limited to a $15 discount. One might ask whether the "worth $15" in the first screen applies to the friend’s free ride or to the existing user’s free ride or perhaps both. But the Details screen leaves no doubt that this limitation applies only to the existing user. Notice the placement of the "up to $15" parenthetical only in the sentence describing the existing user’s free ride. In contrast, the separate sentence about the new user’s ride promises "their first ride free" with no indication of any maximum value.

These discrepancies create unfortunate surprises for typical Uber customers. Consider the standard workflow. An existing Uber user tells a friend about Uber and, in person, helps the new user install the app and create an account, including entering the existing user’s referral code when prompted. "You’ll get a free ride," the existing user explains, guided by Uber’s simple on-screen offer. The new user then takes an expensive ride; expecting the ride to be free (as promised), the new user might choose Uber for a distance that would otherwise have been a better fit for a train or bus, or the new user might accept a high surge multiplier. Only later does the new user learn that according to Uber, "free" actually meant a $15 discount. The user would have no written evidence of Uber’s "free ride" promise, which was conveyed orally by the existing user. So the new user is unlikely to complain — and my experience (detailed below) indicates that a request to Uber is unlikely to get satisfaction.

I know about these problems because of an experience referring a friend — call her my cousin — in January 2016. I told her she’d get a free ride, but her receipt showed no such benefit. In fact she took her first ride in another country, which prompted me to check for other discrepancies between Uber’s marketing statements and its actual practice.

Piecing together statements from Uber’s support staff and the various disclosures in Uber’s Android, iOS, and mobile web apps, I found five separate restrictions that were not mentioned mentioned anywhere in Uber’s new user offer as presented to existing Android users:

  • The new user’s credit only applies to a ride in the country that Uber designates as the new user’s home country or the currency that Uber designates as the new user’s home currency. But Uber’s signup page doesn’t ask about a user’s home country or currency. As best I can tell, Uber automatically sets a user’s home country based on the user’s IP address or location at the time of signup. (Source: Uber staff indicated that "the promo is currency specific" in explaining why my cousin received no discount on her first ride.)
  • The existing user’s credit can only be redeemed towards a ride in the country that Uber designates as the existing user’s home country. (Source: Uber’s iOS app, GET FREE RIDES offer, secondary disclosure screen, stating that "discounts apply automatically in your country," emphasis added.)
  • The new user’s maximum ride value varies by country. Not only is there a maximum value (contrary to the simple "first ride free" in Uber’s second screen above), but the maximum value is not mentioned to the existing user. (Source: Uber’s iOS app, GET FREE RIDES offer, secondary disclosure screen; and mobile web, new user offer, page footer.)
  • All discounts expire three months from issue date. (Source: Uber’s iOS app, GET FREE RIDES offer, secondary disclosure screen.)
  • Offer is not valid for UberTaxi. (Source: Uber’s iOS app, GET FREE RIDES offer, secondary disclosure screen; and mobile web, GET FREE RIDES offer, page footer.)

The table below presents the Uber’s marketing offers in all three platforms, along with the errors I see in each:

  Android iOS Mobile Web
Primary disclosure FREE RIDES. Share your invite code [placeholder]. Send friends free rides and you’ll get one too, worth $15! Details. INVITE FRIENDS. GET FREE RIDES. They get a free ride and you will too (worth up to $15), after their first ride. Details. GET FREE RIDES. Sign up now to claim your free gift from [placeholder] ($15 off first ride)*.
Secondary disclosure Share your promo code with friends and they’ll get their first ride free. Once they’ve tried Uber, you’ll automatically get a free ride (up to $15) the next time you use Uber. CLOSE.

Every time a new Uber user signs up with your invite code, they’ll get their first ride free (value amounts vary by location).

Once they take their first ride, you’ll automatically get your next ride free (worth up to $15).

Discounts apply automatically in your country and expire 3 months from their issue date. Offer not valid for uberTAXI.

Every time a friend signs up with your invite code, they’ll get their first ride free (value amounts vary by country). Once they use it, you’ll automatically get a free ride to use the next time you Uber (worth up to $15). Offer not valid for UberTaxi.
Errors

New user’s ride is actually limited to $15 (or other amounts in other countries). In contrast, both disclosures indicate that there is no limit to the value of the new user’s ride.

Discount only applies to a new user’s first ride in the user’s home country as determined by Uber.

Existing user’s discount can only be redeemed in existing user’s home country.

Discounts for both the new and existing user expire three months from issue date.

Offer is not valid for UberTaxi.

Secondary disclosure plausibly contradicts primary disclosure: Primary disclosure promised "a free ride" for the new user, while secondary disclosure retracts "free ride" and instead offers only a discount. In contrast, FTC rules allow secondary disclosures only to clarify, not to contradict prior statements.

Discount only applies to a new user’s first ride in the user’s home country as determined by Uber.

Discount only applies to a new user’s first ride in the user’s home country as determined by Uber.

Existing user’s discount can only be redeemed in existing user’s home country.

Discounts for both the new and existing user expire three months from issue date.

I first alerted Uber staff to these discrepancies in January 2016. It was a difficult discussion: My inquiries were bounced among four different support representatives, with a different person replying every time and no one addressing the substance of my messages. So I reluctantly gave up.

Six weeks later, a different Uber rep replied out of the blue. He seemed to better understand the problem, and I managed to get two separate replies from him. At my request, he committed to "pass this along to the appropriate team." That said, he did not respond to my repeated suggestion that Uber needed to refund affected consumers.

Eight weeks after my final correspondence with the fifth Uber representative and sixteen weeks after I first alerted Uber to the problem, I see no improvement. Uber’s Android app still makes the same incorrect statements about promotion benefits, verbatim identical to what I observed in January.

Credit on your "next trip" — or later, or not at all

Uber claimed I'd get a 'credit' on my 'next trip.' Uber claimed I’d get a "credit" on my "next trip." In fact, the credit seems to apply only to a future trip in the same country where the problem occurred.

In a variety of circumstances, Uber responds to customer complaints by issuing credits towards a customer’s "next trip." For example, during a recent attempt to ride with Uber in Mexico, I was unable to find or contact the driver. (I was where the on-screen pushpin told me to be, and GPS seemingly told the driver he was where he was supposed to be, but we just couldn’t find each other.) I later received an email receipt showing that I had been charged a cancellation fee. In Uber’s "Help" area, I used Uber’s "I was charged a cancellation fee" feature, and I was immediately advised (emphasis added):

We’ve credited your Uber account. Thanks for letting us know what happened. A credit has been added to your Uber account. This credit will apply to your next trip.

Imagine my surprise when, upon returning to the US a few hours later, I took another Uber ride but received no such credit.

It seems Uber’s notion of credits is in fact country-specific or currency-specific. My problem resulted from difficulty finding a driver in Mexico, where I don’t live and rarely travel. Far from applying the credit on my "next trip," it seems Uber’s systems will carry the credit forward to my next journey in Mexico. (See Uber’s Payment screen, "Credit Balances" section, showing the amount of the cancellation fee as a credit in the currency associated with the country where that fee was charged.) But this is much less useful to users traveling internationally. For example, Uber might impose a time limit on the credit — analogous to Uber’s undisclosed three month limit for use of a "free ride" credit (as revealed in the preceding section). And some users may never return to (or never again take Uber rides in) certain countries or currencies. The plain language of "your next trip" of course purports to protect users against all these contingencies; "your next trip" means a trip denominated in any currency, perhaps soon but perhaps indefinitely in the future. Uber’s actual practice is plainly less favorable to consumers.

Here too, predictable consumer responses increase the harm from Uber’s approach. If a consumer was charged improperly and felt Uber’s response was out of line, the consumer might pursue a credit card chargeback. But when Uber tells the consumer "We’ve credited your Uber account" and "This credit will apply to your next trip," there’s every reason to think the problem is completely fixed. Then the consumer may forget about the problem; certainly the consumer is less likely to diligently check future Uber receipts for a credit that was slated to be automatic and guaranteed. In addition, consumers are vulnerable to the passing of time: If a consumer rides with Uber only occasionally, the permissible time for a chargeback may have elapsed by the time the consumer’s next ride.

Update (May 25, 2016): Four weeks after I reported this discrepancy to Uber, I received a reply from an Uber representative. He confirmed that I did not receive the promised credit for the general reason I described above — a credit provided in one currency, while my next trips was in a different currency. I reminded him that Uber’s statements to users say nothing of any such restriction. I also pointed out that Uber is capable of converting currencies, and I encouraged him to assure that other users, similarly situated, are appropriately refunded. So far as I know, Uber has not done so.

Others’ reports

Checking with friends and colleagues, and receiving further reports from strangers, I’ve learned about a fair number of other Uber billing errata. For example, one user confidently reported that when a driver cancels a ride — perhaps seeing a surge in another app, getting lost, learning that the passenger’s destination is inconvenient, or just changing his or her mind — Uber still charges the passenger a cancellation fee. I haven’t been able to verify this, as I don’t have an easy way to cause a driver to cancel. But in the Uber help tool, the "I was charged a cancellation fee" menu offers as one of its preset reasons for complaint "My driver cancelled" — confirming that Uber’s systems charge cancellation fees to passengers when drivers cancel. Of course Uber’s systems can distinguish who pressed the cancel button, plus Uber could ask a driver the reason for cancellation. I see no proper reason for Uber ever to charge a passenger a cancelation fee if it is the driver who elected to cancel.

Users with experience with this problem, or other Uber contracting or billing errata, should feel free to contact me. I’ll add their experiences here or in a follow-up.

Update (June 4): Readers alerted me to UberPool drivers repeatedly charging for two passengers purportedly riding, when only one passenger was actually present, increasing the charge to passengers.

Update (June 4): In federal litigation against Uber, blind passenger Tiffany Jolliff reports that not only did multiple Uber drivers refuse to transport her and her service dog, but Uber charged her a cancellation fee each time a driver refused to transport her.

Lessons from Uber’s billing errors

I see four distinct takeaways from these billing errors. First, Uber’s engineering, testing, and legal teams need to sharpen their focus on billing, promotions, and credits. The coding of a promotional offer is inextricably linked to the marketing text that describes the offer. Similarly, the coding of a customer service benefit must match the text that explains the benefit to users. Both should be checked by attorneys who specialize in advertising law and consumer protection. Instead, in the problems I described here, Uber’s billing logic seems to be entirely separate from the text presented to consumers. It is particularly striking to see Uber’s three separate textual descriptions of the new user promotion — all three of them incorrect, yet in three different ways. Even a basic attorney review would have flagged the discrepancies and identified the need to inquire further. An advanced attorney review, fully attuned to FTC disclosure rules, might also question what appears in the primary disclosure versus the secondary disclosure. Attorneys might reasonably caution Uber against repeatedly and prominently promising "FREE RIDES" when the company’s actual offer is a discount.

Second, Uber’s overcharging is both large and long-lasting. I reported the new user promotion problems in January 2016, although they probably began considerably earlier. (Perhaps Uber will respond to this article by determining, and telling the public, when the problems began.) In response to this article, I expect that Uber will fix these specific problems promptly. But given Uber’s massive operations — many thousands of new users per month — the aggregate harm is plausibly well into the millions of dollars.

Third, my experience calls into question whether Uber’s customer service staff are up to the task of investigating or resolving these problems. Writing in to customer service is fruitless; even with screenshots proving the discrepancy in the new user promotion, Uber was slow to promise a refund to match the marketing commitment. (It took five separate messages over eight weeks!) In fact, even after promising the refund in a message of March 16, 2016, that refund never actually occurred. Similarly, I promptly alerted Uber to the "next ride" credit not provided — but ten days later, I have received neither the promised credit nor any reply. Others have reported the shortfalls of Uber’s customer service staff including ineffective responses, a focus on response speed rather than correctness, and insufficient training. My experience suggests that these problems are genuine and ongoing. Users with the most complicated problems — Uber system flaws, discrepancies between records, billing errors — appear to be particularly unlikely to achieve resolution.

Finally, users lack meaningful recourse in responding to Uber’s overcharges. In each of the problems I found, Uber is overcharging a modest amount to each of many thousands of customers. Ordinarily, this would be a natural context for class action litigation, which would allow a single judge and a single set of lawyers to figure out what happened and how to set things right. But Uber’s Terms and Conditions purport to disallow users to sue Uber at all, instead requiring arbitration. Furthermore, Uber claims to disallow group arbitration, instead requiring that each consumer bring a separate claim. That’s inefficient and uneconomical. Uber’s arbitration clause thus provides a de facto free pass against litigation and legal remedies. Of course many companies use arbitration to similarly immunize themselves against consumer claims. But Uber’s controversial activities, including the overbilling described here among many other disputes, give consumers extra reason to seek judicial oversight.

Next steps

Just last week, Uber formed a paid advisory board of ex-regulators, most with competition and consumer protection expertise. These experts should exercise independent judgment in looking into the full breadth of Uber’s problems. I doubt overbilling was previously on their agenda, but my experience suggests it should be. To investigate, they might review all customer service threads with five or more messages, plus look for all messages attaching screenshots or mentioning "overcharge" or "promised" or "contract." Tthey shouldn’t rely merely on Uber staff summaries of customer experience; with an advisory board of superstars, the group should bring independent judgment to assessing and improving the company’s approach.

Meanwhile, Uber’s response should include a full refund to each and every user who was overcharged. For example, when Uber promised a "free ride" to an Android user who in turn referred a friend, Uber should provide the friend with a refund to achieve exactly that — not just the $15 discount that may be what Uber intended but isn’t what the offer actually said. Since Uber may be disinclined to offer these refunds voluntarily, I’m alerting consumer protection and transportation regulators in appropriate jurisdictions to help push to get users what they were promised.

Posted on

EC Statement of Objections on Google’s Tactics in Mobile

Today the European Commission announced a Statement of Objections to Google’s approach to Android mobile licensing and applications. Broadly, the EC’s concerns arise from Google’s contractual restrictions on phone manufacturers — requiring them to install certain apps, in certain settings, if they want other apps; preventing customizations that manufacturers would prefer; requiring manufacturers to set Google Search as the sole and default search provider.

These questions are near and dear to me because, so far as I know, I broke the story of Google’s Mobile Application Distribution Agreement contracts, the previously-secret documents that embody most of the restrictions DG Comp challenges. I described these documents in a February 2014 post:

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.

I offered the HTC MADA and Samsung MADA, both as they stood as of year-end 2010. So far as I know, these are the only MADA’s available on the web to this day; while Google now admits that MADAs exist (a fact unknown to the public before I posted these documents), no one has circulated any newer versions. Occasional news reports discuss new versions, most notably a September 2014 piece from The Information’s Amir Efrati reporting new and growing requirements embodied in "confidential documents viewed by The Information" but unfortunately not available to the public. So the documents I posted remain the best available evidence of the relevant restrictions.

While news reports and the EC SO offer some sense of MADA requirements, there’s no substitute for reading the plain language of the underlying contracts. I cited and quoted key sections in my 2014 piece:

"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).

"Naked exclusion" and impeding competition

Competition lawyers offer the term "naked exclusion" for conduct unabashedly intended to exclude rivals, for which a dominant firm offers no efficiency justification. That diagnosis matches my understanding of these tactics, as the MADAs give no suggestion that Google is trying to help consumers or anyone else. Rather, the MADAs appear to be intended to push Google’s own businesses and prevent competitors from getting traction.

Consider the impact on competing firms. Suppose some competing app maker sought to increase use of one of its apps, say Yahoo seeking greater usage of Yahoo Maps. Yahoo might reasonably offer a bonus payment to, say, Samsung as an incentive for featuring the Yahoo Maps app on new phones sold via, say, AT&T. To encourage users to give Yahoo Maps a serious try, Yahoo would want its service to be the only preinstalled mapping app; otherwise, Yahoo would rightly anticipate that many users would discard Yahoo Maps and go straight to the familiar Google Maps. For $2 per phone, Samsung might be happy to remove Google Maps and preinstall Yahoo Maps, figuring any dissatisfied consumer could download Google Maps. And if some of that $2 was passed back to consumers via a lower price for purchasing the phone, consumers might be pleased too. Crucially, Google’s MADA prevents this effort and others like it. In particular, the MADA requirements prevent Samsung from removing any of the listed Google apps, Google Maps key among them. And if Samsung can only offer Yahoo the option to be a second preinstalled mapping app, it’s much less clear that Yahoo is willing to pay. In fact, based on Yahoo’s reasonable projections of user response, there may no longer be a price that Yahoo is willing to pay and Samsung is willing to accept.

The first key effect of the MADAs, then, is that they prevent new entrants and other competitors from paying to get exclusive placement. This impedes competition and entry, and streamlines Google’s dominance.

Meanwhile, the MADAs correspondingly reduce pressure on Google to provide market-leading functionality and quality. Some competing apps might be a little bit better than Google’s offerings, and a phone manufacturer might correctly assess that consumers would prefer those alternatives. But phone manufacturers can’t switch to those offerings because the MADA disallows those changes. This barrier to switching in turn discourages competing app makers from even trying to compete. After all, if they can’t get traction even when their apps are genuinely better, they won’t be able to raise capital and won’t develop the improvements in the first place.

Finally, the MADAs prevent Google from needing to pay to get and retain preferred placements and defaults. On desktop computers, search engines pay to be a browser’s default — giving additional revenue to a computer manufacturer, and reducing device cost. But MADAs allow Google to require that it be the default search provider, and require that its apps be preinstalled and prominent, all without payment to phone manufacturers.

Assessing Google’s responses

This week reporters conveyed to me Google’s responses to the EC’s SO. First, Google argued that it is merely requiring that its apps be preinstalled, not ruling out the possibility that other apps may be preinstalled too. That defense has three key weaknesses.

  • Some MADA provisions explicitly do require that Google functions be the sole or default in their spheres. Consider the requirement that Google Search be the default search provider for all Web search access points (MADA Section 3.4(4)) and the requirement that Google’s Network Location Provider service must be preloaded and default (MADA Section 3.8(c)). One can hardly overstate the importance of these two functions. Search is the most natural way to monetize users’ activities and is the natural gateway to other functions and services. Meanwhile, location providers are the crucial translation between a phone’s sensors and its inferences about the user’s geographic location — collecting and aggregating location data with exceptional commercial value though of course also special privacy consequences. In these two crucial areas, Google does exactly what its defense claims it does not — requiring not only that its services be installed, but that they be installed as the sole and exclusive default. We are fortunate to be able to read the MADAs (HTC, Samsung) to see these requirements embodied in contract language.
  • The possibility of a more intrusive restriction does nothing to deny the harm from the approach Google chose. Google sketches a different restriction on competition that would cause even larger harm — requiring not just preinstallation of Google apps but explicit contractual exclusion of competitors. But the possibility of a worse alternative does not mean Google’s approach is permitted.
  • Google’s argument runs counter to settled European competition law. Consider experience from prior EC proceedings against Microsoft. Microsoft always allowed OEM’s to install other web browsers and other media players. Nonetheless Microsoft faced EC penalties for requiring that OEM’s include Microsoft’s browser and media player. The law of the land, for better or for worse, is that dominant firms may not invoke this approach.

Second, Google told reporters that its tactics are necessary to protect the health of the Android ecosystem and to build and retain consumer trust. But this argument strains credibility. Would the Android ecosystem truly be less reliable or trustworthy if some phones came with, say, Yahoo Maps? The better assessment is that Google imposes MADA restrictions to advance its business interests. To evaluate these alternative understandings of Google’s conduct, one might depose Google employees or better yet read contemporaneous documents. Beginning in 2010, Skyhook litigation revealed some of Google’s internal email discussions in this area, revealing reveal that their purpose is competitive — "using compatibility as a club to make them [phone makers] do things we want." Further evidence against Google’s ecosystem/trust argument comes from Android’s other notable ecosystem weaknesses — from brazenly counterfeit apps to confusingly inconsistent user interfaces. Allowing those problems to fester for years, Google cannot plausibly claim significant consumer confusion or ecosystem harm from, say, a competing maps app clearly labeled as such.

Third, Google argued that dissatisfied phone manufacturers can always install core Android without any Google Mobile Services and hence without the MADA obligations. But this approach ignores commercial realities. In wealthy markets such as the EC and the US, few customers would accept an Android phone without Google Play, the app store necessary to install other apps. Without Google Play, consumers cannot get the Facebook app, the Pandora, Uber, and so on. Such a limited phone would be a nonstarter for mainstream users. Amazon’s Fire flop reveals that even Amazon, with a trusted name and distinctive positioning, could not offer a viable phone without Google Play access to install other apps. Conversely, consider how much more attractive users would have found Fire had they been able to use Google Play to get the benefit of third-party apps alongside the distinctive features Amazon provided. But Google’s MADA exactly prohibited that approach — converting a promising potential competitor into a weakling that quickly collapsed.

Looking ahead

One crucial next step is discussion of remedies — what exactly Google must do in order to correct the distortions its MADAs have created. Bloomberg reports Google reducing the number of apps phone manufacturers are required to preinstall and feature — but dropping losers like Google Plus is just tinkering around the edges.

The obvious first step is that Google should withdraw the MADA restrictions. With no more MADA, phone manufacturers could take the distinct Google apps that they want, and not others. Google has no proper reason to prevent a phone manufacturer from combining Google Play with, say, Yahoo Maps and Bing Search. Indeed, with Google’s search dominance increasingly protected from competition as Yahoo stumbles and Microsoft withdraws, these combinations are the most promising way to increase competition in mobile.

Next, it goes nearly without saying that Google should pay a substantial penalty. Billion-dollar fines have become routine in Europe’s competition cases against American tech giants, including for conduct far less brazen and less obviously calculated to impede competition. Anything less at this point would seem to be a slap on the wrist undermining the importance of the EC’s effort.

Most of all, a full remedy requires affirmative efforts to undo the harm from Google’s years of improper conduct. After Microsoft’s browser tactics were deemed unlawful, the company was for five years obliged to present a "ballot box" in which consumers affirmatively chose among the five most popular browsers — presented in random order with no default. It’s easy to envision a similar approach in mobile: Upon first activating a new smartphone, a user would choose among the top five maps apps, top five search engines, top five geolocation services, and so forth. These obligations would most naturally track all the verticals that Google has targeted through its MADA restrictions. As users saw these options, competing app makers would get a prominent opportunity to attract users at modest expense — beginning to restore the competition that Google has improperly foreclosed.

Finally, a remedy should undo the secrecy Google has imposed. I wrote in 2014 about the remarkable steps required to obtain the MADAs — documents whose very existence was purportedly confidential, and whose terms contradicted the public statements (and sworn testimony) of Google’s leaders. This secrecy prevented app developers, competitors and the general public from knowing and debating Google’s tactics and raising concerns for a prompt regulatory response. Furthermore, secrecy emboldened Google to invoke methods that would have been less attractive had they been subject to public scrutiny from the outset. As part of competition proceedings, Google should be compelled to publish key contracts, facilitating analysis and discussion by the interested public. Meanwhile, as John Gapper writes in the FT, it’s ironic for Google to claim that EU officials "could be better informed" when Google itself limits distribution of the most important documents.