4 ms·
> The worldview underlying articles like this one, which I believe is itself a mistake, is that software must be able to accommodate 100% of cases encountered i
by arghwhat 4y ago
> The worldview underlying articles like this one, which I believe is itself a mistake, is that software must be able to accommodate 100% of cases encountered in the real world.
The mistake I believe you are making is removing users from the set you accommodate with absolutely no valid reason or gain.
Sure, there can be valid reasons to discriminate against users, but you better have a valid reason with no non-descriminating option available.
When it comes to email, not only is the discriminating approach completely broken, the non-discriminating approach is free of any problems, and will likely be implemented anyway!
> When someone provides "mymail@[123.123.123.123]" in an online signup form, it's much more likely that they are trying to do something fishy than this actually being their email address.
So people with addresses you do not consider normal must be doing fishy things?
In 2022, fishy things are done with gmail.com addresses as they go unnoticed, are easy to issue and are universally accepted and deliverable. People don't use addresses that raise eyebrows when they're trying to go unnoticed.
> When someone doesn't fill in the "last name" field on a passport application form, it's much more likely that they overlooked the field than that they actually don't have a last name.
Not a valid argument as we can test emails trivially but not test names without very specific registry accesses.
... But this is also a perfect example of an incorrect heuristic. Hopefully you do not consider it fair to exclude all members of societies that do not use last names as fair? That's far more grotesque than your email example after all, and fairly illegal under most anti-discrimination laws out there.
Instead, add a checkbox for "I do not have a last name" if you think that failing to enter your last name is a common enough error to bother those without.
- p-e-w 4y ago> The mistake I believe you are making is removing users from the set you accommodate with absolutely no valid reason or gain. That's a very strange objection. Virtually every online service excludes all customers that don't have a credit card. Many exclude all users that don't have a mobile phone or are unwilling to provide their phone number, even where the service has nothing to do with phones. Simplifying/excluding assumptions about users are ubiquitous on the web (and in society in general) today. > Hopefully you do not consider it fair to exclude all members of societies that do not use last names as fair? They're not being excluded, they just have to go through some extra steps, which is already true for many, many people for a near-infinite number of reasons. Those extra steps might involve workarounds like the one I mentioned. > Instead, add a checkbox for "I do not have a last name" This isn't feasible because there are hundreds of special cases like that. Forms (and software systems) would balloon in complexity and become utterly unmanageable in the "99% case" if every single possibility was catered to. Just some examples: There are people who don't have a name at all (yes!). There are people who don't know their date of birth (fairly common actually). Should standard forms have checkboxes for all of these cases? The map is not the territory. Expecting databases to perfectly model reality is an exercise in futility. It's far better in most cases to make the data fit the model (say, by filling in default or approximate values where the true value isn't known or available) than to relax constraints to the point where they become meaningless just because there is the odd entry that doesn't fit in, while the overwhelming majority of entries do.
- arghwhat 4y ago> That's a very strange objection. Virtually every online service excludes all customers that don't have a credit card. But they do not discriminate against who issued it. Valid? All good. Just like it with email. > They're not being excluded, they just have to go through some extra steps Disallowing an empty last name field is exclusion, not extra steps. Asking if it's correct is extra steps, which might be fair. Disallowing what in your opinion is a "weird" email is exclusion, not extra steps. Allowing me to use it after sending me an email would be extra steps. However, the name situation is just a validity or database issue, the email is unwarranted discrimination as all emails have the same format. And that is exactly why the argument is not applicable: It is one thing to have a system not fit due to too an ill defined legal form or too many possible options (which is unacceptable on its own, but is hard to resolve), it is another entirely to decide to discriminate actively without cause, especially as it is extra work. Your first argument was that an invalid email was a typo, which the validation flow sorts out which is needed anyway as a gmail address is no less likely to habe a typo. The latter was that weird emails are likely fraudulent, which is just flat out false. So with those out of the way, what reasons remain for going out of your way and writing additional code for deciding what email address is right and what is wrong?
- p-e-w 4y ago> But they do not discriminate against who issued it. Valid? All good. Just like it with email. Ahaha of course they do! Try paying online with a credit card issued by a bank from Uganda, or by a bank that allows customers to prepay their credit card bills, or with a "privacy.com" type virtual card, and you will very quickly see that payment processors most certainly do not treat all cards the same, even if they are valid. And yes, that's "just like with email". Because the majority of online services will outright reject addresses from anonymous/"temp mail" providers, even though they are perfectly valid and can receive mail. Many will additionally disallow +suffix addresses, because they can be used to create multiple accounts from the same mailbox, and also make it easier to automatically get rid of spam originating from the service provider. Service providers want the user's primary, personal email address. Exclusion rules exist to increase the likelihood that this address is in fact what the user has entered. The standard validation flow is clearly not sufficient, else service providers wouldn't bother with all the additional complexity.