search

ckan / ideas

[DEPRECATED] Use the main CKAN repo Discussions instead:
https://github.com/ckan/ckan/discussions
40 stars 2 forks source link

Anonymize publisher users #105

Open davidread opened 10 years ago

davidread commented 10 years ago

User accounts are public on CKAN, yet when CKAN is used by governments these are civil servants who should not be disclosed.

e.g. look at an activity stream and it says who created it - even the username could have a personal name in and that should not be public. Also, you should not be able to click on the user to see what else they have done. And you should not be able to see a list of all users at /user.

The original premise behind making user accounts public, was that CKAN was a social network, like github. However I think government administrators just doing their job should not be identified by default. Showing people's names doesn't seem right e.g.: http://data.glasgow.gov.uk/organisation/activity/british-transport-police

So I propose that anyone with an admin or editor role should be shown publicly as "Admin for Cabinet Office" or something. And if you have a role with Cabinet Office then you can actually see the exactly who it was. If there are sites that genuinely want to make admin/editors public then maybe we need a config option to do this?

This is basically what data.gov.uk has implemented in its templates and hacks to CKAN core. data.gov doesn't have users because it harvests. I believe Canada ends up stripping out users in its harvest.

adamamyl commented 10 years ago

However I think government administrators just doing their job should not be identified by default.

There's a degree of accountability here, but with the demise of the faceless bureaucrat approaching, there's an interesting culture shift. Ideologies aside, I think the guidance that Barnet are using --

"if the officer is on the published organization chart, their contributions can be directly attributable."

For others, it's a case of general unit level accounts. I think this is a good solution (social, not technological).

OTOH, I think it might be useful if there were an option to set the (activity|users)' list/api calls:

I think there will be issues if org editors can't see the users (how else will they add people -- assuming orgs are used).

davidread commented 10 years ago

Accountability needs to be the public body, not the individual. Only really senior people are named publicly, and in our experience they are not the people editing datasets. So in the cases I know about, every time privacy overrules accountability.

Creating unit-level user accounts is not something that suits data.gov.uk - can you tell me any sites which it does suit? Also I don't think there is any precedent for this in any groupware software. If all the users in a group have the same password, what happens when one person asks for a password reset - do they have a group-level email account too. Are we demanding that all our government users must have unit-level email accounts that all users have access to too? I just don't see that option as thought through.

I think it is overly ambitious to code 8 different possible configurations of this. We should simply establish what would be best for most websites, and if there is no way we can satisfy everyone provide an option.

I guess you could call my proposal as "org members upwards". Can you say whether that would suit the CKAN projects you've been involved in or not?