Randomize the order of sent contributions in batches

[mathieui]

Use case
Disclaimer: I did not look at the code before opening this, maybe it is an irrelevant request, and I am no expert in OSM contributions.

When using StreetComplete, I do not want my movements to be tracked through the various quests I fulfill along the way.It seems that it would currently be possible to know such things (and incidentally, precisely where I live, work, shop, etc…) through my OSM profile history.

Proposed Solution

To add some noise into this very personal history, my proposed solution is to randomize the order in which grouped modifications are sent (assuming that is a thing), or even individual contributions, so that no clear point of origin or destination can be inferred. Obviously due to the nature of OSM mapping, we cannot change the content itself, which already reveals some information about the mapper, but this proposed feature would make it at least slightly harder.

[westnordost]

This is probably not possible. It is not possible to upload the edits in any order because some edits made with StreetComplete are dependent on another. For example you split a way, and then answered other questions on the different sections. So, a random order would not work. Right now I have no idea how a conditional random order could be achieved without badly messing up the logic. The edits do not refer to each other like "I depend on this or that edit" but know nothing of another - the dependence is implicit based on the order in the upload queue.

[westnordost]

Maaaybe it would be possible to always upload split-ways (in order) first, then randomize the rest. But I am not sure about that and I am somewhat wary to touch this central logic of the app because it could badly mess things up.

[smichel17]

Perhaps something along these lines this could be cleanly integrated with the logic for deciding when to close a changeset? For example, when a changeset includes an edit which is order-dependent, then that changeset is not randomized. Obviously this wouldn't solve the problem, but it might be a relatively safe/clean first step.

Independently, I was going to propose for auto-upload to wait to upload until it determines that the changeset should be closed-- mostly for battery savings, partially to avoid publishing realtime location data.

Also see #3208 and #3466 for recent related discussions.

[biketeur]

Eine Änderung der jetzigen Verarbeitungsweise bzw. randomisierte Speicherung von Quests bringt nicht das Gewünschte:
ein User geht an einem Tag X von A nach B und beantwortet etliche Quests. Egal in welcher Reihenfolge die Quests hochgeladen werden, wenn alle beantworteten Quests des Tages X auf einer Karte markiert werden, ist der Weg des users ersichtlich. Offen ist vielleicht, ob er von A nach B oder von B nach A gegangen ist. Aber dies kann man durch weitere Überlegungen evtl. auch herausfinden

[westnordost]

Ja, korrekt.

[timothywashere]

Are you talking about live tracking whilst you're using the app or at some time in the future?
I can see the concern for the first but surely the answer is just to turn off the auto upload option.
I don't see the concern with the second, unless you are worried someone will work out your way home from work or something?

[westnordost]

So to be clear: The app uploads edits in exactly the same order as they were created, regardless if the auto upload option is on or off.

Since the upload of the individual edits is always some milliseconds apart, it is theoretically possible to derive from the timestamps from where (start) to where (end) a survey with this app went. If the edits were instead uploaded in a random order, the path the survey went would still be deriveable but not whether the user went from A to B or from B to A.

Though, I'd say that this additional detail is somewhat negligible, considering the more fundamental privacy issue that exposes the location(s) the user went while contributing.
But this is a general issue anyway with contributing data on-site to OpenStreetMap and is a combination of the requirement that anonymous contributions are not possible in OSM and maybe also the lax protection of the data (you don't even need to be logged and thus acknowledge the terms and conditions to see who contributed what at what time).

The only workaround for a contributor to improve privacy for himself here is to use a range of several accounts. E.g. semi-anonymous secondary OSM accounts that are not tied to your usual OSM activities or identity.

[mnalis]

I agree, the path taken by user is trivially reconstructed regardless of POI order (as users moves using their own foot or some vehicle, and not using teleport), and thus doing that would only produce false sense of privacy, which is arguably actually much worse than explicitly stating what the privacy issues are (as SC currently does).

As noted, helping improve OSM on the ground (by using apps like SC) is necessarily going to lead to revealing where one has been.

@mathieui There are few things one might employ if they were so concerned about the issue, to make it somewhat harder for others to mine publicly available OSM data to undermine their privacy (but at a loss of some convenience, as always):

• do not enter any user identifiable information into OSM (including your known e-mail address or recognizable username), so even when bad actors find out where someone have been, they will not know it is where you have been.
• use those OSM account(s) only for SC mapping (i.e. no setting home, no setting friends, no OSM messages etc).
• avoid mapping several kilometers around location-sensitive places (like home or work - that probably means somewhat less contributions though); only start mapping when you are far away from them (but also do not be too obvious - if you've mapped most of the city except two kilometer-wide circles, such geoblocking is as telling as if your were mapping them daily! see http://hdyc.neis-one.org/ / https://yosmhm.neis-one.org/ for example)
• never use auto-upload functionality of SC (default!); instead, accumulate several weeks (or even months) of updates and upload them manually all at once (that will likely lead to some lost work if the area is frequently mapped by others, though) - preferably some time after they have been mapped and not immediately afterwards
• do not map frequently used routes (like daily going to work or to home); instead, concentrate your efforts on mapping when visiting public and rarely used ones (like weekend trips to different locations; avoid mapping when visiting friends/family though)
• use different OSM accounts to map different parts of city (do not confuse them, though. Probably ruins gamification effect of SC too; although I guess one can practice competing their own alt-personas one against another 😄)
• use modified fork of StreetComplete, which does not set source=survey, fakes the editor name to simulate JOSM or iD, and uploads all changes in one changeset

(Of course, none of that would help at all if one was explicitly tracked outside of OSM, like by some bribed google employee having access to location data helpfully submitted by Android automatically, or $DEITY forbid if one was person of interest of some shady organizations or governments)

[matkoniecz]

If someone really, really, really needs to keep locations fully private I would rather advise to not map by survey.

Even after applying solutions above, given low density of OSM mappers, in most cases it would be possible to reconstruct it.

[smichel17]

Or invite all your friends/neighbors/random people on the street to do mapping, to increase the density :D

…

On Sat, Nov 20, 2021 at 05:20, Mateusz Konieczny ***@***.***> wrote: If someone really, really, really needs to keep locations fully private I would rather advise to not map by survey. Even after applying solutions above, given low density of OSM mappers, in most cases it would be possible to reconstruct it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.