GDPR related sign-up changes

[simonpoole]

I'm doing some work on this and we need some place to discuss and document. I expect that this will be one of the things that can happen rather sooner than later, once we've hammered the details down.

• revised privacy policy and better display on sign up page (following the current trend likely the most important points mediately visible and a link to the full version)
• same for ToU likely incorporating the current API ToU with expanded privacy section
• the above will fail on mobile due to the limited screen space (need a solution for that)

Open questions:

• should we add a check box that the terms have been read (LWG)?
• opt in for receiving non operational mass messages (simply because we are re-jigging things, LWG)
• we want to make sure that everybody has seen the new terms, instead of inventing a new mechanism, what about zero hour blocks (has some drawbacks obviously)

[pnorman]

we want to make sure that everybody has seen the new terms, instead of inventing a new mechanism, what about zero hour blocks (has some drawbacks obviously)

Don't we have a mechanism from the CT change where people had to to agree before editing? Could we adapt that to make sure people have "signed" the privacy policy.

This is probably a more general problem - we need a way to make sure people see a policy change before continuing to use the site. Most sites have these fairly frequently. We do better, since we're not trying to collect all kinds of invasive data, but we can still expect future changes.

[woodpeck]

I have recently toyed with the even older "you have to agree to not be anonymous any more before you can edit" feature, and that at least is still fully functional.

[gravitystorm]

The CT signup process still works, in that if you still have a non-CT account and try to do things you have to accept the CTs first.

I'm against "re-using" existing code directly. It would be a nightmare if the code is covered in references to the contributor terms, but it had been repurposed to being acceptance of a ToU. For example, you can send messages and still be logged in and all sorts without agreeing to the CTs, but what we're proposing here covers much more of the site (e.g. read-only API requests).

I'd also like to avoid adding a zero hour block to every user - it would certainly pollute the list of user blocks somewhat!

I think what needs some clarity is:

• Do we need to store a confirmation that the privacy policy has been agreed to? Boolean or timestamp?
• How should we handle future privacy policy changes - do we just blank the 'privacy_policy_agreed' column every time we change the policy? Or do we need to track versions and agreements for each version?
• Do we need to handle the API ToU agreement separately, or is there just one agreement to cover both privacy policy and API ToU?

[simonpoole]

There is no meaningful way to "agree" to the privacy policy (it will essentially be an one sided statement) and we want to avoid any thing that could be interpreted as Consent. However we do want a checkbox for terms of use.

IMHO (but just that) showing a "must at least look at" message functionality before continuing is something we should have in any case, but because it is not necessary to use the website at all for contributing (one of the things we learnt during the licence change), I don't see a way around the same behaviour as a zero hour block (aka blocking the API till the message has been looked at).

[gravitystorm]

OK, so as I currently understand it:

• We need to show everyone the new privacy policy one-time on signin, but with no agreement tickbox
• We therefore need to store if they've seen the privacy policy, so we don't show it on every login
• We need to show everyone the new ToU on signin, with an agreement tickbox
• We therefore need to store if they've agreed to the ToU
• We need to block API access, both read and write, until both documents have been viewed/agreed
• We need to amend the signup form, so that it shows the new privacy policy, and we store that they have seen it (so they aren't affected by the implementation of the first task in this list)
• We need to amend the signup form, so that they agree to the ToU (with a tickbox, again stored).
• For the above agreements, storing a boolean is fine. If we need to get a fresh agreement in future, we can null out the columns for all users and that will re-trigger the blocks/signin displays

I think we should start by implementing the signup flow changes, and then we can phase in the rest (e.g. showing things on signin to the website, then eventually adding the api block unless already seen/agreed at signup or signin).

[simonpoole]

Looks good to me.

Note: there is no hard requirement that we show the full privacy text on sign up (and in the end the same goes for existing accounts).

I would suggest that we present the couple of most important points plus a link to the policy, so not too much different than the current signup page (which is a good place in any case as it gives the user a fighting chance to choose a non-revealing user name).

What we -do- have to do is add an easy way to find the policy on/from the website, needs a bit of thinking too.

[pnorman]

What we -do- have to do is add an easy way to find the policy on/from the website, needs a bit of thinking too.

Many websites have a legal section. At one time during the big website look and feel change our current copyright page was called license or legal, which I didn't like because the copyright of OSM is a core feature of it. Perhaps we need a page for other legal, but I don't know where we'd put the link.

We do have a general problem that there are pages on the site that are undiscoverable, e.g. /fixthemap

[1ec5]

We need to show everyone the new ToU on signin, with an agreement tickbox

#6610