[__MatrixMan__]

We should be displaying hashes in a color scheme determined by the hash (foreground/background colors for each character determined by a hash of the hash, salted by that character's index, adjusted to ensure sufficient contrast).

That way it's much harder to make one hash look like another.

[9dev]

As someone with red/green vision deficiency: if you do this, please don’t forget people like me are unable to distinguish many shades of colours, which would be very disadvantageous here!

[AaronAPU]

It’s not like it would hurt you for there to be supplementary info others can see but you can’t.

[gblargg]

I think 9dev was saying that providing only a colorized version might make it unreadable to some people, not merely that they wouldn't benefit from the extra color information.

[macintux]

And it's not like it would hurt the developers to be conscious of their choices.

[zarzavat]

There's actually nothing the developers can do about this particular issue other than to display all colors and allow colorblind people to see the colors that they can see.

[__MatrixMan__]

It doesn't matter which colors the algorithm chooses so long as background/foreground are very distinguishable to as wide an audience as possible, and prev/next are likely to be distinguishable more often than not.

That's a lot of flexibility within which to do clever color math which accounts for the types of colorblindness according to their prevalence.

[b112]

For the newly made up feature, which doesn't exist yet, but already has an issue?

Simple. Instead of forcing colour, one could retain a no colour option maybe?

Done. Solved.

Everything should have this option. I personally have no colour vision issues, other than I find colour annoying in any output. There's a lot who prefer this too.

[__MatrixMan__]

Agreed, although I would argue that maximal hash contrast should be default, and if people find they prefer less, they can turn it down.

If you're the sort of person who would think about adjusting it to suit your sensitivity to this kind of attack, you're likely not the sort of person that the feature is trying to protect anyhow.

[mdaniel]

Team https://no-color.org/ for life

One will not be surprised to see that Chalk chooses its own path via the stunningly opaque FORCE_COLOR=0 and is all :fu: to people who suggest otherwise <https://github.com/chalk/chalk/issues/547#issuecomment-11268...> One will especially enjoy the "get bent" response because I discovered that one issue by, you know, searching the issues <https://github.com/chalk/chalk/issues?q=is%3Aissue%20NO_COLO...>

[__MatrixMan__]

You could still ignore the colors and just read the characters, like people do now, and you could still use whatever color cues you are sensitive to.

[Spivak]

Not sure why you're being downvoted, OpenSSH implemented randomart which gives you a little ascii "picture" of your key to make it easier for humans to validate. I have no idea if your scheme for producing keyart would work but it sounds like it would make a color "barcode".

[Macha]

I have to say the openssh random art has never really helped for me - I see each individual example so infrequently and there's so little detail to remember that it may as well just be a hash for all the memorability it doesn't add

[__MatrixMan__]

If you ignored the characters and just focused on the background colors, yeah I suppose it would look like a barcode. But the way I envision it, each line on the barcode is a character, so it still copy/pastes into notepad as the original text, but it'll copy/paste into word as colored text with colored background.