AB2561 adds a short chapter to the Business and Professions Code that requires an operating system or application to set a user’s default privacy setting to the "most privacy protective" option the product offers and forbids changing that setting without the user’s explicit consent. The bill imports the Civil Code definition of "personal information" to define its scope and applies to software that collects, processes, or stores personal information about a user in California and that exposes privacy settings to users.
This is a narrow but consequential change to product design and consent flows. Vendors will need to document and operationalize what constitutes the "most privacy protective" configuration, redesign onboarding and update flows, and reconcile the rule with enterprise management, security updates, and analytics needs.
The statute is short and leaves several key implementation and enforcement questions open, which will shape how companies comply in practice.
At a Glance
What It Does
The bill requires operating systems and applications to ship with the single most privacy-protective setting enabled by default and forbids changing a user’s privacy setting unless the user gives explicit consent. It defines "application" and "privacy setting" and relies on the Civil Code's definition of "personal information."
Who It Affects
The rule covers OS vendors and app developers whose products collect, process, or store personal information about users in California and that present privacy settings to users. It also affects advertisers, analytics vendors, enterprise IT teams using device management, and privacy-first service providers.
Why It Matters
By moving the privacy choice to the default, the bill reduces the burden on nontechnical users and changes the economics of data collection. Because the statute is terse and omits enforcement and exception language, implementation details and compliance costs will be decided in product teams and possibly through litigation or enforcement guidance.
More articles like this one.
A weekly email with all the latest developments on this topic.
What This Bill Actually Does
AB2561 inserts a new short chapter into California’s Business and Professions Code focused on device- and app-level privacy defaults. It defines an "application" as software that collects, processes, or stores personal information about a user in the state and that exposes privacy settings, and it adopts the Civil Code definition of "personal information" by reference.
The bill’s operative obligations are twofold: set the default privacy choice to the most protective option a product offers, and do not change a user’s privacy setting without explicit user consent.
Because the text treats operating systems and applications the same way, vendors across the stack—from mobile and desktop OS makers to individual app developers—must evaluate their configuration, telemetry, analytics, and feature flags to identify the product’s most protective state. The statute’s definition of "privacy setting" is broad, covering collection, use, sharing, disclosure, retention, and processing, so defaulting the most protective option could mean disabling background telemetry, limiting data sharing with third parties, or turning off personalized features by default.The bill does not create definitions for "operating system" or "explicit consent," nor does it include exceptions for security patches, enterprise device management, or functionality that requires data to work.
That silence matters: product teams will need to decide whether consent obtained through account sign‑in, enterprise profiles, or prompts during setup qualifies as "explicit consent," and whether vendor-initiated changes to settings tied to security or legal obligations are permitted. The lack of express enforcement language or penalties also leaves open who will police compliance and how violations will be remedied, so firms should plan both product and legal strategies while monitoring for implementing guidance.
The Five Things You Need to Know
Section 22683(a) defines "application" as software that collects, processes, or stores personal information about a user in California and that offers privacy settings; the bill relies on Civil Code §1798.140 for "personal information.", Section 22683(c) defines "privacy setting" to include options governing collection, use, sharing, disclosure, retention, or processing of personal information.
Section 22684(a) requires operating systems and applications to configure a user’s default privacy setting to be the "most privacy protective" option the product offers.
Section 22684(b) prohibits an operating system or application from changing a user’s privacy setting without the user’s explicit consent.
The statute is silent on definitions for "operating system" and "explicit consent," contains no express enforcement mechanism, and includes no carveouts for security updates or enterprise management.
Section-by-Section Breakdown
Every bill we cover gets an analysis of its key sections.
Who and what counts as an "application" for this chapter
This subsection sets the territorial and functional scope by tying coverage to software that handles a user’s personal information "in the state" and that provides user-facing privacy settings. Practically, that captures mobile apps, desktop clients, and web-enabled software that store or process data associated with California users and expose controls. The choice to anchor "personal information" to Civil Code §1798.140 imports a broad, commonly used definition (names, identifiers, commercial info, browsing history, etc.), which widens coverage beyond narrowly defined categories of data.
What counts as a "privacy setting"
The bill defines privacy settings expansively to cover any configurable option that affects collection, use, sharing, disclosure, retention, or processing. That means not only obvious toggles for tracking or ad personalization, but also retention policies, upload/backup behaviors, telemetry controls, and feature-level choices that involve personal information. For engineers and product managers, this creates a need to inventory any setting that touches personal data and to document which configuration constitutes the most protective state.
Mandate to set the most privacy-protective default
This subsection imposes a default-duty: when shipping or provisioning a device or app, the vendor must choose the single option that is most protective of privacy among the options it offers. That is a relative standard rather than an absolute technical specification, so compliance will likely require internal policy decisions (e.g., disabling analytics by default, restricting third‑party sharing, or setting minimum retention periods). Companies should expect to update onboarding flows, documentation, and testing to demonstrate how defaults were selected and why they are the most protective choice available.
Ban on provider-initiated changes without explicit consent
This provision bars vendors from altering a user’s privacy setting without explicit consent, which limits remote or unilateral changes to configuration. The language does not define "explicit consent," leaving open whether affirmative click-through, account reauthentication, or other interactions qualify. It also does not state exceptions for security updates or legal compliance, so organizations operating at scale will need governance rules for when and how to request or record consent and how to handle managed devices and emergency updates.
This bill is one of many.
Codify tracks hundreds of bills on Privacy across all five countries.
Explore Privacy in Codify Search →Who Benefits and Who Bears the Cost
Every bill creates winners and losers. Here's who stands to gain and who bears the cost.
Who Benefits
- Nontechnical California consumers: They gain stronger protection by default, reducing the need to find and change settings to avoid tracking or data sharing.
- Privacy‑focused app and OS vendors: Companies already shipping privacy‑protective defaults face lower switching costs and can market compliance as a competitive advantage.
- Vulnerable user groups (seniors, children, low‑income users): Users less likely to change defaults get protection without extra action, reducing exposure to unwanted profiling.
- Civil society and privacy advocates: The rule advances privacy-by-default norms and creates clearer product design standards to press against invasive collection practices.
Who Bears the Cost
- OS vendors and app developers: They must audit settings, change default configurations, redesign onboarding and update flows, and maintain consent records — all of which increase development and compliance costs.
- Advertising and analytics ecosystems: Reduced default data collection will lower the availability of behavioral signals used for targeting and measurement, potentially decreasing ad revenue for publishers and platforms.
- Enterprises and managed‑device administrators: MDM and enterprise profiles may conflict with consumer-level defaults; IT teams will need processes to reconcile enterprise policies with the statutory default and consent requirements.
- Regulators and enforcement bodies: Because the text omits enforcement details, state agencies may face pressure to issue guidance or pursue enforcement without clear statutory tools, potentially stretching resources.
Key Issues
The Core Tension
The bill pits the public interest in stronger, easier privacy protection for ordinary users against the operational and economic realities of software ecosystems that rely on configurable data collection for security, personalization, and advertising; choosing privacy by default protects many users but forces product and enterprise trade-offs that the text does not resolve.
The bill establishes a clear behavioral rule but leaves central pieces undefined or unaddressed, creating substantive implementation questions. "Most privacy protective" is a comparative, product-specific standard that requires firms to choose among multiple configurations; absent objective criteria, vendors will develop their own selection methodologies, producing inconsistent outcomes across the market. Similarly, the statute does not define "explicit consent," which could range from a clear affirmative opt‑in to a softer browser or account preference, and that ambiguity will drive disputes about whether settings were lawfully changed.
Operational conflicts are likely. Many systems rely on background telemetry, diagnostics, or limited data sharing for security, fraud prevention, or core functionality; defaulting to the most restrictive option could degrade services or push companies to seek additional, post‑install consent flows that in turn increase user friction or consent fatigue.
The absence of carveouts for enterprise-managed devices or security updates also raises questions about how vendors should handle critical patches or enterprise policy overrides without violating the prohibition on changing settings without consent. Finally, enforcement is unclear — with no penalties or private right of action specified, compliance incentives will hinge on agency guidance, market pressure, or litigation challenging the statute’s meaning.
Try it yourself.
Ask a question in plain English, or pick a topic below. Results in seconds.