i think this could be resolved by assigning a color to each user based on a hash. maybe people would try to find collisions there (i.e. specifically find usernames that get the same color as you), but if you do something like color_index = hmac(user_address, client_nonce) % color_count where client_nonce is unique to each client, it would be impossible to manipulate usernames to get a collision or even a higher chance at it.
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.
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?
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:
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.
Assign random colors and save them on the client. This would probably balloon without an LRU data structure, but it could work.
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.
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.
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.
Of course, I’d still want to see the instance with every user and also with every chanel.
Like email. Sure, some clients only show the first name, but somewhere I want to see the full address, can be small, can be hidden in a compact view, but full address is a must.
i think this could be resolved by assigning a color to each user based on a hash. maybe people would try to find collisions there (i.e. specifically find usernames that get the same color as you), but if you do something like
color_index = hmac(user_address, client_nonce) % color_countwhereclient_nonceis unique to each client, it would be impossible to manipulate usernames to get a collision or even a higher chance at it.The full user adress should suffice for the hash, because there is only one hyacinth@feddit.de, for example.
Also, do you really need a hash? Isn’t there a simpler alternative, developing an app?
yeah, the point is that if
hyazinthe@feddit.dehashes 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.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?
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:
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.
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.
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.
Nice visual feedback.
Of course, I’d still want to see the instance with every user and also with every chanel.
Like email. Sure, some clients only show the first name, but somewhere I want to see the full address, can be small, can be hidden in a compact view, but full address is a must.
Bob@family.us is not bob@microsoft.com
www.bank.com is not www.bank.scammer.com
Berlin, Oregon is not Berlin (Germany)
Names are not unique. That’s why we have addresses.