Mobile

Subscribe to Mobile via RSS

Yesterday, Los Angeles City Attorney Mike Feuer filed an unfair competition lawsuit on behalf of the People of the State of California against the operator of the popular Weather Channel app (“TWC app”) for allegedly failing to conspicuously disclose to users that the TWC app collects and shares users’ mobile geolocation data. (People v. TWC Product and Technology, LLC (Cal. Super., L.A. County)).  In essence, the suit alleges that the TWC app mines users’ precise geolocation data after receiving permission to gather location information to provide “personalized local weather data” without also adequately disclosing that the app also packages this data trove for advertising and analytics services unrelated to weather reporting. The City is seeking injunctive relief and civil penalties under state law for this alleged unfair business practice.  Feuer held a press conference today further detailing the State’s position in this lawsuit and expressed his hope that this case would spur litigation in other jurisdictions and legislation on the issue.

This post discusses some of the contractual requirements imposed by Apple and Google regarding the collection and sharing of locational information.  What consents, if any, do Apple and Google require that app publishers obtain before collecting and using locational information?  This is a question that is being asked with increasing frequency.  In fact, a regular beat of media coverage on the issue  (see, e.g., here or here), has reached crescendo levels with a much-discussed article this past week in the New York Times. Coincidentally (or maybe not?), the NYT article was published the day before Google CEO Sundar Pichai testified before the House Judiciary Committee on Google’s privacy and data collection practices, among other things.

Last week the WSJ published an article detailing how companies are monetizing smartphone location data by selling it to hedge fund clients.  The data vendor featured in the WSJ article obtains geolocation data from about 1,000 apps that fund managers use to predict trends involving public companies.  However, as we’ve…

Courts are increasingly taking a magnifying glass to electronic contracting processes, particularly how the presentation of the terms of service and call to action are displayed.  As such, companies might take a second look at their own user registration and e-commerce purchase processes to ensure they offer reasonably conspicuous notice of the existence of contract terms and obtain manifestation of assent by the user to those terms.  Courts will generally enforce clickwrap style agreements as long as the layout and language of the site or mobile app give the user reasonable notice that a click will manifest assent to an agreement.  Last year, the Second Circuit, in the notable Meyer opinion, blessed Uber’s mobile contracting process, but in considering a similar Uber platform, a New York state court late last month declined to compel the arbitration of user claims due to what the court considered an “ambiguous registration process.”  (Ramos v. Uber Technologies, Inc., 2018 NY Slip Op 28162 (N.Y. Sup. Ct. Kings Cty. May 31, 2018)).  Such conflicting rulings highlight the importance of web design in determining if a service’s terms are deemed enforceable.

In this long-running dispute that has been previously dubbed “The World Series of IP cases” by the presiding judge, Oracle America Inc. (“Oracle”) accuses Google Inc. (“Google”) of unauthorized use of some of its Java-related copyrights in Google’s Android software platform. Specifically, Oracle alleges that Google infringed the declaring code of certain Java API packages for use in Android, including copying the elaborate taxonomy covering 37 packages that involves multiple classes and methods.  Google had declined to obtain a license from Oracle to use the Java APIs in its platform or license the same under an open source GPL license; instead it copied the declaring code from the 37 Java API packages (over 11,000 lines of code), but wrote its own implementing code.  Google designed it this way, believing that Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.

We have been closely following the legal and legislative developments relating to biometric privacy, and in particular, the flow of litigation under the Illinois biometrics privacy law.   It was interesting to see how the Illinois law (as well as a similar Texas law) influenced Google’s  offering of a new facial recognition feature on the Google Arts & Culture app. (It is also interesting to note that the media coverage of the app has made the Illinois and Texas laws subjects of mainstream discourse.)

The Google Arts & Culture app, which was originally released a couple years ago, offers users virtual tours of museums and a searchable database of other art-related content.  What recently made it one of the hottest free apps is a new entertaining tool that compares a selfie to a database of great works of art and presents the results that most closely match the user’s face.  [Note: My classical art doppelgänger is “Portrait of a Gentleman in Red” by Rosalba Carriera. What’s yours?].  However, out of an apparent abundance of caution, Google has disabled this art-twinning function in Illinois and Texas, presumably because those states have biometric privacy laws that regulate the collection and use of biometric identifiers like facial templates; while the Texas statute can only be enforced by the state attorney general, Illinois’s Biometric Information Privacy Act (BIPA) contains a private right of action and remedies that include statutory damages. Interestingly, Washington users are able to access this tool, despite Washington having enacted its own biometric privacy law last year.  Perhaps that is because, as described in the referenced blog post, compliance under the Washington statute is less demanding than under the Illinois or Texas statutes.

This week’s Apple X announcement was not more than a few hours old, and the questions began to come in. Apple’s introduction of Face ID facial recognition on its new phone – although already available in some form on several Android phones – generated curiosity, concerns and creativity.  Unfortunately, the details about specifically how the recognition feature will really work are yet unknown.  All the public knows right now is that the phone’s facial “capture” function, powered by an updated camera and sensor array, will direct 30,000 infrared dots around a user’s face and create a hashed value that will presumably be matched against a user’s face during the unlocking procedure.

The questions and issues this raises are too numerous and varied to address in a single blog post. I will simply point out that the concerns over Face ID range from spoofing (e.g., Can the phone be unlocked by a picture? [Apple says no, explaining that the system will map the depth of faces]) to security (e.g., Is the “face map” or hashed value stored in a database which can be breached? [Apple, says no, like fingerprints in Apple’s current Touch ID feature, the face map will be securely stored locally on the device]).

One issue that I thought was particularly interesting, however, relates to the ability of apps residing on a phone to interact with facial captures. Unless disabled, Face ID could potentially be “always on,” ready to capture facial images to authenticate the unlocking of the phone, and possibly capturing facial images as the user interacts with the unlocked phone.  So, clients have asked: Will the apps on the phone be able to access and use those facial captures?

In recent years, courts have issued varying rulings as to whether online or mobile users adequately consented to user agreements or terms of service when completing an online purchase or registering for a service.  In each case, judges have examined the facts closely, particularly the user interface that presents the terms to the user before he or she completes a transaction.  In an important ruling vindicating Uber’s user registration and electronic contracting process, the Second Circuit reversed the lower court and held that the notice of Uber’s terms of service was reasonably conspicuous and that the plaintiff unambiguously manifested assent to the terms, and therefore agreed to arbitrate his claims with Uber. (Meyer v. Uber Technologies, Inc., 2017 WL 3526682 (2d Cir. Aug. 17, 2017)).  While clearly good news for Uber in this litigation, in blessing Uber’s mobile contracting process, the court also established something of a template for other mobile apps to follow to ensure that their terms and conditions will be enforceable against their members or users. 

Craigslist has used a variety of technological and legal methods to prevent unauthorized parties from violating its terms of use by scraping, linking to, or accessing user postings for their own commercial purposes. For example, in April, craigslist obtained a $60.5 million judgment against a real estate listings site that had allegedly received scraped craigslist data from another entity. And craigslist recently reached a $31 million settlement and stipulated judgment with Instamotor, an online and app-based used car listing service, over claims that Instamotor scraped craigslist content to create listings on its own service and sent unsolicited emails to craigslist users for promotional purposes.  (Craigslist, Inc. v. Instamotor, Inc., No. 17-02449 (Stipulated Judgment and Permanent Injunction Aug. 3, 2017)).