Linking to icons in the repo leaks PI to github/microsoft

[simonpoole]

For a number of layers icons required for attribution are stored in this repo and liked to from the configuration (for example for the OSM carto layer), this leads to PI leakage to the operators of github when an app requests the icon on behalf of an user. This might be acceptable for layers which by definition leak data to commercial providers, but would seem to be rather problematic for a tile source like the OSM carto layer.

I would suggest adding a base64 encoded version of the icon at least for this layer. If that is acceptable I'll create a corresponding PR (and fix the OSM carto licence at the same time as rather out of date).

[simonpoole]

Note that an alternative approach would be to save the icons on the OSM wiki (or something else operated by the OSMF, we also have some AWS storage iirc).

[rbuffat]

In the past @grischard implemented checks to strip the inline icons in order to reduce the file size. I could imagine that a small size of the geojson is/was something that was favored by iD. At least it looks as if the file size was one of the main drivers behind the imagery-index project.

CC @tyrasd @bhousel

See the following commits for the relevant changes: https://github.com/osmlab/editor-layer-index/commit/3a19df0f36f04091427aa92dd023a7af6275befe https://github.com/osmlab/editor-layer-index/commit/1242d0d0233ca785395d20430bb97e25497b5a1b

[simonpoole]

@rbuffat I fully support the size argument (though for me it is mainly a question of how long it takes to read and parse the file once), but from a data protection point of view it should be possible to start off with a source that doesn't increase the minimum required exposure of PI (aka the OSM standard layer), and then the users can be informed when they switch layers to something else.

The other aspect is the unexpected side effect of not just leaking PI to the operator of the source, but to github / microsoft, Naturally this could be included in the privacy policy of the layer in question, but I suspect that simply moving the icons somewhere less controversial would make more sense.

[tyrasd]

For the osm carto layer we could simply use https://wiki.openstreetmap.org/w/images/thumb/7/79/Public-images-osm_logo.svg/24px-Public-images-osm_logo.svg.png

---

Please excuse me to slightly extend the scope of this issue, but I guess this could be relevant: Isn't loading the index from github (e.g. https://osmlab.github.io/editor-layer-index/imagery.geojson) also problematic in the same way?[^1] A solution would be to deploy the hole editor-layer-index repository on an OSMF server. This would solve both this and the icon loading issues at the same time.

[^1]: iD currently circumvents this issue by compiling the whole index into the iD bundle at build time, but I would like to change this to a dynamically loaded resource in the near future.

[simonpoole]

Please excuse me to slightly extend the scope of this issue, but I guess this could be relevant: Isn't loading the index from github (e.g. https://osmlab.github.io/editor-layer-index/imagery.geojson) also problematic in the same way

Yepp, Vespucci includes the current version in the APK, so similar to iD, but updating manually will fetch the configuration from this repo, see http://vespucci.io/help/en/Privacy/

[rbuffat]

Pushing the repo to an OSM server would also ensure that we could have control over the URL the imagery* files can be retrieved. Currently, the URL can change when Github decides to change something.

[grischard]

@Firefishy could we set up a reverse proxy for these, say on imagery.openstreetmap.org?

[Firefishy]

Yes, I can setup hosting or proxy for this.

[cicku]

When you fetch the list hosted on Github, you already leak yourself?