Closed Bug 1742251 Opened 3 years ago Closed 3 years ago

Improve email privacy and scope transparency

Categories

(Bugzilla :: User Accounts, enhancement)

Product:
Bugzilla
Component:
User Accounts
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 218917

People

(Reporter: 4i2mz0emy, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

Originally, I created an account here by Oauthing my github account (because why wouldn't I want to link that? Sure I don't develop MUCH right now, and certainly nothing of quality, but it's still a developer account). I noticed it asked for my email on the Oauth page, but thought nothing of it because most sites are smart and just use email for authentication needs. I quickly realized my mistake when I posted my first issue, and today finally got around to figuring out how to change my Bugzilla account's email without a password (it turns out I basically have to reset the password since, presumably, the password field on the account's database record starts out blank? Thankfully, resetting it doesn't deauthorize github). However, I'm still quite irritated that my email address was leaked in the first place.

Actual results:

My email was leaked for no discernibly legitimate reason. A bit of research led me to discover issues #163551 and #218917. The first was started 20 years ago, titled "implement complete email address privacy", and was closed at the implementation #218917.
#218917, however, does not really solve 163551's problem. The problem, as stated in 551's first post, is "I would like to be able to hide my email-address from any user using Bugzilla."; as it currently stands, you still need to reveal a working email because otherwise you can't confirm the email change.
I'm also concerned that, even 19 years ago, you knew you shouldn't be listing email addresses, yet you still do today. And furthermore, you tabled a long-term fix proposed by Mike Miller.
Quoting Stephen Lee (218917, issue description):
: Some such as Mike Miller, bug 120030 comment 47 felt that:
:: There's no reason to make it complicated. The system should never list email
:: addresses, period.

:: If someone needs to send someone a message, they should use the system, and
:: negotiate for email if they want.
: This may be a good long-term solution, but I would assert that the implied use
of an email contact form for this would be beyond the remit of this RFE, and
should instead be done as a separate enhancement later.
"the system should never list email addresses, period." Stephen quoted this 19 years ago! How much longer do we want to postpone a "long-term solution" that should've frankly been in the product AT LEAST 10 years ago?!
On a related note, I find the accusation in comment 19 of issue #163551 that "Mozilla and Bugzilla are in the stone ages of user privacy." to be both ironic and tragic, in that it was posted 12 years ago but you have progressed, at best, to the Bronze Age. You are still publishing email addresses, which have to be working email addresses (otherwise you can't confirm the change). Why? Why, why, why?

Expected results:

"The system should never list email addresses, period. "
And failing that, the user should be informed how their address will be used, so they don't assume it's "just for authentication" like I foolishly did.

actually, it looks like the wrong email is still showing on my account even after I changed it. Am I going to have to wait 3 days before Now That is corrected? In the meantime, I will politely request that no one mention my current email, no, not even in a "needsinfo" tag. please wait until that SHA256 for the email's first 11 letters is "a097ecbc47d6ba72de7e5bc5fb9cad651c6752888325438f577e3b19d9fd9088"; if anyone mentions my old email, I might disable this account and just not bother with it.

Wait, how did I end up switching accounts without switching accounts?
(To be fair, the token warning should have given me a hint, but I still... I just... I can't... with this site right now)

Bug 218917 will be fixed in upstream Bugzilla 6.0. Upstream Bugzilla 6.0 has not yet been released.
The website bugzilla.mozilla.org uses some heavily customized code version (before non-existing "6.0", obviously).

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

"closed 6 years ago"................ Dupe or not, that's awfully stale
Also I see me email from this account is still being leaked despite the reply I accidentally made as Twisted Code asking you not to perpetuate the leakage.
image
Is there any way, currently, to avoid this while still logging in with GitHub? I tried changing my email but it doesn't seem to have worked.

Okay my third attempt to change my email seems to have worked, changing it to one I got through Mozilla Relay. Thank you to anyone around here that contributed to Relay, by the way!
However, this work around doesn't address my original complaint (that email addresses are shown in the first place), and frankly I'm not sure if 218917 does either (that's focusing on making it possible to have different emails, but I want to be able to hide the address completely?); is reopening this out of the question?

(Not to mention my other major complaint: I'm upset that I was given no chance to know my address would be revealed until after I posted)

I still require clarification on how this is a duplicate of #218917. While I admit I have not read the entire thing (50+ messages worth of technical talk, much of which I don't understand at my skill level), at least based on the title, that seems like it's more about allowing email and login name to be different. Contrariwise, this item is about not requiring people to display an email in the first place.
I would like to reopen this until I understand the first, and preferably both, of the following:

  1. How this is a duplicate when, at least from what I read in the allegedly duplicated issue, the functionality I'm asking for was specifically excluded from that work item to be "done later".
  2. if it is a duplicate as claimed, doesn't that basically mean this has been a problem for 19 years? As in, we knew roughly 19 years ago that "email privacy is important", yet everyone is still required to give an email, which is displayed on all of their activities? how the hell does it take 19 years to make DISPLAYING your email optional?

Forgive me if any of this seems out of line, but I just can't wrap my head how this behavior makes any sense in the year 2021 (soon to be 2022). I just want to be able to report bugs. No one needs to contact me directly, and I only expected my email to be used for authentication.

sed 's/for 19 years/for 19 years, or at least 6 since that was closed/'
(this isn't meant to actually be interpreted as a command, or at least not by strict syntax. I'm just doing the next best thing I can to actually being able to edit my message. Which, by the way, is another absence-of-a-feature that makes this software seem dated)

Why do the above comments render as "1 month ago" when December was clearly > 1 month before February? Another thing on my pile of "why is this site's software so dated" sorts of questions.
Back to my yet-to-be-answered question: how is this a duplicate of a resolved issue if it itself is not resolved? In terms of a state machine, this makes no sense to me. I see the following possible states:
[VALID] issue A is resolved, issue B is not resolved/"new" and is not a duplicate (no association between the tickets)
[VALID] issue A is not resolved, issue B is not resolved and is a duplicate of A (both are work in progress in a sense)
[VALID] issue A is resolved, issue B is a resolved duplicate of A (this is what you are saying by marking this as resolved duplicate, but is not true. If it were, there would either be a warning on signing up with github saying "hey just so you know, anyone will be able to see the email address you share here", or else it would've been a "won't fix" resolution and everyone just has to deal with it, with much anger to go around)
[INVALID] issue A is resolved, issue B is a duplicate of A but not resolved (Error: there is no "duplicate, not resolved" status, because why would there be?)

Flags: needinfo?(default-qa)

how is this a duplicate of a resolved issue if it itself is not resolved?

Please read comment 3: It's resolved in the codebase of the Bugzilla software, and you filed this ticket under the product "Bugzilla". The installation hosted at bugzilla.mozilla.org is not being tracked under the product "Bugzilla".

Why do the above comments render as "1 month ago"

That's a different topic and irrelevant for this ticket. Feel free to file separate bugs as separate bugs.

Flags: needinfo?(default-qa)

(In reply to Andre Klapper from comment #10)

how is this a duplicate of a resolved issue if it itself is not resolved?

Please read comment 3: It's resolved in the codebase of the Bugzilla software, and you filed this ticket under the product "Bugzilla". The installation hosted at bugzilla.mozilla.org is not being tracked under the product "Bugzilla".

Why do the above comments render as "1 month ago"

That's a different topic and irrelevant for this ticket. Feel free to file separate bugs as separate bugs.

Oh, I completely misunderstood that! I didn't realize Bugzilla and bugzilla.mozilla.org were completely different things.
So if I wanted to refile this under a different product, i.e. this site, would that be okay (and not a duplicate)? And what product would that be (I'm a little lost in all the options)?

You need to log in before you can comment on or make changes to this bug.