![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://fry.gs/pictrs/image/c6832070-8625-4688-b9e5-5d519541e092.png)
How about a government-sponsored, non-profit authentication service? That is, it should be impossible to get a loan, open a line of credit, or anything else in somebody’s name, without the lending institution verifying that it’s actually on behalf of the named individual. Eliminate the security-through-obscurity technique of using bits of easily-leaked personal information as a poor substitute for actual authentication.
I mean, (as a comparative example) I have to go through an OAuth2 consent dialog to connect a third-party app to my email account, yet somebody can saddle me with huge debts based on knowing a 9-digit number that just about everybody knows? It’s the system that’s broken, tightening up the laws on PII is just a band-aid.
Case-sensitive is easier to implement; it’s just a string of bytes. Case-insensitive requires a lot of code to get right, since it has to interpret symbols that make sense to humans. So, something over wondered about:
That’s not hard for ASCII, but what about Unicode? Is the precomposed ç treated the same lexically and by the API as Latin capital letter c + combining cedilla? Does the OS normalize all of one form to the other? Is ß the same as SS? What about alternate glyphs, like half width or full width forms? Is it i18n-sensitive, so that, say, E and É are treated the same in French localization? Are Katakana and Hiragana characters equivalent?
I dunno, as a long-time Unix and Linux user, I haven’t tried these things, but it seems odd to me to build a set of character equivalences into the filesystem code, unless you’re going to do do all of them. (But then, they’re idiosyncratic and may conflict between languages, like how ö is its letter in the Swedish alphabet.)