Sign in Subscribe
IoT

Turning Mobile Privacy Guidance into IoT Best Practices

How can mobile privacy guidance help solve IoT transparency challenges? This article translates established mobile privacy principles—including layered notices, just-in-time disclosures, and privacy by design—into practical best practices for connected devices and AI-enabled products.

Lydia

— 20 min read
Share
Turning Mobile Privacy Guidance into IoT Best Practices

This article translates existing mobile privacy guidance into actionable best practices for the Internet of Things. It explains how lessons from mobile apps — like layered notices, just-in-time disclosures, and privacy-by-design requirements — can be adapted to connected devices that often lack traditional user interfaces. Readers will find a roadmap that combines regulatory guidance, case studies, and practical checklists to help developers and companies design transparent, compliant, and user-centric IoT products

Introduction

Mobile privacy refers to the privacy rights of users of mobile devices — smartphones, tablets, wearables, and connected devices. While many of the same principles apply as with general internet privacy, mobile services present unique risks because they rely on apps, app stores, and integrated third-party software development kits (SDKs). These services often process highly personal data streams such as geolocation and biometric identifiers. The information can be used to generate behavioral profiles through persistent identifiers, including advertising IDs, which can be combined to track individuals across platforms and services.

Regulators have developed a comparatively rich body of guidance on how to address these risks in the mobile context, particularly around disclosures, layered notices, and just-in-time prompts. IoT devices present a similar challenge — many lack a user interface altogether — but because they often pair with a mobile app, existing mobile guidance provides a practical framework that can be reinterpreted to improve transparency and user control across the IoT ecosystem.

Why mobile privacy is unique

Mobile devices differ from traditional computers not just in size but in how deeply they are woven into people’s daily lives. They function as communication tools, location trackers, health monitors, digital wallets, and entertainment hubs — all at once. This convergence means that mobile privacy risks are both broader and more intimate: the same device that delivers convenience can also create a comprehensive portrait of a person’s movements, relationships, health, and preferences.

Regulators therefore treat mobile privacy as a distinct and higher-risk category within the broader data protection landscape, because certain technical features of mobile devices create heightened privacy concerns, including:

  • Persistent location tracking: Mobile devices travel with users, making it possible to build detailed movement histories; research shows individuals can often be uniquely identified with just a handful of spatio-temporal points.
  • Sensor data explosion: Beyond cameras and microphones, modern devices capture heart rate, fingerprints, voice data, accelerometer readings, and more.
  • Identifiers: Persistent and advertising IDs are particularly sensitive because they can be linked to usage patterns across apps, devices, and ad networks. Even when names are removed, these identifiers allow re-identification and profiling.
  • High-risk categories: Contacts, photos, geolocation data, and biometrics continue to be considered especially sensitive and subject to heightened regulatory expectations.

One of the most pressing challenges is providing meaningful disclosures on devices with limited or no user interface. This issue is well recognized in the mobile context, where guidance already exists on layered privacy notices, app store labels, and just-in-time prompts. IoT devices face the same problem, but with less established regulatory playbooks. Because many IoT products pair with mobile apps, there is a natural synergy: the mobile app can serve as the gateway for disclosures, consents, and user controls not only for the app itself but also for the connected device. In this way, mobile privacy guidance offers a practical framework that can be reinterpreted and extended to improve transparency in the broader IoT landscape.

For many years, the United States relied on a patchwork of sectoral and general laws rather than a single federal privacy statute. The Telephone Consumer Protection Act (TCPA) restricted automated calls and text messages without prior consent. The Gramm–Leach–Bliley Act (GLBA) limited how financial institutions could share consumer data. California’s CalOPPA and later the CCPA were among the first state-level efforts to address online privacy. The Wiretap Act regulated the interception of electronic communications. And the Federal Trade Commission Act (FTC Act) served as a broad catch-all, allowing the FTC to pursue unfair or deceptive data practices. Taken together, these overlapping rules formed the basic structure of U.S. privacy law, but they left significant gaps — gaps that states have since rushed to fill with more comprehensive consumer privacy legislation.

The enactment of the California Consumer Privacy Act (CCPA) fundamentally changed this dynamic and commenced the push toward overarching privacy laws that has since been followed by many states. By 2025, the U.S. privacy landscape is defined by a rapidly expanding patchwork of state consumer privacy laws. More than a dozen states — including California, Colorado, Connecticut, Virginia, Utah, Texas, Oregon, Montana, and Delaware — have enacted statutes that apply directly to mobile services and apps. Each law comes with its own requirements, ranging from how companies must obtain consent for the processing of sensitive data, to the scope of opt-out rights for targeted advertising, to specific obligations on data minimization and retention. For mobile developers and IoT manufacturers, this creates a fragmented compliance environment where a single app may need to honor different consumer rights depending on the state of the user. As a result, companies are under increasing pressure to build harmonized frameworks that anticipate and reconcile these differences, rather than attempting to comply state by state.

Practice guidelines for mobile

In the mobile context, regulators and industry developed prior to 2020 a substantial body of guidance that, while not legally binding, provides important roadmaps for compliance. The Federal Trade Commission (FTC), through its 2013 and 2018 reports, emphasized transparency, privacy by design, and the need for regular security updates. The California Attorney General issued its “Privacy on the Go” guidance in 2013, later reinforced by a joint statement with major app store operators, which pressed developers to adopt clear and consistent disclosure practices. In addition, a range of self-regulatory frameworks — such as those developed by the NTIA, the Future of Privacy Forum (FPF) and Center for Democracy & Technology (CDT), and the CTIA — have sought to establish best practices for mobile data collection, advertising, and user consent. Collectively, these resources illustrate a consensus around privacy by design and layered transparency, and they remain a practical reference point for companies developing or updating their mobile services.

[See Resources below for links to the guidance]

Building Trust Through a Layered Transparency Model in Mobile and IoT

To meet best-in-class privacy transparency requirements, organizations developing mobile apps and IoT devices should not only post a privacy notice but also supplement it with short-form and just-in-time notices. Collectively, these layered disclosures ensure that users are fully informed about data collection, use, and sharing practices across diverse platforms and connected ecosystems. Regulators are increasingly treating failures in transparency as deceptive practices under both state and federal law, and the Gibson Guide’s 2025 review notes that the accuracy of app store privacy labels has become a particular enforcement priority.

To provide meaningful transparency in both mobile and IoT ecosystems, organizations are expected to deploy three complementary types of notices. A privacy notice is the foundation, required to be conspicuous and specific to each app or device, and must cover data types collected, their uses, retention practices, third-party sharing, user choices, correction rights, contact information, effective date, and any legally required disclosures. Short-form notices serve as plain-language highlights that use icons or concise text to summarize key practices for users at a glance. Finally, just-in-time disclosures appear as pop-ups or prompts before sensitive or unexpected data collection — such as access to geo-location, contacts, or photos — ensuring that users are aware and able to make an informed choice before the collection occurs.

Mobile & IoT Privacy Notices
Developers should post, and app platforms or marketplaces should require, a dedicated privacy notice for each product. This obligation is reinforced under California law, which has long required specific notices to inform users about data practices (see case study: Case study: Delta Airlines). Platforms often incorporate this requirement into developer or distributor agreements, mandating either a hyperlink to, or the full text of, the policy as part of the approval process. Notices must accurately describe the data collected, its uses, retention periods, third-party sharing, user choices, correction rights, and contact information, as well as the effective date and the process for notifying users of material changes.

The California AG’s Privacy on the Go guidance recommends further disclosure of whether payment information or unique identifiers are collected directly by the app/device or through a third party. Privacy notices must be conspicuously posted and easily accessible — through app store download pages, device packaging, or embedded menus — consistent with CalOPPA, the California Consumer Privacy Act (CCPA), and FTC guidance. COPPA also requires that apps or IoT services directed at children under 13 link to the notice directly from the homepage or device interface.

Short-Form Notices (SFNs)
Short-form notices are particularly valuable given the limited screen space on mobile devices and the constrained interfaces of many IoT products. These should highlight key practices from the long-form notice in plain, concise language, supported by icons (e.g., a location pin for geo-location data). Best practices, reflected in the NTIA’s Short Form Notice Code of Conduct, suggest including: (1) the types of data collected; (2) a link to the full privacy notice; (3) whether personal data is shared with third parties; and (4) the identity of the developer or device manufacturer. SFNs should appear either on the app/device homepage or on the screen where data collection occurs. Developers may rely on platform-provided SFNs, but only where the disclosure precisely matches their actual practices — otherwise, separate disclosure is required.

Importantly, under the CCPA, these short-form notices also can operate as a “notice at collection,” and therefore they must be presented at or before the point of data collection and must clearly explain the categories of personal information collected and the purposes for which that data will be used.

Just-in-Time Disclosures & Consent

Just-in-time disclosures — sometimes called “enhanced” or “special” notices — are essential in both mobile and IoT contexts, as users often do not expect data collection beyond core functionality. These disclosures should be presented at the moment users take an action that triggers sensitive or unexpected collection. Both the California Attorney General and the FTC recommend obtaining affirmative express consent: (1) the first time an app or IoT device collects sensitive data (such as geo-location, health metrics, or audio recordings), and (2) when collection occurs in an “unexpected” way. Examples include IoT devices accessing microphones or cameras beyond their advertised purpose, or mobile apps sharing data with ad networks for behavioral advertising. Just-in-time disclosures should explain the intended use of the data, identify any third parties receiving it, provide a clear opt-in choice, and — where feasible — link to the full privacy notice. These practices align with COPPA’s direct notice requirement and reflect the FTC’s heightened focus on meaningful consent for sensitive data.

Case Studies & Enforcement

Transparency failures across both mobile and IoT ecosystems have consistently drawn regulatory action. Carrier IQ’s hidden software, which collected user data through pre-installed programs, led to accountability findings for OEMs and carriers. Delta Airlines was required to issue a separate mobile app notice. Goldenshores confirmed that just-in-time consent must be obtained for geo-location. Uber’s “God View” highlighted the risks of inadequate employee access controls. In the BLU Phones case, the FTC emphasized developer due diligence, contractual controls, and disclosure obligations for third-party code. In re Matis confirmed that even sharing aggregated data requires disclosure.

As highlighted in the Gibson Guide’s 2025 review, more recently, enforcement has expanded to adtech practices and children’s apps, with multi-state AG actions , while private litigation under wiretap and biometric privacy laws has surged, particularly targeting apps and IoT devices that incorporate tracking technologies.

A consistent lesson from enforcement is that sharing with third parties must be clearly disclosed, and, where feasible, accompanied by links to those parties’ own privacy notices. Opt-in consent is expected whenever the sharing involves sensitive information or occurs in ways a user would not reasonably anticipate. Opt-out consent is likely required under state privacy laws unless sharing with a processor under a compliant contract.

Regulators have also sharpened their focus on the accuracy of app store privacy labels, with both the FTC and state attorneys general treating discrepancies between disclosed practices and actual data flows as deceptive trade practices. This underscores that transparency obligations are not static check-the-box exercises but dynamic duties that extend across disclosures, consent mechanisms, and the accuracy of platform-facing privacy representations.

Practical Checklist: Transparency in Mobile & IoT
Privacy Notice (Long-Form)
Draft a privacy notice specific to each app or IoT device (not just a general corporate policy).
Include: data types collected, purposes of use, retention periods, third-party sharing, user choices, correction rights, contact information, effective date, and process for material updates.
Post notices conspicuously (e.g., app store page, device setup screen, in-app settings menu).
Ensure compliance with CalOPPA and CCPA/CPRA etc. requirements for “conspicuous posting” and disclosure of retention and sensitive data practices.
Short-Form Notices (SFNs)
Provide plain-language summaries of key practices using icons for clarity (e.g., location pin for geo-location).
Place SFNs where data is collected (e.g., app homepage, device onboarding flow).
Ensure SFNs correspond exactly to your data practices — don’t rely on platform defaults if they don’t match.
Treat SFNs as “notice at collection” under the CCPA, disclosing categories of data and purposes before collection.
Just-in-Time Disclosures & Consent
Use pop-ups or prompts before accessing sensitive or unexpected data (e.g., geolocation, contacts, camera, health metrics).
Obtain affirmative opt-in consent for sensitive/unexpected uses or sharing.
Clearly explain intended uses, identify third parties, and link to the privacy notice.
Re-present disclosures when practices change or new data types are introduced.
For children’s apps/devices, ensure compliance with COPPA’s direct notice requirements.
Third-Party Sharing
Disclose all third-party integrations where possible (SDKs, APIs, cloud services). At the minimum, disclose controller to controller transfers.
Where feasible, link directly to third-party privacy notices.
Secure contractual assurances and monitor third-party data use (see BLU case).
Provide opt-in for sensitive data sharing; ensure opt-out rights are available under CCPA/CPRA.
Platform & Label Accuracy
Ensure app store privacy labels (Apple/Google) match actual data flows.
Regularly audit labels to prevent discrepancies that regulators consider deceptive.
Monitor updates to platform privacy requirements (e.g., Apple App Tracking Transparency, Google Advertising ID).

Privacy by Design (PbD)

A Privacy-by-Design approach is especially critical in the mobile and IoT ecosystem, where devices continuously collect, process, and transmit personal information. Developers are expected to embed privacy safeguards into the entire engineering lifecycle, from concept to deployment, rather than bolting them on later. This requires first mapping how the app or device will function, then carefully distinguishing between data essential to core services and data that is merely desirable. Sensitive information — such as health, biometric, or geolocation data — must be flagged early and explicitly disclosed to users, along with any reliance on third-party analytics or service providers. Equally important, mobile and IoT developers should provide users with meaningful choices about data use and retention, while rigorously testing applications before release to evaluate whether data flows align with the stated purpose. This systematic, proactive approach ensures that privacy is not just a compliance exercise but a core design principle that builds trust in connected technologies.

The Gibson Guide’s 2025 review underscores that data minimization and purpose limitation have become central compliance duties under emerging state privacy laws, closely mirroring the GDPR’s long-standing standards. These principles require organizations to limit collection to what is strictly necessary for defined purposes and to avoid secondary uses that are incompatible with those purposes. For mobile and IoT providers, this reinforces the importance of carefully mapping data flows and justifying each element of collection within the scope of disclosed functionality, ensuring that privacy-by-design practices are not only recommended but increasingly mandated by law.

The same guide also emphasizes that regulators are prioritizing enforcement around children’s data, sensitive health information, and biometric identifiers, marking them as high-risk categories under both state privacy statutes and Federal Trade Commission actions. This reflects a clear trend toward heightened scrutiny of data types that pose greater risks to individual autonomy and security, signaling to mobile and IoT developers that extra safeguards and compliance measures are expected when handling these categories.

In practice, developers of mobile applications and IoT devices should adopt a structured process that ensures privacy is integrated at every stage of design. This begins with distinguishing between data that is strictly necessary for the app’s core functions and information that is merely optional. Any collection or use of sensitive data — such as precise geo-location, health metrics, or biometrics — must be clearly highlighted and justified. Developers should also map all instances of third-party access, including analytics and advertising services, to ensure users are fully informed of external data flows. Finally, before launch, apps should undergo rigorous testing to confirm that data practices align with both legal requirements and privacy-by-design commitments, closing the loop between design intentions and operational compliance.

Special focus areas include:

  • Geolocation: disclose retention, sharing, new uses, reminders.
  • Persistent IDs: prefer resettable, opt-out options.
  • Third-party sharing and third-party code: monitor SDKs, ad networks, analytics.
  • Retention: limit duration; delete metadata or de-identify data.
  • Employee access: restrict to business-need-to-know.

Geo-location

The Goldenshores case study illustrates how geo-location data is subject to heightened regulatory scrutiny in the United States. Regulators and industry codes emphasize that transparency must go beyond the initial notice displayed when an app first requests access to location services. The CTIA guidelines, for example, recommend that developers disclose how long location data will be retained, whether retention periods vary based on circumstances, and what categories of location information will be shared with third parties. They also advise clear disclosures if geo-location is repurposed in new or materially different ways, coupled with periodic reminders to users that their data continues to be shared. Some platforms have implemented visual cues, such as standardized icons at the top or bottom of the screen, to serve as ongoing signals that location information is being accessed or transmitted. Together, these practices operationalize Privacy by Design by embedding clear, recurring user controls into the mobile experience.

Recent state privacy laws have further raised the stakes by explicitly classifying geo-location as sensitive data, requiring heightened protections. The California Consumer Privacy Act (CCPA), as amended by the CPRA, treats “precise geolocation data” as sensitive personal information, giving consumers the right to limit its use and disclosure. Other state frameworks, similarly impose stricter requirements on the collection and sharing of location information. For mobile and IoT developers, this means that implementing CTIA-style best practices is no longer only a matter of industry guidance — it is becoming a compliance necessity under state law, with geo-location singled out as requiring special safeguards.

Persistent Identifiers

Beyond location tracking, persistent identifiers raise parallel concerns for privacy-preserving design. The evolution of mobile practices highlights the importance of selecting identifiers that balance functionality with user control. When Apple stopped accepting apps that relied on device UDIDs in 2013, developers shifted toward the Identifier for Advertisers (IFA), which can be reset and allows opt-out from behavioral tracking. Similar privacy-driven changes appeared with the introduction of randomized MAC addresses to prevent long-term device tracking across networks. However, subsequent research revealed limitations — most notably, a 2017 U.S. Naval Academy study showing that devices could still be consistently tracked despite randomization flaws in chipset design. Researchers reported that they were able to “track 100 per cent of devices using randomization, regardless of manufacturer, by exploiting a previously unknown flaw in the way existing wireless chipsets handle low-level control frames” (see “Resources” below for a link to the paper). These examples reinforce the Privacy-by-Design imperative: identifier systems must be evaluated not just for technical feasibility but also for whether they meaningfully preserve user autonomy in practice.

Allowing Access by/Sharing with Third Parties

Information collected through mobile apps and IoT devices is often shared with third parties, sometimes via code such as SDKs embedded directly into the software or through device integrations with external services. Developers must therefore understand and continuously monitor what data third-party code or services collect, how that information is used, and with whom it is shared. These practices should be disclosed transparently to users, supported by ongoing oversight of third-party behavior and reinforced through contractual assurances. In the IoT context, where device functionality frequently depends on third-party cloud services or integrations, these obligations are particularly critical to maintaining user trust.

Sharing through Software Development Kits (SDKs) deserves special consideration, as these tools have become a major focus of regulators and litigants. The IAPP article Pursuit of App-iness: the Legal Considerations of SDKs highlights how SDKs, while offering developers ready-made functions for login, analytics, payments, and messaging, often enable extensive data collection and disclosure to third parties. Enforcement actions by the FTC against InMobi, X-Mode, InMarket, GoodRx, and others show repeated failures to obtain valid consent, honor operating system privacy settings, or disclose third-party uses of sensitive data like health and location information. To mitigate risk, the article stresses that both app developers and SDK providers bear responsibility for securing informed, affirmative consent, honoring system-level restrictions (such as Apple’s App Tracking Transparency and Google’s Advertising ID), and implementing supplier assessment programs to validate how data is collected, shared, and protected

Privacy by Design further requires developers to assess whether users must be given an opt-out of sharing under the CCPA or other State Privacy laws — or, in the case of minors, opt-in consent under state laws and COPPA — and to implement those rights effectively. States, particularly California, have pursued SDK-related cases, treating undisclosed SDK data flows as unlawful “sales” or “sharing” under the CCPA.

Retention
An essential element of Privacy by Design in the mobile and IoT context is retention management — limiting the duration for which personal data and associated metadata are stored. Developers should clearly define retention schedules that tie directly to the purpose for which the data was collected and avoid indefinite storage. Where ongoing retention is unnecessary, data should either be deleted or robustly de-identified so that individuals cannot reasonably be re-identified. This applies not only to user-facing information such as account details or location history but also to metadata generated by devices and apps, which can often be just as revealing.

The Gibson Guide’s 2025 review review makes clear that state privacy laws are converging around storage limitation as a core obligation, aligning closely with GDPR principles. For example, the California Privacy Rights Act (CPRA) explicitly requires businesses to disclose retention periods and prohibits keeping personal data “longer than is reasonably necessary” for the disclosed purpose. Other state frameworks, such as those in Colorado and Virginia, incorporate similar purpose-driven retention limits, underscoring that deletion or de-identification is no longer best practice alone but a compliance mandate. For mobile and IoT developers, this means retention rules must be embedded directly into data flows and system architecture, reinforcing privacy by design while meeting evolving legal standards.

Employee access

Managing employee access is another critical dimension of Privacy by Design for mobile and IoT systems. Access to personal data should be restricted strictly on a business-need-to-know basis, ensuring that only employees who require the information to perform their job functions can view or handle it. This approach aligns with the Gibson Guide’s 2025 review, which stresses that organizational safeguards — such as role-based access controls and internal oversight — are increasingly emphasized under state privacy laws and FTC enforcement priorities. By embedding access controls into system architecture, documenting role-based permissions, and conducting periodic reviews, organizations can show regulators that sensitive personal data is managed responsibly and only accessed when legitimately necessary.

Practical Checklist: Privacy by Design (PbD) for Mobile & IoT
Core Principles
Map how the app or device will function before development begins.
Distinguish between data that is essential to core services and data that is optional.
Flag sensitive data early (e.g., health, biometric, geolocation) and disclose its use clearly.
Provide meaningful user choices regarding data collection, use, and retention.
Test apps and devices prior to launch to confirm data flows match stated purposes.
Apply data minimization and purpose limitation: collect only what is necessary, and avoid secondary uses inconsistent with the original purpose.
Implement heightened safeguards for high-risk categories (children’s data, health data, biometrics) given regulatory priorities.
Geo-Location Data
Disclose retention periods, including whether they vary by context.
Identify what categories of location information will be shared with third parties.
Notify users if location data will be repurposed for new or materially different uses.
Provide periodic reminders that location information is being shared.
Use visual cues (e.g., icons) to signal when geo-location data is active.
Treat precise geo-location as sensitive data under CCPA/CPRA, requiring heightened protection and user rights to limit its use.
Persistent Identifiers
Favor resettable identifiers (e.g., IDFA, Google Advertising ID) that allow user opt-outs.
Avoid permanent reliance on UDIDs or MAC addresses.
Regularly review identifier systems to ensure they preserve user autonomy in practice.
Consider randomized or rotating identifiers, but validate their effectiveness through testing.
Disclose identifier practices in privacy notices, including retention and reset options.
Third-Party Access & Sharing
Map all third-party integrations (SDKs, APIs, cloud services, analytics).
Monitor third-party code behavior and data flows continuously.
Secure contractual assurances requiring third parties to follow retention and privacy commitments.
Disclose all sharing clearly, and link to third-party privacy notices where feasible.
Obtain opt-in consent for sensitive or unexpected third-party sharing; provide opt-out where required under CCPA/CPRA.
Pay special attention to SDKs: ensure affirmative express consent, honor OS-level restrictions (e.g., App Tracking Transparency), and validate third-party compliance through supplier assessment programs.
Retention & Deletion
Define purpose-based retention schedules for each category of data.
Explicitly disclose retention periods in privacy notices, as required by CPRA.
Automate deletion or de-identification once data is no longer needed.
Apply retention rules not only to primary data but also to metadata and logs.
Ensure policies apply across both device storage and cloud services.
Audit retention practices regularly for compliance with state laws and internal policies.
Employee Access Controls
Restrict access strictly on a business-need-to-know basis.
Embed role-based access controls into system architecture.
Document access rights and permissions, and review them periodically.
Monitor for misuse or overreach (e.g., “God View”-style abuses).
Align practices with FTC and state enforcement priorities on organizational safeguards.

Conclusion

Mobile and IoT privacy compliance in the U.S. continues to center on two pillars: privacy by design and transparency. Even in the absence of a comprehensive federal law, regulators have shaped de facto standards through guidance, enforcement actions, and industry codes. For developers and ecosystem players, this means embedding privacy safeguards into products from the earliest design stage, clearly disclosing practices through layered notices, and exercising vigilance over third-party integrations. These steps not only reduce legal risk but also strengthen user trust in increasingly data-driven technologies.

Looking ahead, the landscape is set to intensify. The Gibson Dunn 2025 review forecasts stronger attorney general enforcement, heightened scrutiny of AI-driven applications, expanded protections for children’s data, and new incident reporting obligations. Together, these trends signal that privacy compliance in mobile and IoT is evolving from a patchwork of expectations into a more rigorous, multi-layered regime — making proactive, design-centered approaches not just best practice but essential for long-term success.

Resources

Gibson Dunn U.S. Cybersecurity and Data Privacy Review and Outlook — 2025

IAPP article Pursuit of App-iness: the Legal Considerations of SDKs

Mobile best practice guidelines from regulators:

Mobile best practice guidelines from industry and industry associations:

Case-law and case studies

(A) Case-law:

  • In Re: Google Inc Cookie Placement Consumer Privacy Litig., №13–4300 (3d Cir. 2015) and Vasil v. Kiip Inc. 15-cv-09937, 2018 U.S. Dist. LEXIS 35573 (N.D. III. Mar. 3, 2018) (Regarding the difference between content of communication subject to the US Wiretap and metadata not subject to the Act)
  • Reyes v. Lincoln Automotive Financial Services, №16–2104-cv, 2017 WL 2675363 (2d Cir. June 22, 2017) (Plaintiff filed suit against Lincoln, alleging violations of the Telephone Consumer Protection Act (TCPA), 47 U.S.C. 227. The Second Circuit affirmed the district court’s grant of summary judgment for Lincoln, holding that plaintiff did introduce sufficient evidence from which a jury could conclude that he revoked his consent, but that the TCPA does not permit a consumer to revoke its consent to be called when that consent forms part of a bargained‐for exchange. In this case, plaintiff’s consent was not provided gratuitously, it was included as an express provision of a contract to lease an automobile from Lincoln.)
  • Edelgsverg v. Vroom, Inc., 16-cv-62734-GAYLES, 2018 U.S. Dist. LEXIS 500420 (S.D. Fla. Mar. 27 2018)
  • Case study: Carrier IQ (Device manufacturers and software developers can be held accountable for surreptitious collection of personal data on mobile devices even where the data is held in the device)

(B) Case studies:

Research papers

Unique in the Crowd: The privacy bounds of human mobility 2013 Scientific report article by Yves-Alexandre de Montjoye, César A. Hidalgo, Michel Verleysen & Vincent D. Blondel (researchers found 95% percent of cellphone users can be uniquely identified by using only four spatio-temporal points -that is, four points identifying their approximate whereabouts at an approximate time)

Read more