Section 230 of the Communications Decency Act continues to act as one of the strongest legal protections that social media companies have to avoid being saddled with crippling damage awards based on the misdeeds of their users.

The strong protections afforded by Section 230(c) were recently reaffirmed by Judge Caproni of the Southern District of New York, in Herrick v. Grindr. The case involved a dispute between the social networking platform Grindr and an individual who was maliciously targeted through the platform by his former lover. For the unfamiliar, Grindr is mobile app directed to gay and bisexual men that, using geolocation technology, helps them to connect with other users who are located nearby.

Plaintiff Herrick alleged that his ex-boyfriend set up several fake profiles on Grindr that claimed to be him. Over a thousand users responded to the impersonating profiles. Herrick’s ex‑boyfriend, pretending to be Herrick, would then direct the men to Herrick’s’ work-place and home. The ex-boyfriend, still posing as Herrick, would also tell these would-be suitors that Herrick had certain rape fantasies, that he would initially resist their overtures, and that they should attempt to overcome Herrick’s initial refusals. The impersonating profiles were reported to Grindr (the app’s operator), but Herrick claimed that Grindr did not respond, other than to send an automated message. Continue Reading Lawsuit Against Online Dating App Grindr Dismissed Under Section 230 of the Communications Decency Act

The European Union (EU) has made reform of the e-commerce rules in Europe one of its main priorities for 2018.

The European Commission has already published two proposed Directives relating to cross-border e-commerce but legislative progress has been slow—a situation that the Commission plans to correct in 2018.

The Commission’s stated aim is to establish a more harmonised set of rules for the supply of digital content and sale of online goods across the EU, and to make it easier and less costly for businesses to engage in cross-border commerce. But what most e-commerce providers will focus on is the increased rights for EU consumers, particularly in the context of defects. The new rules will apply to online e-commerce providers, whether EU-based or not.

These changes are part of a wider programme of reform affecting all businesses operating in the Technology, Media and Telecoms (TMT) sectors in Europe.

Background

The European Union’s 2018 Work Programme sets out a challenging agenda of legislative and regulatory change for the TMT sectors, to be delivered in conjunction with the EU’s Digital Single Market (DSM) strategy. The Work Programme includes a list of the pending legislation that the Commission wants to have delivered most swiftly to European citizens as part of the DSM strategy. Any business with digital or technology operations in the EU will need to monitor and react to the EU’s planned changes.

The Commission launched its DSM strategy in May 2015. We have written a number of articles following the DSM’s progress: at its inception, one year in and in 2017 following a mid-term review. With the Commission still waiting for a number of its proposals to be delivered, 2018 is a key year in the life of the DSM.

The DSM strategy is broken down into three “pillars” and 16 Key Actions. The first “Key Action” is to develop rules to make cross-border e-commerce easier, including harmonised rules on contracts with consumers and other consumer protection when buying online. Two proposed Directives relating to cross-border e-commerce were issued relatively quickly – firstly, a proposed Directive on the supply of digital content (Digital Content Directive) and, secondly, a proposed Directive on online and other distance sales of goods (Online Goods Directive) (together, the “Proposed Directives”).

In a 2016 blog post we explored the scope, content and likely impact of the Proposed Directives across the EU generally (and in the UK and Germany specifically). In this alert, we review the progress that has been made so far and look ahead at the likely impact of these Directives in 2018.

The Digital Content Directive

At present, some EU Member States (such as the UK, the Netherlands and Ireland) have introduced legislation to govern the sale of digital content to consumers; other member states apply existing rules on the sale of goods or services that were not intended for digital content. That makes it very hard to apply EU-wide principles on the sale of digital content. Depending on the member state, the sales contract could be considered as a sales contract, as a services contract or as a rental contract. And then there’s the question of whether consumer sales law is applicable to digital content: in Germany and in Italy, a consumer is protected under consumer sales law when it comes to digital content, and the courts qualify intangible goods as a moveable object; whereas in Norway, the online supply of digital content is considered a service contract, and consumer sales law is not applicable.

The draft Digital Content Directive will harmonise the rules that apply to the provision of digital content to EU consumers, including rules on the remedies to which consumers are entitled for allegedly defective content. If any digital content is defective, firstly the EU consumer will be able to request that the defect be fixed – with no time limit on the ability to make that request—and, secondly, the burden of proof is reversed so that it will be the supplier’s responsibility to prove that the defect did not exist at the time of supply. See a more detailed summary here.

The rules would apply: (i) regardless of the method of sale, and (ii) to both digital content sold to the consumer (i.e., licensed on a perpetual basis) and digital content supplied under a temporary licence on a subscription basis. Currently, most EU Member States do not have national consumer protection legislation specifically concerning sales or subscription of digital content to consumers (the issue tends to be covered by sales of goods or services rules).

European Council: General Approach

After the Commission issued the draft Digital Content Directive in December 2015, there was steady progress through 2016 and various committees debated or “took stock” of the proposal.

In March 2017, the European Data Protection Supervisor raised concerns with the proposal – namely that the provision of data as “counter-performance” was problematic (as discussed further below) and that there was a potential overlap in scope with the incoming General Data Protection Regulation.

However, the first major development on the Digital Content Directive took place in June 2017, when the European Council clarified the EU’s position on the proposal as follows:

  • Scope. The scope of the Digital Content Directive includes so-called “over-the-top” interpersonal communication services (such as voice and video calling, text messaging, email and social networking), bundle contracts and the processing of personal data. However, the Council recommended that embedded digital content (meaning, digital content or services that are pre-installed in goods such as smart fridges) should be excluded, leaving these issues to be governed by the rules on the sale of goods. Additionally, the Council explicitly stated that the proposal would not affect existing national and EU laws on copyright and related rights.
  • Non-conformity. The Digital Content Directive, as initially drafted, allowed subjective conformity criteria (i.e., criteria that are agreed in an individual contract) to prevail over objective conformity criteria (i.e., criteria that are stipulated by law). The Council rejected the idea that subjective conformity takes priority, requiring compliance with both subjective and objective criteria for conformity, unless the latter is expressly waived in advance by the consumer.
  • Remedies. The Council suggests that suppliers should have a second chance to supply the digital content or service in certain situations and proposes eliminating the strict hierarchy of remedies for lack of conformity that were initially proposed by the Commission.
  • Time limits. The Council proposes both that there should be a one-year time limit in relation to the reversed burden of proof on suppliers and also that any warranty or limitation period relating to the liability of the supplier must be at least two years under applicable domestic law. It stopped short of suggesting that warranty periods should be mandatorily harmonised across the EU.

European Parliament: Joint Report

The next key development took place in November 2017 when the two committees within the European Parliament that are responsible for progressing the proposed Digital Content Directive (being the Internal Market and Consumer Protection Committee (IMCO) and Legal Affairs (JURI)) adopted a joint report on the proposal. A number of compromise amendments to the draft Digital Content Directive were prepared on the basis of the report, of which the main ones were:

  • Emphasis on data protection. The provisions on data protection in the draft Digital Content Directive should be prioritised over the contract law provisions.
  • Provision of data as counter-performance. The Digital Content Directive was drafted to cover digital content that is provided for non-monetary consideration, such as when a consumer provides his/her data to a supplier in exchange for access to content. The compromise amendment suggested in the report is to limit the provision of data as counter-performance to only personal data.
  • Latent defects. The draft provisions on a supplier’s liability for latent defects were removed, allowing Member States to retain or introduce domestic laws on liability for such defects.
  • Non-conformity. Consistent with the Council’s approach, the report suggests that all subjective and objective criteria for conformity must be met, unless the consumer expressly consents to waive compliance with such objective criteria in advance.
  • Time limits. Also in keeping with the Council’s approach, a time limit was introduced in connection with the proposed reversal of the burden of proof. However, the report suggests a time limit of two years (rather than the Council’s proposal of one year) and introduces an additional time limit relating to trader liability for defects of one or two years.
  • Embedded digital content. The scope of the draft Digital Content Directive was expanded to cover digital content embedded in tangible goods, in contrast to the amendment proposed by the Council.

Next Steps

The report was referred to the European Parliament, Council and Commission to commence informal trialogue talks, which are now expected to take place in the first part of 2018.

The Online Goods Directive

The draft Online Goods Directive will apply new rules to goods sold online or otherwise at a distance to EU consumers. Face-to-face sales are not covered, nor are contracts for the supply of services.

The key provisions of the Draft Online Goods Directive include a reversal of the burden of proof (i.e., the onus will be on the seller to prove that any defect didn’t exist at the time of sale) for two years; consumers won’t lose their rights if they don’t inform the seller of a defect within a certain period of time (as is currently the case in some Member States); if the seller is unable or fails to repair or replace a defective product, consumers will have the right to terminate the contract and be reimbursed also in cases of minor defects. See a more detailed summary here.

The draft Directive replaced the Commission’s previous attempt at harmonisation, which took the form of a proposed Regulation on a Common European Sales Law. The EU Parliament’s IMCO published its draft report on the Directive in November 2016, supporting the full harmonisation measures envisaged, but suggesting an expansion of the scope of the Directive to cover offline sales. This was driven by the desire for consistency – the idea that a common set of rules across Member States would be valuable for online, distance and face-to-face sales alike, rather than having a fragmented legislative framework that would vary depending on the method of sale.

After publishing its draft report, IMCO tabled over 200 amendments to the draft Online Goods Directive during a committee meeting in January 2017, and more in July 2017 (mostly relating to the expansion of the scope of the draft Directive to offline sales).

The Commission subsequently released an amended proposal on 31 October 2017. Although the main elements of the Online Goods Directive were unaltered, the amended proposal did provide for the following noteworthy changes:

  • Offline sales. In alignment with the suggestions in the draft report, the scope of the proposed Directive was expanded to cover offline sales. As a result, Directive 1999/44/EC on consumer sales and guarantees would be fully repealed (whereas before, it would have been only partially amended).
  • Second-hand goods. Member States will have the option of narrowing the scope of the Online Goods Directive to exclude contracts for the sale of second-hand goods sold at public auction.

Next Steps

The amended proposal has been resubmitted to the European Parliament and Council. We await a decision from the European Economic and Social Committee, after which the European Parliament will need to vote on the proposal at first reading.

What Should We Expect in 2018?

We will be keeping tabs on the Proposed Directives as they progress under the ordinary legislative procedure, although, because there is no time limit on the first reading stage, it is difficult to predict exactly when we will see movement.

It is also difficult to predict the impact of the Proposed Directives on the UK. The UK is, of course, due to leave the EU in March 2019, which is likely to be before the Proposed Directives are implemented. It will therefore be for the UK to decide the extent to which it wishes to reflect the provisions of the final Proposed Directives in national law, if at all. The commercial benefits of harmonisation with EU Member States will need to be weighed carefully against the drawbacks of overhauling consumer laws so soon after the changes introduced by the UK Consumer Rights Act 2015.

“My Google Home Mini was inadvertently spying on me 24/7 due to a hardware flaw,” wrote a tech blogger who purchased Google Inc.’s latest internet of things (IoT) device. Following the incident, a pact of consumer advocacy groups insisted the U.S. Consumer Product Safety Commission (CPSC) recall the Google smart speaker due to privacy concerns arising when the device recorded all audio without voice command prompts.

The CPSC is charged with protecting consumers from products that pose potential hazards. Traditionally, this has meant hazards that may cause physical injury or property damage. But as internet-connected household products continue to proliferate, issues like the “always-on” Google Home Mini raise an important question: Where does cybersecurity of consumer IoT devices fit within the current legal framework governing consumer products?

The Explosion of IoT

Forecasts predict that by 2020 IoT devices will account for 24 billion of the 34 billion devices connected to the internet. According to a recent Gemalto survey, “[a] hacker controlling IoT devices is the most common concern for consumers (65%), while six in ten (60%) worry about their data being stolen.”

The rapid growth of the IoT market and continued integration into daily life raises the question of which regulatory body or bodies, if any, should be responsible for consumer safety when it comes to cybersecurity for consumer IoT devices.

The Intersection of Consumer Product Safety, Privacy and Cybersecurity

The CPSC’s jurisdiction has traditionally been limited to physical injury and property damage. It is “charged with protecting the public from unreasonable risks of injury or death associated with the use of the thousands of types of consumer products under the agency’s jurisdiction.” Continue Reading Connected Devices Bring New Product Liability Challenges

Blue Touchscreen Smart phones with colorful medical application icons

Health care apps are one of the most important and growing segments in the ecosystem known as the Internet of Things (IoT). After the recent amendments to the Health Insurance Portability and Accountability Act (HIPAA) that—among other things—broadened the definition of a “Business Associate,” many technology companies found themselves wondering whether they were, or were not, subject to HIPAA. Health and Human Services (HHS) recently issued some guidance, Health App Use Scenarios & HIPAA, that attempts to provide some clarity on these issues for app developers.

HIPAA, while broad in some ways, is actually somewhat narrow in its application. It does not apply to all medical information. Instead, it primarily focuses on “Covered Entities,” or CEs. A CE is a health care provider that conducts certain transactions in electronic form, a health care clearinghouse, or a health plan. If your company does not meet those criteria, then it is not a CE, and not subject to HIPAA as a CE.

While that analysis is an important step, it is not the final step in assessing whether HIPAA impacts your app. A company that does not meet the definition of a CE can still be a “Business Associate,” or BA—in essence a service provider for a CE—if it receives, maintains, or transmits Personal Health Information (PHI) on behalf of a CE. As we will see, the “on behalf of” language is critical.

In the emerging realm of health care apps, another distinction with its own set of acronyms is also important—the difference between an EHR and a PHR. Electronic Health Records (EHRs) are electronic records that are, in essence, created or maintained by a CE or a BA. They are official records that facilitate medical treatment, and they are subject to HIPAA and other medical record requirements. At their core, they are provider-centric records.

Personal Health Records (PHRs) are a related but distinct concept. PHRs are medical records that typically are electronic, but consumer-facing and not necessarily part of a patient’s medical file. While related to EHRs and interoperability (that is, the ability of all necessary health care providers to be able to review and place a patient’s medical information into an electronic chart), the purpose of PHRs is to inform patients rather than to serve as the basis for treatment, which is the purpose of an EHR. This distinction is important in understanding the guidance that HHS recently provided.

The first scenario that HHS evaluates in its guidance is one that is becoming increasingly common:

A consumer downloads a health app to her smartphone. She populates it with her own information. For example, she inputs blood glucose levels and blood pressure readings that she obtained herself using home health equipment.

In this scenario, HHS concludes that the app developer is not a BA, and therefore HIPAA doesn’t apply, because the consumer is using the app to create a PHR, and the health care providers are not involved. This scenario is common in the personal health space, and likely applies to some of the health and fitness trackers on the market.

The second scenario is also a common one, but it has more of a connection to health care providers:

A consumer downloads a health app to her smartphone that is designed to help her manage a chronic condition. She downloads data from her doctor’s EHR through a patient portal, onto her computer and then uploads it into the app. She also adds her own information to the app.

Despite the connection to an EHR, HHS does not believe that the app developer is a BA within HIPAA, even though it is receiving PHI from a CE. In this case, the app developer was not hired by the CE to “provide or facilitate” the service; hence, it is not operating “on behalf of” the CE, and in essence the EHR information becomes a PHR once transmitted to the app.

The third scenario moves closer to the HIPAA line, but still does not cross it:

A doctor counsels a patient that his BMI is too high, and recommends a particular app that tracks diet, exercise, and weight. The patient downloads the app to his smartphone and uses it to send a summary report to his doctor before his next appointment.

Despite the transmission of medical information to a CE, and the doctor’s recommendation of the app, HHS does not believe this app developer is a BA. This is again due to the “on behalf of” language in the definition of a BA. In sum, the transmission of information to a CE, by itself, does not make the app developer a BA.

Interoperability is a key issue with EHRs, and at times entities will enter into Interoperability Agreements, as explained by HHS in the next scenario:

A consumer downloads a health app to her smartphone that is designed to help her manage a chronic condition. A health care provider and the app developer have entered into an interoperability arrangement at the consumer’s request that facilitates the secure exchange of consumer information between the provider EHR and the app. The consumer populates information on the app and directs the app to transmit the information to the provider’s EHR. The consumer is able to access test results from the provider through the app.

Despite the transmission of medical information to a CE, as well as an interoperability agreement, the app developer in this case is still not a BA because the agreement was initiated by the consumer. Therefore, even in this scenario, the transmission is not “on behalf of” a CE.

The next scenario presented by HHS moves past an agreement initiated by the consumer, and into a scenario that does trigger HIPAA, according to HHS:

At direction of her provider, a patient downloads a health app to her smartphone. The provider has contracted with app developer for patient management services, including remote patient health counseling, monitoring of patients’ food and exercise, patient messaging, EHR integration and application interfaces. Information that the patient inputs into the app is automatically incorporated into provider EHR.

The key factor for HHS in this scenario is that the provider contracted with the app developer for patient management services that involve creating, receiving, and transmitting PHI, and the app is part of those services.

Finally, HHS provided a scenario that is essentially a split or hybrid scenario:

A consumer downloads to her smartphone a mobile PHR app offered by her health plan that offers users in its network the ability to request, download and store health plan records and to check the status of claims and coverage decisions. The app also contains the plan’s wellness tools for members, so that they can track their progress in improving their health. The health plan analyzes health information and data about app usage to understand effectiveness of its health and wellness offerings. App developer also offers a separate, direct-to-consumer version of the app that consumers can use to store, manage, and organize their health records, to improve their health habits and to send health information to providers.

In this case, the portion of the app that is offered by the health plan triggers HIPAA and the developer is a BA, but this does not extend to the direct-to-consumer side of the business. If the app developer keeps the data separate, then, according to HHS, “the developer does not need to apply HIPAA protections to the consumer information obtained through the ‘direct-to-consumer’ app.” It appears that HHS is unofficially recognizing a hybrid designation for app developers, though the concept is, in actual terms, one more appropriately applied to CEs.

HHS offered a series of questions that app developers who are not CEs can ask to determine whether they are a BA:

HHS offered a series of questions that app developers who are not CEs can ask to determine if they are or are not a BA:

  • Does your health app create, receive, maintain, or transmit identifiable information?
  • Who are your clients? How are you funded?
    • Are your clients covered entities?
      • e.g., hospitals, doctor’s offices, clinics, pharmacies, or other health care providers who conduct electronic transactions;
      • health insurance issuers; health or wellness program related to a health plan offered by an employer
    • Were you hired by, or are you paid for your service or product by, a covered entity? Or another business contracted to a covered entity?
    • Does a covered entity (or a business associate acting on its behalf) direct you to create, receive, maintain or disclose information related to a patient or health plan member?

Even though an app developer may not be covered by HIPAA, HHS notes other existing guidance regarding apps, including direction from the Federal Trade Commission. This guidance, as well as any applicable laws, should be considered if HIPAA is not applicable.

As the IoT becomes more ubiquitous, novel apps will appear allowing us to gather and process more health information. App developers who wish to create health-related apps should factor this guidance in early so that they can understand the rules of the road and determine whether HIPAA applies.

The HHS guidance can be found here.