On the subject of security, I've read through: https://www.unicode.org/reports/tr36/#Deletion_of_Noncharacters which says: "The issue is the following: A gateway might be checking for a sensitive sequence of characters, say "delete". If what is passed in is "deXlete", where X is a noncharacter, the gateway lets it through: the sequence "deXlete" may be in and of itself harmless. However, suppose that later on, past the gateway, an internal process invisibly deletes the X. In that case, the sensitive sequence of characters is formed, and can lead to a security breach."
Checking a string for a sequence of characters, then passing the string to a different function which (potentially) modifies it, then using it in a context where the security checks mater, just screams bad practice to me. There should be no modification permitted between a security check and security-sensitive use. The string should always be sanitized before being checked for exploits. Any function which modifies the characters in any way (and is not itself security-aware) should implicitly mark the string as unsafe again. Or am I off base? Security is not really my specialty, but the approach described in the TR stinks horribly to me. And in my idea, noops would be stripped as part of string sanitization. But the more I consider it, the more I understand such a thing would have had to have be built into Unicode at the earliest stages. Basically, it's too late now. -----Original Message----- From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Richard Wordingham via Unicode Sent: Sunday, June 23, 2019 04:37 To: unicode@unicode.org Subject: Re: Unicode "no-op" Character? Discardables are a security risk, as security filters may find it hard to take them into account. Richard.
