1. 9
  1.  

  2. 17

    The web (vs DNS) way is verifying that there is a rel=me link on the site pointing to the twitter/… etc account. This is e.g. implemented in Mastodon.

    1. 3

      Have to get more clients incorporating these methods. Ultimately Twitter itself should publish a set of best practices that they could make accessible. But they may be hesitant to do this for anything that points outside of their own walled garden.

      1. 1

        Yeah, I don’t think Twitter is particularly interested in having clients load resources from 3rd party sites/services. They might build a backend service that scrapes + caches URLs in profiles and does similar verification; they’re certainly scraping all the other URLs people post. (I vaguely recall profile URL contents being used as one trust & safety signal back in the day, but not the ad-hoc lookup via DNS.)

        Nostr – another “decentralized Twitter” option that I actually really like the look of as a pragmatic alternative to e.g. ADX – does this via optional profile metadata and a lookup on a .well-known/nostr.json path on the domain part of display names. E.g., rcoder@example.com gets looked up client-side via a normal HTTP request to https://example.com/.well-known/nostr.json. If the public key listed in that document matches the local part of the name, I get a “verified” checkmark.

      2. 1

        My idea would have been to have a meta tag in the head to do the verification with.

        1. 7

          <link rel="me" href="https://twitter.com/foo"> also works in the head.

      3. 4

        The biggest problem I see with this is that most people don’t have a domain name. What’s to stop scammers from just not specifying a website in their bio? Twitter can’t warn you about that because it’s way too common.

        1. 4

          A lot of the people being impersonated do have domain names, however. We’re trying to raise the bar here, not a magic bullet.

          1. 2

            Sure, but how many people are going to actually click into the profile from the DMs just to check if it has a domain name, absent any warning from Twitter that it doesn’t have one? Maybe Twitter could warn you only if the profile was suspiciously similar to another profile that does have a domain name? But in that case, who cares about the domain name? Just warn me about the profile directly.

            It doesn’t scale.

            1. 1

              The proof-of-concept code is just to demo how the convention would work under the hood. Were this to gain traction this would be largely automated, and whatever you’re accesing twitter with would have it integrated.

        2. 3

          The central point of the argument is at the end of the post; if the attacker needs to buy a domain, it makes the attack less scalable. Now they have to invest money into the attack, and because the return is uncertain, it might not be worth it.

          Instead of integrating with this solution, Twitter could charge $20 per account that wants to be “verified”. It would have the same effect and Twitter would have a new source of revenue. Thinking about it, I don’t know why they aren’t doing this already.

          1. 3

            simply reference the resource you want using underscore scoping in DNS labels within TXT records:

            Who pays the costs required to treat DNS as a sort of ersatz key-value store? Are they distributed among users, or externalized and borne by the DNS infrastructure itself? Because, like, DNS is absolutely critical internet infrastructure, and already highly over-burdened…

            1. 4

              Either you run your own DNS server or you pay someone to (or use a free plan somewhere that is compensated another way). So that’s who pays the cost. You do.

              1. 1

                When you register a domain, your money goes to the registrar; when you pay for DNS hosting, it goes to the “leaf node” in the DNS tree. None of your money goes to the intermediating infrastructure, AFAIK. (Maybe I’m wrong?) And that’s what I’m pointing out.

                1. 7

                  The domain registrar has to pay the registry a fee per domain. There is also a fee to ICANN for gTLDs (I’m not sure if the ccTLDs has this). All of this is paid directly to your registrar and included in the final price. This all goes to stuff like staffing and technical infrastructure (including DNS hosting) for both the registry and ICANN.

                  A quote from Wikipedia:

                  When a registrar registers a .com domain name for an end-user, it must pay a maximum annual fee of US$7.85[4] to VeriSign, the registry operator for com, and a US$0.18 annual administration fee to ICANN. Most domain registrars price their services and products to address both the annual fees and the administration fees that must be paid to ICANN.

              2. 2

                Because, like, DNS is absolutely critical internet infrastructure, and already highly over-burdened…

                What makes you think DNS is highly over-burdened? It’s already used to convey meta-data like domainKeys, SPF data, RBLs, RPZs and already used for validation of ownership across countless applications.

                None of this is highly overburdening the DNS infrastructure. The existing system handles, in aggregate, millions of queries per second already.

                1. 2

                  What makes you think DNS is highly over-burdened?

                  Conversations with first- and second-tier maintainers of the root DNS servers and core DNS infrastructure, mostly. It would be great if folks didn’t think of DNS as an ersatz key-value store that you don’t have to pay for.