Re: [Lucid] FW: [[e-mail]: Re: Non-normalizable diacritics - new property]

[Shawn Steele <[e-mail]>]

> Any of these forms, if they can be guaranteed to be stable, will satisfy that condition, but the point about the discussion is that identifiers that are "reasonably mnemonic" as one could characterize IDNs, do occupy a space between machine and human interaction with writing systems.

This discussion seems to be about lots of things, but "reasonably mnemonic" would limit the problem hugely.  That implies that I can see it and remember what it was to type it later.  However that scenario doesn't hit any of the security concerns being raised as I'm going to type it using the appropriate keyboard for my language.  Sure, if the domain had a Cyrillic l may have trouble, however that's not mnemonic, that's someone being sneaky.  (See fraud below)

> Actually, Arabic even has potential "variants" among the digits, so while you can make the identifier be based on the numeric value of what the human wrote in whatever writing system, you get into issues of recognition of identifiers etc. once they are communicated in their human-readable form.

That's digressing from my point.  I was trying to say that, if we consider the problem without any human factors, we already have unique IDs.  There's no way that machines confuse any of these names, it's only the humans that do that.  (Yes, they're an important part). 

> It's not just the conventions of a group of users, but also human perception issues that plague human-readable identifiers, and the "sociological" issue of the need to counteract fraud.

That's an additional requirement to the "reasonably mnemonic" above.  However if this entire exercise is intended to counteract fraud, then we get my view that "trying to address these codepoints is way more costly than its benefit".  

The people in this room aren't going to click on "1stbank.trustme.com", but everyone else on the planet (or at least 90% of them) click that link.  So worrying about someone spelling it "lstbank.com" provides close to zero value.  At least in the right font 50% of the other humans might start suspecting that one.

Heck REAL BUSINESSES send me to crappy URLs like that all the time.  "We partnered with ABCsurvey.com to get your feedback, trust us".  "We're replying about your recent experience from [e-mail]".  "We see you like our museum, consider donating at fundraising.com/ourmuseum".  Even my BANK does that.  Heck, they even send me the "1stbank.trustme.com" links.  It irritates me to no end. 

(This total obliviousness to security/spoofing/phishing isn't even limited to DNS, I've received calls because of billing glitches and the bank says "you can pay now, give us your CC or check routing info".  That's normal.  They they ask my secret code or whatever to verify it's me, and I point out that I can't even verify that they're who they say they are and they're stumped.  Well, you can call us back at 1-800-123-4567.  Seriously!?!?!  Even my bank has no clue what security is?)

Fix that, and then we can talk about whether it's worth fixing a couple esoteric code points.  There are FAR easier exploits for any serious attacker to attack.  It's certainly not worth risking breaking real strings and real mnemonics that real users might want to use.  (IMO its not even worth prohibiting I♥NY.com)

At this point I'm well beyond the "identifying the problem statement", sorry.

However, that does bring me back to the "what are we trying to do this for?" question.  IMO there is no value in trying to secure DNS by prohibiting these.  However I'm open to the idea that there's an machine/computer science need for unique identifiers that apparently we want to be mnemonic.  I have no clue what those scenarios are.  I get wanting an IRI to identify a unique resource, but we already have that (presuming the machine does the interpretation there's no ambiguity).  I am clearly totally missing whatever scenario it is where a confusable type ID is needed for an identifier in a system where it could actually be confused.

-Shawn