Consider enforcing the privacy policy we come up with, with a CSP rule. If there isn't a task for that yet, perhaps we can create one for it. That way, in the event a misconfiguration, bad upgrade, or misunderstood plugin, etc. causes a third-party connection we will have a task for "New thing didn't work, let's figure out why" or "Fix X before re-trying upgrade" instead of "Oops, we're leaking data, how long will we let it sit like that?".

We currently have a CSP rule on Phabricator, WordPress (techblog), Jenkins, doc.wm.o, and various other services. I don't know if we can include it yet in the standard expectation for new services in production, but perhaps it's time that we make it so.

In T285354#7171268, @Krinkle wrote:

Consider enforcing the privacy policy we come up with, with a CSP rule. If there isn't a task for that yet, perhaps we can create one for it. That way, in the event a misconfiguration, bad upgrade, or misunderstood plugin, etc. causes a third-party connection we will have a task for "New thing didn't work, let's figure out why" or "Fix X before re-trying upgrade" instead of "Oops, we're leaking data, how long will we let it sit like that?".

We currently have a CSP rule on Phabricator, WordPress (techblog), Jenkins, doc.wm.o, and various other services. I don't know if we can include it yet in the standard expectation for new services in production, but perhaps it's time that we make it so.

Let's tackle that work in a separate task. The scope here is specific to GitLab Sign-in Restrictions.

@brennen has updated the sign-in restriction with a link to our code of conduct governing technical spaces and our General disclaimer.

I'll try to do some digging about what else may be needed (for example, I note phabricator has a terms of use policy).

In T285354#8677941, @thcipriani wrote:

@brennen has updated the sign-in restriction with a link to our code of conduct governing technical spaces and our General disclaimer.

Sign-in text under Sign-in restrictions on https://gitlab.wikimedia.org/admin/application_settings/general itself is empty.

https://idp.wikimedia.org/login (IDP, CAS-SSO) used to log into GitLab has a footer with Privacy policy, Terms of Use, Code of Conduct. I do not see a link to a General disclaimer.

Signup for a developer account at https://idm.wikimedia.org/signup/ (IDM, Bitu) says "The email address you associate with your Wikimedia developer account will be publicly visible." and email address is required. However, linked IDP's Foundation Privacy Policy says "Register for an account without providing an email address or real name." which seems to contradict.
Making IDP link to https://foundation.wikimedia.org/wiki/Policy:Non-wiki_privacy_policy might be more appropriate - should that be a subtask? (Disclaimer: IANAL, this is a similar problem to T214251 which recewived input from WMF Legal)

I boldly set the "Sign-in text" in GitLab to the following line:
By signing in you agree to the following terms and policies: [Privacy policy](https://foundation.wikimedia.org/wiki/Policy:Non-wiki_privacy_policy) • [Terms of Use](https://foundation.wikimedia.org/wiki/Policy:Terms_of_Use) • [Code of Conduct](https://www.mediawiki.org/wiki/Code_of_Conduct)

1. Go to https://gitlab.wikimedia.org/
2. Select "Sign in" in upper right corner
3. End up on https://idp.wikimedia.org/login
4. Enter credentials
5. Text is correctly displayed on 2FA page:

I also propose to add a default license in the same place, because stuff in https://gitlab.wikimedia.org/explore/snippets etc.:
..., and you agree to content being licensed under [Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0](https://creativecommons.org/licenses/by-sa/4.0/) unless otherwise noted; code licensed under [GNU General Public License (GPL) 2.0](https://www.gnu.org/licenses/old-licenses/gpl-2.0.html) or later and other open source licenses.

In T285354#9330068, @Aklapper wrote:

I boldly set the "Sign-in text" in GitLab to the following line:
`By signing in you agree to the following terms and policies:

I think Legal should give the nod to that text before deploying (or retroactively if they're quick). By saying "you accept these terms.." etc. you're effectively asking users to enter into a contract, and since we're talking privacy policy it's also important to Privacy (i.e. strategic/legal). Even if it's just reaffirming that an already established blanket policy applies here too, it should be Legal that nods sagely and says "Yes, indeed, that policy is the one that applies here and the surrounding text presents it correctly".

Or put another way, I don't think technical type people should make decisions about this stuff on their own any more than lawyers should +2 a patch to core: the issue is not within their skillset or within the scope of their responsibilities.

(I have no opinion on the actual text; at a quick glance it seems reasonable enough.)

@Xover: That makes sense, and I am sure confident that the input from WMF Legal on T214251#9294048 also applies here when it comes to the appropriate Privacy Policy.

@brennen, @Jelto: Any of you know if settings set under https://gitlab.wikimedia.org/admin/application_settings/general might get overwritten by some Puppet magic (or something like that), or if they are permanent? TIA!

Final text set under https://gitlab.wikimedia.org/admin/application_settings/general#js-signin-settings :

By using this site, you agree to the [Terms of Use](https://foundation.wikimedia.org/wiki/Policy:Terms_of_Use), [Privacy policy](https://foundation.wikimedia.org/wiki/Policy:Non-wiki_privacy_policy), and [Code of Conduct](https://www.mediawiki.org/wiki/Code_of_Conduct).

Content licensed under [Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0](https://creativecommons.org/licenses/by-sa/4.0/) unless otherwise noted; code licensed under [GNU General Public License (GPL) 2.0](https://www.gnu.org/licenses/old-licenses/gpl-2.0.html) or later and other open source licenses.

In T285354#9330060, @Aklapper wrote:

@brennen, @thcipriani: Is setting the "Sign-in text" field in the GitLab admin settings UI permanent or does this also need to land up in some Puppet etc place?

This seems like the only place this is set, digging through the code a bit.

Note, in 16.2 these fields are deprecated ( see "sign_in_text" here: https://docs.gitlab.com/ee/api/settings.html), it seems like you need to use the "appearance" api now: https://docs.gitlab.com/ee/administration/appearance.html#sign-in--sign-up-pages

To the content, the content you've set seems aligned with our other tools in this space.

We don't set sign_in_text in the config for application settings API (see gitlab2002.yaml for example). And yes there is a deprecation warning for that field in the api:

Deprecated: Use description parameter in the Appearance API. Custom text in sign-in page.

Luckily in T349167 I started to work on a script for the appearance API as well (MR, if that's merged it should be quite easy to set the text programmatically there as well. In the appearance API the field is called description and described as:

Markdown text shown on the sign in / sign up page

jelto opened https://gitlab.wikimedia.org/repos/releng/gitlab-settings/-/merge_requests/53

add terms of service and privacy policy to description

jelto merged https://gitlab.wikimedia.org/repos/releng/gitlab-settings/-/merge_requests/53

add terms of service and privacy policy to description