Why changing one checkbox cannot repair an extractive system
The internet has developed an extraordinary faith in the checkbox.
A website may depend on cloud infrastructure scattered across several physical locations, load software written by companies the visitor has never heard of, measure behaviour through an analytics service, call an external font library, display a map from another provider, run a security service at the edge of the network, and send selected events into a customer-management system. Somewhere inside this arrangement there may be several contracts, databases, processors and technical teams, with machines exchanging information in fractions of a second.
The human being, meanwhile, receives a rectangle containing three choices: Accept all. Manage preferences. Reject optional cookies. That rectangle has acquired a remarkable amount of moral responsibility. It is expected to compress an entire technical architecture into a moment of individual choice and, somehow, transform whatever happens afterwards into something we meaningfully authorised.
This is not an argument against consent, nor is it an argument that every analytics service, software library or cloud provider is secretely plotting our downfall. Digital systems need infrastructure. Websites need servers. Applications need to communicate. Organisations need to understand whether their services work. Some data processing is genuinely necessary, useful and proportionate.
The problem begins when we confuse the interface through which a decision is expressed with the system that decision activates.
That distinction matters because European data-protection rules already expect privacy to extend much further than the checkbox. The European Data Protection Board’s 2026 summary on data protection by design and by default describes privacy protection as a mandatory and continuous responsibility: it should be built into systems before processing begins and reconsidered as technologies, purposes and risks change. One of the practical questions it recommends is disarmingly simple: can we design this to use less data?
It is an excellent question. It is also one the average person cannot answer from a cookie banner, because by the time the banner appears, an enormous number of architectural decisions have already been made.
So perhaps we should start somewhere less abstract.
Let us check the weather.
1. A weather app would like to know where you are
There is nothing inherently sinister about a weather application asking for our location. If we want to know whether it will rain where we are standing rather than somewhere 400 kilometres away, the application needs some way of determining approximately where “here” is. France’s data-protection authority, CNIL, uses weather services as a straightforward example of legitimate geolocation use: navigation, mobility, local weather and certain safety functions all depend upon location.
The same regulator also points to the other side of the relationship. Location has considerable economic value, and information generated through mobile applications can circulate into advertising and other commercial ecosystems far beyond the immediate function that caused it to be collected. CNIL’s July 2026 guidance specifically notes that a weather or sports application might need a location to provide its service while also using or sharing geolocation information as part of an advertising-funded model.
Already we have two very different versions of the sentence “the weather app uses my location.”
In the first, the service needs enough information to determine our area, retrieves a forecast and does little more. In the second, location also becomes an input into analytics, advertising, audience measurement or another downstream system. Both may begin with the same tap on Allow location. What happens afterwards depends on the architecture beneath it.
Before location even enters the picture, however, something more basic has happened. Our device has had to find the weather service on the internet. When we type an address into a browser or an application contacts an online service, the device needs to locate the machine that can answer. Human beings prefer names such as example.com; networks ultimately route traffic using numerical addresses. The Domain Name System, or DNS, performs part of that translation. We can think of it loosely as one of the internet’s distributed address books, although—as with most internet metaphors—the real machinery becomes more complicated as soon as somebody asks a second question.
Once the destination is found, the device establishes a connection and sends a request. On a properly configured modern website, this should occur over HTTPS, using encryption to protect the contents travelling between our browser and the service against many forms of interception or alteration in transit. This matters enormously. Without transport encryption, passwords, form entries and page contents would be much easier for somebody observing the network to read.
But there is a distinction that privacy marketing sometimes steps around rather delicately: encrypted does not mean invisible.
The destination still has to answer us, and network infrastructure still needs enough information to route traffic. The service receiving the request can ordinarily observe the network address from which the request arrives, whether that is our direct public IP address or the address of an intermediary such as a VPN. The browser may send other technical information, and requests can contain cookies associated with that service. Depending on configuration, information about the page from which another resource was requested may also travel with the request.
This is worth dwelling on because we tend to imagine data collection as an intentional act. We picture ourselves typing our birthday into a form or pressing a button labelled Share location. Yet computers necessarily generate other forms of information simply by communicating. Addresses, timestamps, request details, software characteristics and session information are part of how networks and applications function.
Some of this information is necessary. Some becomes useful for security. Some helps diagnose errors. Some can be minimised. Some may be retained for minutes and some for much longer. Some can be combined with information collected elsewhere.
The privacy question therefore begins to change. It is no longer simply what did I tell the service? It becomes what did the interaction itself reveal?
That distinction is our first loose floorboard.
2. Your location is not one thing
Even the apparently straightforward idea of “sharing location” hides several technical possibilities.
A smartphone can determine location through satellite positioning systems such as GPS, but it does not always rely on satellites alone. Depending on the device, operating system and conditions, location may also draw upon nearby Wi-Fi networks, Bluetooth signals, mobile-network infrastructure, IP addresses and other contextual information. CNIL’s current guidance explicitly describes geolocation as potentially relying on GPS together with IP, Wi-Fi and Bluetooth information.
From the user’s perspective, all of this can be compressed into one moment: Allow this app to access your location? From the system’s perspective, an operating system, application, software components, network infrastructure and one or more online services may all participate in producing and processing the result.
That difference between human-scale simplicity and machine-scale complexity is central to modern privacy.
It also explains why the distinction between precise and approximate location matters. If all a weather application needs is enough information to tell us that rain is approaching Lisbon, knowing which side of the sofa the phone is resting on is not an obvious operational requirement. CNIL specifically recommends selecting a level of precision appropriate to the function and even notes that local processing or a manually supplied postcode can sometimes avoid sending precise coordinates to a remote server altogether.
This is privacy by design becoming tangible. It is not merely a paragraph in a policy. It is a developer, product manager or service owner deciding that a function requiring regional weather does not require an extremely precise history of somebody’s movements.
The same principle works well beyond location. An organisation may need to know whether somebody is over eighteen without needing their exact date of birth. It may need to know a participant’s municipality without requiring their complete home address. A photo application may need access to one image rather than an entire photographic history. An event organiser may need to know that a participant requires an accessibility arrangement without retaining that information indefinitely once the event is over.
These decisions seem small because we encounter them one field and one permission at a time. Taken together, they determine how much raw material enters the information system in the first place.
Once information enters, however, something important happens.
It rarely stays alone.
3. The app is rarely alone in the room
When we open an application, we naturally imagine that we are interacting with the organisation whose name appears beneath the icon. Software architecture is considerably less socially tidy.
Developers rarely write every function of an application from scratch, nor would we want them to. If a team needs maps, authentication, crash reporting, payment processing, notifications, analytics or advertising functionality, it often makes sense to integrate an existing software component rather than spend six months reinventing it badly.
One common form of reusable component in mobile applications is an SDK, or software development kit. An SDK can contain code, libraries and tools that allow developers to add a capability relatively quickly. This is one of the reasons contemporary software is economically possible: applications are assembled partly from layers of reusable technology rather than constructed as isolated little kingdoms.
CNIL notes that common SDK categories include error reporting, audience measurement, advertising, notifications and other technical functions. More importantly, its guidance explains why SDKs matter for privacy: code integrated into an application can have the same software-level access as the rest of the application. If a permission has been granted to the application, integrated SDKs may, by default, have the technical capacity to access the relevant data as well. Whether they actually do so depends upon implementation and configuration, but the visible application boundary is therefore not necessarily the same thing as the data boundary.
The web works differently, but the underlying idea is familiar. A webpage can retrieve scripts, images, fonts, maps, videos, analytics and other resources from domains other than the one we intentionally visited. A reader experiences one page while the browser may be communicating with several technical services beneath it.
None of this is automatically abusive. An embedded video needs to be retrieved from somewhere. A content-delivery network can improve speed and resilience. A crash-reporting system might help developers identify the exact defect that made us shout at the phone yesterday afternoon.
The privacy question is not whether external infrastructure exists. It is whether we understand what information each component receives, why it receives it, whether that information is necessary and what happens afterwards.
This is where cookies enter the story, although cookies have acquired such celebrity in European privacy discussions that one might be forgiven for imagining the entire surveillance economy lives inside a biscuit.
A cookie is, in essence, a small piece of information a browser can store and later return to a service. Because ordinary web requests do not automatically remember that the visitor making one request is the same visitor who made the previous one, cookies are extremely useful. They can keep us signed in, remember a shopping basket, retain preferences and support many entirely ordinary features of the web.
That same continuity is also why cookies became useful for tracking. If a browser repeatedly presents the same identifier, a service can associate several interactions with what appears to be the same browser. If a third-party service is present across many websites, the possibility of linking activity becomes more powerful, although browsers, regulation and industry practices have increasingly restricted traditional forms of third-party tracking.
The important point is that cookies are one mechanism for establishing continuity, not the definition of tracking itself.
Deleting a cookie can remove one identifier. It does not abolish the wider technical and commercial desire to answer a very useful question: have we seen this visitor before?
To understand why that matters, we need to talk about recognition.
4. The internet does not always need your name. Sometimes your coat will do.
Imagine a railway station in which nobody knows our name. Every morning we enter wearing the same unusual green coat. We arrive around 8:17, buy coffee from the same kiosk, usually stand beside the third carriage and return at approximately the same time in the evening.
Nobody needs to know that the person in the green coat is called Sofia to recognise that the green coat keeps returning.
Digital identification can work in a surprisingly similar way.
A service may recognise us because we are logged into an account. That is the obvious case: we have effectively announced who we are. But systems can also distinguish browsers and devices through identifiers that do not themselves contain our civil identity. Cookies can maintain sessions. Applications can use identifiers permitted by the operating environment. Network information contributes context. Browser storage can preserve state.
Then there is the stranger practice of fingerprinting.
Every browser needs to reveal some information in order to function properly. Websites need enough information about capabilities to deliver compatible content. Different characteristics — browser configuration, language, time zone, screen properties, device capabilities and aspects of how content is rendered — can sometimes be combined into a pattern distinctive enough to help recognise a browser.
No single characteristic has to say THIS IS SOFIA’S LAPTOP. Any one trait may be shared by millions of users. The combination can be considerably less common.
This is the moment where privacy stops behaving like traditional identification. For most of human history, identifying someone usually meant connecting information to a name, face, address, number or other explicit identity. Digital systems can obtain considerable value much earlier. A retailer does not necessarily need to know that Browser 8F4 belongs to Elena Martins in order to observe that Browser 8F4 keeps returning to pages about newborn equipment. An advertising system does not need a passport number to conclude that Device 291 appears interested in mortgages.
Recognition can precede identification, and once recognition exists, behaviour can begin accumulating around it.
Suppose the same device appears at one location most nights and another location on weekdays. The evening location may be a home. The weekday location may be a workplace. If the device repeatedly appears beside another device overnight, a relationship may become inferable. If it appears near a particular school each weekday morning and afternoon, another relationship may become plausible. If it repeatedly visits a specialist medical facility, a health-related inference can become possible.
CNIL’s 2026 geolocation guidance makes this point unusually clearly: movement patterns can reveal a home, workplace, interests, relationships and visits to places associated with sensitive characteristics, and even data presented under technical identifiers can sometimes be reidentified by combining location patterns with other information.
None of those facts had to be typed into a profile.
The person never clicked a box labelled Tell us where you sleep.
The system did something more interesting: it observed.
5. The most intimate data may be the data you never gave anyone
Our familiar language about personal data can make information sound rather orderly. We give our name. We provide an email address. We enter our age. We choose a delivery address. Privacy notices reinforce this picture because they often organise information into categories that resemble database columns.
Contemporary systems can produce new information from the relationships between those columns and from behaviour that was never entered into a form at all.
It is useful to distinguish between three kinds of information. Declared data is what we intentionally provide: a name on a registration form, a date of birth in an account, an occupation on a professional profile. Observed data arises through interaction: pages visited, locations recorded, purchases made, time spent or devices used. Inferred data is what a system or analyst concludes from patterns in declared and observed information.
The categories overlap in practice, but the distinction reveals something important. Digital privacy does not concern only what a system knows because we told it. It increasingly concerns what a system can infer because enough traces accumulated around us.
One location coordinate is almost boring: a phone was at a latitude and longitude at 15:11. Twenty thousand coordinates collected over months are something else. Most nights may begin and end at one place, weekdays may cluster around another, Tuesdays might include a particular sports centre and every second weekend might follow the same motorway to another residence.
The dataset does not contain a field labelled daily life.
Daily life nevertheless starts appearing.
The same logic applies elsewhere. An individual purchase can seem trivial; a pattern of purchases may suggest a new child, dietary change, financial difficulty, hobby or major household transition. A single search reveals a moment of curiosity; a sustained search history can reveal interests, intentions or fears a person has never articulated to anyone. Communication metadata can expose relationships even if the content remains encrypted. Timing can reveal routines, while networks can reveal communities.
This is an unusual property of data: sensitivity can emerge through combination.
A street address may be public. The address of a church may be public. Knowing that a particular mobile device spends ninety minutes at that church every Sunday morning introduces a different kind of information. A clinic’s location may appear on a map. Linking a persistent device to repeated visits creates another layer of meaning.
Neither underlying fact needed to be secret for the relationship between them to become intimate.
That is why privacy increasingly resembles network science more than the old metaphor of a locked filing cabinet. The information contained in individual nodes matters, but relationships between them can reveal structures that no individual node contains.
It is also why claims that a dataset is “anonymous” deserve careful scrutiny. Removing names certainly helps, and rigorous anonymisation can genuinely prevent information from being connected back to a person. But replacing a name with an identifier does not automatically produce anonymity if the remaining pattern is sufficiently distinctive or another dataset can provide the missing bridge.
Imagine our green coat again. The station does not know the wearer’s name. Then one morning the person uses a loyalty card at the coffee kiosk.
The coat has met the name.
Digital systems can create equivalent bridges. An identifier that begins life as pseudonymous may later become associated with an account, transaction, email address, telephone number or another dataset. Information gathered in one context can gain identifying power when combined with information gathered in another.
This is why some of the most consequential privacy controversies concern not extraordinary secrets but ordinary information moving through extraordinary machinery.
At the moment of collection, our weather location may simply answer which forecast should we display? Retained over time, associated with an identifier and combined with other sources, the same category of information can begin answering questions nobody ever put to the user: where do you probably live, where do you probably work, which places recur in your routine and what might those places suggest?
The most interesting privacy question is therefore no longer simply what information did you give the system? It is what the system can discover once observation becomes memory and memory becomes pattern.
6. When metadata becomes biography
The word metadata has an almost reassuring dullness to it. It sounds administrative, the sort of thing that belongs in a grey spreadsheet beside “file size” and “last modified.” In technical terms, metadata is information about other information: when something happened, where it came from, which device was involved, who communicated with whom, how long an interaction lasted or which page was requested.
The contents of a message may feel deeply personal, while the metadata surrounding it can appear almost trivial.
Until there is enough of it.
Imagine that we know nothing about the contents of someone’s communications, but we can see that the same device leaves one residential address every weekday at 7:46, arrives in an office district around 8:20, returns home most evenings, visits one medical building twice a month and spends Sunday mornings near the same place of worship. We can also observe that the device frequently spends the night beside one other device and appears near a school at roughly the same times each weekday.
No email has been opened. No photograph has been inspected. No questionnaire has been completed. Yet a surprisingly detailed outline of a life is emerging.
This is why the distinction between content and context matters so much. We naturally treat content as sensitive because content feels intimate: the words we write, the photographs we take, the diagnoses in a medical record. Context can reveal the structure around those things. A communications network can expose relationships without showing what was said. Repeated movements can suggest routines without anyone asking about them. A sequence of transactions can reveal changing circumstances without a profile containing a field labelled life event.
The US Federal Trade Commission’s case against location-data broker X-Mode and its successor Outlogic makes this concrete. The FTC alleged that the companies sold precise location information capable of revealing visits to places including medical and reproductive-health clinics, places of worship and domestic-abuse shelters. Its final 2024 order prohibited sharing or selling sensitive location data and imposed additional requirements around suppliers, downstream use, deletion and retention.
The important thing about this example is not simply that geolocation is sensitive. The sensitivity is created partly by association. A clinic’s address is not secret. A church’s address is not secret. The intimacy appears when a persistent identifier can be connected to visits and then, directly or indirectly, to a person.
We can think of this as the privacy version of a pointillist painting. One dot tells us very little. Thousands of dots create a face.
The technical achievement is not that any individual piece of data suddenly became dramatic. It is that systems became extremely good at connecting pieces that once lived apart.
That is where metadata starts becoming biography.
7. The data broker enters through the side door
Most of us understand the basic social contract involved in giving information directly to an organisation. We open a bank account and expect the bank to know certain things about us. We make a medical appointment and understand that the clinic will possess some health information. We order something online and know that a delivery address has to exist somewhere in the transaction.
The contemporary data economy becomes harder to reason about when information starts moving sideways.
A company may collect information directly from users, but it can also receive information through software partners, advertising systems, public records, commercial datasets, mobile applications and other intermediaries. Data brokers operate in this world of aggregation. Their business is not necessarily to provide the original service that generated the information. It may instead be to collect, organise, infer, categorise or resell information so that it becomes useful in another context.
This is where an apparently insignificant identifier becomes valuable. One organisation may know that an advertising identifier visited a set of locations. Another may know that the same identifier interacted with particular applications. Another dataset may contain household information. A retailer may hold transaction history. A marketing platform may assign audience categories. Individually, these datasets answer narrow questions; combined, they can construct a much richer model of a person’s behaviour, household or likely interests.
The economic logic is relatively straightforward. Information becomes more valuable when it improves prediction. A system that knows only that somebody visited a page can do comparatively little. A system that believes the same person recently searched for mortgages, moved between two cities, purchased nursery furniture and spends weekday mornings around a particular office can make stronger guesses about what that person might do next.
Those guesses are not necessarily accurate. Anyone who has spent three weeks being followed around the internet by an advertisement for the item they already bought knows that the surveillance economy occasionally possesses the sophistication of a Labrador carrying one extremely important sock.
Inaccurate inference is not harmless simply because it is inaccurate, however. Advertising, fraud prevention, risk assessment, recommendation systems and other forms of categorisation can still be shaped by models that are partial or wrong. Privacy therefore intersects with another issue: how systems construct us, not merely how they observe us.
The FTC’s action against Avast is instructive for this reason. Avast sold security and privacy products, yet the FTC alleged that its antivirus software and browser extensions collected detailed browsing information and that its Jumpshot subsidiary sold data derived from that information to more than 100 third parties. The FTC’s 2024 final order prohibited Avast from selling or licensing browsing data for advertising and required a $16.5 million payment.
There is almost too much irony available here. Software installed partly to protect users from tracking became, according to the regulator, part of an architecture through which browsing behaviour was commercialised.
The deeper lesson is not that antivirus software is untrustworthy. It is that product category is not the same thing as operating model. A product may describe itself as private, secure, open, ethical or protective. The useful questions still live underneath: what does it collect, what does the provider do with the information, who else receives it, how long does it remain and what incentives exist around it?
The BetterHelp case reveals another aspect of the same problem. The FTC alleged that the online counselling service used or disclosed information including email addresses, IP addresses and health-questionnaire information to advertising companies despite assurances about how personal health data would be handled. The final 2023 order required $7.8 million in payments and restricted sharing of health data for advertising.
What makes the case particularly revealing is context. An email address is not inherently a medical record. An IP address is not inherently a mental-health diagnosis. Yet those identifiers take on different meaning when attached to somebody seeking counselling or completing a health questionnaire.
A piece of information is therefore not sensitive only because of what it says. It can become sensitive because of where it was collected, why it was collected and what it becomes connected to.
That is a considerably more difficult reality to fit inside a cookie banner.
8. Privacy, security, anonymity and secrecy are not the same thing
Privacy debates become unnecessarily confusing because several different ideas are routinely collapsed into one another.
Imagine an organisation building a database containing extremely detailed information about employees’ movements, family circumstances, communications and health. Technically, the database is excellent. It is encrypted, administrator access requires strong authentication, every access is logged, backups are tested and penetration testing finds no serious vulnerabilities.
From a cybersecurity perspective, this may be a beautifully protected system. From a privacy perspective, we should still ask why the organisation possesses all of that information.
That distinction is fundamental. Security is concerned with protecting systems and information against unauthorised access, alteration, disruption or loss. Privacy asks a broader question about whether information about people should be collected, used, shared and retained in the first place, and under what conditions.
Security can protect a privacy-respecting system. It can also protect an extraordinarily efficient surveillance system.
Anonymity is different again. An anonymous contribution cannot reasonably be connected to an identifiable individual. That can matter enormously for whistleblowing, research, political participation or sensitive support services. But anonymity is not always required for privacy. We expect a doctor to know who we are. We expect an employer to know our identity. We expect a bank to know whose account it is operating. The privacy requirement in those relationships is not that we become nameless; it is that information remains within appropriate boundaries.
Secrecy is narrower. Something is secret when it is deliberately concealed or restricted. The familiar phrase “If you have nothing to hide, you have nothing to fear” quietly transforms privacy into secrecy and then treats secrecy as suspicious.
Almost none of our ordinary privacy practices works that way. We close curtains without assuming the living room contains criminal activity. Doctors conduct consultations in private rooms. Lawyers protect confidential communications. Children keep diaries. Organisations restrict salary records. Researchers limit access to identifiable participant data. Couples have conversations that are not public meetings.
We do these things because different relationships require different boundaries, and those boundaries are part of what allows the relationships themselves to function.
9. “Nothing to hide” misunderstands what privacy is for
There is a reason the “nothing to hide” argument remains attractive. It turns an enormous structural problem into a simple moral test. If observation is dangerous only to people doing something wrong, privacy becomes the concern of the guilty and everyone else can relax.
Human beings do not behave that way.
Imagine writing a private message while your employer stands behind your chair. Imagine searching for information about a health concern while your family watches the screen. Imagine discussing an unpopular political idea in a room where every sentence will be recorded, made searchable and permanently attached to your identity.
Even if nobody ultimately punishes you, the environment has changed. You may still speak, but you may speak differently.
This is why privacy has a civic dimension. Democracies depend not only upon a formal right to speak but upon spaces in which people can develop thoughts before speaking publicly, associate with others, seek advice, investigate institutions, consult lawyers, contact journalists, organise politically and change their minds.
Privacy connects here with architecture in a way we do not discuss often enough. A private room and a public square produce different forms of behaviour. Neither is inherently superior. We need public spaces because democratic life depends upon visibility, encounter and collective action. We need private spaces because intimacy, experimentation, reflection and uncertainty require boundaries.
A functioning society contains both.
Digital systems increasingly blur that distinction because activities that once disappeared can now be recorded, retained, searched and combined. Reading a political pamphlet in a library once left relatively little trace. Reading its equivalent online can generate requests, timestamps, account activity, analytics events and other technical records depending on the system. Visiting a shop once created a fleeting encounter with a cashier. An online store can potentially remember every product considered and every interaction leading up to a purchase.
The difference is not that digital technology is uniquely evil. It is that memory has become cheap and observation has become scalable.
Historically, forgetting acted as a form of social friction. Not every awkward question, temporary interest, failed relationship or half-formed political idea became part of an indefinitely reusable behavioural archive. Digital environments can invert that default, preserving traces because the technical cost of retention is small and the possible future value of information is uncertain.
The civic question is what happens when people begin behaving as though systems might always remember.
That is where privacy stops being merely a consumer preference and begins to look like part of the infrastructure of autonomy. A society in which people can never meaningfully step outside observation may remain formally free while becoming behaviourally narrower.
That is a very different problem from having something to hide.
10. We built an extraordinarily complicated system and gave the user homework
Once privacy is understood at the level of infrastructure, something about the modern privacy interface starts to look slightly absurd.
Consider how we approach safety in the physical world. A building owner cannot reasonably install unsafe electrical wiring and then solve the problem by asking every visitor to inspect seventeen switches before entering. We do not regard a theatre as safe because every member of the audience has personally reviewed the fire plan. A car manufacturer cannot compensate for defective brakes with an especially informative consent form.
Good systems reduce the number of dangerous decisions ordinary people have to make.
Digital privacy has often evolved in the opposite direction. The architecture becomes more complicated while the user acquires more responsibility. We are expected to understand location permissions, advertising identifiers, cookie categories, processing purposes, privacy notices, browser controls, app permissions, third-party sharing, retention periods, account settings and whatever entirely new category appears after the next software update.
There is nothing wrong with giving people control. The mistake is confusing control with burden.
A privacy-respecting system should not require users to become amateur forensic engineers merely to avoid excessive collection.
This is precisely the logic behind data protection by design and by default. The EDPB’s 2026 guidance presents it as a continuous responsibility rather than a decorative compliance exercise. Organisations should consider minimisation, access, security and other protections when selecting and designing processing methods, then continue reviewing them as systems and risks evolve.
That changes the conversation. Instead of asking only whether a user consented to precise location, we can ask whether precise location was necessary. Instead of asking how long we are permitted to keep a dataset, we can ask how long the service actually needs it. Instead of collecting everything and surrounding the resulting pile with increasingly sophisticated safeguards, we can reduce the amount of information entering the architecture in the first place.
This resembles a familiar principle from safety engineering: where possible, eliminate a hazard at its source rather than relying exclusively on protective layers around it.
Privacy can work the same way.
An organisation can spend substantial resources encrypting, auditing, controlling access to and eventually deleting a particular field of personal information. If that field was never necessary, it has another option: do not collect it.
The European Commission describes this formally as data minimisation: personal information should be adequate, relevant and limited to what is necessary for a defined purpose. It also links privacy by default with restricted access and shorter retention.
There is a simple idea underneath all of this that we will return to later: sometimes the safest piece of personal data is the one that never enters the system.
That does not mean individuals should simply shrug and wait for every organisation on Earth to redesign itself. There are meaningful places where we can intervene today, provided we understand which layer we are actually changing. Some actions prevent information from leaving a device; some make tracking more difficult; some protect accounts; some change what a network intermediary can observe; and some simply move trust from one organisation to another.
The distinction matters because the privacy industry has occasionally learned the same trick as the wider technology industry: offer one reassuring button for a problem that actually has several layers.
So before we turn the perspective around and examine organisations, we need to answer the practical question privacy writing too often saves for three hurried paragraphs at the end: where can an ordinary person actually interrupt the data journey?
11. Where an ordinary person can actually interrupt the data journey
By this point, privacy can begin to sound depressingly infrastructural. If information passes through operating systems, browsers, applications, networks, analytics platforms, identifiers and organisations we have never heard of, it is reasonable to wonder whether an individual has any meaningful control left.
We do, but not through a single magical setting. Practical privacy works by intervening at different points in the journey, and some interventions are especially valuable because they occur before information travels further into the system.
The strongest place to begin is often the device itself. Modern mobile operating systems increasingly allow people to restrict location to periods when an application is in use, choose approximate rather than precise location and revisit permissions after they have been granted. CNIL explicitly recommends these approaches and advises users to disable unnecessary geolocation, review permissions regularly, remove unused applications and limit advertising tracking where possible.
Those choices look small because they appear as switches in an operating-system menu, but technically they can change everything downstream. If an application never receives continuous precise location, that information cannot later be transmitted by that application into an analytics system, associated with an identifier or retained in its database. Privacy has improved not because six organisations were asked to behave responsibly with the information but because less information entered the relationship in the first place.
A useful change is therefore to stop asking only do I trust this company? and ask does this particular function genuinely require this permission? Trust matters, but necessity is often easier to reason about. Navigation requires location while navigating. A weather service may require an approximate area. A photo-editing application requires access to the photographs we want to edit. None of those purposes automatically establishes a permanent claim over every location, image or contact stored on a device.
The browser provides another intervention point. Tracking protection, restrictions on third-party state and reputable content blockers can reduce the number of requests made to external tracking services. The architectural distinction matters: preventing a request from occurring is different from allowing information to leave and relying entirely on downstream promises about how it will be used. Browser protections do not make fingerprinting impossible and should not be marketed as invisibility cloaks, but reducing persistent identifiers and unnecessary third-party communication still changes the ease with which behaviour can be connected across contexts.
Account security belongs in this conversation as well, even though it solves a different problem. An attacker who takes over an email account can often recover passwords elsewhere, read private communications and gain access to documents far more efficiently than any advertising network could infer them. Unique passwords, a reputable password manager, multifactor authentication, timely updates and device encryption protect the boundary around information we intentionally entrusted to systems. They do not fix an extractive business model, but they help prevent somebody who was never part of the relationship from entering it.
VPNs are useful precisely because they demonstrate why privacy tools should be understood by layer. A Virtual Private Network changes the network path. Websites generally see the VPN service’s public address rather than the user’s home address, while traffic between the device and VPN is protected inside an encrypted tunnel. That can be useful on untrusted networks and can change what a local internet provider directly observes. It does not make us anonymous to a service we deliberately sign into. If we log into a social network through a VPN, the social network has not developed amnesia. The network layer changed; the account layer did not.
Encrypted DNS similarly protects a particular part of the journey rather than transforming the whole internet into private space. Tor can provide much stronger anonymity properties for use cases where that is genuinely required, including journalism, activism and work under repressive conditions, but ordinary privacy should not be framed as a requirement that everybody adopt the operational habits of an intelligence service just to check a restaurant menu.
End-to-end encrypted communications provide another useful architectural example. Properly implemented end-to-end encryption is designed so that readable message content remains available only at the communicating endpoints rather than being available in plaintext to the intermediary carrying the messages. That substantially changes who can access content. It does not necessarily eliminate every form of metadata surrounding the communication, such as timing or account relationships.
Nuance is not a defect here. It is the difference between understanding a technology and treating it as a talisman.
Service choice matters too. The previous article in this series, Free Is Not the Same as Open, explored how product labels can conceal very different operating models. The same is true of privacy. A commercial service can have a strong privacy architecture. An open-source service can be configured to collect extensive telemetry. A hosted open-source service can still rely on third-party analytics, and a poorly maintained self-hosted server can be substantially less safe than a professionally operated service.
Open source can nevertheless change the balance of control. Code may be inspectable. A service may be self-hosted or moved between providers. Community scrutiny can expose behaviour that would otherwise be difficult to inspect. Data formats and migration routes may be more open. Those are meaningful possibilities because privacy is partly about controllability.
Open source is not, however, a privacy certificate. A self-hosted server that nobody updates is not a triumph of digital autonomy. It is a neglected computer with philosophical ambitions.
Finally, one of the least fashionable privacy technologies remains extremely effective: deletion. Most of us have acquired a digital attic containing old travel applications, conference platforms, abandoned productivity tools, fitness services and accounts created during a brief Tuesday-afternoon conviction that this particular app would transform our life. Those systems may still contain contact details, documents, location histories or other information. Where an account no longer provides meaningful value, exporting anything worth preserving and closing the relationship reduces the number of places in which information continues to exist.
We clean physical cupboards because objects accumulate. Data accumulates too. The difference is that old shoes rarely participate in a data breach.
12. The most useful privacy question is not “Am I safe?”
Privacy advice often ends badly because it promises a state that does not really exist. Words such as safe, private, anonymous and protected sound reassuringly final. Actual privacy is contextual.
The sensible level of protection for checking tomorrow’s temperature is different from the level required by a journalist communicating with a confidential source. A family photograph creates a different risk from a database containing information about people using a domestic-abuse service. The same person can move through several of these contexts in one day.
A better question is therefore: does this system need to know this in order to do what I am asking it to do?
That question moves us away from fear and toward proportionality. If a weather service needs our town, giving it the town can be entirely reasonable. If navigation requires precise location during a journey, the connection is obvious. If an online retailer needs an address to deliver something, that relationship is straightforward.
The question becomes more interesting when the relationship between information and purpose weakens. Why does an application require the entire contact list? Why should precise location remain available while an application is not in use? Why does a simple website need several external analytics systems? Why must an exact date of birth be collected when an age band would accomplish the same purpose? Why does an account created for a one-day event need to remain indefinitely?
These are not anti-technology questions. They are design questions.
They return us to data minimisation, one of the least glamorous and most powerful ideas in privacy engineering. From a privacy perspective, unnecessary data means unnecessary exposure. From a cybersecurity perspective, it means more information available to steal. From an engineering perspective, it increases complexity. From a governance perspective, it creates additional access, retention and deletion decisions. From an economic perspective, it can generate management and compliance costs.
Collecting everything “just in case” can therefore feel sophisticated while quietly producing a more expensive and fragile system.
For decades, technological progress rewarded the ability to remember. Storage became cheaper, databases became larger and analytics became more powerful. Organisations learned that information might possess future value, so the rational instinct was often to retain it.
A more mature digital culture may need to develop the opposite capability as well: knowing when not to know.
That is why the safest piece of personal data in a system can sometimes be the one that never entered it.
For an individual, this principle helps us make better choices about permissions, tools and accounts. But there is an uncomfortable twist waiting underneath it, because most of us are not only people whose information is processed. We also work somewhere. We organise events, manage mailing lists, recruit staff, teach students, support beneficiaries, communicate with clients, administer websites, conduct surveys, share documents and increasingly use AI systems to help with all of these activities.
At some point during the working day, we cross to the other side of the privacy relationship. The weather app stops being the system observing us.
We become the weather app.
And the question changes from how do I protect my data? to something considerably more consequential: what happens to everybody else’s information once it enters our organisation?
he checkbox was only the beginning.
For individuals, privacy often begins with permissions, browsers and better choices. For organisations, the problem becomes much more structural: where data travels, who can access it, which suppliers receive copies, what sits inside logs and backups, what enters AI systems, how long information survives, and whether deletion really means deletion.
In the professional part of this article on REDefine // Civic Intelligence, we move beneath the interface and into the organisation itself. We unpack how to map real data flows, reduce unnecessary collection, govern suppliers and access, manage AI exposure, design retention and deletion properly, and build privacy into the infrastructure rather than leaving it to policy language.
Paid subscribers also get access to the REDefine Data & Privacy Infrastructure Map, our 21-page fillable working tool for examining a digital system from data collection all the way to deletion, exit and organisational risk.
Subscribe on Substack to continue reading the professional section and access the practical resource.
