Id: Allow sanitizing personal information from imagery_used

[1ec5]

If a mapper traces from a custom background layer, the URL template is included in the changeset’s imagery_used comment. The tag’s value is read-only and the 🗑 button is disabled, so the mapper has no control over the tag. This can be undesirable when the URL template contains personal information. For example:

• The URL could contain a personal API access token that could be abused for other purposes such as hotlinking.
• If a mapper sets up a personal server for fellow mappers to trace from, the hostname could be a static IP address belonging to a personal computer. Even though permission was given to trace from the WMS and the imagery is suitably licensed, the server’s owner may be reluctant to allow their IP address to be listed publicly on the changeset page for security or privacy reasons.

Automatically populating imagery_used provides a measure of accountability, but I think the mapper should be able to manually prevent personal information from being exposed. Otherwise, the Custom Background Settings dialog should warn the mapper that the URL template will be publicly visible, so they know to take precautions.

[simonpoole]

We already have cases in which local instances of iD have been used to try to cloak the use of non-legit sources, the suggested change would simply make if much more easier.

While the concept of personal API keys has some merit see https://github.com/osmlab/editor-layer-index/pull/548 . I would like to see a valid use of them for something that wouldn't be included in ELI in the 1st place (essentially while accounts could potentially be private, the source itself should always be available to all for inspection).

[1ec5]

As someone who removes inappropriately sourced features from time to time, I understand the concern about abuse. In the end, there are many ways for someone who’s determined enough to conceal their source. iD is open source, after all.

I opened this issue after experiencing the second example above. (The particular source I used is publicly available as a massive download; the only thing private was the hosted copy.) I don’t think I would’ve unintentionally exposed a fellow mapper’s static IP address had I seen a warning about imagery_used or had imagery_used been visible by default in the upload panel. In my opinion, making imagery_used more discoverable but still immutable would be a reasonable compromise.

[andrewharvey]

While I've found imagery_used useful in spotting questionable sources, I still agree users aren't expecting this to be made public so, it should be shown that it will be uploaded, and users given the chance to redact it if they like.

[grischard]

As DWG, we really like that people can't hide if they're tracing from, say, Google.

[1ec5]

Totally understandable. However, I hope the DWG would find it an acceptable compromise to warn the user against entering any personal information such as IP addresses in the custom imagery dialog. It does tip the hand of changeset reviewers, but only a little.

[quincylvania]

I'm in favor of adding the message. Mappers should be informed when a piece of data like that will be published.

[bhousel]

I did this in 47aaec0db - I added rules to sanitize the common kinds of personal tokens that we see in the wild. Let me know if there are others we should test for..

I think this strikes a fair balance between protecting our users personal information and also providing accountability.

If anyone (e.g. DWG) sees mappers tracing from custom sources that raise concern, you can always just ask them to share the apikey privately, and revert their work if they don't respond to reasonable communication attempts (common practice already).

var source = iD.rendererBackgroundSource.Custom('http://example.com');
expect(source.imageryUsed()).to.eql('Custom (http://example.com )');  // note ' )' space

var source = iD.rendererBackgroundSource.Custom('http://example.com?access_token=MYTOKEN');
expect(source.imageryUsed()).to.eql('Custom (http://example.com?access_token={apikey} )');

var source = iD.rendererBackgroundSource.Custom('http://example.com?connectId=MYTOKEN');
expect(source.imageryUsed()).to.eql('Custom (http://example.com?connectId={apikey} )');

var source = iD.rendererBackgroundSource.Custom('http://example.com?token=MYTOKEN');
expect(source.imageryUsed()).to.eql('Custom (http://example.com?token={apikey} )');

var source = iD.rendererBackgroundSource.Custom('http://example.com/wms/v1/token/MYTOKEN/1.0.0/layer');
expect(source.imageryUsed()).to.eql('Custom (http://example.com/wms/v1/token/{apikey}/1.0.0/layer )');

[1ec5]

This does address the access token aspect of the feature request – thanks!

However, I think the consensus on this ticket had moved toward putting a notice into the Custom Background Imagery dialog about public disclosure, which could just as well be an admonition against private or copyrighted sources. That could still be relevant to the sources not covered by this fix, whether legitimate or illegitimate.