Take Back Your Data

California is moving an age-bracket signal into the operating-system and application-store layer. That is a specific technical change with specific legal limits, not proof that every age-assurance law works the same way.

The useful questions are concrete: what data is collected, who supplies it, which applications receive it, what the law forbids, and what recourse exists when the signal is wrong. Separately, data portability determines whether losing access to one cloud account also means losing the only copy of your records.

California's AB 1043, the Digital Age Assurance Act, is a concrete example. The enacted text becomes operative January 1, 2027. For a device whose primary user is a child, it requires an operating system provider to present an accessible account-setup interface where an adult account holder supplies the child's birth date, age, or both. The provider must make a minimum age-bracket signal available to a requesting application through a secure real-time API. The law describes that bracket as nonpersonally identifiable data; it does not require the signal to identify the child by name. Civil penalties, recoverable by the California Attorney General, are capped at $2,500 per affected child for each negligent violation and $7,500 for each intentional violation, with a good-faith safe harbor for erroneous signals and reasonable technical limits.

Other jurisdictions regulate age assurance through different laws and platform duties, so they should not be collapsed into one rule. The point here is narrower: AB 1043 places a new collection and signaling duty at the operating-system and application-store layer. Even with statutory data-minimization limits, that new interface deserves technical and public scrutiny before it becomes routine.

The Problem Is the Architecture, Not the Goal

AB 1043 moves an age-bracket data flow into the OS layer while limiting the signal to the minimum required information. The public policy question is how that interface will be governed, audited, and prevented from expanding beyond its stated purpose.

Protecting children online is a legitimate policy goal. The implementation still matters. A system that collects age or birth-date input and exposes an age bracket to applications creates a new trust boundary among the account holder, OS provider, app store, and developer. The enacted law limits the data shared and prohibits unrelated third-party use, but enforcement, retention, auditing, and later legislative changes remain reasonable subjects for scrutiny.

This is why precise language matters. An age bracket is not the same thing as a named identity, and the statute says the signal should be nonpersonally identifiable. It is still data about a user, delivered through an OS-level API. A useful critique should test the actual collection, disclosure, retention, and appeal behavior rather than assuming either perfect privacy or inevitable abuse.

Your Data Is Their Hold on You

Keeping an independent local copy reduces dependence on a provider's retention, export, and account-access rules. It does not erase legal obligations or security risk, but it gives you another recovery path and lets you choose where the copy is stored.

Cloud accounts can hold email, documents, photos, contacts, and other records that are difficult to replace after an account lockout, product change, or breach. An export does not delete the provider's copy, but it reduces the chance that one account becomes the only place your data exists.

Local storage has its own obligations: encryption, access control, backups, updates, and lawful requests still matter. The practical advantage is control over the copy, format, backup schedule, and recovery process, not immunity from law or compromise.

Centralized data is a liability as well as a sovereignty problem. IBM's 2025 Cost of a Data Breach report reports a $4.44 million global average and a $10.22 million U.S. average among 600 organizations studied from March 2024 through February 2025. Those enterprise averages do not predict the cost of an individual's account breach. They do show why keeping one recoverable copy, with a tested restore path, is more useful than treating a cloud account as the only archive.

Product Option: Create a Local Export

Cloud Scraper is an open-source desktop exporter whose repository documents Google and Microsoft support plus experimental Apple support. It writes selected data to local formats; it does not delete the provider's copy. Treat each export as a recovery copy, protect its credentials, and test that the files can be restored.

Cloud Scraper repository documents Gmail, Google Contacts, Calendar, Drive, and Photos; Outlook mail, Microsoft Contacts, Calendar, and OneDrive; and experimental Apple Contacts, Calendar, and iCloud Drive support. Its format table maps mail to EML, contacts to vCard, calendars to iCalendar, and cloud files to their original formats.

The export is a new local copy, not proof that the provider deleted its copy. The repository says transfers go directly to local disk rather than through an intermediary service. That reduces one dependency, but provider APIs, account access, export completeness, and local storage security remain part of the risk model.

Run a small export before relying on it. Verify the expected record count and file formats, encrypt the destination, make a second backup, and restore a sample. Apple support is labeled experimental upstream, so test it separately and do not treat the provider list as a guarantee that every account item will export.

How This Connects to OpenFactory

OpenFactory can reduce unwanted software and cloud defaults by letting you choose packages and configuration for supported Linux builds. That is separate from exporting account data. Neither product eliminates network observation, legal duties, provider-held copies, or endpoint compromise; each changes one part of the user's control boundary.

A custom image can make software selection and configuration explicit. For a supported target, the completed build record and manifest show what the service produced; your own runtime tests establish how that image behaves in its deployed environment. A catalog entry or article alone is not proof that a particular image contains no telemetry.

Data portability addresses a different failure mode: whether one account is the only usable copy of important records. Using both tools can improve control over system inputs and recovery copies, but each needs its own verification. That is the evidentiary bridge between this article's architecture discussion and the product options.

What You Can Do Right Now

Start with a small, testable recovery plan: export one data category, inspect the format, encrypt the destination, make a second backup, and perform a restore. Then document which provider copies remain and which account credentials can still unlock them. Independence comes from verified recovery options, not from moving risk to an unmanaged disk.

The following steps reduce different risks. None is a blanket privacy guarantee:

• Export your data with Cloud Scraper or a provider-native export. Record the data types and formats received; the provider's source copy remains unless you separately delete it.
• Protect and restore the copy with encryption, a second backup, and a dated restore test. This reduces account lockout risk while adding responsibility for local access control and media failure.
• Inspect an OS build with OpenFactory. Use its manifest and completed test record to verify a supported image, then test network behavior in your environment. Customization does not itself prove the absence of telemetry or compromise.
• Encrypt selected network paths with a private home VPN when remote devices need access to the local copy. A VPN protects traffic between its endpoints; it does not erase endpoint logs, provider records, or all network metadata.
• Read the enacted text before sharing a legal claim. Record its jurisdiction, operative date, covered party, required data, exceptions, and enforcement mechanism so different age-assurance laws are not collapsed into one architecture.

The practical goal is modest and measurable: know where the authoritative copy lives, keep an independent recovery copy, verify that you can restore it, and make factual claims about the systems and laws involved.

Tools can support that process. The test records and restore results are what make it dependable.