Obviously we trust the OWG to make important decisions. What I’m trying to say is that the current guideline says nothing about what should(n’t) be in a privacy policy, and that content guidelines like “We won’t accept a privacy policy that says all personal data of users will be sold to undisclosed shady third parties” could be made a bit more explicit.
1 Like
We should probably decide what sort of privacy policy would be acceptable. Otherwise people will go through all that effort to apply… Only to be told it’s dead in the water
1 Like
This would seem to be a bit of a red herring. Anything that the OSMF hosts or operates is going to have to be compatible at least in its default configuration with the OSMFs privacy policy.
There’s some wiggle room there, say if the developers would like to receive crash/debugging data, but that would have to be opt-in.
2 Likes
As this policy suppose to be kind of like a check list of requirements, it would be better to be explicit about the privacy policy condition, which would be acceptable for OWG/OFMF. Otherwise, why having a policy when OWG can decide for editor A, in this way and for editor B in a different way.
Thank you all for the helpful discussion and suggestions.
The OSM Operations team will discuss at our next fortnightly call.
Anyone willing to summarise the themes / suggestions / discussion from a neutral point of view?
Key themes from my review of this thread:
- The policy should be clear in its language in distinguishing between desktop, in-browser, and mobile editors, and how this factors into consideration
- There is concern about whether this policy is specifically prompted by a consideration of whether to include RapiD and whether this proposed policy and that decision are comingled. Along these lines, there are concerns about whether to include editors which bring in importable external data sources more easily.
- There are different perspectives on whether to focus on quality (high bar to include an editor) versus diversity (include a larger number of editors for more varying use cases)
- An editor should have a privacy policy that’s acceptable to OSM community expectations
- There are concerns about whether it is acceptable to link the edit button to an externally-controlled website
- There is a desire for the community to be able to evaluate an editor for a period of time between when it is proposed and when it is approved, so that contributors can provide feedback to the OWG on a proposal to add an editor
7 Likes
Such concerns should be extended to plugins like JOSM MapwithAI that let’s import these external data very easily. For example, see this changeset.
There is a difference between somebody actively seeking out the data available via that plugin and importing it at their own risk, and the OSMF going ‘that’s all fine to import’ to a very large audience.
3 Likes
I’m not quite sure about this point. Assuming, the policy is prohibiting editors which provide the function to upload AI generated data, that would also apply to jOSM and it’s MapwithAI-Plugin. So in my understanding under such kind of policy jOSM would need to make sure, it accept only the remote link from osm.org if no MapwithAI-plugin is installed.
Of course still you would be able to upload AI generated data with jOSM
Prioritizing Children’s Rights under UK GDPR
Since OpenStreetMap allows editors aged between 13 to 18, but we lack information on who is under 18, I suggest treating every OSM user as potentially being a minor.
Therefore, the UK GDPR section related to children (its suggestions and recommendations) could be particularly important. ( Using children's information: a guide | ICO )
I believe it is unethical to redirect users from the main OpenStreetMap org site, which complies with UK GDPR rules, to any external OSM Editor that does not adequately protect the rights of underage OSM users.
As far as I know, while both U.S. CCPA and UK GDPR prioritize children’s privacy, the UK GDPR offers more comprehensive and explicit protections for children’s personal data.
The situation becomes more complex if the editor program:
- Displays commercial advertisements
- And/or links user data with identifiers from Mapillary, Meta, Google, etc.
In these cases, it is especially important to ensure that the rights of underage OSM users are protected.
Since complaints against OSM Editor programs not operated by the OSM Foundation can be filed in courts around the world (for example, RapidEditor in California), I suggest that the OpenStreetMap Foundation establish a chosen court to quickly make decisions in disputed cases in the best interest of the OSM community.
2 Likes
But that assumption is wrong, the policy only concerns itself with the integration of editors on the OSM website (aka those editors that the OSMF explicitly promotes), not with which editors are in general allowed to use the OSM editing API and in which form.
Yes, it is imaginable that at one point in time there could be such a policy, but that would have a far larger scope and consequences than what is on the table now. Not to mention that it currently would be completely unenforceable.
2 Likes
My point is not about the OSM editing API but about the Edit with Remote Control-link. The rules, which editors are featured by the OSMF with promoting them in the Edit menu should be equal. If the policy requires “no-AI-data” that should apply to all Editors mentioned/listed in the drop down. In case of jOSM that means the name should be removed from the link description.
The editor examples in brackets after “Edit with Remote Control” are surely just examples? As currently implemented, there’s no way that the site can control what might receive a “please edit…” request by remote control. The person using “edit with remote control” must have actively installed whatever will get invoked themselves, so any actions that that program takes should not be a surprise. They won’t have installed it from OSMF directly.
1 Like
There’s two cases here that are substantially different
- an editor that provides built-in mechanisms to directly bring external geodata without the user supplying the geodata
or - an editor that has some background imagery that contains geodata,
- an editor that can be expanded with plugins to bring in external geodata,
- an editor that can open sources of external geodata.
JOSM and P2 have been able to bring external geodata into OSM for well over a decade.
1 Like
If I get your point, correct, the difference is built-in vs. plugin?
So if someone create a 3rd party editor like jOSM with builtin AI-functionality and make use of the Remote-Control link, what would be the idea to prevent this? From my point of view, if OWG can’t enforce such policy for all editor reachable by the website, in the end it will let OWG look weak.
If an “evil-AI-editor” is allowed to use Remote link, but not allowed to be directly reachable, that should be clearly communicated. Because in the end there is no different. Especially on mobile devices, there is not much of a difference between I get an editor in my browser while clicking on the link or I get a new app opened while clicking on a link. In the end I click on a link on OSM website and opened the “evil-AI-editor”.
Exactly, so on one site OSMF “don’t care” which editor is using that link and on the other site OSMF should enforce a “no-AI-policy”. For me, that doesn’t fit together. Even though I would like to have such “no-AI-policy”.
It is technically impossible to choose what happens on computer run by someone in such case.
They could have configured their computer so Libre Office Calc is opened on using remote control edit button.
It is not “don’t care”, it is “computers are not working this way”.
(it is possible that I am mistaken)
2 Likes
Technical I agree with you. So, it might be the remote control function can’t comply with the such policy.
Remote control is not an editor. It doesn’t have to comply with the editor inclusion policy.
2 Likes
The difference is you have to install the app first.