Extend static content relating to data protection (DPA) / GDPR

[philosophicles]

Result of #122. The main aim of this issue is changes and additions to static wording held in twigs, not code logic changes. Unfortunately I'm not very specific in all aspects below - figuring out the specifics is part of the task.

Some of these changes may require communication to users as a result - compare to any large site like eBay or Facebook that notifies users when key policy wordings change. Probably implied consent - "we've told you, up to you to act if you don't accept the changes". Therefore, in case any non-Camdram admins have an urge to work on this, please keep the site admins involved so user communication can happen in a timely fashion relative to any pull requests.

Most relevant page is: http://beta.camdram.net/privacy.

• the Cookie part is recent and Good
• the Privacy part may not be
• there are things missing that the DPA / ICO suggests should be stated, for example who the data controller is. (not an exhaustive list)

This page needs to describe more accurately, completely and clearly (in plain English) what Camdram currently does, and other things we may reasonably do in the future that would still fall under fair, reasonably-expected usage. Some comparison to other websites' legal/privacy sections will be helpful for this, although clearly we only need to include what is relevant to our situation.

We are also missing (AFAIK) any Terms and Conditions that users must agree to. These need creating and need to collect implicit or explicit agreement during user sign up (e.g. a tickbox and link). (Also address retrospective agreement for existing users.) This should contain anything to do with general "userness" and more importantly any terms/conditions associated with show/venue/society type administration - the kinds of devolved admin rights that come with power and responsibility, that full site admins aren't involved with granting most of the time.

We also need some amount of words (I don't yet know what form these will be best in - "code of conduct"?) covering extra terms, conditions, obligations etc that full site admins agree to adhere to. Full Admins are a small, slowly-changing set of people so the requirement is very different here, and does not need to be as formal. It would be good to transparently tell end-users that full admins do get full access to the database and that we agree not to do anything silly with it. (An extreme example - making clear that Camdram as an organisation would disavow any admin who sold the data on to a random third party.)

Lastly, there may be room for brief additions to various existing twigs for situations where new data is being collected into Camdram, or used in particular ways, to inform end users of their obligations. The example I have currently is when adding show participation info (cast/crew lists) - the user adding this info should have checked that the people concerned are OK with their names going on Camdram, or be confident that those people actually expect the data to land on Camdram. So a brief 1-sentence "have you checked...?" type addition in the right place would make clear the responsibility for this.

[hoyes]

An idea I had related to the last paragraph - we could oblige producers to give an e-mail address for each person they add to a show, which we would only use (if we don't already recognise the e-mail address as belonging to a Camdram user) to send a message notifying them that their name is now on Camdram (which could have a subtle 'opt out' link perhaps), and we wouldn't store the e-mail address permanently. Such a thing could have other advantages too (disambiguation, driving people to sign up to Camdram), and I'm guessing producers need people's e-mail addresses anyway so it wouldn't be too much of a burden. Or would collecting extra personal info create more problems than it solves?

[philosophicles]

I think that's a great idea @hoyes, something similar had occurred to me when I did the original DP review action. I also agree we would need to double check that this wouldn't "create more problems than it solves" as you suggest - I don't think it would, especially if we don't actually write that email address to the database at all.

However, I currently see the scope of this issue as falling a bit short of that as a new feature - to implement that would definitely be a new feature, not just changing some words. If it's OK with you, can we let this new feature slide for now? It falls under a more general banner of "making more effort to inform the 'person' (who is not necessarily a user) about their name being publically listed". I don't want this issue to get blurred with that theme, which will need more discussion separately, once we've got the things in this issue sorted. (I am keeping track of later tasks like this, elsewhere.)

[hoyes]

OK sure let's just add some words for now, and I'll park that idea alongside all the others...

Thanks again for looking into all this.

[philosophicles]

General note - the recent informal review of GDPR compliance that was conducted over email with the Camdram admins should also be considered along with all the above.

[CHTJonas]

A thought that's come up from a conversation I've had with someone today who is concerned about the availability of location/time data on Camdram: any access to API or web UI should require the user to login/authenticate with an account, or register a new account etc.

I'm not sure I necessarily agree but thought I'd post it just so there was some representation of the viewpoint 😄

[CHTJonas]

From @stumo's email to webteam.

Some concrete things it's probably worth doing:

• Add a link to the privacy policy on the user signup email
• Add to the privacy policy any extra things we're likely to ask for as part of removal, if that will make our lives easiest.
• Add a reminder where people add this data that they should be getting people's consent, and if anyone's under 18 their parents consent too. (Remember some students arrive at Cambridge age 17).
• Potentially have an internal annotated version of the privacy policy that has what we do in certain situations in practice

[CHTJonas]

@philosophicles also writes:

The other thing I've been thinking for a while, but never got anywhere with, was that perhaps we should have some more explicit text on show pages that is seen by a show admin who is about to add show credits.

Something in the gist of "Remember to get permission from the people you're adding here, to be sure they are OK with their names being public on this website. It's your responsibility to have obtained this permission." (That's terrible wording, but you get the idea.)

@alexbrett points out that with GDPR both the controller and processors are liable, thus we can't just entirely pass the buck on data protection to societies/producers.

[CHTJonas]

@philosophicles I can see you assigned this to yourself. Are you alright if I take a look at this and add a few bits of static content/rework the privacy policy a bit? I'll submit a pull request with my changes so we can all comment on changes to wording etc.

[philosophicles]

Please go ahead! I did do some work on this back in 2014 (maybe into 2015) but not since GDPR. Thank you for restarting some momentum on this.

[GKFX]

A thought that occured to me recently is that development.camdram.net (let’s say anything showing the develpment warning) needs a completely different privacy policy. E.g.

Privacy warning

You’re browsing a developers’ copy of Camdram. By default, anyone can log in as an administrator. This means that any personal data that you enter may be visible to the public.
For example, if you create an account with your Google account, third parties may see your Google email. Do not enter any personal information into this copy of Camdram unless you are happy for it to become publicly known.
If you’re looking for the real Camdram website, which does seek to protect your privacy, go to https://www.camdram.net.

There should then be a link from the development banner to the privacy policy.

[GKFX]

Also to address @CHTJonas’s point about Camdram telling the public where people will be at a given date and time: that’s a significant reason why producers need to get consent before adding people to shows. It might be worth spelling out to producers in the UI that some people legitimately do not want this in the public domain, or at least not until it’s in the past.

[philosophicles]

By default, anyone can log in as an administrator.

For example, if you create an account with your Google account, third parties may see your Google email.

Slightly off-topic but how will anyone log in to the https://development.camdram.net default accounts (the ones detailed in our README) once passwords are completely gone away?

Or to put that another way, how will anyone then be able to log into https://development.camdram.net without using a personal Google/Facebook/Twitter/Raven account (that won't have admin access)?

[CHTJonas]

☝️ Answered in #394