iD
iD copied to clipboard
openstreetmap
Corrections to Privacy Policy
This updates and clarifies a few points in the privacy policy.
todo
- [ ] clarify section about the ideditor.com domain
These edits make it sound a lot like that OSM Foundation have taken over control of the iD project?
Have you been asked by your bosses at the OSM Foundation directly to make this change? Can you share this decision with the public?
Is this a decision that we can reconsider (at least until the next board is seated in a few weeks and has a chance to meet?)
the original privacy policy was written in close consultation with the LWG, which is the legal point of contact indicated in this document. Can we get confirmation that the LWG has signed off on the changes to the document
I forgot to mention this in my original post, but yes: These changes had already been signed off by the LWG (//cc ~~@KathleenLD~~ @kathleenlu09 //edit: sorry for the mixup of usernames here).
Replying to https://github.com/openstreetmap/iD/pull/8837/files#discussion_r762489477:
It is true that not every instance of iD is fully run by the OSMF. However, the iD repository makes it quite clear that when one just says "iD", the instance operated by the OSMF is meant. See for example the website link on the top right, the various links to osm.org scattered throughout the repository and the releasing instructions. Further, this is the privacy policy which is linked from the actual iD editor hosted at osm.org.
Does the privacy policy need to account for independent deployments, or is it up to them to provide their own privacy policies even if nothing is being customized?
As far as I can see, the policy is written in a way that is quite deployment-independent (except for the contact email and where it mentions the ideditor.com website perhaps).
If anyone runs their own public instance of iD they are required (by law, I would think) to display a privacy policy which matches their version of iD that they run. If they don't customize iD in any way, the needed changes would be minimal.
This probably isn’t the best venue to hash out any kind of text with legal ramifications, but I’ll just point out that “operate iD” is ambiguous: there’s a desire on the one hand to avoid implying that the OSMF runs iD development, whereas it sounds like the passage is being reworded to allow that the instance of iD currently being used is deployed on OSMF servers.
Have you been asked by […] the OSM Foundation directly to make this change?
No. These changes were initiated by myself in an attempt to correct a mistake in the privacy policy.
Is this a decision that we can reconsider (at least until the next board is seated in a few weeks and has a chance to meet?)
I think it doesn't hurt to wait a few weeks for this, sure.
avoid implying that the OSMF runs iD OSMF runs iD development
Well, one could argue that the OSMF nowadays also "operates" (in the sense of: finances) at least some of the iD development. But this is in my opinion irrelevant here, since the sentence in question needs to be read in the context of a privacy policy, which is by definition not about development processes at all.
the original privacy policy was written in close consultation with the LWG, which is the legal point of contact indicated in this document. Can we get confirmation that the LWG has signed off on the changes to the document
I forgot to mention this in my original post, but yes: These changes had already been signed off by the LWG.
I don't see anything in the LWG minutes about revising the iD privacy policy, so we must have a different idea of what "signed off by the LWG" means. https://wiki.osmfoundation.org/wiki/Working_Group_Minutes#2021
@tyrasd Can you please provide information about LWG signing off the changes?
Can you please provide information about LWG signing off the changes?
This came up in an email conversation following a question I sent to [email protected]. Perhaps this doesn't count as "signing off": if there is a better way, please let me know.
@tyrasd Can you please share the relevant parts of the email conversation here?
It should be noted that there is now some legal precedence, see https://www.gesetze-bayern.de/Content/Document/Y-300-Z-GRURRS-B-2022-N-612 , that providing javascript that is run on/in a client does in fact fall in the responsibility of the operators of the website that embeds the javascript. In particular any third party content loaded by such code needs either explicit consent or a DPA covering it (retrieving any content from the US even with consent would seem to be associated with legal jeopardy).
