The Export Button Is Not Ownership
Every major platform offers some version of an export button. Google Takeout. Facebook's "Download Your Information." Twitter's archive. These features exist partly because regulators demanded them and partly because they cost platforms almost nothing to provide. They hand you a ZIP file and call it data rights.
That framing is a category error. Receiving a copy of your data is not the same as owning it. The platform still holds the original. The platform still processes it. The platform's business logic still runs on it every second after you download the archive. The export was a snapshot of a moment, not a transfer of control.
Real data ownership is not about copies. It is about provenance, consent, interoperability and the structural power to revoke. The export button satisfies none of those criteria at the technical level. Engineers building privacy-preserving systems need to understand this distinction precisely, because the gap between "we gave users their data" and "users own their data" is where most compliance theater lives.
Dr. Patrick Fisher's work through Own Your Data Inc explores this gap as a foundational problem in data governance. Volume 6 of The Invisible Series, The Invisible Data, frames it plainly: portability without revocability is disclosure, not ownership. That distinction has direct engineering consequences.
What Portability Actually Means in a Sovereignty Stack
Portability in a genuine data sovereignty context has three dimensions that the export-button model collapses entirely.
The first dimension is structural portability. Your data must be expressible in formats that are not platform-proprietary. This means open, machine-readable schemas with published specifications. JSON-LD with established vocabularies, RDF graphs, or formats governed by standards bodies like the W3C. If your data can only be read by the platform that produced it or by tools that require that platform's cooperation, you do not have structural portability.
The second dimension is semantic portability. Moving bytes from one system to another is meaningless if the receiving system cannot interpret what those bytes represent. Semantic portability requires shared ontologies and agreed vocabularies. The W3C Verifiable Credentials Data Model is one of the clearest attempts to standardize this at the identity layer. Semantic portability is what transforms a file into actionable personal data that a different system can use without human translation.
The third dimension is operational portability. Even structurally and semantically portable data is useless if the user cannot operationally move it, meaning move it programmatically, at will, without platform approval, to a destination of their choosing. This requires APIs that are genuinely open, not rate-throttled into irrelevance or gated behind developer agreements that platforms can revoke.
The GDPR's Article 20 right to data portability is widely cited as establishing this right in law. What it actually established is a much weaker version: the right to receive data in a "commonly used and machine-readable format." That language is broad enough to include a CSV file with non-standard column names. The regulation names the right but does not specify the technical floor required to make it meaningful.
The Technical Requirements of Real Data Portability
Building genuine portability into a data system requires architectural decisions that most product teams do not make, because those decisions impose costs and constrain the platform's own future data use.
The first requirement is a canonical data model with versioning. Every record that a user generates must be expressible against a stable, versioned schema that the user can inspect. Schema drift, where the platform quietly changes what fields mean or drops historical fields, is incompatible with real ownership. Versioning is not optional. A user who exported their data in January must be able to import it to a new system in December without schema translation failures caused by undocumented platform changes.
The second requirement is cryptographic provenance. For data to be genuinely portable, its origin must be verifiable. This means signing data records at creation time with keys that the user controls or that a trusted third party governs on the user's behalf. Decentralized Identifiers (DIDs), specified by the W3C in the DID Core specification, provide the identity anchor for this signing model. When a user moves their data, the provenance chain travels with it, and the receiving system can verify authenticity without calling back to the originating platform.
The third requirement is granular consent receipts. The Kantara Initiative's Consent Receipt Specification defines a machine-readable record of what a user consented to and when. Real portability means those consent receipts travel with the data. When you move your data, the new system inherits the full consent history. It does not start with a blank slate that allows re-purposing the data under new terms. Consent receipts are the audit trail that makes revocation meaningful.
The fourth requirement is revocation that propagates. This is the hardest requirement and the one most systems skip. If a user withdraws consent or exercises a right to erasure under GDPR Article 17, that signal must propagate to every downstream system that received a copy of the data. This requires a revocation registry that downstream systems are contractually and technically obligated to poll. Without propagating revocation, deletion is cosmetic.
The fifth requirement is format independence at the application layer. The portability stack must be separate from the application that generated the data. When Instagram's servers go dark, the photos and social graph that users generated should not go dark with them. This architectural separation is what distinguishes a data fiduciary model from a platform model. The NIST Privacy Framework identifies data minimization and separation of function as core privacy engineering principles. Portability architecture is where those principles become concrete.
Consent Architecture and Portability Cannot Be Separated
One of the most common mistakes in privacy engineering is treating consent management and data portability as separate concerns served by separate systems. They are not separable if ownership is the goal.
Consent governs the conditions under which data was originally collected and the purposes for which it may be processed. Portability moves that data to new contexts. Without consent architecture traveling alongside the data, portability creates a loophole: the new system receives data without the constraints that governed its creation.
This is the mechanism by which data brokers operate. They receive data from one context, strip the consent constraints that governed collection in that context and re-use the data under their own terms. Structural portability without consent portability is a data broker pipeline by another name.
A real ownership stack binds the consent record to the data object at the cryptographic level. The consent receipt is not stored separately in a consent management platform that the user cannot inspect. It is a signed artifact attached to the data, readable by any conforming system. When data moves, the consent artifact moves. When consent is revoked, the revocation token references the same identifier that the consent receipt carries.
The IETF's work on OAuth 2.0 Rich Authorization Requests (RFC 9396) provides a partial model for expressing fine-grained authorization alongside data access. The W3C's work on Verifiable Presentations extends this toward user-controlled credential sharing. Neither is a complete consent portability solution, but both represent the standards layer on which such a solution must be built.
How PDAOS Approaches Portability as a First-Class Primitive
The Personal Data Asset Origination System developed through Own Your Data Inc treats portability not as a compliance feature added after the fact but as a design primitive from which the rest of the system is derived.
In the PDAOS model, every personal data record is a structured asset with four bound components: the data payload, a provenance signature, a consent receipt and a revocation reference. None of these components is optional. A record without all four is not a personal data asset in the PDAOS sense. It is a raw data fragment under platform control.
This structure means that when a user moves a personal data asset, they move ownership, not just content. The receiving system receives the provenance chain, the consent terms and the revocation hook in the same operation. There is no post-hoc consent negotiation between the user and the destination. The terms are embedded in the asset.
The PDAOS approach draws on the data trust model articulated by researchers at the Open Data Institute and on the decentralized identity primitives specified by the W3C DID Working Group. MyDataKey is the applied product implementation of these principles, designed to give individuals a key-based interface to their own data assets across institutional boundaries.
The goal is not to replicate what platforms do with a privacy label attached. The goal is to invert the architecture: the user holds the asset, and platforms request access to it rather than holding the data and granting users a download window.
The Interoperability Gap That Regulation Has Not Closed
Regulation has named the right to portability without specifying the technical interoperability required to make it real. This gap is not accidental.
GDPR Article 20 specifies the right but defers to "commonly used" formats without defining them. The EU Data Act, which applies to IoT and machine-generated data, goes further by requiring data holders to provide real-time access through APIs. But real-time API access is not the same as sovereignty. The platform still controls the API. The platform can change it, throttle it or shut it down.
The Digital Markets Act targets gatekeepers and requires interoperability between messaging services, but its scope does not extend to the full personal data layer. The California Consumer Privacy Act provides the right to know and the right to delete but its portability provisions mirror GDPR's ambiguity on format standards.
What regulation has not produced is a mandated technical standard for portability that includes provenance, consent binding and revocation propagation. Without that standard, platforms can satisfy the letter of the law with a ZIP file and a download link.
The policy gap is where engineering must lead. Standards bodies including the W3C, IETF and ISO are where the technical floor for meaningful portability will be established. Engineers and privacy researchers who participate in those processes are building the regulatory prerequisites that legislators have not yet written.
What Engineers Building for Sovereignty Must Prioritize
For engineers designing systems where data sovereignty is a real requirement rather than a marketing claim, the priority list is concrete.
Use open schemas with public specifications. Schema.org vocabularies, JSON-LD contexts published under stable URIs and data models registered with standards bodies are the baseline. If your data model lives only in internal documentation, you do not have portable data.
Implement DID-based provenance from the start. Retrofitting cryptographic provenance into an existing system is orders of magnitude harder than building it in at the data model layer. The W3C DID Core specification and the associated Verifiable Credentials Data Model provide the foundation. Start there.
Build consent receipts as database objects, not UI acknowledgments. A checkbox interaction that writes a boolean to a column is not a consent receipt. A signed, structured record conforming to the Kantara specification is a consent receipt. These are architecturally different. Design the system for the latter.
Design revocation as a first-class operation. Every data sharing event must produce a revocation reference. Revocation must be testable: can you demonstrate that a downstream system stops processing data within a defined window after a revocation signal is issued? If you cannot demonstrate this, you do not have real revocation.
Separate the portability layer from the application layer. The export mechanism should be a system function independent of any single application. Users should be able to export, migrate and delete their data through the portability layer regardless of the state of any individual application that uses that data.
The export button will remain the industry default as long as it satisfies regulators and costs platforms nothing more. Engineers who understand the difference between a download and ownership are the ones who will build the infrastructure that makes the difference real. That work is the technical foundation of The Invisible Data's core argument: data ownership is an engineering problem before it is a policy problem, and solving it requires building systems that make extraction, provenance and revocation structurally inescapable rather than contractually promised.