Restoring privacy and freedom - #23
Conversation
… gatekeepers. Removed knowledge from AVIs of who is using services of which RPs.
|
I strongly agree. with everything in this pr. Twitter is already asking both my money and government ID to verify my age to access some of the content. I refuse to give them that and found a very simple and free solution that is actually very safe and respects my privacy but is somewhat a slippery slope to actually dangerous activities. Since I strive for an accessible and open internet, and region locking being the bane of my existence I refuse to disclose how I did it to a party that would be willing to ban it. But let's just say I feel like a citizen of Russia or China since I have to resort to that. |
| | T-Scy | Scytáles & T-Systems Age consortium | | ||
| | WB | Web Browser (or web app) | | ||
| | ZKP | Zero Knowledge Proof | | ||
|
|
There was a problem hiding this comment.
It might be good to define the word "App" also in this list.
| App/app | Software or application of any kind or implementation method
There was a problem hiding this comment.
As an EU citizen I'd like to strongly urge the authors of this project and all authorities involved to accept this PR, or at the very least seriously consider the changes outlined for README.md. While the PR touches on much more than just the use of Google Play Integrity and/or other proprietary technologies, I'd like to expand a bit on this issue specifically.
I believe most of the people involved are acting in good faith, and I commend you for designing a secure and, if ZK proofs are used, a fully private system. However, we as the EU must not and cannot rely completely on foreign companies and/or governments for systems as critical as this; whether they be American, Chinese, or otherwise. I hope I don't need to explain why, especially in the current geopolitical climate. And while most government systems still use foreign proprietary technology such as Microsoft Windows, steps are clearly being taken to move towards free and open alternatives, so when designing a system from the ground up we should not contribute to the problem.
And as for the argument that this spec doesn't enforce GPI and Member States themselves should choose whether to implement it or not: I think it'd be best to solve the problem at its root here, instead of needing to have this discussion for each and every downstream implementation. Additionally, GPI is the most widely-known and used API of its type. Unless forbidden or strictly recommended otherwise, most downstream implementations would likely default to using it over other alternatives.
---
disclaimer
| requesting age verification SHALL NOT learn the identity of the users from the | ||
| flow, and the parties providing verification SHALL NOT learn the identity of | ||
| the requesting parties, and SHOULD NOT learn the identity of the users if it | ||
| is feasible to avoid that. |
There was a problem hiding this comment.
I think something similar to: "Additionally it MUST NOT be possible to uniquely fingerprint users across services or sessions based upon the age verification method."
This would preclude a UUID representing a user from being embedded in whatever verification method sent to services. It would also even preclude an encrypted UUID that could only be decrypted by law enforcement for example.
There was a problem hiding this comment.
(I see this is already discussed later, but I think it is important to list requirements explicitly together in this regard)
There was a problem hiding this comment.
There should be indeed some additions for at least
- Ensuring users cannot be identified between services as being the same person
- Since the document recommends e.g. banks set up both age verification and identity verification, that it is impossible to create any logs or similar that could be used in combination to identify who identified when for which site's age verification request, maliciously or otherwise.
| User reviews the request details, verifies the information, and confirms the | ||
| transaction to proceed. | ||
| transaction to proceed. The process SHALL be completely offline and not | ||
| transmit any information to any server. |
There was a problem hiding this comment.
Given this proposal this sounds like it may be sufficient for it, but it should be explicitly stated in the requirements that any external verification service, whether public or private, MUST NOT have any ability to track how many times a particular person attempts to verify their age across any/all services, including if they request it at all.
| @@ -473,10 +516,11 @@ minimising data retention. | |||
| * Stored Verification(8b): RPs may optionally store information derived from | |||
There was a problem hiding this comment.
This must be GDPR compliant, it must be possible for users to not be tracked across sessions.
There was a problem hiding this comment.
"RP" refers to 3rd party sites requesting age verification, and they are required to follow the GDPR as it is, and there does not really need to be any additional dictation for how they must do things.
There are quite likely certain things that will be age restricted that may require the user to have an user account, and other things that do not. Up to the RP to decide which is the correct way to implement it within the confines of the GDPR for them.
This just says the RP can store the successful age verification status on the user's account if one exists, which is obvious, of course they can, and they should.
|
Great work!! I'm glad to see all these improvements. Also hope this gets merged! |
|
Any requirements for integrity checks should be removed, and expressly forbidden. Additionally, the requirement for "Proof providers". Only then will the app be compatible with human rights and privacy. |
* state parameter optional * improved description of the DC API * Improvements in text related to Client and Reader authentication * updates on trusted lists * updates based on internal review
| dependency on otherwise unnecessary or unwanted mobile devices to Users, or | ||
| a risk from depending on the significant mobile device vendors abusing their | ||
| dominant roles in the industry and e.g. forcing users to accept their Terms of | ||
| Service or Privacy Policy to verify the integrity of their devices or similar. |
There was a problem hiding this comment.
This last sentence sounds wrong. Is there perhaps a line missing between 387 and 388?
| their mobile device to open the AVI. | ||
| * A text based token containing the same information, to use via copy & | ||
| paste or similar functions, using e.g. Base64 encoded JSON, or Base45 encoded | ||
| CBOR as in the EU COVID passports. |
There was a problem hiding this comment.
Do you mean "EU Digital COVID Certificates"?
|
I strongly support this Pull Request as it directly addresses the fundamental flaws and user concerns originally raised in the now-closed Issue eu-digital-identity-wallet/eudi-app-android-wallet-ui#287. Simply closing that issue did not solve the underlying problem; it only silenced the symptoms. As a citizen and user, I want to emphasize that the current reliance on Google Play Integrity is a "digital shackle" that effectively blackmails citizens into using proprietary US-based ecosystems. It is unacceptable that a European sovereign identity solution requires the approval of a third-party corporation’s TOS to function. This PR is a vital technical step toward restoring the "Knowledge of Usage" privacy and enabling the use of hardware-backed open standards. This is the only way to ensure that users of privacy-focused operating systems like GrapheneOS are not treated as second-class citizens. Please move forward with these changes to ensure that European digital identity remains independent, inclusive, and truly sovereign. |
|
I totally agree with @fullperm-alpha! It is not a backdoor, it is a back-BARN! |
|
I totally agree with @fullperm-alpha too. If the EU aims to deliver a credible, future-proof digital identity, it must decisively reduce critical dependencies on US technologies and prioritize open, auditable, and sovereign solutions developed and governed within Europe. I therefore strongly encourage moving forward with this Pull Request. It is an essential step toward ensuring that European digital identity remains independent, inclusive, and truly sovereign. |
|
how about we as a society plainly reject and abolish these fascist advances? how on earth is anybody here even considering to show papers to use the web? grow some spine folks. nitpicking about specs is gonna get you the perfect ibm punched cards. nothing else. |
Sorry you feel the need to comment without knowing what you're commenting on. This PR is to reject the fascist advances, not to nitpick about specs. |
I don't think it was his intention to diminish your efforts but rather just to add bit of good old fashioned civil disobedience to the mix 😃 Edit: Again also without any kind of bad intention towards you or your work i think it is actually not entirely baseless for him to point out that constructive involvement in a project such as this is kind of a double edged sword. On one hand being constructive is generally a good thing but on the other it also somewhat legitimizes the matter at hand in a context such as this. One has to think of it kind of like a negotiation where the ideal outcome is always maximalist and prematurely settling for anything less than that is pretty much not only somewhat self defeating but also nudges people towards consciously centering around trying to make a bad thing less bad instead of trying to remove the bad thing. Besides that it is sadly quite probable that no feedback - regardless of how minimalist or maximalist - having any kind of relevant impact whatsoever will be taken into account anyways, which again casts doubt on why concessions should be made at all. In the end we are obviously all in the same boat though. |
| As it is blatantly clear that the members of the EU are regularly attempting | ||
| to destroy the right to privacy and security of its citizens, by e.g. | ||
| attempting to destroy the security of encryption and mandating "master keys" | ||
| or other backdoors to services, additional security measures SHALL be |
There was a problem hiding this comment.
Remove the charged language, it's not relevant to the specification.
There was a problem hiding this comment.
not relevant to the specification
are you relevant? or are you a good slave?
There was a problem hiding this comment.
No, he is right. Charged language isn't a good fit for a technical spec. We can voice our hate of certain powers within the EU that want to undermine privacy, but this isn't the place for it.
| status list may be utilized as an effective solution for managing the | ||
| revocation status of attestations. | ||
| single-use credential and remain valid for a minimum period of three (3) | ||
| months from the date of issuance, since Users tend to not de-age. If a |
There was a problem hiding this comment.
Avoid being snarky on the specification.
There was a problem hiding this comment.
Avoid being snarky
"please don't call out horse shit for what it is. all hail EU!"
There was a problem hiding this comment.
Again, he is right. In this case I find the proposal funny, but it's snarky, and that gives people grounds to not accept it when searching for a reason.
| * An Age Verification App made available as a mobile application SHOULD be | ||
| published on the App Stores for Android and iOS operating systems and MAY be | ||
| published on other App Stores (e.g. Huawei, Samsung). | ||
| * An Age Verification App SHALL be made available as a web application that |
There was a problem hiding this comment.
Not sure if it's technically feasible to to device attestation from a web app. Are the webauthn APIs within the browser enough? I actually don't know.
There was a problem hiding this comment.
The whole idea of device attestation is DRM. All it does is remove control from the user, on a device they should be owning, which significantly degrades security. Remote attestation should be banned, not embraced.
There was a problem hiding this comment.
A truly secure system does not rely on 'attestation'. It is possible, for example, to require a government-issued ID chip to sign the age proof, and that is compatible with a libre host PC.
There was a problem hiding this comment.
Yeah, HSMs and smartcards can definitely be used here. They could even have NFC, to make things more convenient.
19 participants
There may be additional changes required to complete the changes here.
Not accepting, declining, or deleting this PR is confirmation that the authors are willingly complicit in the destruction of the privacy of EU citizens, and building additional strong dependencies on identified gatekeepers under the DMA.