4 ms·
> The assumption that you can get away with a heuristic would be a falsehood. That depends on what you mean by "get away". Plenty of large-scale software syste
by p-e-w 4y ago
> The assumption that you can get away with a heuristic would be a falsehood.
That depends on what you mean by "get away". Plenty of large-scale software systems implement some of the "falsehoods" mentioned in the article. Those systems still operate, so they seem to "get away" with it just fine.
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. But no system, past or present, does that. In the end, it's always users that end up adapting to the system instead. There are countless examples for this, such as people who have no last name filling in their name as both first and last names so they can apply for a passport which requires those fields to be filled.
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. 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. And that's reason enough to reject such emails outright, without even bothering with the usual validation flow.
- 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?