They could do a lot of things, if they cared.

For example: limit app and account renames; when creating/renaming app/account, compute levenshtein distance to all the existing ones and if distance < threshold, make it subject to manual review and make it unlisted before cleared.

Problem is, from my observation, that Google has a culture of hating any manual processes, because they do not scale, so they avoid them, unless compelled by law.

2nd problem is that they have big enough market share that they don't have to care about things that are not convenient to them. Slightly off-topic but in a similar way, Apple can increase iphone price 10% per year and get away with it, because people still buy.

Manual processes scale just fine. They just don't want to pay for it.

Exactly. Hearing "support doesn't scale" is complete bullshit. They just would prefer to skirt the costs.

True, for example, AWS is doing fine for years with manual customer services despite its scale.

Scaling in 2017 means "scales like f(x) = ax+b" with a=0, b=0

Maybe for Google.

Scaling well means "costs / effort scale like f(x) = ax^p +b " with p < 1. Not scaling well means having p > 1.

What is a "normalized slug"?

The kind of excerpt-like thing you see on the end of many many modern URLs. "rare-white-moose-captured-on-film-in-sweden" in this one: www.bbc.com/news/av/world-europe-40918494/rare-white-moose-captured-on-film-in-sweden

It's machine-produced and surprisingly good at revealing accidental/unintentional/evil duplicates, considering how cheap it is.

slug is a term leftover from newspapers. You most commonly see slugs today where a title might be "Did you know this mushroom is off the hook?" and the URL is turned in to a "slug" like

    example.com/mushroom-off-the-hook/

Here is an example of the Django framework's "slugify" https://github.com/django/django/blob/master/django/utils/te...

A simpler representation of some text, using only lowercase letters, numbers and dashes for spaces. Removes any unsafe or "invisible" characters, accents, and sometimes simple words. Often used in URLs.

TEXT: Fake WhatsApp update from “WhatsApp Inc.” with Unicode whitespace: 1M downloads

SLUG: fake-whatsapp-update-from-whatsapp-inc-with-unicode-whitespace-1m-downloads

All names get reduced using Unicode normalization.

Recently, thousands of users were duped into installing "АdВIосk РIuѕ" in Chrome. Every one of those letters is Unicode normalized.

(Hint: it's not just the I's masquerading as l's.)

Fair enough. I'm a little surprised that those hold up under NFK normalization. А sure as heck seems compatible with A.

I suspect that if they haven't already, they will now

Or visually rendered and use some kind of picture diffing to decide if they're visually similar ?

That sounds a lot harder than just normalizing the string

You would think so, but that turns out not to be the case. Mostly because it doesn't require humans to think of edge cases. It also more closely addresses the actual problem of "do these things look similar when rendered on screen" as opposed to the abstract problem. For instance, render and score catches "rn" being visually similar to "m".

What may look like decoration to English readers e.g. the ä in häagen dasz or ö in Motörhead, are actually distinct letters in languages that have them. Disallowing display names because another one exists but without diacritics and the like is just asking for a ton of manual review. And how do you handle scripts that only use ASCII for English loan words, say Chinese, Japanese, Thai, Arabic, Russian and Indian scripts?