26

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:

Email updating on modern sites

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":

Email updating on Area 51

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.

Improve this question
4
  • 2
    To be fair, I suspect that making the "feature" more clear/explicitly stated probably is not optional at all. As usual... GDPR.
    – SPArcheon - on strike
    Commented Jan 13, 2020 at 8:43
  • @Hitodama Meaning, it's mandatory?
    – Sonic the Anonymous Hedgehog
    Commented Jan 13, 2020 at 8:44
  • 1
    I think as now the current implementation could be seen as a)tricking the user into thinking they removed some info from the system while the info is still there and b) storing info about an user when there is no more reason to do that. But keep in mind that this is obviously IMHO and I am not a lawyer. What I actually meant is that it would be advisable for Stack to make the thing explicit directly on the profile page to protect them from potential problems in the future. The cost to do so is probably very small and they already said that they can remove the info on request.
    – SPArcheon - on strike
    Commented Jan 13, 2020 at 8:52
  • Basically, since they apparently already have a way to be "compliant" and remove the data if one should request that.... all it is left is to advertise it in an easily discoverable place. So, instead of having to search for this question on Meta (used by less than [insert arbitrary percentage] of the users some say :P) it will be clearly readable directly on your profile page.
    – SPArcheon - on strike
    Commented Jan 13, 2020 at 8:56

2 Answers 2

Reset to default
14

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.

Improve this answer
6
  • 6
    I've updated the question. tl;dr I understand the reasons for retaining it currently, but I want it to be made clear to users that if they want their prior email address removed, they'll have to request it.
    – Sonic the Anonymous Hedgehog
    Commented Jan 10, 2020 at 21:48
  • 1
    Eh, tbh, I think that would just flood us with a lot of requests from people who don't actually care and just submitted a request because the site said to. Most people who are truly concerned about this already figure it out in other ways and contact us about it, and we handle it for them. Many find it out through the account recovery system still working for their old email address.
    – animuson StaffMod
    Commented Jan 10, 2020 at 21:50
  • I've made another update. This issue could be causing certain users' Area 51 commitments to not count towards the 200+ rep total.
    – Sonic the Anonymous Hedgehog
    Commented Jan 20, 2020 at 2:15
  • 1
    @Sonic Your assumption is just wrong. It's not possible to create a second network account with the same email address. They'd never get past the registration process there without connecting back to their existing account, and all their activity. Try not to read into things more than what is actually present. Yes joining Area 51 still pulls from that old field, simply because Area 51 is super old and hasn't been updated to pull from something else yet, but that field is also still directly editable on Area 51.
    – animuson StaffMod
    Commented Jan 20, 2020 at 3:00
  • 1
    Ah, so that might not be a cause of the bug. So, then, what is the most common cause of someone creating an Area 51 account only to not have it tied to their network account? I've seen quite a few documented cases of that (in comments, chat, as well as off-site).
    – Sonic the Anonymous Hedgehog
    Commented Jan 20, 2020 at 3:17
  • 1
    @Sonic They'd have to use a different email address or encounter some other unrelated bug. Keep in mind that Area 51 now runs through the auth system on Meta rather than its own auth system, so a lot of older bugs are simply obsolete.
    – animuson StaffMod
    Commented Jan 20, 2020 at 3:20
3

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.)

Improve this answer
4
  • 2
    I think you underestimate the amount of work that would be required to build a full UI with proper explanations as to why a user would ever need that UI. I would much rather developers finally set aside the time to tackle the last couple of issues that are preventing the field from being dropped than waste time creating more UI to clear it out, which will inevitably have to be removed when the field no longer exists. I'm... also not clear on what the second quote has to do with the following text at all. Unregistered users are just the main blocker for why the field hasn't been dropped.
    – animuson StaffMod
    Commented Mar 1, 2021 at 17:57
  • @animuson 2 fair questions: 1º Is there a foreseeable solution for this? (Or is it dead-locked - and for how many years has it been dead-locked already?) 2º How do you quantify and weigh-in the concerns this caused to registered users? "Send an email" just doesn't seem like a solution in the small-hours when all a user wants is to clear out his PII.
    – bad_coder
    Commented Mar 1, 2021 at 18:08
  • 2
    This has been ongoing for a couple (?) years now. It's not a straight-forward "just do it" process. It's a "we've been slowly changing all the features that ever used that field" process and once all those features no longer use it, the field can be safely dropped. Unregistered users are just the one that hasn't been figured out quite yet.
    – animuson StaffMod
    Commented Mar 1, 2021 at 18:12
  • 2
    Sending an email takes 5 seconds, and then you wait until we have the 5 seconds to process it. I don't know why you are so against submitting a form when that is still the same process used for GDPR. I don't find "sending an email" to be an inconvenience to the user or a good reason why we would need a different process for this.
    – animuson StaffMod
    Commented Mar 1, 2021 at 18:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .