I fear this is likely an ipsilon issue as all our apps now authenticate through it, so chances are that the same problem will exist with the FAS replacement if ipsilon is not able to check that checkbox.

@abompard @ryanlerch this ticket may interest you.

I was thinking that maybe we could tell noggin to return fullname == username if privacy is checked, but IIRC ipsilon will hit the ldap server directly, so the logic needs to be in ipsilon.

In the new FAS replacement, we have dropped most (but not all) the fields that were covered by the "privacy" setting, so this setting was removed. I haven't seen a requirement for the new system to have this kind of setting. I think it could be done, but it means an LDAP schema change, and a new feature in fasjson, noggin and the fas2ipa migration script (Ipsilon will get its data from fasjson).

Are we sure we want to bring back that feature?

Yeah, we probably need this feature.

Yeah, there are legitimate reasons that a contributor may want to keep their personal information private, in accordance with our privacy policy.

Whether the information is just not passed to authenticating applications (which may cause problems for some services), or is anonymized in some way is less important to me. If we're going to materially change how we apply our privacy policy, I'll need to take that up with the law-talkers.

In the new FAS replacement, we have dropped most (but not all) the fields that were covered by the "privacy" setting, so this setting was removed.

Let's invert the question: What are the remaining fields in the FAS replacement?

• username
• email

What else?

• timezone?
• full name?

@bcotton if I understand correctly the link you've provided there, first and last names are considered public:

some personal data attached to Fedora accounts is made public by default. Specifically:

    your first and last name;

@bcotton if I understand correctly the link you've provided there, first and last names are considered public:

````
some personal data attached to Fedora accounts is made public by default. Specifically:

your first and last name;
````

Nevermind, this is the list of PI that is public if one does not check the privacy checkbox

I'm looking at that list on the privacy policy page, could someone explain what the "affiliations" are? I'm not sure.

@abompard That translates into groups you're a member of today, but it used to also include employer information (as in the really early days we collected that too).

I have created a feature request in Noggin to track this: https://github.com/fedora-infra/noggin/issues/363

I don't think we can prevent applications from knowing which groups a user is a member of, as this is what most of the permissions are based on.

I think just hiding the email address would work well enough for that, since it covers if you're employed by someone.

I don't think we can prevent applications from knowing which groups a user is a member of, as this is what most of the permissions are based on.

Agreed. I think the "affiliations" is probably irrelevant these days.

I think just hiding the email address would work well enough for that, since it covers if you're employed by someone.

I don't think that would work, since many applications would need to know the email address in order to function. If someone wants to hide their employer, they can use one of the myriad free-as-in-beer webmail services.

Well, in that scenario, we'd just return <username>@fedoraproject.org. That still exists and would work as a mask.

Well, in that scenario, we'd just return <username>@fedoraproject.org. That still exists and would work as a mask.

That's actually better by default in some (most?) cases. Some platforms make it hard to change your email if your FAS email changes. It took some wrangling to get Discourse, for example, to start sending email to my redhat address after I updated my email in FAS. It kept wanting to use the personal account that my FAS account formerly pointed to.

Well, in that scenario, we'd just return <username>@fedoraproject.org. That still exists and would work as a mask.

That's actually better by default in some (most?) cases. Some platforms make it hard to change your email if your FAS email changes. It took some wrangling to get Discourse, for example, to start sending email to my redhat address after I updated my email in FAS. It kept wanting to use the personal account that my FAS account formerly pointed to.

I seem to recall we did that at some point. Two potentials things with it: one of the issue is that that wrangling would now be imposed on everyone w/o opt-out, the second is that not everyone with a FAS account have the alias, you need to be CLA+1. So if you use id.fp.o w/o being CLA+1 and after being CLA+1, you may get 2 different email addresses which some system will recon as two different accounts (hey bugzilla, mailman...)

Maybe worth an RFE to noggin/fasjson to return the alias if the user asks it? Then they'll have to deal with the consequences but it would not be the default.

Maybe worth an RFE to noggin/fasjson to return the alias if the user asks it? Then they'll have to deal with the consequences but it would not be the default.

Ah, I knew there was a reason we didn't do something smart like that. I'll just pretend like I didn't say it for now and submit it as an RFE later if it seems super important.

We do not give out <username>@fedoraproject.org email addresses unless a person joins a group. We have a couple hundred thousand accounts which would get added to @fedoraproject.org who have only been used to 1 time post to discourse or found out that they could not spam the wiki anymore or send out spam emails as @fedoraproject.org [Which was the reason this CLA+1 was originally put in place.]

That said the vanity emails are going to be a problem from increasing DKIM/DMARC rules and will probably end up having some GDPR++ issue.

Note that the privacy policy says: "The only exception to this is for your email address, which may still be visible in some Fedora services such as Bugzilla"

Which IMHO, we should change to just say something like "Your email address is public information and will not be hidden by the privacy setting"

Anyhow, should we keep this open? Or just close it in favor of the upstream ticket to implement this now?

Yeah, I'll close this in favor of the upstream ticket.