A user's original email address is retained in the system even after they've changed it on all sites (privacy risk, potential Area 51 sync issues)

Question

To understand this report, first, let's have a look at the profile fields for setting one's primary email address in the system.

On most sites in the network, you'll find that option in Edit profile and settings and Edit email settings:

On Area 51, which uses a relic of the Stack Exchange engine as it appeared in 2011, you'll access the page on the info tab of your user profile, and clicking "edit":

You might think that both fields edit the exact same thing. But they actually edit two different fields. For clarity, I'll call them legacy field and notification field - you'll see why those names make sense later.

Before the notification system was completely reworked, there was just one email field in the system - the legacy field. This field existed on all sites and could be updated on all sites using a settings page similar to the Area 51 screenshot above, and was used for all system notifications as well as for Gravatar.

When the email notification system was completely reworked, a new email field, the notification field, was created, and is the field that is updated by the modern site screenshot above. This email address is the one used today for notifications. However, on all sites, the information that was previously retained in the legacy field was retained - it's no longer visible in the profile info to a normal user, and is visible only to moderators, but it's still there.

This, therefore, can mean that users who've registered accounts prior to the notification rework and have later changed their email address still have their prior email address stored - it isn't in any way shown to the user, neither is it editable. It also has the added side effect of not changing a user's Gravatar if they're using that (the Gravatar system still uses the legacy field).

Per the link above, this also affects users who originally joined using an unregistered cookie-based account and later registered their account - the email address used at the time of cookie creation is retained even if they register and change it in their profile.

Why are these two profile fields retained as separate fields, rather than being unified into a single field? It doesn't make much sense to me to retain them that way. If the concern is about Gravatar, then why not update the Gravatar system to use the notification field?

Also, can we please unify them into the same field on all sites? If that's not possible, can we clear out the contents of the legacy field for all users on all sites? I understand Area 51 can't be updated to use the new system, but it still has only one field, and it's directly editable.

---

Update after answer

It now makes sense to me why there are separate fields, and that the new notification field is verified and saved network-wide while the previous field is not verified and stored per-site.

However, the answer states this:

We can't just clear the field for all users. That would break a bunch of stuff for users who aren't concerned about it right now. [...] We can clear those obsolete Email fields on a per-user basis if a user is concerned about an old email address being attached to their account. All they need to do is ask.

Can we please make it clear to users changing their email address that if they want their prior email address to be removed, they'll have to make a request? This is not at all clear to someone who doesn't know the innards of the system (the person I linked earlier didn't know this until they curiously looked at their own profile with a moderator-only tool), and it would be very nice if this were made clear.

---

Update 2

I came across this bug report (closed as a duplicate of this as it's caused by the same thing reported here), in which when the user attempted to register for an Area 51 account, the separate email verification that takes place for that site specifically used an old email address that the user had since changed. This means that the process for syncing Area 51 accounts probably uses the legacy field (perhaps from the user's oldest account?) for linking the user's account there to their network account.

While in the case of the linked bug, it just ended up being a minor annoyance, this could be a real problem if the user doesn't have access to their prior email address anymore. It could also be the cause of other potential bugs.

Answer 1

You make quite a few incorrect assumptions when writing about this. I've written about this email field before in a few places, somewhere, but let's sum up the issue here:

The two email field cannot be "unified" because they are stored in completely different places. The old Email field was stored directly on the User, which means it could be different on each individual site. The new VerifiedEmail field is stored at the network account level. It is global and thus the same for all sites. These are completely separate tables in the database and accessed differently. It's not as if there are just two email fields stored in the same table. VerifiedEmail also goes through verification steps, as emphasized by its name, whereas the old Email field was just a free-form text box that you could type anything into. It would be irresponsible to assume that anything in the Email field is worthy of being in the VerifiedEmail field.

When you registered makes no difference whatsoever. Even for newly registered users, the old Email field is still populated for a variety of legacy reasons. New users just wouldn't ever notice until they decided to change their verified email address at some point.

The old Email field is considered obsolete and deprecated. We're not interested in keeping it forever. The plan is to eventually drop that column from the Users database completely - just erase it. We cannot do that until everything that uses that field is rewritten to somehow utilize the VerifiedEmail field instead. We've rewritten a lot of things to correctly use it, but there are still some oddities that have held us up. Gravatar wasn't so much an issue, but rather how to handle users who had different emails (and thus different Gravatars) from site-to-site. That functionality would no longer exist once we switch to VerifiedEmail, since it's not a per-site field anymore. The biggest issue regarding this is unregistered users. Because an unregistered account has no VerifiedEmail (they're not registered, it cannot be verified), that Email field is still the only way for us to tie it back to someone to potentially be registered or recovered in the future. As you've noticed, that system also isn't implemented at all in Area 51, where it still lets you directly edit the old Email field we're trying to get rid of.

We can't just clear the field for all users. That would break a bunch of stuff for users who aren't concerned about it right now. It would make more sense to just mass replace everything with VerifiedEmail and drop the column now, because it would be better to let everything be broken with an actual email address than to let everything be broken with a null email address. We can clear those obsolete Email fields on a per-user basis if a user is concerned about an old email address being attached to their account. All they need to do is ask.

That's not to say there's much of an excuse for why this work hasn't been completed yet. I bother people about it every few months because this Email field causes a lot of headaches for the support team in regards to user lookups and weird merge issues. It's just a really annoying thing to have lingering around, and we'd really love to see it disappear sooner rather than later. At one point I'd even suggested having the system automatically copy VerifiedEmail into Email on a schedule as an interim solution until the obsolete field could be dropped, but there were other issues with attempting to do that.

Answer 2

I want to add to the discussion, (hopefully @animuson♦ doesn't mind me quoting him)

We can't just clear the field for all users.

(...) All they need to do is ask.

I can fathom the inherent technical difficulties to this. However, I also think that providing a UI where users can remove the email by their own means -without having to send an email- is desirable.

The biggest issue regarding this is unregistered users.

I think a considerable number of users would welcome the ability to take care of this by themselves without needing another man-in-the-loop. It's a possible compromise solution (while less ambitious than an all-out system wide change) that would expedite a user drive change and immediately alleviate privacy concerns this may cause to a subset of users.

(A last argument would be that developer-time outweighs number of users who want this, but since it's a privacy issue we can say users would consider this priceless. Also, we should wonder how this scales, and how many users were left with a privacy concern over being off-put from sending an email.)