I can see how this might be surprising for people, but it's also basically how email has always worked -- so it's a bit weird to ding Gmail for it. The address book would need to have two entries for names: one for you to type as a shortcut, and one to put on the outgoing message.
I'm trying to work out how the author came to the presumption that contact names would ever be private. As in, what other software are they using where that would be a standard feature?
The closest I can come to is _maybe_ SMS where names never transit the system, only the phone numbers. So whatever name you associate to a number in your phone stays in your phone.
> what other software are they using where that would be a standard feature?
In WhatsApp I can give a contact name to a number but I don't believe anyone else sees it. Even if I tag them using @ in a group chat - I suspect that everyone just sees the name that they've set for that contact.
It's always interesting when you get a glimpse into a foreign way of thinking about the world. It makes sense that someone for whom email has always been a process of interacting with a website might not realize that the "to" line is really just a free-form text field, and that all apparent structure is being applied ad-hoc by the client. But are you even thinking about email as something which has a client, if you're using GMail? I can see how it would be reasonable to imagine that the big mystery machine which appears to control the whole process would have some master database of email addresses in it somewhere.
I mention in the post that, if nothing else, this feels more like a UX failure.
Yeah, this _is_ expected behavior, but at the same time I think will catch most people off guard, especially people who aren't as technically inclined.
It's kind of impressive how much this post exposes how little knowledge the author has about email. Not the best look for someone who is trying to get hired for their dev skills.
A lot of people don't realize that any sort of verification for email isn't part of email, but came later. SPF and DKIM help, but they're relatively new and still not required.
Wasn't that long ago you could set your FROM header to whatever you wanted and be pretty sure the email would be received.
Billy Mays with OxyClean here and you can't be 100% sure I'm not! This next email trick will shock you.
People come from mobile contact apps, where it's normal to call contacts "Mother of <kids classmate>", "Sara Mobile New 2025", or "Hot Wife".
Now "unified messaging" tries to blur the lines between technologies and I completely understand that people expect that only the necessary information (the email address) is leaving their devices.
So maybe it's time to change the default behavior of email clients?
Related: If you send an e-mail to "Some Name with something interesting" <a.person@company.org> and company.org runs Microsoft Exchange and a.person@company.org is in Active Directory, then Exchange will erase "Some Name with something interesting" <a.person@company.org> and replace it with a pointer to Active Directory and you will never see "Some Name with something interesting".
Like the opposite effect as discussed here. o365 is probably doing the same
At some point in the past, while we were dating, I had my wife's phone and changed my contact name to something far more risqué than "Hot Wife". I called her, she saw it come up, we laughed, she changed it back a few days later.
My primary email address was <[first].[last]@gmail.com>. But somehow this name got associated with <[first][last]@gmail.com>. Google notoriously ignores dots in your email address most of the time, but apparently not all of the time. Google Contacts does all sorts of magic when merging multiple contacts as one. Structurally my wife had two contacts for me with different email addresses, but the UI was merging them into a single display contact. Since we used the form with the dot in it, nobody noticed....
... until about 10 years later. We were now married, had kids, and we're in the process of interviewing to hire an au pair (a live-in, foreign exchange nanny). My wife emailed a prospective au pair, the agency, and CCed me, but fat fingered the email address without the dot.
We were dropped by the au pair agency and had to go with a different one.
The vCard RFC 6350 includes the property "nickname". Apple's "Contacts" uses this standard. You can use "nickname" for searching and in my testing the "First Last" fields are used when sending email. The nickname is what is displayed in iMessage and when receiving a call.
I can see how this might be surprising for people, but it's also basically how email has always worked -- so it's a bit weird to ding Gmail for it. The address book would need to have two entries for names: one for you to type as a shortcut, and one to put on the outgoing message.
I'm trying to work out how the author came to the presumption that contact names would ever be private. As in, what other software are they using where that would be a standard feature?
The closest I can come to is _maybe_ SMS where names never transit the system, only the phone numbers. So whatever name you associate to a number in your phone stays in your phone.
Email has certainly never worked that way.
> what other software are they using where that would be a standard feature?
In WhatsApp I can give a contact name to a number but I don't believe anyone else sees it. Even if I tag them using @ in a group chat - I suspect that everyone just sees the name that they've set for that contact.
My phone is how I track most of my contacts, so it makes sense to me that someone would assume email contacts work the same way.
I’ve was surprised by an email that revealed my saved contact name recently, and I used to work for an email company.
It's always interesting when you get a glimpse into a foreign way of thinking about the world. It makes sense that someone for whom email has always been a process of interacting with a website might not realize that the "to" line is really just a free-form text field, and that all apparent structure is being applied ad-hoc by the client. But are you even thinking about email as something which has a client, if you're using GMail? I can see how it would be reasonable to imagine that the big mystery machine which appears to control the whole process would have some master database of email addresses in it somewhere.
I mention in the post that, if nothing else, this feels more like a UX failure.
Yeah, this _is_ expected behavior, but at the same time I think will catch most people off guard, especially people who aren't as technically inclined.
It's kind of impressive how much this post exposes how little knowledge the author has about email. Not the best look for someone who is trying to get hired for their dev skills.
> Issue a warning or otherwise make it clear before sending when a contact name differs from the email's official sender name.
An email [address] does not have an "official sender name", so it is impossible for anyone to do what the author is suggesting Google should do.
The behaviour is potentially unintuitive, but also an almost inevitable result of how email has always worked.
A lot of people don't realize that any sort of verification for email isn't part of email, but came later. SPF and DKIM help, but they're relatively new and still not required.
Wasn't that long ago you could set your FROM header to whatever you wanted and be pretty sure the email would be received.
Billy Mays with OxyClean here and you can't be 100% sure I'm not! This next email trick will shock you.
People come from mobile contact apps, where it's normal to call contacts "Mother of <kids classmate>", "Sara Mobile New 2025", or "Hot Wife". Now "unified messaging" tries to blur the lines between technologies and I completely understand that people expect that only the necessary information (the email address) is leaving their devices. So maybe it's time to change the default behavior of email clients?
Related: If you send an e-mail to "Some Name with something interesting" <a.person@company.org> and company.org runs Microsoft Exchange and a.person@company.org is in Active Directory, then Exchange will erase "Some Name with something interesting" <a.person@company.org> and replace it with a pointer to Active Directory and you will never see "Some Name with something interesting".
Like the opposite effect as discussed here. o365 is probably doing the same
I was bit by this really hard.
At some point in the past, while we were dating, I had my wife's phone and changed my contact name to something far more risqué than "Hot Wife". I called her, she saw it come up, we laughed, she changed it back a few days later.
My primary email address was <[first].[last]@gmail.com>. But somehow this name got associated with <[first][last]@gmail.com>. Google notoriously ignores dots in your email address most of the time, but apparently not all of the time. Google Contacts does all sorts of magic when merging multiple contacts as one. Structurally my wife had two contacts for me with different email addresses, but the UI was merging them into a single display contact. Since we used the form with the dot in it, nobody noticed....
... until about 10 years later. We were now married, had kids, and we're in the process of interviewing to hire an au pair (a live-in, foreign exchange nanny). My wife emailed a prospective au pair, the agency, and CCed me, but fat fingered the email address without the dot.
We were dropped by the au pair agency and had to go with a different one.
Thank you for sharing this retrospectively hilarious story.
The vCard RFC 6350 includes the property "nickname". Apple's "Contacts" uses this standard. You can use "nickname" for searching and in my testing the "First Last" fields are used when sending email. The nickname is what is displayed in iMessage and when receiving a call.
This is basically how every mail client (MUA) works, everywhere. You'll see the exact same behaviour with Outlook and MS 365, etc.
This is by far the humblebraggiest of any security incident report I've seen
Seemed like the opposite to me, they're outing themselves