#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:1 by , 5 years ago
follow-up: 4 comment:2 by , 5 years ago
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".
follow-up: 8 comment:3 by , 5 years ago
+1 for not adding it. Privacy makes no sense to me for this use case.
follow-up: 5 comment:4 by , 5 years ago
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 by , 5 years ago
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 by , 5 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:7 by , 5 years ago
Keywords: | ELI privacy added |
---|
follow-up: 11 comment:8 by , 5 years ago
Cc: | added |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
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:10 by , 5 years ago
These are, grouped by URL, the privacy_policy_url
attributes we have in ELI today:
https://gist.github.com/grischard/ed41a25ac108b23f0fd96407b363d104
comment:11 by , 5 years ago
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.
follow-up: 13 comment:12 by , 5 years ago
Vespucci uses privacy_policy_url
from ELI today:
This is the blocker that's preventing it from switching the imagery index URL from ELI to JOSM.
comment:13 by , 5 years ago
Replying to Stereo:
Vespucci uses
privacy_policy_url
from ELI today:
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?
follow-up: 15 comment:14 by , 5 years ago
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".
follow-ups: 16 19 comment:15 by , 5 years ago
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 by , 5 years ago
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 by , 5 years ago
<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 by , 5 years ago
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 by , 5 years ago
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 by , 5 years ago
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 by , 5 years ago
Milestone: | → 20.03 |
---|
comment:22 by , 5 years ago
Status: | reopened → new |
---|
comment:23 by , 5 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:28 by , 5 years ago
https://github.com/osmlab/editor-layer-index/pull/816 integrates the mirror
property in ELI, including privacy_policy_url
(clever!)
comment:30 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:31 by , 5 years ago
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.
follow-up: 33 comment:32 by , 5 years ago
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.
follow-up: 38 comment:33 by , 5 years ago
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.
follow-up: 37 comment:36 by , 5 years ago
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 by , 5 years ago
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 by , 5 years ago
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.
New issue: https://github.com/osmlab/editor-layer-index/issues/690