GDPR compliance

[JP5457]

three main features: -A mandatory privacy policy that users must accept on their first attempt to login -the ability to opt into and out of account deletion -php scripts for emailing users eligible for deletion and for deleting users

[LordAro]

I reiterate - once you implement this, you cannot undo it. You should be very very sure the data that is being deleted is only what's desired. Have you checked backups (and restoring from those backups) recently?

[LordAro]

Since I can feel the inevitable "because GDPR" response, I'm going to point you at https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/the-principles/storage-limitation/

You can keep personal data for longer if you are only keeping it for public interest archiving, scientific or historical research, or statistical purposes.

Delete the bits that are not needed if you feel you must (I'm trying not to think about why is_wheelchair stored at all), but my view is that the database is primarily covered by the above and should not be touched

I feel the need to say that I'm not opposed to deletion in general - I'm the one that deleted the 'gender' field from the database after the thorny question of how that should be represented came up. The answer was of course that we didn't need it and so shouldn't be keeping it. And that was before GDPR...

[adfw]

To put my tuppenth' worth in, since the initial GDPR regulation came about when I was Head of Computing in 2016 (e.g. it got passed and appeared upon the horizon), think a discussion was briefly held... (it certainly later led to the "why do we record gender" discussion as @LordAro mentions above).

Just to stick my nose in here too, I think there are several 'classes' of members you might want to consider before doing this:

1. Members who signed up but never presented a show or did anything substantive (e.g. signed up at freshers fair, maybe got studio trained but progressed no further)
2. Members who never presented a show but perhaps were on a team, had a committee position (perhaps rare, but certainly historically there were for e.g. a few people in the technical teams who never had a show)
3. Most importantly, members who were studio trained and presented shows

For 1., I fully agree that under GDPR those members details are fully deprecated, no longer need to be held, and there is no good reason to hold such data - agreed that given a grace period, their details should be removed. For 2., I think there is a reasonable argument that if a member held a position of note in the society (e.g. was on committee), that the society should keep a record of such. For 3., If a member in the database appeared in a show (there may be debate as to how 'important' they are - e.g. presenter, engineer, guest?), and given that URY has always been a broadcast radio station, those members should be fully aware that their participation and being a presenter (or similar) on a licensed broadcaster in the UK, then there is a reasonable 'public interest' in keeping a record, at a minimum, of their appearance on the schedule.

That does not mean that a Subject Access Request, or a Deletion Request, can't occur and those details be made non-public, but my view would be that by presenting on a broadcast radio station, you lose a certain amount of right to privacy at a very high level - e.g. show credit. Mixcloud recordings, photos etc. should of course be deleted on request.

I would also note that any email is unlikely to reach many people who didn't update their contact email address after leaving UoY, and their york.ac.uk account will now go nowhere.

I would certainly see if any advice is available from Ofcom on this in terms of retaining data about presenters beyond the statutory 48-day logs retention period - I would suggest contacting them for advice.

Happy Compliancing, Anthony URY, 2011-2016

[LordAro]

Also come on dude, commit messages are there for a reason

[JP5457]

Also come on dude, commit messages are there for a reason

I'm sorry if you're getting notifications when I commit. I'm commiting a lot because its by far the easiest way to get code onto myradio dev.

[LordAro]

Sounds suspiciously like an actual staging environment :o (though I might suggest actual dev work should be done on your local computer first)

Back in my day we just edited it directly on the server. Often production itself. waves walking stick

[LordAro]

Still, it's not the notifications I'm bothered about - future you will thank past you if you actually write out what you're doing. Helps reduce the "why on earth is that there" factor that inevitably happens months (or weeks or days or hours) later

[michael-grace]

This is why we do rebasing when it's ready. Myradio is difficult to work on locally, so we have testing versions on server. We do care about what commit messages end up in history.

[JP5457]

I've made some significant changed to how this works:

• users now have the option of hiding their details in MyRadio
• automatic deletion now only deletes a few unnecessary columns
• script for deleting almost all data from users that explicitly request deletion

In the meeting we decided that any data visible on ury.org.uk we could defend keeping because it is required for the website to function as advertised.

[ColinRoitt]

Future non-essential changes moved to https://github.com/UniversityRadioYork/MyRadio/issues/1137