Once the whole technical system is implemented, it will be trivial to remove that bureaucratic limitation, and somehow it will be sold as better protection for the children.

Since authorities have the power of accessing that data and identify the user who created the certificate, this scheme is not anonymous.

Authorities can access that data via court orders today, or via a global automatic mandatory data sharing law in the future.

In the example of USA, even if for some reason people still trust the current Government (although ICE already accessed private medical records to track and arrest people), I don't see why they should trust all future Governments which will have retroactive access to all that data.

I'd love to buy an ad-free, subscription-free, tracking-free, touchscreen-free car.

The other person already demonstrated a lack of professionalism by sharing unverified AI slop so, in case of conflict, I wouldn't be surprised if they continued acting unprofessionally by spreading false rumors, unnecessarily escalating the situation to higher ups, secretly sabotaging the project, etc.

How do I tell my colleagues to stop contributing unverified AI output without creating tension between us?

I've never did that so far because I feel like I am either exposing their serious lack of professionalism or, if I wrongly assumed it was AI, I am plainly telling them that their work looks like bad AI slop.

I am aware that uneducated children will become everyone's problem sooner or later, but my argument is that, at the end of the day, in practice, like it or not, this is mostly in control of the parents. The root cause is that parents fail to provide education, modals, and preparation for being a balanced and responsible person that can control its own impulses, and now these same parents want to externalize their responsibilities to malicious Governments, at the expense of everyone's rights.

Giving away privacy for just patching one of the symptoms is a ridiculous ask, especially in this political environment, and especially when it could be tackled in different ways that don't imply losing privacy.

In my opinion, people will be unfit and uneducated in the future no matter what we do, and they will choose malicious leaders, and having privacy in that future will be better than not having it.

If it's the latter, how is age verification supposed to help here exactly?

Since you are asking me to give away my privacy under this promise, I'm interested in the details.

Your child, your responsibility, prepare him better for the world or throw the god damn phone to the trash, but please leave me alone.

I had more sympathy for parents with this problem before, but not anymore. If they don't respect my rights, I don't see why I should care about them.

Department of Defense was the actual lie, the newspeak term. They were not really defending anything, they were using military power globally for pursuing economic interests. However, it was easy to convince people that the whole endeavor was a good thing, because defending your country against the baddies is good, and you should support anyone doing that (otherwise you'd be a traitor!). Thank you for your service (defending us).

On the other hand, the term Department of War is hard to sell, because most people don't want to participate in a war or support someone who wants to start one. Thank you for your service... invading other countries? killing and raping innocents? ransacking resources?

This is an irrelevant detail, but if I'd read the title "Department of Defense vs. Meta", I'd first think Meta is leaking confidential info to other countries. However, if I'd read "Department of War vs. Meta", I'd think Meta doesn't want to promote an unnecessary war.

Just to be clear, here I am not concerned about the verifiers, I am concerned about the authority (Government).

> The base registry stores identifiers of issuers and verifiers, not credential holders.

If the verifiers provide the verification tokens to the Government, can't the Government identify the original issuer even if they don't store them? Don't these tokens contain the DID of the issuer? Please correct me if I'm wrong, maybe I didn't get this part right.

> That's not how that works - they can prove they check by showing logs, rather than VPs

Logs can be manipulated, VPs can't. If I had a company and I was forced to verify users, I'd try to store those VPs for as long as possible, for my own protection.

> There's even legal limits on what identifiers they can store and for how long

I was not aware of this. Is that documented anywhere?

The Swiss E-ID system stores people identifiers and token status lists in their so-called "Base Registry". From https://swiyu-admin-ch.github.io/technology-stack/#credentia...

> Decentralized Identifiers (DID) developed by the W3C represent an identifier standard that provides a subject-controlled method for identifying individuals, organizations, or objects online. In the swiyu Trust Infrastructure, DIDs are utilized as a standard identifier for issuers and verifiers. They are centrally hosted on the swiyu Base Registry.

> In this protocol, the trusted authority issues certifications (“trust statements”) concerning the identity (i.e., who is the real-world identity controlling a DID) and legitimacy (i.e., who is allowed to issue or verify credentials of a specific VC schema) about an entity as SD-JWT VC and publishes these trust statements in the trust registry.

> Token Status Lists are signed, maintained and published by the credential issuers but hosted on the Base Registry.

Switzerland is working on a system that does the former, but if Government really wants to identify users, they can still ask the company to provide the age verification tokens they collected, since the Government hosts a centralized database that associates people with their issued tokens.

If your library is used by multiple consumers, forcing all them to migrate is not trivial, no matter how simple the change is.

If your income comes from these customers, it is not a good idea to put every one of them in the situation of having to choose between updating their code or stoping being your customer.