Brazil’s current debate over online safety has a curious feature: many of the most consequential proposals do not begin with surveillance as their stated objective. They begin with protection.
The ECA Digital asks technology companies to create safer experiences for children and teenagers and, in some circumstances, to reliably determine whether a person is old enough to access a product, service or category of content. Regulators are asking platforms to do more when foreseeable harms emerge. Courts continue to examine when investigators may obtain data that can connect online activity to a person. None of these questions is trivial, and none is solved by simply invoking privacy as a reason to do nothing.
Children do need meaningful protection online. Fraud victims should have effective remedies. Companies should not be able to ignore serious abuse because addressing it is technically inconvenient. Law-enforcement authorities need lawful ways to investigate serious crimes, particularly when life or physical safety is at risk.
The difficult part starts one step later, when a legitimate objective has to become a technical system. A law can describe a purpose narrowly. Software cannot implement a purpose; it implements capabilities. If a service must know whether someone is an adult, something must be built to establish that fact. If a platform is expected to prevent a class of abuse, something must be able to identify the signals associated with it. If an authority may obtain information under certain circumstances, the relevant information must exist somewhere and there must be a path through which it can be obtained.
That is where privacy questions become more interesting than the usual argument over whether a policy is well intentioned. The question is not only what a new power is for. It is what must exist for that power to work, what else that infrastructure makes possible, and whether the limits are embedded in the system or left entirely to promises about how it will be used.
Age assurance is a useful place to start
Age assurance is one of the clearest examples because there is no technically honest way around its central tradeoff. If a service genuinely needs to distinguish a 15-year-old from a 25-year-old, the user has to prove something, or a system has to infer something, about age. A checkbox saying “I am over 18” does not provide meaningful assurance. A reliable answer requires evidence.
That evidence might come from a government-issued document, a digital identity credential, an account whose age has already been established elsewhere, or an estimate derived from a photograph of the user’s face. Other methods may emerge, and different contexts will justify different levels of confidence. But there is no privacy-preserving trick that allows a system to know an attribute without receiving any basis for knowing it.
This matters because a weak criticism of age assurance is easy to dismiss: we should verify age without asking users to prove anything. We do not think that is a serious position. If society decides that certain services must distinguish adults from minors, some proof is unavoidable.
The real privacy question is narrower and much more useful: how much should a person have to reveal in order to prove only the fact that matters? A website that needs to know whether someone is at least 18 does not automatically need that person’s full legal name, CPF number, exact date of birth, home address or a permanent copy of an identity document. It may need confidence in the proposition that the person is an adult. Those are not the same thing.
That distinction is already visible in Brazil’s own implementation of the ECA Digital. The regulatory framework does not treat age verification as permission to collect identity without limits. The March 2026 decree defines an age signal as information or a credential that attests to a user’s age or age range without revealing additional personal data. It requires age-assurance mechanisms to follow data-minimization principles, prohibits the continuous and unrestricted sharing of personal data, and prohibits traceability of a citizen’s identity and history of accesses, requests and verifications. Where documents are used, the decree says that processing should be limited to the age information that is necessary and that the image or copy of the document should not be retained after that information is captured. For age signals shared by operating systems and app stores, the regulation also prohibits sending an exact date of birth, civil identity or profiling data.
Those safeguards are not a minor detail. They show that the choice is not necessarily between reliable age assurance and privacy. The law itself is attempting to separate the proof of an attribute from the disclosure of an identity.
Whether implementations will consistently achieve that standard is a different question, and it deserves scrutiny. But it is worth recognizing good architecture where the framework is clearly asking for it.
Proving an attribute is not the same as identifying a person
This distinction has existed in security engineering for a long time. Many systems ask for more information than the decision actually requires because collecting the full record is easier than designing a narrower proof.
Age is an attribute. So is residency, membership, professional qualification or possession of a particular entitlement. In each case, the relying service may need confidence that a statement is true without needing every piece of information that was originally used to establish it.
A credential issuer could, for example, verify a person’s age once and issue a credential that allows another service to verify only that the required threshold has been met. Selective-disclosure systems can reveal one attribute while withholding unrelated fields. Depending on the system, cryptographic proofs can go further and allow a condition to be demonstrated without disclosing the original value behind it.
None of this eliminates the initial verification. Somebody still has to establish that the person satisfies the condition. If that process involves a passport, the passport was processed. If it relies on facial age estimation, an image of a face was processed. Calling a system “document-free” does not make it data-free, and replacing an identity document with biometrics can introduce a different category of sensitivity rather than making the privacy problem disappear.
The benefit comes from what happens next. The site that only needs an age threshold does not also receive a reusable identity dossier. The same document does not have to be uploaded to every unrelated service. A verifier does not necessarily need to learn every place where the credential is presented. Presentations can be designed to resist correlation. Sensitive evidence can be discarded instead of becoming another permanent database waiting for a breach, misuse or future expansion of purpose.
This is a more demanding design problem than simply collecting a driver’s license and storing a boolean field on an account. It is also a much better expression of what privacy by design is supposed to mean.
The hard part is not the first use
The same reasoning applies beyond age assurance. Public debates usually focus on the first and most sympathetic use of a new capability. A mechanism is proposed to protect children, stop a particular form of fraud, find a person in immediate danger or address a category of serious criminal conduct. The use case can be compelling enough that discussion about the underlying infrastructure feels secondary.
Security engineering teaches the opposite instinct. A new capability should be evaluated not only according to the administrator who introduces it today, but according to everyone who could control it later and every adjacent use that becomes technically possible once it exists.
This does not require assuming that the government, regulator or company introducing a system has a hidden motive. Bad architecture does not require bad faith. Institutions change, legal interpretations change, companies are acquired, emergencies end, and categories created for one purpose can be broadened later. A capability that was expensive or impossible before a system existed may become routine after the system is deployed.
We already accept this logic when evaluating private companies. A service does not deserve to be called secure merely because it has a policy telling employees not to look at sensitive information. We ask why those employees can access it, whether the access is logged, whether the data had to be retained, whether encryption can narrow the number of people capable of seeing it and whether the system can be redesigned so that trust is less necessary.
The same discipline should apply when the capability is created in response to public policy. A legal restriction is important, but a legal restriction and a technical impossibility are not equivalent safeguards. If the architecture makes unnecessary correlation difficult, collects less data, separates contexts and deletes sensitive evidence quickly, fewer future actors have to be trusted. If the architecture is built for maximum visibility and the only protection is a rule saying that visibility will be used carefully, the system is depending on governance to compensate for an avoidable technical power.
Good governance matters. It is simply stronger when the infrastructure does not make abuse easy.
Metadata makes the distinction visible
Brazil’s recent discussion over access to internet records illustrates the same issue from another direction. The Supreme Federal Court has been examining the limits that apply when authorities seek to correlate subscriber information with connection or application-access records. In the ADC 91 proceeding, the debate has included the role of prior judicial authorization and whether narrowly defined emergency circumstances can justify direct access followed by judicial review.
The legal question matters because traffic metadata is often treated as less sensitive than content. It is true that an IP address, timestamp or account identifier is not the text of a private message. But that does not make the surrounding information harmless. Correlated over time, metadata can reveal routines, associations, services used, patterns of movement and relationships between people. It can help turn otherwise abstract activity into an identifiable person.
For privacy engineering, the first question is therefore not only who may request a record. It is also why the record exists, how long it remains available, which identifiers can be correlated, and whether every system involved needs to preserve the same linkability.
Judicial authorization, necessity tests, emergency exceptions and later review are questions of lawful access. Data minimization, separation and retention are questions of architecture. A durable privacy framework needs both.
This is especially important because governments are not the only actors that can misuse a rich dataset. The same information can be exposed by a breach, abused internally, demanded under another legal theory or repurposed by a company that changes its business model. A dataset that never needed to exist creates none of those risks.
Platform accountability creates similar pressures
There is a parallel debate around what platforms should be expected to do before harm occurs. It is no longer credible for a large service to claim that its only responsibility begins after somebody files a report. Platforms influence distribution, recommendation, discovery, contact between users and the speed at which harmful activity can spread. They can and should design reporting systems, escalation procedures, anti-abuse controls and product safeguards that reflect the risks they create.
The privacy problem appears when “do more” is translated too casually into “observe more”. There are many forms of proactive safety engineering that do not require universal inspection. Rate limits can constrain abusive automation. Reputation systems can evaluate risk without exposing all content. Reporting flows can preserve evidence when a user chooses to report abuse. Known malicious artifacts can sometimes be detected through narrow technical signals. Product design can reduce unsolicited contact, restrict risky defaults and create additional friction around high-risk actions. These approaches have tradeoffs, but they demonstrate that safety is an engineering space, not a binary choice between total visibility and total inaction.
Other proposals can be much more invasive. A requirement that effectively demands universal inspection of private communications, persistent identity for ordinary activity, or a general ability to bypass encryption changes the nature of the system for everyone, not only for the people whose conduct motivated the rule.
That difference deserves more attention than it often receives. “Platform accountability” describes an objective. It does not specify an architecture. Two systems can pursue the same legitimate goal while producing radically different amounts of surveillance capacity.
For encrypted services in particular, the distinction is foundational. If a platform has been built so that it does not possess the keys necessary to read user content, creating a new inspection path is not a minor moderation feature. It changes the security model. Once the capability exists, the debate is no longer only about the category of abuse that justified it; it is about who can invoke the capability, how it is protected, what happens when an attacker reaches it, and whether future rules can require it to be used for something else.
This is why “we will only use it for serious cases” is an incomplete security argument. It may be a sincere policy. It is not a property of the system.
The limits should be part of the design
There is a constructive lesson in all of this, and Brazil’s age-assurance rules already point toward part of it. When a new capability is genuinely necessary, the system should be designed with its limits at the same time. If a service needs proof of adulthood, the default should be the smallest useful proof rather than full identity. If a credential is reusable, its presentations should not quietly become a cross-service tracking mechanism. If a document is needed briefly to establish a fact, there should be a strong reason before the document itself becomes a retained record. If an emergency access route exists, the route should be narrow, auditable and difficult to normalize into ordinary access.
The same principle applies to platform safety. Define what a mechanism is trying to detect, which signals it truly needs, how false positives can be contested, what is retained and what stays outside the system. For measures that affect private communications or identity, the burden should be higher precisely because the infrastructure created for compliance may become useful for purposes that were never part of the original debate.
This is not an argument that every safeguard can be enforced cryptographically. Law, courts, oversight, organizational controls and public accountability remain necessary. Some abuses are social or institutional rather than technical, and no protocol can solve them on its own.
But technical limits are valuable because they reduce how much perfect behavior we have to assume from every future participant. We use access controls because policies can be violated. We use encryption because databases can leak. We minimize data because organizations can change. We design systems around least privilege because trusted people and trusted processes sometimes fail. It would be strange to take those principles seriously inside a security product and abandon them when designing the infrastructure through which millions of people will prove who they are, what they are allowed to access or how their online activity can be connected back to them.
Privacy is not a veto on public policy
Privacy advocacy becomes less credible when it treats every regulation as censorship, every safety mechanism as surveillance, or every request for evidence as an attack on anonymity. There are situations in which a platform should know something about a user. There are situations in which a company should preserve evidence. There are circumstances in which investigators should be able to obtain information through lawful process. There are products that should not be available to children, and saying so requires some way of distinguishing children from adults.
Acknowledging those facts does not weaken the case for privacy. It makes the case more precise.
Privacy is not the proposition that systems should know nothing under all circumstances. It is the discipline of asking what needs to be known, by whom, for how long, for which purpose and with what ability to reuse or correlate it later. It is also the recognition that collecting information changes the risk of a system even when everyone involved at the time of collection intends to behave responsibly.
That is why we think the most important part of the current Brazilian debate is not whether the objectives behind these policies are good. In many cases, they clearly are. The more consequential question is whether the infrastructure built to pursue them preserves the same restraint that the policy claims to have.
The ECA Digital’s approach to age signals is interesting precisely because it attempts to make that restraint explicit: establish age when necessary, but do not automatically turn the result into civil identity, exact birth date, profiling data or a record of where the person has used the proof. Those protections will only matter if the systems deployed in practice preserve them, but the architectural direction is the right one.
Other areas deserve the same standard. Access to internet records should remain constrained not only by legal procedure but by sensible retention and minimization. Platform-safety obligations should be assessed not only by whether their goal is legitimate but by whether compliance demands general-purpose surveillance. Exceptional mechanisms should be evaluated as capabilities that may outlive the circumstances that introduced them.
The infrastructure remains after the debate moves on
Public controversies move quickly. Infrastructure does not.
The political argument that creates a system may be forgotten a few years later, while the databases, interfaces, identity signals, logs and access paths created in response become ordinary parts of the internet. Future governments inherit them. Future companies integrate them. Future laws discover that they exist.
That does not mean we should refuse to build anything powerful. Modern societies depend on powerful infrastructure. It means that the power itself deserves the same threat modeling we would apply to any other security-sensitive system.
When a new capability is necessary, we should ask how narrowly it can be built. When personal data is necessary, we should ask how quickly it can stop being necessary. When an identity attribute is sufficient, we should resist turning it into an identity dossier. When lawful access is justified, we should preserve the difference between exceptional access and routine observability. And when a policy depends on a promise that a capability will never be used beyond its original purpose, we should ask whether part of that promise can be enforced by architecture instead.
Good intentions are valuable. They are also temporary. The systems created in their name can last much longer, which is why the infrastructure of good intentions deserves scrutiny of its own.