Policies on U-Report (GDPR Compliance)

[johncordeiro]

This PR was a request from the Unicef team to enable super-admins to add Cookie Policy, Privacy Policy and Terms of Use in the U-Report platform. It will improve the GDPR compliance of the platform.

We designed it in a similar way of RapidPro does today, in this case, the only difference is that policies can be created in different languages and it will be displayed in the same language as the org that users are accessing to.

[nicpottier]

Seems that GDPR really only applies to logged in users no? Or at least could if google analytics was configured to not track IP for these orgs. Forcing every user through a GDPR click-through doesn't seem reasonable for a site that is read-only for 99% of users, the intent of GDPR would be that we just don't track anything for those users. (which I don't think we do, so shouldn't be necessary)

So this should really only apply for logged in users I think.

[yvesbastos]

Seems that GDPR really only applies to logged in users no? Or at least could if google analytics was configured to not track IP for these orgs. Forcing every user through a GDPR click-through doesn't seem reasonable for a site that is read-only for 99% of users, the intent of GDPR would be that we just don't track anything for those users. (which I don't think we do, so shouldn't be necessary)

So this should really only apply for logged in users I think.

There are cookies being used for authentication (top/bottom admin/login bars) and for social features due to social network integrations (Facebook/Twitter plugins). Because they are present in the public home page, the cookie warning must be present for all visitors if we are to be 100% GDPR compliant.

About the privacy policy and terms of use, it becomes essential when you look at U-Report as a platform that comprises several clients (iOS, Android, Web). There are a few key GDPR principles involved, the most important ones in this context being related to consent and transparency. The regulation implies that privacy policies and terms of use must be easily accessible at all times, so adding these to the public website are key to keeping users informed on how U-Report handles data and privacy. Specially in the context U-Report acts, bringing more transparency to such an important aspect as data security is genuinely a very good thing.

[nicpottier]

So I think there are three classes of users to think about, and privacy and compliance should be thought through completely for each:

1. Visitors to the U-Report website, which are neither contacts in U-Report nor admins of a U-Report dashboard. My argument is there should be no privacy statement needed for these users (and that is the goal of the GDPR) in that we do not track any PII for them.
2. U-Reporters themselves, presumably coming in via a link from a message, though perhaps just curious to know what the terms of use are. They can be satisfied by just having the privacy policy public, but there isn't any reason to make that a hijack click-through, they need to be "opting in" from a GDPR perspective via messaging (and have their consent recorded there / date etc..)
3. Admins for U-Report. We are getting data for these users, they need a hijacked privacy policy click through.

As I understand it, this PR is applying 3) to all users, which I don't think is appropriate. Am I wrong on that?

[yvesbastos]

Nic, thank you for your response and for contributing to this important discussion.

There's no regular and intensive data collection for regular, unauthenticated visitors of the website. However, the main page uses social network plugins to display that org's Twitter and Facebook feeds, as well as Youtube videos. Those plugins make use of cookies for each of those platform's own purposes, maybe for facilitating retweets, likes or saving video visualizations.
My point here is: the experience of a regular, unauthenticated user is enhanced by the webpage's cookies. They are there even if users do not login, hence users must be informed about that according to GDPR definitions.

Another point is how the home page works: it relies on cookies to properly layout the top bar admin options (only visible for admins with a valid session) or the bottom bar login button (for unauthenticated users). One more time, this is being used wether the user is logged in or just a visitor - even because using cookies is how I believe the page identifies previous authentication sessions. Please correct me if I'm wrong. Every time the page loads (by any type of user), authentication is verified and the proper home layout is displayed.

After long talks with Unicef and consulting with our legal team, the conclusion reached is that, if a web page depends on cookies to work properly, and all users are subject to that, then all users must be informed of its data policies. In this case, the page uses cookies to infer if users are logged in or not, are an admin or not and to provide integration with third-party providers.

I don't believe the correct manner to look at this matter is by putting users by type in buckets and proposing different approaches. Pages and systems are the ones that must be put into buckets according the data each portion of them collect or their role in providing platform policy clarifications.

[nicpottier]

For the plugins, are you sure these fall on us? We don't control these cookies, these plugins are iframes, so they are coming from Facebook and Twitter themselves (and the user has consented to those previously on those platforms).

An easy way to think about GDPR compliance is that if you are asking whether you have permission to do something, then you ALSO need to provide the user both a log of what you are keeping about them as well as a way of deleting any data you have collected about them. Just asking for permission isn't enough, and if you are asking permission then you are opening the can of worms of then having to provide detailed history for that person as well as clearing whatever you know about them.

Again for unauthenticated users, I think we can make some small modifications to not record anything at all, as well as not even use cookies, there's no real impact there. (assuming iframe discussion above is correct)

Totally agree that authenticated users need a click through though.

Again, let's please remember that the purpose of GDPR is NOT to have every site adopt click through agreements, but instead encourage websites to only collect data when it is absolutely necessary. The envisioned future is not that you click through some long ToS on every site you visit, but rather that sites stop collecting data as a matter of course.