A rebuttal to an anti-passkey, pro-TOTP post that has made the rounds on Lemmy as well.

  • ☂️-@lemmy.ml
    link
    fedilink
    arrow-up
    26
    ·
    edit-2
    11 hours ago

    no, fuck passkeys. they will lock everyone in with their proprietary bullshit.

    use a good generated password in a manager if you will. don’t trust anything corps are pushing.

    • bdonvr@thelemmy.club
      link
      fedilink
      arrow-up
      1
      ·
      18 hours ago

      What are you talking about? I’m locked in with all my passkeys that are stored in my open source self hosted password manager that syncs across all my devices?

      Like, I’m confused on what you mean

      • ☂️-@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        17 hours ago

        people self-hosting their open-source password managers are in the vast minority. most people will use whatever is pushed to them, which is gonna be vendor lock-in.

        • bdonvr@thelemmy.club
          link
          fedilink
          arrow-up
          1
          ·
          16 hours ago

          Sure but that’s not an inherent issue with passkeys.

          You can use whatever proprietary password manager you’d like. Sure that often means people are using the device built in ones…

          But why should that stop me personally from using passkeys?

          • ☂️-@lemmy.ml
            link
            fedilink
            arrow-up
            1
            ·
            16 hours ago

            it is. passkeys are not memorable.

            and if all you are thinking about is how you should personally set up your own computer, you are missing the forest for the trees. we will keep happening upon android type situations if we’re being that individualist.

        • im_fine_sandy@nord.pub
          link
          fedilink
          English
          arrow-up
          6
          ·
          1 day ago

          that’s quite a leap.

          Yes google does have a lot of control over the HTML and HTTP specs because they control the most popular web browser. Whether people are or will in the future be “locked in” to google for that reason is debatable.

          Regardless, the potential for a company to dominate the implementation of a specification is not a reason not to create said specification.

          • bjc@scribe.disroot.org
            link
            fedilink
            arrow-up
            6
            ·
            1 day ago

            Regardless, the potential for a company to dominate the implementation of a specification is not a reason not to create said specification

            yes it is

              • Ferk@lemmy.ml
                link
                fedilink
                arrow-up
                1
                ·
                edit-2
                8 hours ago

                Imagine if HTTP explicitly documented as part of the standard that the “User-Agent” header, when provided, must include a tamper-proof cryptographic signature that allows to securely identify which browser version the user has (with a consortium maintaining a list of registered browsers) so that websites can reject access if you are not using a browser they trust or they don’t like that your browser is too old…

                Considering how much abuse there has been with the User-Agent header… I can’t imagine it being a good idea to include such a thing in the standard.

                If on creation HTTP had included things like that, then I think Gopher and other competitors at the time might not have been a bad option, honestly.

                • im_fine_sandy@nord.pub
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  8 hours ago

                  I don’t see your point I’m sorry. This would make it easier for Google to exclude small competitors.

                  • Ferk@lemmy.ml
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    edit-2
                    8 hours ago

                    The point is that not all protocols are created equal. So “we shouldn’t have created HTTP” depends on what HTTP is specifying.

                    If a protocol makes it easier for big players to abuse the system, then it’s a worse protocol in that respect.

                    The point being made against passkeys is that, in some respects, it’s worse because of the inclusion of attestation as part of the standard.

              • bjc@scribe.disroot.org
                link
                fedilink
                arrow-up
                7
                ·
                1 day ago

                we should have learned our lesson after they did and done our damndest to create protocols immune to capture. there were excuses in 1989, there aren’t now

                  • Ferk@lemmy.ml
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    edit-2
                    9 hours ago

                    A good start would be to not bundle into the protocol a method explicitly intended for services to be able to securely identify what local software (or hardware) you used with the explicit purpose of allowing the service to be able to reject access if that client software (or hardware) is not allowlisted.

                    Passkeys is a great idea. But the “Attestation” part of the protocol …not so much.

                • im_fine_sandy@nord.pub
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  18 hours ago

                  Honestly not sure what’s going on in this thread.

                  Don’t invent the internet because then you will have internet companies.

          • ☂️-@lemmy.ml
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            17 hours ago

            google will also control the most popular passkey manager. is that not obvious by how they already control the most popular password manager, browser, search engine and more?

            • im_fine_sandy@nord.pub
              link
              fedilink
              English
              arrow-up
              1
              ·
              21 hours ago

              I’m really struggling to follow your logic here. You’re saying they already have the most popular password manager so we shouldn’t support a next gen, more secure, open standard because Google will have the most popular client for that also?

              The obvious problem with this reasoning is that… there will be alternatives of you don’t wish to use googles implementation.

              • ☂️-@lemmy.ml
                link
                fedilink
                arrow-up
                2
                ·
                edit-2
                17 hours ago

                unless google finds a way to lock you in (or out), like they’ve done pretty much everywhere else. me and you using foss won’t change what’s coming for society at large.

                i mean how can you not see how they have been hoovering up everything on the internet for the last couple of decades and think they won’t find a way to to capture this too and run it their way, like all before it?

                • im_fine_sandy@nord.pub
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  15 hours ago

                  I do see Google’s behavior and I’m certain that they will do their best to capture this as they have everything else.

                  However, it’s an absurdity to suggest that we should not develop new protocols because google will act to ensure they have the largest market share.

                  • ☂️-@lemmy.ml
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    edit-2
                    12 hours ago

                    there’s the thing though: “we” are not developing it. “they” are.