All

Posted on

Mobilizing an Online Business (teaching materials) with Peter Coles

Coles, Peter, and Benjamin Edelman. “Mobilizing an Online Business.” Harvard Business School Background Note 913-061, June 2013. (educator access at HBP. request a courtesy copy.)

Entrepreneurs starting online businesses often need to mobilize multiple sets of users or customers, each of whom hesitates to participate unless others join also. This case presents several challenges with similar structure.

Supplements:

Mobilizing an Online Business — slide supplement – PowerPoint Supplement (HBP 913702)

Mobilizing an Online Business — slide supplement (widescreen) – PowerPoint Supplement (HBP 914053)

Teaching Materials:

Mobilizing an Online Business – Teaching Note (HBP 913062)

Posted on

Comments to European Commission on Proposed Google Commitments with Zhenyu Lai

The European Commission last month posted a restatement of its concerns at certain Google practices as well as Google’s proposed commitments. This week I filed two comments, including one with Zhenyu Lai, critiquing Google’s proposal. They are available here:

Comments on AT.39740 (Edelman and Lai) as to Google’s exclusive use of screen space to promote its own specialized services, and as to an alternative remedy to preserve competition and user choice in the area of specialized search services.

Comments on AT.39740 (Edelman) as to the failure of Google’s proposed commitments to undo the harm of Google’s past violations, and alternative remedies preserve competition in the area of specialized search services, taking data from publishers, providing advertising services to publishers, and allowing advertisers to use multiple ad platforms.

Our suggested remedy for Google favoring its own vertical search services: Let users choose from competing offeringsAs to Google’s decision to favor its own specialized search services, Zhenyu and I question whether Google’s proposed commitments would effectively preserve competition. In our recent measurement of the effects of Google Flight Search, we found that Google’s large Flight Search “onebox” displays sharply reduced traffic to other online travel agencies as well as driving up the proportion of clicks to AdWords advertising. Google proposes to display a few small “Rival Links” to competitors, but these links would be placed and formatted in ways that make them unlikely to attract users’ attention or facilitate competitive markets.

Instead, we suggest a “ballot box” in which users can choose their preferred specialized search services in any area where Google offers and favors its own specialized search services. For example, the first time a user runs a hotel search or flight search, the user would be presented with a menu of options — reminiscent of the “browser ballot box” a user sees when first booting Windows in Europe. This approach is entirely feasible: Facebook has long merged content from myriad independent developers; numerous developers quickly built browser add-ons to disable Google Search Plus Your World when they found its initial results unhelpful; and the G++ for Google Plus browser add-on integrates other social networks with G+ even though Google declines to provide such integration. Indeed, search engine guru Danny Sullivan in September 2011 suggested that Google “let[] people choose their shopping, local, etc one box provider?”, echoing my February 2011 call for interchangeable components for competing specialized search services. In our comment, Zhenyu and I explore a proposed implementation of this concept.

As to the Commission’s concerns more generally, my comment addresses Google’s failure to undo the harm resulting from Google’s past violations. For each of the Commission’s concerns, I present alternative remedies focused on protecting competition and affirmatively undoing the harm from Google’s past violations. I also flag the need for tough penalties to deter further violations by Google and others.

Reuters yesterday reported that the Commission is likely to require further concessions from Google, including improved remedies. Comments to the Commission are due by June 27.

Posted on

Guidance from ARIN on Legal Aspects of the Transfer of Internet Protocol Numbers

Edelman, Benjamin, and Stephen Ryan. “Guidance from ARIN on Legal Aspects of the Transfer of Internet Protocol Numbers.” Business Law Today (May 2013).

Every device connected to the global Internet needs a numeric identifier, an “Internet Protocol” address (“IP address”). The Internet’s continued growth presents a challenge: most IP addresses have already been assigned to networks and organizations, leaving few left for newcomers and growth. In this context, some networks seek to sell the addresses they previously received–sales that can usefully transfer resources to the networks that most need them, but with certain risks that must be handled with appropriate care. We examine the legal basis of applicable rights and identify the circumstances in which such transfers are permitted.

Posted on

SaferTaxi: Connecting Taxis and Passengers in South America (teaching materials) with Peter Coles

Coles, Peter, and Benjamin Edelman. “SaferTaxi: Connecting Taxis and Passengers in South America.” Harvard Business School Case 913-041, April 2013. (Revised October 2014.) (educator access at HBP. request a courtesy copy.)

SaferTaxi, a taxi booking service in South America must develop its mobilization strategy; that is, it must attract enough passengers and drivers to make its service worthwhile for all. Drivers hesitate to pay for SaferTaxi’s smartphones and service unless these will deliver passenger bookings—and passengers have no reason to sign up unless drivers are available. Meanwhile, regulators question the permissibility of online taxi booking in light of regulatory requirements, and some existing taxi booking vendors feel threatened by SaferTaxi’s efforts to enter the market. As SaferTaxi attempts to satisfy these diverse constituents, international competition looms. What should SaferTaxi’s founders do next?

Teaching Materials:

SaferTaxi: Connecting Taxis and Passengers in South America – Teaching Note (HBP 913063)

Posted on

Google’s Exclusive Flight Search OneBox with Zhenyu Lai

Google often shows “OneBox” search results promoting its own services. These results have prompted antitrust scrutiny: Google awards these preferred placements exclusively to Google’s own services, such as Google Flight Search and Google Maps, but never to competing services such as Kayak or Mapquest. Moreover, Google presents OneBox with special format, including distinctive layouts, extra images, and even in-page interactivity — benefits not available to ordinary listings for other sites. Regulators and competitors sense that these exclusive practices can undermine competition and innovation by denying traffic to would-be competitors. But how large is the effect? How much does Google’s exclusive OneBox placement impact search engine traffic to adjacent online markets?

In a working paper, Zhenyu Lai and I measure the impact of OneBox by using a quasi-experiment before and after the introduction of Google Flight Search. Using a third-party data service, we compare user behavior on searches across thousands of search queries like “cheap flights from sfo to san ” (which displayed a OneBox for Google Flight Search), and similar search queries like “cheaper flights from sfo to san” (emphasis added) (which did not display OneBox). We find that Google’s display of Flight Search in an exclusive OneBox decreased user click-through rates on unpaid search results by 65 percent, and increased user click-through rates on paid advertising links by 85 percent. This effect was disproportionately evident among online travel agencies that were popular destinations for affected search queries.

Our draft provides detailed empirical results as well as a model of how a search engine’s incentives to divert search depend on consumers’ perceptions of the difference between non-paid and paid placements.

Exclusive Preferential Placement as Search Diversion: Evidence from Flight Search

(update: published as Edelman, Benjamin, and Zhenyu Lai. “Design of Search Engine Services: Channel Interdependence in Search Engine Results.” Journal of Marketing Research (JMR) 53, no. 6 (December 2016): 881-900.)

Posted on

Privacy Puzzles at Google Play

Last week app developer Dan Nolan noticed that Google transaction records were giving him the name, geographic region, and email address of every user who bought an Android app he sold via Google Play. Dan’s bottom line was simple: “Under no circumstances should [a developer] be able to get the information of the people who are buying [his] apps unless [the customers] opt into it and it’s made crystal clear to them that [app developers are] getting this information.” Dan called on Google to cease these data leaks immediately, but Google instead tried to downplay the problem.

In this post, I examine Google’s relevant privacy commitments and argue that Google has promised not to reveal users’ data to developers. I then critique Google’s response and suggest appropriate next steps.

Google’s Android Privacy Promise

In its overarching Google Privacy Policy, Google promises to keep users’ data confidential. Specifically, at the heading “Information we share”, Google promises that “We do not share personal information with companies, organizations and individuals outside of Google unless one of the following circumstances apply”. Google then lists four specific exceptions: “With your consent”, “With domain administrators”, “For external processing”, and “For legal reasons.” None of these exceptions applies: users were never told that their information would be shared (not to mention “consent[ing]” to such sharing; Google shared data with app developers, not domain administrators; app developers do not process data for Google, and the data was never processed nor provided for processing; and no legal reason required the sharing of this information. Under Google’s standard privacy policy, users’ data simply should not have been shared.

Users purchase Android apps via the Google Play service, so Google Play policies also limit how Google may share users’ information. But the Google Play Terms of Service say nothing about Google sharing users’ details with app developers. Quite the contrary, the Play TOS indicate that Google will not share users’ information with app developers. At heading 10, Magazines on Google Play, Google specifically notes the additional “Information Google Shares with Magazine Publishers”: customer “name, email address, [and] mailing address.” But Google makes no special mention of information shared with any other type of Google Play content provider. Notice: Google notes that it shares certain extra information with magazine publishers, but it makes no corresponding mention of sharing with other content providers. The only plausible interpretation is that Google does not share the listed information with any other kind of content provider.

Users’ Google Play purchases are processed via Google Wallet, so Google Wallet policies also limit how Google may share users’ information. But the Google Wallet privacy policy says nothing about Google sharing users’ details with app developers. Indeed, the Google Wallet privacy policy is particularly narrow in its statement of when Google may share users’ personal information:

Information we share
We will only share your personal information with other companies or individuals outside of Google in the following circumstances:
* As permitted under the Google Privacy Policy.
* As necessary to process your transaction and maintain your account.
* To complete your registration for a service provided by a third party.

None of these exceptions applies to Google sharing users’ details with app developers. The preceding analysis confirms that the Google Privacy Policy says nothing of sharing users’ information with app developers, so the first exception is inapplicable. Nolan’s post confirms that app developers do not need users’ details in order to provide the apps users request; Google’s app delivery system already provides apps to authorized users. And app developers need not communicate with users by email, making it unnecessary for Google to provide an app developer with a user’s email address. Google might argue that it could be useful, in certain circumstances, for app developers to be able to email the users who had bought their apps. But this certainly is not “necessary.” Indeed, Nolan had successfully sold apps for months without doing so. The third exception does not apply to any app that does not require “registration” (most do not). Even if we interpret “registration” as installation and perhaps ongoing use, Nolan’s experience confirms why the third exception is also inapplicable: Nolan was easily able to do everything needed to sell and service the apps he sold without ever using users’ email addresses.

Even if it were necessary for Google to let developers contact the users who bought their apps, such communications do not require that Google provide developers with users’ email addresses. Quite the contrary, Google could provide remailer email addresses: a developer would write to an email address that Google specifies, and Google would forward the message as needed. Alternatively, Google could develop an API to let developers contact users. These suggestions are more than speculative: Google Checkout uses exactly the former technique to shield users’ email address from sellers. (From Google’s 2006 announcement: “To provide more control over email spam, Google Checkout lets shoppers choose whether or not to keep email addresses confidential or turnoff unwanted email from the stores where they shop”) Similarly, Google Wallet creates single-use credit card numbers (“Virtual OneTime Card”) to let users make purchases without revealing their payment details developers. Having developed such sophisticated methods to protect user privacy in other contexts, including more complicated contexts, Google cannot credibly argue that it was “necessary” to reveal users’ email addresses to app developers.

Evaluating Google’s Defenses

Siliconvalley.com quotes an unnamed Google representative defending Google’s approach:

“Google Wallet shares the information necessary to process a transaction, which is clearly spelled out in the Google Wallet Privacy Notice.”

I emphatically disagree. First, it simply is not “necessary” to provide developers with access to customer names or email addresses in order to process customer transactions. Apple has long run a similar but larger app marketplace without doing so. Scores of developers, Nolan among many others, successfully provide apps without using (and often without even knowing they are receiving) customer names and email addresses. To claim that it is “necessary” to provide this information to developers, Google would need to establish that there is truly no alternative — a high bar, which Google has not even attempted to reach.

Second, this data sharing is not “spelled out in the Google Wallet Privacy Notice” and certainly is not “clear[]” there. The preceding section analyzes the relevant section of the Google Wallet privacy policy. Nothing in that document “clearly” states that Google shares users’ email addresses with third-party developers. The only conceivable argument for such sharing is that such sharing is “necessary” — but that immediately returns us to the arguments discussed above.

Resolution

Google widely promises to protect users’ private information. Google makes these promises equally in mobile. Having promised protection and delivered the opposite, Google should not be surprised to find users angry.

Some app developers defend Google’s decision to provide developers with customer details. For example, the Application Developers Alliance commented that “in the Google Play environment the app purchaser customer data (e.g., name and email address) belongs to the developer who is the seller” — arguing that it is therefore appropriate that Google provide this information to app developers. Barry Schwartz of Marketing Land added “I want to be able to service my customers” and indicated that sharing customer names and emails helps with support and refunds. Perhaps there are good reasons to provide customer data to developers. But these arguments offer no reason why Google did not tell users that their details would be sent to app developers. The Application Developers Alliance suggests that anyone uncertain about data sharing should “carefully review the Google Play and Google Wallet terms of service.” But these documents nowhere state that users’ information is provided to app developers (recall the analysis above), and in fact the documents indicate exactly the opposite.

Meanwhile, sharing users’ details with app developers risks significant harms. Nolan noted two clear problems: First, a developer could use customer contact details to track and harass users who left negative reviews or sought refunds. Second, an attacker could write malware that, running on app developers’ computers, logs into Google’s systems to collect user data. While one might hope app developers would keep their computers secure from such malware, there are tens of thousands of Android developers. Some are bound to have poor security on some local machines. Users’ data shouldn’t be vulnerable to the weakest link among these thousands of developers. An attacker could devise a highly deceptive attack with information about which users bought which apps when — yielding customized, accurate emails inviting users to provide passwords (actually phishing) or install updates (actually malware).

Moreover, Google is under a heightened obligation to abide by its privacy commitments. For one, privacy policies have the force of contract, so any company breaching its privacy policy risks litigation by harmed consumers. Meanwhile, Google’s prior privacy blunders have put Google under higher scrutiny: Google’s Buzz consent order includes twenty years of FTC oversight of Google’s privacy practices. After Google violated the FTC consent order by installing special code to monitor Apple Safari users whose browser settings specifically indicated they did not want to be tracked, the FTC imposed a $22.5 million fine, its largest ever. Now Google has again violated its privacy policies. A further investigation is surely in order.

A full investigation of Google’s activities in this area will confirm who knew what when. Though Nolan’s complaint was the first to gain widespread notice, at least three other developers had previously raised the same concern (1, 2, 3), dating back to June 2012 or earlier. An FTC investigation will confirm whether Google staff noted these concerns and, if they noticed, why they failed to take action. Perhaps some Google staff proposed updating or clarifying applicable privacy policies; an investigation would determine why such improvements were not made. An investigation would also confirm the allegation (presented in an update to News.com.au reporting on this subject) that prior to October 2012, Google intentionally protected users’ email addresses by providing aliases — letting app developers contact users without receiving users’ email addresses. Given the clear reduction in privacy resulting from eliminating aliases, an investigation would check whether and why Google made this change.

Even before that investigation, Google can take steps to begin to make this right. First, Google should immediately remove users’ details from developers’ screens. Google should simultaneously contact developers who had impermissible access and ask them to destroy any copies that they made. If Google has a contractual basis to require developers to destroy these copies, it should invoke those rights. In parallel, Google should contact victim users to let them know that Google shared their information in a way that was not permitted under Google’s own policies. Google should offer affected users Google’s unqualified apologies as well as appropriate monetary compensation. Since Google revealed users’ information only after users purchased paid apps, users’ payments offer a natural remedy: Google should provide affected users with a full refund for any apps where Google’s privacy practices did not live up to Google’s commitments.

Posted on

Misrepresentation of Fuel Surcharges in Airline Price Advertising with Xiaoxiao Wu

Air travel tickets often include surprisingly large amounts described as “tax.” In one round trip New York-Paris ticket we quoted in January 2012, the fare was listed as $230 while “tax” was listed as $598.14 — fully 72% of the listed total. If government taxes were actually as large as Air France claims, many passengers might want to complain to responsible politicians and regulators. And passengers might have a different view of cramped seating, unpalatable food, or other service shortfalls on a $230 ticket versus a $828.14 ticket. But in fact, specifically contrary to Air France’s characterization of $598.14 as “tax,” the majority of the “tax” was not charged by any government, airport, or similar authority, and rather was retained by Air France to defray its ordinary operating expenses.

Our investigation uncovers a variety of examples in which airlines have mischaracterized various surcharges as “tax” and otherwise failed to satisfy applicable price advertising regulation. We present proof in both screenshots and recorded telephone calls, preserving clear records of carriers’ misrepresentations. Details:

Misrepresentation of Fuel Surcharges in Airline Price Advertising