• b3nsn0w@pricefield.org
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    yeah, the point is that if hyazinthe@feddit.de hashes to, say, blue, they can try to find a similar-looking username that also hashes to blue, therefore helping with the impersonation. if you hash a client nonce that’s different for everyone, you may hash to blue on my screen but green on yours, and there will be no relation between who hashes to which color on your screen or mine. the impersonator will have no way to guess if their name would match colors on either of our screens, and if we have, say, 25, colors, it will be a static 4% chance no matter what they do.

    • Strive7307@discuss.tchncs.de
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Sounds like a good solution. To make the colors less invasive it could only activate once two different users with the same name comment in a single thread.

      • b3nsn0w@pricefield.org
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        the problem is you’d need to check for visual similarity, not just the same. spammers and scammers of any kind often take advantage of the full power of unicode to create names that look like the same, but aren’t, and even without unicode you have the issues of I vs l, O vs 0, rn vs m, and so on. if we can figure out a check that the impersonators could actually have a hard time evading that would be nice, but otherwise i don’t really see it.

        imo we should make the colors non-invasive by just minimizing their visual impact. painting the entire comment with the assigned color would be intrusive, but i see no issue with just coloring the usernames, in a very discord-like fashion.

    • hyazinthe@feddit.de
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Ah, I understand. But couldn’t you just implement the unpredictable colors, you are trying to achive client-side, without hashing, say random order of colors?

      • b3nsn0w@pricefield.org
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        I think it should go on the client, and the hash is pretty much a space saving measure. There are three options, as far as I see it:

        1. Assign random colors every time a page is rendered. This could get confusing on repeat visits, but it would come with the added perk of ensuring the impostor has a low chance of hitting the same color as the person they’re trying to impersonate every time.
        2. Assign random colors and save them on the client. This would probably balloon without an LRU data structure, but it could work.
        3. Use the hash. This basically generates random colors in a predictable way, implementing #2 without having to store anything.

        Given that Lemmy does a lot of reloads on navigation I don’t think #1 would work well. The hash is a quick and easy way around the complexities of other implementations.

        And yeah, in theory the server could store the client secret, making the colors consistent across all devices of a user, but it has to be non-public info. If it’s public, an impersonator could target a specific person and find a collision that fools them in particular.