Modify

Opened 16 months ago

Closed 2 months ago

Last modified 2 months ago

#17285 closed enhancement (fixed)

New ELI property privacy_policy_url

Reported by: Klumbumbus Owned by: Don-vip
Priority: normal Milestone: 20.03
Component: External imagery source Version:
Keywords: ImageryCompare ELI privacy Cc: Stereo

Description

ELI added privacy_policy_url: https://github.com/osmlab/editor-layer-index/pull/619
Not sure if we need this and should add it to our schema too.

Attachments (0)

Change History (38)

comment:2 Changed 9 months ago by stoecker

ATM I see no reason. I doubt there really will be many entries which really have policies and then there is not much sense in displaying these in JOSM. A web browser also doesn't warn you before accessing a website that data gets transferred, why should JOSM? And BTW I also see no sense for osm.org, as using a layer is still a user choice, so stating that "IP and map position will be sent to the map vendor" should be enough instead of collecting information which can't be guaranteed to remain exact.

And I personally think bothering the data vendors too much will be counter-productive. As a data provider I probably would understand when asked for a license, but when then another bunch of questions come like privacy policies and whatever else my answer probably would be "don't use our service" and not "yes, we'll provide the required information for our cost-free service".

Last edited 9 months ago by stoecker (previous) (diff)

comment:3 Changed 9 months ago by Don-vip

+1 for not adding it. Privacy makes no sense to me for this use case.

comment:4 in reply to:  2 ; Changed 9 months ago by Klumbumbus

Replying to stoecker:

I doubt there really will be many entries which really have policies

Since GDPR every company which processes personal data must have a privacy policy.

A web browser also doesn't warn you before accessing a website that data gets transferred

But they have a link to the privacy policy e.g. in the footer. And nowadays nearly every website has these cockie banners.

Just my thoughts.

comment:5 in reply to:  4 Changed 9 months ago by stoecker

Replying to Klumbumbus:

Replying to stoecker:

I doubt there really will be many entries which really have policies

Since GDPR every company which processes personal data must have a privacy policy.

Yeah. But not for each service. E.g. our company has a generic privacy policy, but this includes all possibilities. If e.g. the map service simply does not store any data you wont find a privacy policy for this.

BTW I consider the idea, that an IP address is always person-depending data as wrong. For nearly everbody it is impossible to find the person behind an IP address. E.g. we had to add a lot of bullshit to the privacy policy only to cover the fact that all the servers work with IP addresses and everbody can access domain names with a browser, so that IP addresses are recorded and stored. If you leave that away a lot of GDPR relevant crap vanishs and only the important parts remain.

E.g. When asked you can't tell anybody "We store not data about you", because it is possible there was a previous access to your website and the logs files still contains that IP which has no value for you. So you always have to answer: "We don't store any data about you, except our logs may contain an IP address used by you, but we don't know, as we can't find out". That's crap.

A web browser also doesn't warn you before accessing a website that data gets transferred

But they have a link to the privacy policy e.g. in the footer. And nowadays nearly every website has these cockie banners.

Well, first these cookie banners nearly always are bullshit, as they ask you to accept cookies AFTER they set them and privacy policies usually are available for the main webpages, very seldom for individual services.

comment:6 Changed 8 months ago by Klumbumbus

Resolution: wontfix
Status: newclosed

comment:7 Changed 8 months ago by Klumbumbus

Keywords: ELI privacy added

comment:8 in reply to:  3 ; Changed 2 months ago by Don-vip

Cc: Stereo added
Resolution: wontfix
Status: closedreopened

Replying to Don-vip:

+1 for not adding it. Privacy makes no sense to me for this use case.

Changed my mind after reading https://github.com/osmlab/editor-layer-index/issues/586#issuecomment-598179594 comments.

I previously thought it was of no use because at the time there were no evidence to see other projects reuse JOSM data anyway. Now things are changing, so I think we can add this field.

comment:9 Changed 2 months ago by Stereo

Thank you. Thank you. Thank you.

comment:10 Changed 2 months ago by Stereo

These are, grouped by URL, the privacy_policy_url attributes we have in ELI today:

https://gist.github.com/grischard/ed41a25ac108b23f0fd96407b363d104

comment:11 in reply to:  8 Changed 2 months ago by stoecker

Hello,

I previously thought it was of no use because at the time there were no evidence to see other projects reuse JOSM data anyway. Now things are changing, so I think we can add this field.

It's still of no use, but I agree that we can support it when there is real indication other editors will use the index. But from historic experience I expect to see clear steps for this before. It happened too often that JOSM staff implemented something and then the will to do their part in the other software vanished.

comment:12 Changed 2 months ago by Stereo

Vespucci uses privacy_policy_url from ELI today:

https://github.com/MarcusWolschon/osmeditor4android/blob/fb7c3dbe2e57bc4957b8ff0f1a97d12fdbf062c3/src/main/java/de/blau/android/resources/TileLayerDatabase.java#L63

This is the blocker that's preventing it from switching the imagery index URL from ELI to JOSM.

comment:13 in reply to:  12 Changed 2 months ago by stoecker

Replying to Stereo:

Vespucci uses privacy_policy_url from ELI today:

https://github.com/MarcusWolschon/osmeditor4android/blob/fb7c3dbe2e57bc4957b8ff0f1a97d12fdbf062c3/src/main/java/de/blau/android/resources/TileLayerDatabase.java#L63

This is the blocker that's preventing it from switching the imagery index URL from ELI to JOSM.

So you tested everything and anything else is fine, but this is blocking adoption?

comment:14 Changed 2 months ago by marc_marc

I am in favor of having a unified schema between eli and josm, even if it means that there might be an unused attribute on the josm side.
The big advantage is that it removes a possible "excuse".

comment:15 in reply to:  14 ; Changed 2 months ago by stoecker

Replying to marc_marc:

I am in favor of having a unified schema between eli and josm, even if it means that there might be an unused attribute on the josm side.

Fine. Let's begin with implementing these in ELI: eula, logo-url, logo-image, terms-of-use-text, mirror, no-tile-checksum, metadata-header, valid-georeference, last-check, tile-size, mod-tile-features, custom-http-headers, default-layers, format, transparent, minimum-tile-expire. See ImageryCompare.

The big advantage is that it removes a possible "excuse".

Experience shows that this doesn't work. If there is a use we'll support it even if JOSM is not the user. If there is no use then not. And we're fast: It is a matter of hours to implement this and fill in the data - So implementation of this ticket is not the blocker fact. We're committed to do the implementation when it makes sense, but not before.

And to clarify why I'm so strict: When we implement it, we also need to care about the data. And that's a lot of never-ending work. And I don't see any sense in doing this work when nobody uses the data. The implementation itself is simple compared to this afterwork.

comment:16 in reply to:  15 Changed 2 months ago by Stereo

Replying to stoecker:

Replying to marc_marc:

I am in favor of having a unified schema between eli and josm, even if it means that there might be an unused attribute on the josm side.

Fine. Let's begin with implementing these in ELI: eula, logo-url, logo-image, terms-of-use-text, mirror, no-tile-checksum, metadata-header, valid-georeference, last-check, tile-size, mod-tile-features, custom-http-headers, default-layers, format, transparent, minimum-tile-expire. See ImageryCompare.

I've started at https://github.com/osmlab/editor-layer-index/pull/815 as a show of good faith.

comment:17 Changed 2 months ago by Stereo

<mirror> isn't implemented because I can't wrap my head around what that would look like in json schema. Help wanted.

The rest is copied 1:1.

comment:18 Changed 2 months ago by Stereo

https://github.com/bryceco/GoMap/pull/295 PR for GoMap, ready to go IMHO

Vespucci will need a bit more updating for the READMES, the UI, etc.

comment:19 in reply to:  15 Changed 2 months ago by marc_marc

Replying to stoecker:

Replying to marc_marc:

I am in favor of having a unified schema between eli and josm,

Fine. Let's begin with implementing these in ELI

You're right that this also needs to be done, I told Stereo again yesterday, but eli is progressing more slowly. eli hasn't finished integrating the categories yet. I'll take care of that.

comment:20 Changed 2 months ago by Stereo

If the goal is to all work on one common index together, I'd rather not waste too much time on ELI myself.

comment:21 Changed 2 months ago by Don-vip

Milestone: 20.03

comment:22 Changed 2 months ago by Don-vip

Status: reopenednew

comment:23 Changed 2 months ago by Don-vip

Owner: changed from team to Don-vip
Status: newassigned

comment:24 Changed 2 months ago by Don-vip

In 16127/josm:

see #17285 - add privacy-policy-url

comment:25 Changed 2 months ago by SimonPoole

Thanks @Don-vip

comment:26 Changed 2 months ago by Don-vip

In 16128/josm:

see #17285 - add privacy-policy-url in mirror, check links in integration test

comment:27 Changed 2 months ago by Don-vip

In 16129/josm:

see #17285 - add privacy-policy-url in mirror

comment:28 Changed 2 months ago by Stereo

https://github.com/osmlab/editor-layer-index/pull/816 integrates the mirror property in ELI, including privacy_policy_url (clever!)

comment:29 Changed 2 months ago by Don-vip

In 16130/josm:

see #17285 - add privacy-policy-url in mirror

comment:30 Changed 2 months ago by Don-vip

Resolution: fixed
Status: assignedclosed

comment:31 Changed 2 months ago by stoecker

A note: If it would be helpful for other editors to remove certain entries which are anyway unsupported from the output (i.e. strip all wms_endpoint types) please open a ticket for that. That's easy to do and will reduce data transfer. Please don't ask to strip individual tags, that would be overkill.

comment:32 Changed 2 months ago by stoecker

The change wiki:Maps/USA?action=diff&version=205 indicates very well my objections to this tag:
https://gis.iu.edu/privacy/ is a page to generate privacy policies for the university departments, but it is not usable for the data users.

Maintaining such data is useless.

comment:33 in reply to:  32 ; Changed 2 months ago by Don-vip

Replying to stoecker:

Maintaining such data is useless.

If Simon agrees to reuse our index for Vespucci and it brings more contributions to help us maintaining the entries, it will not be useless.

Fixing this 404 took me around 10 seconds. It's much more difficult to track why obscure network errors happen with other servers, and not a lot of folks help me to do it right now.

comment:34 Changed 2 months ago by Stereo

Fixed it again :).

comment:35 in reply to:  34 Changed 2 months ago by Don-vip

Replying to Stereo:

Fixed it again :).

Thanks!

comment:36 in reply to:  34 ; Changed 2 months ago by stoecker

Replying to Stereo:

Fixed it again :).

First you fixed only one entry and second your fix is totally wrong. The link clearly states that it is only for www, not for the map service.

comment:37 in reply to:  36 Changed 2 months ago by Don-vip

Replying to stoecker:

The link clearly states that it is only for www, not for the map service.

I asked them on Twitter, let's see https://twitter.com/VincentPrivat/status/1241305362105597953

comment:38 in reply to:  33 Changed 2 months ago by stoecker

Replying to Don-vip:

Replying to stoecker:

Maintaining such data is useless.

If Simon agrees to reuse our index for Vespucci and it brings more contributions to help us maintaining the entries, it will not be useless.

I didn't say that support of that tag is useless or I wouldn't have allowed it. I said the data is useless.

I don't want to stop the discussion whether the tag altogether makes a sense only because we now have it in our database. It should neither be in our database nor in ELI's.

Fixing this 404 took me around 10 seconds. It's much more difficult to track why obscure network errors happen with other servers, and not a lot of folks help me to do it right now.

Yeah, but my argument is still valid after your fix and Stereo's fix. The data is either broken (before), senseless (after your fix) or even misleading (after Stereo's fix).

Keeping data usage policies in a useful state is not manageable. That's not a simple works/works not check as for the other URLs we have.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Don-vip.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.