Hacker News Reader

Comment by lyu07282 | Hacker News Reader

The alternative would be to just not do anything and to remove liability from Meta et al. In the world we live in, where competing interests already spent tens of billions to bribe/lobby the EU, we have to be realistic about it.

This open source and transparent ZKP-based approach is extremely surprising to see, publishing a draft in advance and inviting the public to break it so it can be improved? Are you kidding me? What about the billions of private investment in all the companies that offer centralized ID checks like Persona, Socure, ID.me and more? Thats a growing billion dollar industry. They all counted on this as a future market opportunity that the EU just seem to have destroyed at least in the EU?

People fighting against this age id app might be paradoxically useful idiots for billion dollar investments and lobbying efforts. The demos is once again dragged into the trenches to fight a war they don't understand.

View on HN

The main issue appears to be that as per the blueprint user MUST use one of the mandated handsets (iPhone or Android with pre-installed and privileged Google Services) and:

- MUST use either Google or Apple account - must not be banned by the provider or sanctioned in the USA

These issues have been flagged to the devs working on the blueprint since the inception, only to be handwaved away.

Getting banned can happen randomly even if you're not doing anything illegal or wrong (it's enough for a robot to decide you're within the blast radius), getting sanctioned can happen if you're an UN lawyer investigating human rights abuses USA actually likes.

So I do see a problem here.

The technical specifications published online foresee publication of the app also on alternative android stores, but Linux phone users are missing out. Though I guess things could always be extended...

Their security model requires remote attestation. So, open, user-controlled platforms cannot be used. Of course some other future locked-down linux-based OS might be usable.

Remote attestation in theory includes all aosp-compliant attestation implementations (in practice that's GrapheneOS already), but the current project plans and implementation openly reject it.

Only "open" in a twisted sense, and definitely not user-controlled: Remote attestation per definition means to accept only pre-approved operating systems. If anybody builds an implementation, regardless whether it is aosp-compliant or not, this will be excluded, until the App developer or someone in the chain explicitly approves that implementation. That is the whole purpose of that technology. Including GrapheneOS in that pre-approved list just shifts power from Google and the App Developer to GrapheneOS Developers and the App Developer. Nice for GraphenOS, still bad for users and devs of any other OS variant or platform.

> The alternative would be to just not do anything and to remove liability from Meta et al.

Or just give parents easy to use parental controls. But that wouldn't grow the surveillance state.

Or just have parents look after their children.

That’s why they want parental controls that actually work and don’t require the skills of a sysadmin to get right.

Reply on news.ycombinator.com