The question at hand
Lyft's $1.8 million CCPA settlement with the California Attorney General highlighted a critical issue. Lyft, an app-only service, required users to leave the app to opt out of the sale or sharing of personal information. Users had to navigate through links from the in-app Privacy Policy to a "Do Not Sell or Share My Personal Information" webpage, re-enter login details, and submit more personal information. The Attorney General found this process cumbersome and non-compliant with the CCPA.
This raises a crucial design question for consent and DSAR operators: When your product is app-based, should the opt-out option be integrated into the app, or can a well-designed web-based mechanism suffice?
The case for the web-based mechanism
Teams that prefer web-based opt-outs often do so for operational reasons.
One system of record. A single web form feeds into one request queue, one identity-verification process, and one audit trail. Native opt-out controls in iOS, Android, and webviews increase the complexity of maintaining consistency. Each additional surface is a potential point of failure for the suppression signal to reach downstream vendors.
Cross-channel reach. Many businesses collect data from websites, apps, and offline sources. A central web page can address all these channels. An in-app toggle might only cover the app, leaving users uncertain if they've opted out everywhere.
Release cadence. Web changes can be implemented immediately. Mobile changes depend on app store review cycles, and users on older app versions may not see updates. If your legal team updates the opt-out wording, the web can reflect this instantly.
Traditional model familiarity. Historically, the "Do Not Sell" link on a website footer was the standard. Teams assumed an app could direct users to the same destination.
These are valid engineering concerns, but they don't constitute a legal defense.
The case for the native in-app opt-out
The Lyft case illustrates why native in-app opt-outs are often favored.
The user is already authenticated. The Attorney General noted that Lyft required users to re-enter credentials despite already being logged in. This added friction serves no verification purpose. If your app knows the user, asking for re-authentication on a web page appears as a barrier.
The context switch is the burden. Leaving the app to navigate a series of links to a form is the "detour" described by the Attorney General. For an app-only business, the app is the primary channel. A control outside this channel is effectively hidden.
The process mirrors the data flow. Lyft's data collection, use, and monetization occurred within the app. Regulators expect the right to opt out to be exercisable in the same environment.
Symmetry of Choice. Consent Notice design rules emphasize equal prominence for accept and reject options. If opting in is easy but opting out requires multiple steps and a login, the interface undermines genuine choice.
The downside is cost and complexity, but the settlement shows the cost of delaying this work.
Where practitioners actually land
Most experienced teams adopt a hybrid approach, favoring the native experience.
- App-first businesses implement a native opt-out accessible from settings or the account screen, using the user's authenticated session for identity. They maintain the web page as a secondary option.
- Web-first businesses with a companion app allow a link-out only if it leads directly to a working opt-out without requiring re-authentication or additional data. A link to a generic privacy page won't suffice.
- Teams with extensive vendor ecosystems focus on propagation. They use the in-app toggle as a trigger that writes to the same suppression store as the web form, ensuring the backend remains consistent.
The shared principle: have one source of truth accessible through multiple channels, with the primary channel being the easiest to use.
Enforcement context is also important. Lyft is the ninth CCPA enforcement action by the California Department of Justice, following settlements with companies like General Motors, Sephora, and DoorDash. Many of these are app, streaming, or gaming businesses. The Lyft case emerged from a March 2025 investigative sweep focused on geolocation data and personal information sharing. If your product collects location data and relies on advertising, you're already under scrutiny.
Our take
Build the native opt-out. Operational arguments for a web-only approach are valid, but they're issues you can solve with architecture, not reasons to burden users.
Here's what to check in your product:
- Count the steps. How many taps does it take to reach an opt-out from any screen? If it requires leaving the app, you're following the Lyft pattern.
- Audit re-authentication. If the user is logged in, don't ask for login details again. Avoid collecting additional personal information you already have.
- Match the channel. If data is collected and used for advertising in the app, the opt-out should be in the app.
- Centralize the suppression. Regardless of the entry point, route every opt-out into one store that controls downstream sale and sharing, and keep a record of each request.
- Test it as a stranger would. Have someone unfamiliar with your privacy policy try to opt out, and time the process.
The tradeoff is cost and slower release cycles. The alternative is a $1.8 million penalty, mandated remediation you'll have to build anyway, and a required notice informing California consumers about the right you previously made difficult to use. Teams that treat usability as a compliance requirement, not an optional feature, are the ones who won't face the next settlement announcement.
