California's new AB 2561 law has sparked questions from many teams about its impact on mobile apps. The main confusion lies in how it differs from the California Consumer Privacy Act (CCPA) and whether it introduces new technical requirements beyond current consent processes.
Here's what you need to know.
Understanding AB 2561
AB 2561 targets apps or operating systems that change user privacy settings without explicit consent. It defines "privacy setting" as any user-configurable option in an app's privacy menu that affects the collection, use, sharing, disclosure, retention, or processing of personal information.
While the Federal Trade Commission (FTC) has long enforced against retroactive changes to privacy practices, AB 2561 establishes a clear rule specifically for settings changes. This blog addresses the questions compliance teams are asking as they assess their current implementations.
Q1: Does AB 2561 require more than install-time consent?
Yes, if you change privacy settings after initial consent.
Install-time consent covers the purposes disclosed at collection. AB 2561 focuses on later changes to settings a user has configured. For example, if a user sets location sharing to "only while using the app" and an update changes it to "always," AB 2561 prohibits this without explicit consent.
This differs from seeking permission for new data types, which is already managed under CCPA's purpose limitation rules. AB 2561 is about altering existing configurations.
Q2: What is considered "changing" a privacy setting?
Any modification to a user-configurable option in your privacy menu that affects personal information handling.
Examples include:
- Switching a toggle from "off" to "on" for analytics tracking
- Changing a radio button from "essential only" to "all cookies"
- Modifying a dropdown from "do not share" to "share with partners"
- Resetting a disabled data-sharing option to enabled
Fixing a bug that prevents a setting from working as labeled or implementing a security patch that doesn't alter data processing doesn't count.
Q3: How does this relate to CCPA's consent requirements?
AB 2561 adds a specific obligation within CCPA's broader framework.
CCPA prohibits using personal information for materially different purposes than disclosed at collection without consent. AB 2561 addresses settings changes specifically, even if the purpose remains the same.
For instance, if a user consented to location tracking for "service delivery" and configured access to "only while using," changing it to "always allow" requires explicit consent under AB 2561. CCPA's purpose limitation would apply if you used that data for marketing instead.
Both need to be satisfied.
Q4: Can settings be changed during an app update, then consent obtained afterward?
No. Consent must be obtained before changing the setting.
This means your update flow must detect any settings changes, present a consent notice, and only apply the change if the user consents. If they decline, the setting must stay the same.
Q5: What if settings are reset for security or privacy improvements?
Consent is still required if the change affects personal information handling.
AB 2561 doesn't exempt security improvements or privacy-enhancing changes. If you're modifying a user-configurable privacy setting, explicit consent is necessary regardless of intent.
If the change is purely technical and doesn't alter any privacy setting the user can configure, you're outside AB 2561's scope.
Q6: Does this apply to cookie consent on mobile sites or just native apps?
AB 2561 specifically refers to "applications," meaning native mobile apps and possibly desktop applications.
Browser-based cookie consent on mobile sites falls under existing CCPA rules and the ePrivacy Regulation framework for EU users. These require prior consent before placing non-essential cookies. If you're changing cookie preferences set through your Consent Management Platform, CCPA's prohibition on using data for materially different purposes applies, but AB 2561 focuses on app-level settings.
The principle remains: don't change user privacy configurations without explicit permission.
Q7: If we use a third-party SDK for privacy settings, who's responsible?
You are, as the app operator.
AB 2561 doesn't differentiate between settings you control and those managed by third-party code. If your app presents a privacy menu with user-configurable options, you're responsible for ensuring those settings aren't changed without explicit consent, regardless of the SDK or vendor.
Audit your third-party dependencies to ensure they don't autonomously modify privacy settings. Your vendor contracts should require notification of any changes affecting user privacy settings and prohibit such changes without your approval.
Q8: What's the enforcement mechanism?
The bill doesn't create a new private right of action. Enforcement falls under California's consumer protection framework and potentially the California Privacy Protection Agency's authority.
The Attorney General and CPPA can pursue violations, but individual users can't sue directly under AB 2561. However, a settings change without consent could trigger CCPA violations that do carry private action rights if they involve a data breach.
Treat this as any CCPA requirement: the regulatory exposure is significant even without private lawsuits.
Next Steps
Review your app update process to identify where privacy settings might change. Map each setting in your privacy menu to the data flows it controls, and build a pre-update consent check for any modifications.
If you're using third-party SDKs, audit their updates for changes affecting privacy controls. Ensure your vendor reviews include questions about handling user privacy settings across versions.
Align your consent architecture across web and mobile properties. While legal requirements differ, the operational principle is the same: user privacy preferences remain until the user changes them.
