612
Stop Killing The Internet: No Digital ID & No Age Verification | European Citizens' Initiative (citizens-initiative.europa.eu)
submitted 1 month ago by to c/technology@lemmy.world
33 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 0 points 1 month ago (4 children)

Honestly I think what is needed here is something similar to TLS: build a chain of trust with multiple "authorities" that can validate your age.

Then we can potentially have open identity issuers that validate age, minimum/no logging, ram servers, periodic power cycles, and independent audits. Assign the cert to an email address or something. Only include age >16/18/21 and a expiry date.

There would be a problem with tracking accounts across services, but if the cert name is only tied to an email, it wouldn't offer any more tracking info than the email used tied to your online accounts.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 1 month ago (3 children)

    Do you know how the implementation proposed by EU works?

    How would that be a better solution? It is more complicated, more expansive and I see no benefits with it, in comparision to what the EU proposes

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 1 month ago* (last edited 1 month ago) (2 children)

    I'll start off by saying I'm not super familiar with the EU proposal for digital IDs (other than looking at a few articles here and there), but

    1. I'm not in the EU. The EU proposal is tied specifically to the EU. And without documents that establish physical presence in the EU it makes it hard to interact with EU services. A cert with an email doesn't have this problem.

    2. There are more problematic cases than "non-EU citizen outside of the EU want to access EU services". There are always edge cases where there's a piece of document that establishes the person is legally allowed to be here but is glossed over as an "ID". Usually, you can present these in person and a human would be able to check it. It's much harder to convince an automated machine to do so, especially when it isn't in a drop down list. Which means no digital ID for this person (since the system can't verify). This is not hypothetical. I have actually encountered this myself outside of the EU. Impossible to submit rental applications, trade-ins at Best buy, rent cloud servers, etc. A verification system backed by multiple non-government entities can alleviate this by 1) only verifying age and 2) verifying age through different methods, sometimes even through human vetting.

    3. Data protection is governed by policy in the EU proposal. Policy can change. It's a lot harder when something is technically impossible by design. A cert with only an email cannot produce a name in it, even if storage was implemented incorrectly.

    4. My understanding is that while the digital id wallet is supposed to be open source, currently it depends on Google attestation framework and can't even work on GraphineOS. You don't run into this problem with a file.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 month ago (1 child)

    1 & 2: it would work the same as all other EU specific things. You don't need to comply with GDPR for people outside EU, you wouldn't need to verify users outside the EU.

    3: I don't know what you mean. It could be easy to modify spec of those certs to include names.

    4 You don't know how this proposition is supposed to work.

    In short:

    There're officially approved apps (you can't just create you implementation arbitrary, but if you implementation meets all standards, you can work to have it approved). Using those apps, your credentials are secured with one (or many, I don't understand that part) of:

    • Hardware secure element
    • Software secure element
    • External device
    • Server HSM operated by the provider

    Those apps must also use some defined encryption standards.

    When you create your app, it needs to be approved by one of the member states.

    The app can store all kinds of personal governmental things such as your ID, bank account number, drivers license, etc.

    When a service wants to know whether you are 18 or more, you can give them your wallet. The wallet app will show who demands what informations and a reason they put in the request. You can approve or reject the request.

    It doesn't have to be tied to google or anyone other.

    Yes, those apps won't be libre, but (and you don't need to agree with me) in my opinion this is better than letting people create any implementation they want.

    GrapheneOS can create thier implementation, that relies on hardware security chip. Linux distros can create a joint implementation reliant on yubikeys and alternatives.

    Also, alternatives must remain.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 1 month ago*

    Response to 1: funny thing is that one of the ID verification issues I specifically had is with Hetzner. They need to do a ID verification, recognizes my address is from Country A outside of the EU, so it goes through a Country A specific verification. Then rejects my ID because it's a rare form of ID in Country A. I also have an ID for Country B but they won't recognize it with a Country A address.

    Response to 2: I'm specifically referring to people residing in the EU for this one. People in the EU that "slip through the gaps" since their ID is somewhat uncommon, thus getting locked out of digital services since they can't validate and obtain a digital ID easily.

    Response to 3: the counterpoint here is network transport protocols, such as TCP and UDP. At this point, it is no longer possible to build new protocols or modify these protocols because of how entrenched the infrastructure hacks surrounding these protocols are, such that no new protocol header would be possible to get through the Internet without it being dropped by middleboxes. I'm suggesting utilizing this technical moat as a feature here: have a simple proposal spread so wide that it becomes almost impossible or economically unfeasible to switch to something invasive.

    My issue with 4 is more about current implementation rather than the proposal. So far, the main (or only functional implementation, I'm not sure) is the one that depends on Google attestation. While this could change, I'm not the biggest fan of trusting something to "policy/proposals". X509 is robust, has key management sorted out, and doesn't have this specific issue. While anyone can create a cert, that doesn't mean the cert is useful if it's not signed by an approved CA.

  • permalink
  • fedilink
  • source
  • parent