31–40 of 83 posts
Why does Unicode threat Omega and Ohm like different characters?
Even English speakers will easily confuse 1,I, and l, depending on how they're represented by the browser. And 0/O.
For more fun, try drawing any shape on http://shapecatcher.com/ and see all the similar-looking Unicode characters.
Earlier quoted context omitted.
Easy to implement in a small project. Not so easy in a large enterprise project likely comprised of multiple interconnected systems.
Not a good excuse. There are plenty of enormous projects that provide only one basic interface to a bit of information. See every operating system API for examples.
VirtualAlloc: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
VirtualAllocEx: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
VirtualAllocExNuma: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
It all started out nice and clean I'm sure, but within a few years you start to see many more than one basic interface to some things.
Earlier quoted context omitted.
Based on their description of the bug, it sounded like the code was modular, but they called the function twice: once when the password reset request was generated, and again when the link in the email was clicked. However, when the link was used, canonical_username was once again applied So after they sent the password reset link, they called "fetchUserIdByName" again, but they passed in a username that had already…
If you're saying canonicalise(canonicalise(name)) is not the same as canonicalise(name), that's going to be seriously bug-prone. Idempotence ftw.
Earlier quoted context omitted.
Based on their description of the bug, it sounded like the code was modular, but they called the function twice: once when the password reset request was generated, and again when the link in the email was clicked. However, when the link was used, canonical_username was once again applied So after they sent the password reset link, they called "fetchUserIdByName" again, but they passed in a username that had already…
If you're saying canonicalise(canonicalise(name)) is not the same as canonicalise(name), that's going to be seriously bug-prone. Idempotence ftw.
Why does Unicode threat Omega and Ohm like different characters?
http://en.wikipedia.org/wiki/Ohm#Ohm_symbol
"Unicode encodes the symbol as U+2126 Ω ohm sign, distinct from Greek omega among letterlike symbols, but it is only included for backwards compatibility and the Greek uppercase omega character U+03A9 Ω greek capital letter omega (HTML: Ω Ω) is preferred."
And from the Unicode Standards doc that is the source for that section:
"Greek Letters as Symbols: The use of Greek letters for mathematical variables and operators is well established. Characters from the Greek block may be used for these symbols.
For compatibility purposes, a few Greek letters are separately encoded as symbols in other character blocks. Examples include U+00B5 µ n the Latin-1 Supplement character block and U+2126 Ω in the Letterlike Symbols character block. The ohm sign is canonically equivalent to the capital omega, and normalization would remove any distinction. Its use is therefore discouraged in favor of capital omega. The same equivalence does not exist between micro sign and mu, and use of either character as micro sign is common; for Greek text, only the mu should be used."
Earlier quoted context omitted.
Because they have rather different meanings. Capital omega (Ω, U+03A9) is a Greek letter, with the lower-case form ω; ohm (Ω, U+2126) is a symbol used in electrical engineering with a related symbol "mho" (℧, U+2127).
FYI, that all units measuring physical properties named after scientists use capitalized letters for their abbreviation[1]. So the ohm (named after Georg Ohm) is abbreviated as the uppercase omega, no idea why they are different unicode values, since they do not have different meanings. Note that omega was probably used so that the 'O' wouldn't be confused with '0', e.g. 4O would be confusing, but 4Ω is not. [1]The t…
Why does Unicode threat Omega and Ohm like different characters?
Unicode has lots of characters that look alike, because, well, lots of human languages ended up with similar-looking characters. Even English speakers will easily confuse 1,I, and l, depending on how they're represented by the browser. And 0/O. For more fun, try drawing any shape on http://shapecatcher.com/ and see all the similar-looking Unicode characters.
Earlier quoted context omitted.
If they did as you suggest, the specific account-stealing flaw they had wouldn't happen, but since many unicode points have very similar glyphs, there would still be "copycat" accounts. That is, the strings "Oscar" and "Οscar" appear very similar (if one has the proper fonts installed), and one user could therefore pose as another. It's true that many sites don't care about this, but I don't fault Spotify for trying…
It looks to me as if the prevention of this caused more problems than it solved.
The letter À (A grave) can be written as the UTF-8 bytestream 0xC3 0x80 (i.e. a single "character"), or as À - i.e. a letter A, then a combining grave character i.e. 0x41 0xCC 0x80.
The two are identical. Except they have different byte representations. If you don't normalize your unicode you will run into major problems.
Earlier quoted context omitted.
Based on their description of the bug, it sounded like the code was modular, but they called the function twice: once when the password reset request was generated, and again when the link in the email was clicked. However, when the link was used, canonical_username was once again applied So after they sent the password reset link, they called "fetchUserIdByName" again, but they passed in a username that had already…
If you're saying canonicalise(canonicalise(name)) is not the same as canonicalise(name), that's going to be seriously bug-prone. Idempotence ftw.
I don't see any real reason to rely on idempotence. They could simply store two names: One is provided by the user (verbatim), and the second is its reduction to lowercase letters and digits (canonical). For all internal logic, they could use only the canonical name, and use the verbatim name in the front-end to make the user happy. > Lower casing has the key property of being idempotent, i.e., that applying it more…
>They could simply store two names Presumably you mean in the database? I don't see a reason to keep a copy of the lower() transformation of a string when it is incredibly cheap to transform a small string to lowercase. What exactly is the point of that? I would just call lower() as needed, personally.