Id: Privacy Policy

[bhousel]

We've been working with @kathleenlu09 from the LWG on a privacy policy for iD which will bring us in compliance with the GDPR. Thank you Kathleen for all your work on this! 🙇

Though this work has been ongoing since September and this has been mentioned in other channels and in the LWG minutes, we should have an issue here for visibility too.

The key points for iD will be:

• Make the privacy policy available on GitHub
• Show a link to the notice at startup and require users to accept it
• Account for all the data that we collect about a user. While iD doesn't have a concept of "server logs", user activity does get saved as changeset tags, and this includes things like the user's name, count of changesets, walkthrough completion status, etc.
• Account for all of our third party assets that we fetch (There is a lot! This includes aerial imagery, streetview imagery and detections, Q/A detections, OSM note gravatars, and assets from third parties like the brand logos or wikidata commons images. e.g. #7028, #6660, #6361, #5167, #5823, and many others).
• Making sure that all of these assets can be opted out of (imagery already can, not the other things).

This is also separate from #5017, which is about making any GDPR related changes for the OSM API. Also worth mentioning that this privacy policy wouldn't cover any forks or other instances of iD that handle data differently - such as RapiD or frodrigo/iD. Those organizations will need their own privacy policy.

[Nakaner]

Where can I find the link to the privacy policy in the user interface?

I don't think that this issue should be closed by commit ada4fb5814a51c3e49e451149a54e1469b6c971c. Leaving the question about the usage of resources from graph.facebook.com aside, the privacy policy is still not sufficient. I compared it to my checklist and was not able to tick all the boxes:

• [ ] name and contact details of the responsible person (this can be a company) [1],
• [ ] if the responsible entity has a data protection officer (it might be required), his/her name and contact details [1],
• [x] the purposes of the processing for which the personal data are intended
• [ ] the legal basis for the processing [2],
• [x] if the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party,
• [x] the recipients or categories of recipients of the personal data [3],
• [x] contact details for third-party content included in iD [4],
• [ ] the period for which the personal data will be stored [5],
• [ ] usage of clear and plain language [6],
• [ ] a couple of rights of the persons whose data is processed [7]:
  
  
  
  • [ ] The person has the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability [8].
  
  
  • [ ] The person has the right to file a complaint with a supervisory authority.
  
  

I recommend to include a list of all third party content providers, their contact details and where their privacy policies can be found. This can, once provided by Editor Layer Index, generated automatically. Otherwise you likely have to answer a couple of more questions in your privacy policy which I did not mention in the list above.

See article 14 GDPR for further information.

Thinking a bit more about the issue, it does not look as a useful way for websites, where iD is deployed, to link to your privacy policy. They might have different logging enabled at their website (duration, stored information). Maintaining a second privacy policy is something I would avoid because it might make it difficult to comply with the requirement of clear and plain language. Instead, it would be better for iD to provide a clear list of things to include in privacy policies if one deploys iD. For your public development instances, a privacy policy might still be a good idea but I wonder why you choose to link to the lasted version of the master branch and not to the version of the privacy policy at the date of the release. If you (or ELI as dependency) remove something in future, an older version of iD links to an incomplete privacy policy, doesn't it?

[1] This includes a postal address.

[2] That's point (f) of article 6(1) GDPR.

[3] i.e. all responsible entities of third party content iD loads from third party sites

[4] I think it is best practice to do so.

[5] You already linked to the privacy policies of some third-party providers but

[6] Links to source code files for a list of satellite imagery and street-side imagery sources are likely not meeting this requirement.

[7] That's usually copy and paste text and more or less part of all privacy policies.

[8] You have to inform the subject about their right but if you operate a simple website, your response on such requests will very likely be "I can't identify you in my logfiles.".

[bhousel]

@Nakaner Thanks for checking the privacy policy.. If you concerns please contact the LWG and @kathleenlu09 . We on the iD side are not experts in this stuff.

[bhousel]

Where can I find the link to the privacy policy in the user interface?

oh - this I can answer.. We added another pane to the side for User Preferences and Privacy, and it includes a link to the privacy policy:

Also, a message is shown at startup like this:

The text in English is:

When user uses iD for the first time:

By using this software, you agree to do so in accordance with the iD privacy policy, which can be found here.

When policy has been updated, splash screen will show again and the message reads:

Our privacy policy has recently been updated. By using this software, you agree to do so in accordance with the iD privacy policy, which can be found here.

[Nakaner]

Having the privacy policy on the splash screen is good but I expect such a link either in a "About" menu or just as a small link in the footer of the window. Users should always be able to find it and using "here" as a link is hiding it a bit.

I think the whole privacy topic is not sufficiently addressed by iD yet, not all the boxes are checked at the moment. That's why I ask to reopen this GitHub issue.

[kathleenlu09]

@Nakaner please write to LWG at [email protected] regarding any requested changes you have to the privacy policy.
I'm not sure where you got your checklist from, but for each request, please document which section of GDPR you believe necessitates the change and link to the relevant section. This will help LWG more efficiently review your comments. I would suggest using https://gdpr-info.eu/ as that has all the sections on separately and more easily linked pages.

[rory]

What about changing the default to opt in, rather than opt out? That's often viewed as better security & privacy?

[quincylvania]

What about changing the default to opt in, rather than opt out? That's often viewed as better security & privacy?

My personal views on this—

Apps make a range of connections. Some are fundamental to how the app works and are essentially required, like iD's connections to OpenStreetMap and imagery providers. Some are superfluous and should be opt-in, like analytics trackers (which iD doesn't have).

I see the icon loading as somewhere in the middle. It's not integral but it makes the mapping experience better. So my own feeling is that it should be turned on by default, but I understand that others may come to a different conclusion.

For that matter, I don't know why we'd let iD make any connection that we're not comfortable turning on by default. But people have different comfort levels so it's a tricky issue!

[rory]

Can I state something that I presumed was obvious? I think the problem is the use of Facebook. I think a lot of reasonable objections to requesting third party images, are not the general idea (as you say, noone complains about aerial imagery), but the fact that it includes Facebook. Facebook have a horrible track on privacy & they are too powerful. Lots of people I know (not german hacker geeks who go to CCC, regular people (most people I know in Karlsruhe fall into that category actually)!) just don't trust Facebook or have Facebook accounts.

I've mapped betting shops in towns in middle England (Peterborough). If a regular local had used iD to do that, Facebook would probably start showing them pro-Tory ads (which can be lies). Someone adding data to OSM should not have that risk. That area was a battleground constituancy and flipped from Labour to Conservative by ~2,500 votes a few weeks ago. Loading an image from Wikimedia Commons doesn't have the same risk.

"tracking analytics" is not an bad description of http requests to Facebook IMO.

On 24 December 2019 16:28:42 CET, Quincy Morgan [e-mail] wrote:

What about changing the default to opt in, rather than opt out?
That's often viewed as better security & privacy?>

My personal views on this—>

Apps make a range of connections. Some are fundamental to how the app
works and are essentially required, like iD's connections to
OpenStreetMap and imagery providers. Some are superfluous and should be
opt-in, like analytics trackers (which iD doesn't have).>

I see the icon loading as somewhere in the middle. It's not integral
but it makes the mapping experience better. So my own feeling is that
it should be turned on by default, but I understand that others may
come to a different conclusion.>

For that matter, I don't know why we'd let iD make any connection that
we're not comfortable turning on by default. But people have different
comfort levels so it's a tricky issue!>

-- >
You are receiving this because you are subscribed to this thread.>
Reply to this email directly or view it on GitHub:>
https://github.com/openstreetmap/iD/issues/7040#issuecomment-568766907

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[rory]

For the avoidance of doubt, I have no idea of the political views of the iD developers, and I'm sure there is no grand conspiracy for them to help any political party in the UK. (which is an absurd conspiracy theory, I shouldn't have to type that)

It's just important to think though the unintended consequences of design decisions.

On 24 December 2019 17:47:58 CET, Rory McCann [e-mail] wrote:

Can I state something that I presumed was obvious? I think the problem
is the use of Facebook. I think a lot of reasonable objections to
requesting third party images, are not the general idea (as you say,
noone complains about aerial imagery), but the fact that it includes
Facebook. Facebook have a horrible track on privacy & they are too
powerful. Lots of people I know (not german hacker geeks who go to CCC,
regular people (most people I know in Karlsruhe fall into that category
actually)!) just don't trust Facebook or have Facebook accounts.

I've mapped betting shops in towns in middle England (Peterborough). If
a regular local had used iD to do that, Facebook would probably start
showing them pro-Tory ads (which can be lies). Someone adding data to
OSM should not have that risk. That area was a battleground
constituancy
and flipped from Labour to Conservative by ~2,500 votes a few weeks
ago. Loading an image from Wikimedia Commons doesn't have the same
risk.

"tracking analytics" is not an bad description of http requests to
Facebook IMO.

On 24 December 2019 16:28:42 CET, Quincy Morgan
[e-mail] wrote:

What about changing the default to opt in, rather than opt out?
That's often viewed as better security & privacy?>

My personal views on this—>

Apps make a range of connections. Some are fundamental to how the app
works and are essentially required, like iD's connections to
OpenStreetMap and imagery providers. Some are superfluous and should
be
opt-in, like analytics trackers (which iD doesn't have).>

I see the icon loading as somewhere in the middle. It's not integral
but it makes the mapping experience better. So my own feeling is that
it should be turned on by default, but I understand that others may
come to a different conclusion.>

For that matter, I don't know why we'd let iD make any connection that
we're not comfortable turning on by default. But people have different
comfort levels so it's a tricky issue!>

-- >
You are receiving this because you are subscribed to this thread.>
Reply to this email directly or view it on GitHub:>
https://github.com/openstreetmap/iD/issues/7040#issuecomment-568766907

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Nakaner]

@kathleenlu09 I am writing this response intentionally in the public on GitHub, not by email because I – in the spirit of the Organised Editing Guidelines which have a similar requirement – want to stay this discussion to be transparent because it affects the rights of OpenStreetMap contributors.

This is the same checklist without the footnotes but with references to the individual articles of GDPR:

• [ ] name and contact details of the responsible person (article 13(1) point (a)),
• [ ] if the responsible entity has a data protection officer (it might be required), his/her name and contact details (article 13(1) point (b)),
• [x] the purposes of the processing for which the personal data are intended (article 13(1) point (c)),
• [ ] the legal basis for the processing (article 13(1) point (c)),
• [x] if the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party (article 13(1) point (d)),
• [x] the recipients or categories of recipients of the personal data (article 13(1) point (e)),
• [x] contact details for third-party content included in iD (article 13(1) point (e)),
• [ ] the period for which the personal data will be stored (article 13(2) point (a)),
• [ ] usage of clear and plain language (article 12(1) sentence 1),
• [ ] a couple of rights of the persons whose data is processed:
  
  
  
  • [ ] The person has the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability (article 13(2) point (b)).
  
  
  • [ ] The person has the right to file a complaint with a supervisory authority (article 13(2) point (d)).
  
  

I forgot to mention the following issues and point to keep in mind of the privacy policy:

• If you based the processing on consent, users would have the right to revoke their consent. If the do so, further processing is not legal if it is based on consent, not legitimate interest.
• It is questionable whether a consent given as an opt-out can be seen as a consent.

[bhousel]

@Nakaner iD (the app) does store some data in the user's browser storage, but we (the developers) don't have access to it. Maybe we could make this clearer, because most of your unchecked boxes (like about the period that the data is stored and request for removal) don't make any sense for an app like iD. We don't store or process any users personal data.

[Nakaner]

It seems that you, @bhousel, did not have the background knowledge I assumed when I wrote my comments above.

If a web server writes access logs with IP addresses (and iD's JavaScript code is served by a web server), it store personal data because IP addresses – even those assigned dynamically by your ISP – are personal data. See the decision on that by ECJ for further reference. Given that the configuration of the logging is different on each web server – even if it is just the duration of storage (how Logrotate was configured etc.) – it does not make a lot of sense to have a unique iD Privacy Policy. Instead, iD would be much better if it its developers provided the information to be added to the privacy policy of the organisation deploying iD.

[kathleenlu09]

Hi @Nakaner, it appears that you are making some unwarranted or incorrect assumptions. The decision of whether the organization deploying iD wants to incorporate the information about iD into its main privacy policy, or to link to iD's privacy policy, is up to that organization. As iD is an open source project, anyone in the world could choose to deploy it, with or without informing iD's maintainers, and the deployer also chooses how long to store logs, etc., and has the responsibility of noting that in its own privacy policy.
For the openstreetmap.org website, OSMF, upon the recommendation of LWG, makes the decision of whether to directly incorporate or link out to information from the privacy policy, not iD's maintainers. Your opinion may be noted the next time LWG discusses this matter. However, if you wish us to formally discuss it, please write into [email protected], as GitHub is not an active channel of communication for us.