On 29 October 2026, the California Attorney General announced a $1.8 million civil penalty settlement with Lyft over how riders and drivers could opt out of the sale and sharing of their personal information. The allegation fits in one sentence: Lyft's service exists only inside a mobile app, and its opt-out lived outside it. A rider who wanted to say no had to leave the app, load a webpage in a mobile browser, and then sign in again to prove who they were, to a company that already knew.
If you ship a mobile app that talks to an ad network, an analytics SDK or a data partner, this is a build ticket more than a legal question. The same method rules also govern the opt-out of automated decisionmaking technology (ADMT) that applies from 1 January 2027, so an app team that gets the pattern right now has done part of that work. This is a builder's read of a public enforcement action and the regulation text, not legal advice. Counsel decides whether the rules cover you.
What did California say Lyft got wrong?
The facts below come from the Attorney General's 29 October 2026 announcement and the complaint, People v. Lyft, Inc., filed on 28 October 2026 in San Francisco Superior Court (Case No. CGC-26-641775). They are allegations in a settlement, not findings after a trial.
- The business model. The complaint says Lyft offers its services exclusively through its mobile app, and that one account links a person's rider and driver profiles across the Lyft and Lyft Driver apps.
- The data flow. Starting in mid-2023, according to the complaint, Lyft disclosed device identifiers, IP addresses and coarse geolocation to third parties to target ads at riders. The complaint says this let Lyft charge more for advertising and triggered the opt-out right. It also says the Attorney General found Lyft did not sell or share precise geolocation, so the case is not about the heavier rules on precise location.
- The missing control. There was no native setting inside the app. The complaint says the only route was a chain of links through the in-app privacy policy to a "Do Not Sell or Share My Personal Information" webpage in the phone's browser.
- The second hurdle. After tapping the opt-out button on that page, the complaint says users were asked to resubmit their login credentials and verify their identity, "even though consumers were already logged into Lyft's app and Lyft knew the consumers' identities."
The Attorney General's release says the settlement requires Lyft to provide an in-app opt-out and to tell California consumers about their right to stop the sale of their personal information. It describes the matter as growing out of a 2025 investigative sweep of how companies use geolocation data, and calls it the ninth CCPA enforcement action by the state's Department of Justice. The release does not state reporting terms, so this post does not guess at them.
What do the California Consumer Privacy Act (CCPA) regulations require of an app?
Three parts of the regulations, effective 1 January 2026, do the work here.
Section 7026(a) says a business that sells or shares personal information must offer two or more designated methods to opt out, and that "at least one method offered shall reflect the manner in which the business primarily interacts with the consumer." For a company with no website storefront, the primary interaction is the app. A link that opens a browser is a method, but it is not the one that mirrors how the person uses the product.
Section 7026(b) and (c) say the method must be "easy for consumers to execute," must "require minimal steps," and must comply with section 7004. A business "shall not require a consumer submitting a request to opt-out of sale/sharing to create an account or provide additional information beyond what is necessary to direct the business not to sell or share the consumer's personal information."
Section 7026(d) adds the clause that decides the sign-in question: a business may ask for information necessary to complete the request, "such as information necessary to identify the consumer," but "to the extent that the business can comply with a request to opt-out of sale/sharing without additional information, it shall do so." If the app already holds an authenticated session, the session is the identification.
Section 7004(a)(4)(A) names the pattern outright as an example of choice architecture that "impairs or interferes with the consumer's ability to exercise their choice": requiring the consumer to click through disruptive screens before they can submit an opt-out. And section 7004(a)(2) adds symmetry: the opt-out path cannot take more steps than the path to opt in.
Does the same rule apply to the ADMT opt-out?
Yes, almost word for word, which is why this case matters beyond advertising. Section 7221(c) says a business using ADMT for a significant decision must offer two or more opt-out methods, and "at least one method offered must reflect the manner in which the business primarily interacts with the consumer." Section 7221(d) requires the methods to be easy, minimal-step and compliant with section 7004. Section 7221(e) and (f) repeat the bar on requiring an account or a verifiable request beyond what is necessary.
Picture a 20-person lending-app company whose only product is a mobile app, and whose underwriting model decides credit limits. Credit limits are in the financial category of significant decisions in section 7001(ddd). If its ADMT opt-out is a webform on a marketing site that asks the user to log in again, it has rebuilt the Lyft problem for a heavier decision. Our guide to the ADMT opt-out request timeline covers the 15-business-day clock; this post covers how the request is made in the first place. Whether a given decision counts is the first question, and what counts as ADMT lays out the definition.
How do you build an opt-out that lives in the app?
Take a company with an iOS app, an Android app, three ad or analytics SDKs and a nightly export to a data partner. Here is the build that the Lyft allegations suggest.
- 1.Put the control in settings, not in a policy. A "Do Not Sell or Share My Personal Information" row in the privacy section of settings, one tap from the screen people already use. A link buried three screens deep in a policy document is the path the complaint describes.
- 2.Use the session you already have. If the user is authenticated, the opt-out request carries the token and nothing else. Do not send them to a login page, and do not ask for fields you hold. Section 7026(d) is the rule to cite when someone in the room says "we need to verify them."
- 3.Write the choice to the account. Store it against the user ID, not only on the device, so it reaches the same person's other devices and the linked profile. In the Lyft complaint one account joined the rider and driver apps, which is the case where a device-only flag fails.
- 4.Gate every outbound path on one check. Ad SDK initialization, server-side conversion calls and the partner export all ask the same "may we share this person's data?" question. In an app, the easy failure is an SDK that initialises at launch, before any setting is read.
- 5.Make the effect visible. Section 7026(g) requires a way for the consumer to confirm the request was processed. A toggle in settings that reads the same record your gate reads does that.
- 6.Keep the web path too. Section 7026(a)(1) still requires an opt-out preference signal and a form for online collection. The in-app control is added, not substituted.
For the downstream half (telling partners that already received the data), the Disney settlement post walks the account-level model, and the LocateSmarter intake post covers what a request form may ask for.
When is this the wrong build?
If you do not sell or share personal information, most of this does not apply, and the right first step is a data-flow inventory that proves it. An app that sends data only to service providers under written contracts, with no cross-context advertising, may need no opt-out at all. The CCPA checklist for engineering teams is a sensible place to confirm that before you build anything.
A second case is a company with a mobile app and a large web property where users really do start on the web. Section 7026(a) asks for the method that reflects the primary interaction, so the answer turns on facts about your own users, and a native control is still cheap enough that most teams will want it. Counsel can tell you where the line sits.
How should you scope the work?
Start with a test account on a clean install. Open the app, log in, find the opt-out, use it, and count the taps and the screens that ask for anything. Then watch network traffic for the next ten minutes and list every host that still receives device identifiers. The count of taps tells you about section 7004. The list of hosts tells you about everything else.
If you want help, our ADMT compliance engineering team builds notice, opt-out and logging work for products with California users. You can run the ADMT checker to see which of your decisions fall under the automated-decisionmaking rules, or talk to us with your app list, SDK list and partner exports.
Sources
- California Attorney General: Privacy Rights Can't Be Left in the Rearview, Attorney General Bonta Secures $1.8 Million Settlement with Lyft (29 October 2026)
- California Attorney General: People v. Lyft, Inc., complaint, San Francisco Superior Court Case No. CGC-26-641775 (filed 28 October 2026)
- California Privacy Protection Agency: CCPA regulations, Title 11 Division 6 Chapter 1, effective 1 January 2026, sections 7004, 7026 and 7221
