182
Fact : what's really behind the Swiss E-ID (slrpnk.net)
submitted 1 year ago by to c/privacy@lemmy.ml
69 comments fedilink hide all child comments
 

End of September, Switzerland will vote for E-ID. A big threat for our privacy as it will widely used for tons of new use cases.

Behind the government pitch of an "open source project, completely optional" hides big tech industry... Which will make it mandatory to access their services.

What are your thoughts on that ?

#Switzerland #Privacymatters

you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 1 year ago (8 children)

If I'm not mistaken, it's up to the the service that's using the Belgian e-id to enable some of the options or not. For example, the website where I check my payroll only works through itsme or with a card reader — no TOTP or SMS 2FA. It's a big issue because itsme refuses to run when you don't pass Google's safety net.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 1 point 1 year ago* (last edited 1 year ago) (7 children)

    I'm talking about public services. For private services I have no idea what they all do and, as importantly, what they are legally bound to do. I would hope that obviously they would have to provide at least 1 solution that doesn't rely on any third party, e.g at least provide the card reader with legal Belgian ID option (which seems to be what they offer you, so IMHO that's good enough), but I don't know.

    ItsMe not running is pretty good in terms of privacy because their entire business model is, and correct me if I am wrong, to be an intermediary. I didn't check what data they share but I'd be pleasantly shocked if it was none.

    The card reader might seem slightly inconvenient or outdated but there is no intermediary and it is, AFAICT, secure because it's based on well established cryptography.

    PS: it's also fun because you can play with PAM and thus, I didn't try that, login or get su and sudo with your ID card.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 1 point 1 year ago (6 children)

    It doesn't matter whether it's a private or public service if they both use the same auth provider (beId). I wouldn't be surprised if the SMS/TOTP options went away completely at some point for our "security".

    A different issue is that itsme is often the only option when doing things on mobile. Sure, you can avoid it for now, but it's getting increasingly inconvenient to do so, unfortunately. I try to express my disappointment to itsme every now and then about the fact that they require Google's SafetyNet and that the Connective Plugin needed to activate itsme in the first place doesn't even work on Linux, but to no avail. They sent me a detailed email about setting up a Windows VM to get it working so credit where it's due for the effort, but the situation is still bad...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 1 year ago (5 children)

    itsme is often the only option when doing things on mobile

    Indeed that's why TOTP, via e.g. Ente Auth, was a good surprise. I didn't see it until now and I believe that's the mobile alternative to ItsMe.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 1 year ago

    I don't think it is because there's only one authority, one identity provider, and that's the federal government. All authentications pass through them. Enthe Auth or any other application will never be able to prove your identity without making an online call to the federal servers.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 year ago (3 children)

    That's what I was saying — sometimes the TOTP option is not available at all for certain services. Ente, Aegis, Bitwarden, etc won't save you there and itsme remains the only option on mobile when that's the case.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 1 year ago*

    That's actually a choice made by the service. The onboarding document has the options listed and they get to choose, which is imho stupid. Just offer all options.

    Service A has email enabled, service B doesn't. Since ACM/IDM is SSO you can first authenticate with service A with your email code and then go to service B already authenticated.

  • permalink
  • fedilink
  • source
  • parent