Release Notes (Privacy law compliance) - December 31, 2019

January 3, 2020

11 hours ago, thomfre said:

With the new crazy API change, where even data for users that have explicitly authorized an app gets blocked, how can you continue to let c:geo operate?

Do you want c:geo to be blocked by GS?
Why that?

c:geo only processes data that the logged in user can also view via his browser. There are no GDPR violations.

4.6k · January 3, 2020

5 minutes ago, 2Abendsegler said:

Do you want c:geo to be blocked by GS?
Why that?

c:geo only processes data that the logged in user can also view via his browser. There are no GDPR violations.

And probably not easy to do, if it identifies as a browser there's no way to know if it's an app or a real browser anyway.

4.6k · January 3, 2020

5 minutes ago, 2Abendsegler said:

c:geo only processes data that the logged in user can also view via his browser. There are no GDPR violations.

Right, but violations of the ToU (regarding scraping) are still in place. :rolleyes:

January 3, 2020

@HHL

That's true.
But if GS hasn't provided a usable API for years, that's not surprising. What should c:geo or the GC little helper II also do, throw away the entire development and do everything new, because there is finally a usable API. I think that's too much to ask.

January 3, 2020

16 minutes ago, 2Abendsegler said:

Do you want c:geo to be blocked by GS?
Why that?

c:geo only processes data that the logged in user can also view via his browser. There are no GDPR violations.

Yes.

Other official partner apps are blocked, how is it possible for Groundspeak to continue to let c:geo steal data? Doesn't this give Californian users the ability to sue Groundspeak? If not, why block official partner apps?

January 3, 2020

2 minutes ago, 2Abendsegler said:

But if GS hasn't provided a usable API for years, that's not surprising.

But they have! For many years now...

January 3, 2020

10 minutes ago, thomfre said:

Doesn't this give Californian users the ability to sue Groundspeak? If not, why block official partner apps?

Certainly not, because c:geo and GClh only processes data that the logged in user can also view via his browser. That is nothing forbidden.

Maybe, the blocked official partner apps processes with more data?

8 minutes ago, thomfre said:

But they have! For many years now...

Yes, but in 2010 and the following years there are no API.
And as I started with GClh development in 2016, I actually had no desire to throw everything away.

January 3, 2020

6 minutes ago, 2Abendsegler said:

Certainly not, because c:geo and GClh only processes data that the logged in user can also view via his browser. That is nothing forbidden.

Maybe, the blocked official partner apps processes with more data?

Yes, but in 2010 and the following years there are no API.
And as I started with GClh development in 2016, I actually had no desire to throw everything away.

I don't care about gclh or other scripts. C:geo is scraping data, in violation with the ToU. Nothing you say will change that.

4.6k · January 3, 2020

2 minutes ago, thomfre said:

C:geo is scraping data, in violation with the ToU. Nothing you say will change that.

So...?

That's between GS and C:geo, nothing to do with us.

January 3, 2020

Just now, on4bam said:

So...?

That's between GS and C:geo, nothing to do with us.

Of course it has to do with us. It's our data they scrape......

4.6k · January 3, 2020

1 minute ago, thomfre said:

Of course it has to do with us. It's our data they scrape......

Yup, exactly what can be seen on the website. Makes no difference.

January 3, 2020

9 minutes ago, thomfre said:

I don't care about gclh or other scripts. C:geo is scraping data, in violation with the ToU. Nothing you say will change that.

You don't have to be interested in the script or the scripts. It was just an example from my practice to explain you the situation.
And I had and have no intention of saying, that c:geo is not scraping data, in violation with the ToU. If you had read my articles carefully, you would not have missed that either.

Edited January 3, 2020 by 2Abendsegler

January 3, 2020

1 minute ago, 2Abendsegler said:

You don't have to be interested in the script or the scripts. It was just an example from my practice to explain you the situation.
And I had and have no intention of saying, that c:geo is not scraping data, in violation with the ToU. If you had read my articles carefully, you would not have missed that either.

What I meant is that there's a difference. Gclh is not scraping the site like c:geo is.

January 3, 2020

3 minutes ago, on4bam said:

Yup, exactly what can be seen on the website. Makes no difference.

If this is the case, why is some profiles blocked in the API? That data is also visible on the website. If Cachly is blocked from showing the data l, why is c:geo allowed to display it?

This is wrong. Time for c:geo to finally face it, and start behaving like the rest of the apps.

4.6k · January 3, 2020

1 minute ago, on4bam said:

Makes no difference

The automatically download makes the difference between just browsing a cache page and scraping the site on the other hand. The latter is not wanted and strictly forbidden by the ToU. c:geo just behaves server unfriendly.

Hans

January 3, 2020

If I wish I can block sites such as PGC, cachetur, etc. And other apps from reading my data, because that's my choice, but C:geo violates my privacy by scraping the site...

Groundspeak therefore need to block C:geo

https://www.geocaching.com/account/settings/authorizations?success=True

January 3, 2020

1 hour ago, ardila.nl said:

The certificate for secure-stats.pingdom.com get loaded instead of a certificate for status.geocaching.com

HTTP Works fine http://status.geocaching.com/

When I click on your HTTP link I get the same message.

January 3, 2020

4 minutes ago, thomfre said:

What I meant is that there's a difference. Gclh is not scraping the site like c:geo is.

Hm ... there is not really a big difference for me. GClh works like c:geo and operate like a browser. After receiving data, GClh build the data into the webpage.

4.6k · January 3, 2020

2 minutes ago, thomfre said:

If this is the case, why is some profiles blocked in the API? That data is also visible on the website. If Cachly is blocked from showing the data l, why is c:geo allowed to display it?

This is wrong. Time for c:geo to finally face it, and start behaving like the rest of the apps.

Via the API data is shared and that's where privacy laws come in, if you have a problem with your data in c:geo then you must have a problem with browsers too as the show the gc website and keep data in their cache.

January 3, 2020

Just now, 2Abendsegler said:

Hm ... there is not really a big difference for me. GClh works like c:geo and operate like a browser. After receiving data, GClh build the data into the webpage.

So you are saying that you violate the ToU as well?

January 3, 2020

3 minutes ago, cghove said:

If I wish I can block sites such as PGC, cachetur, etc. And other apps from reading my data, because that's my choice, but C:geo violates my privacy by scraping the site...

Groundspeak therefore need to block C:geo

https://www.geocaching.com/account/settings/authorizations?success=True

And yes @Oceansazul, that is a request you can take further up the system

January 3, 2020

6 minutes ago, 2Abendsegler said:

Hm ... there is not really a big difference for me. GClh works like c:geo and operate like a browser. After receiving data, GClh build the data into the webpage.

GClh works in the browser on a site that by contract protects my privacy, C:geo does not protect my data....

Edited January 3, 2020 by cghove

January 3, 2020

23 minutes ago, thomfre said:

So you are saying that you violate the ToU as well?

? This is no secret and can be explained by the chronological sequence of the development, the API and the ToU. It is like all or almost all scripts do it, you know.

But think a minute about it, instead wailing. ?

The scripts can only see the data like a browser do it. That is the core you don't want to admit.

If you block your profile statistic, a script can not see it. If you don't block it, the script can see it. It is easy.

Edited January 3, 2020 by 2Abendsegler

January 3, 2020

15 minutes ago, cghove said:

GClh works in the browser on a site that by contract protects my privacy, C:geo does not protect my data....

No. ?

If you block your profile statistic, a script can not see it. If you don't block it, the script can see it. It is easy. c:geo does the same.

Edited January 3, 2020 by 2Abendsegler

8.6k · January 3, 2020

No, if someone says "delete my data", HQ is obligated legally to do so. C:Geo is not. C:Geo does not protect private data. They take data they were not expressly given (this is not the same a human browsing a web page with no intent to keep that data offline for their own purposes - which btw they're also allowed to do). C:Geo ignores the TOU and keeps data they were not given for continued offline use, without the users' knowledge or permission were the user to request that data be deleted.

So yes, "C:geo does not protect my data" (nor does GClh), and both are in violation of the TOU for scraping the website and storing that data for their own purposes.

January 3, 2020

12 minutes ago, 2Abendsegler said:

No. ?

If you block your profile statistic, a script can not see it. If you don't block it, the script can see it. It is easy. c:geo does the same.

I'm not just talking about stats, this is how my privacy is protected in third party apps.

C:geo disrespects and violates my choices, that's why Groundspeak need to block scraping from that app...

4.6k · January 3, 2020

1 minute ago, thebruce0 said:

No, if someone says "delete my data", HQ is obligated legally to do so. C:Geo is not. C:Geo does not protect private data. They take data they were not expressly given (this is not the same a human browsing a web page with no intent to keep that data offline for their own purposes - which btw they're also allowed to do). C:Geo ignores the TOU and keeps data they were not given for continued offline use, without the users' knowledge or permission were the user to request that data be deleted.

So yes, "C:geo does not protect my data" (nor does GClh), and both are in violation of the TOU for scraping the website and storing that data for their own purposes.

If I download your data with API partner software and you later ask HQ to delete your data it will disappear from the GS servers but remain in the API partner's database.

try again

January 3, 2020

1 minute ago, on4bam said:

If I download your data with API partner software and you later ask HQ to delete your data it will disappear from the GS servers but remain in the API partner's database.

try again

Wrong. Partners are required to delete data when told to do so by Groundspeak.

January 3, 2020

18 minutes ago, thebruce0 said:

No, if someone says "delete my data", HQ is obligated legally to do so. C:Geo is not. C:Geo does not protect private data. They take data they were not expressly given (this is not the same a human browsing a web page with no intent to keep that data offline for their own purposes - which btw they're also allowed to do). C:Geo ignores the TOU and keeps data they were not given for continued offline use, without the users' knowledge or permission were the user to request that data be deleted.

So yes, "C:geo does not protect my data" (nor does GClh), and both are in violation of the TOU for scraping the website and storing that data for their own purposes.

This is not right.

At the time c:geo take the data, it was allowed by the user.
It is, as if I save the website locally on my hard drive. If I do that, according to your definition, I would also violate privacy.

Edited January 3, 2020 by 2Abendsegler

January 3, 2020

Just now, 2Abendsegler said:

This is not right.

At the time c:geo take the data, it was allowed by the user.
It is, as if I save the website locally on my website. If I do that, according to your definition, I would also violate privacy.

Also wrong. C:geo takes logs from people that doesn't use c:geo. Not allowed by the user.

14.9k · January 3, 2020

46 minutes ago, thomfre said:

If this is the case, why is some profiles blocked in the API?

Because the law says the API has to block those profiles.

46 minutes ago, thomfre said:

That data is also visible on the website. If Cachly is blocked from showing the data l, why is [snip] allowed to display it?

One more time, Groundspeak is not allowing the app in question to download/store/display the data. The app in question is violating Groundspeak's TOU by acting like a regular browser and scraping the site. Groundspeak could block the app in question, but they'd block users with regular browsers at the same time.

January 3, 2020

4 hours ago, thebruce0 said:

Something has changed with the order of, or the asynchronous loading of, essential UI scripts, and it wasn't this way before the update... don't know if it's currently being looked into, but I just wanted to get my two (slightly annoyed) cents in ;P

I can only agree. Again, many functions and links are still unavailable or only reload themselves.

January 3, 2020

1 minute ago, thomfre said:

Also wrong. C:geo takes logs from people that doesn't use c:geo. Not allowed by the user.

You do not understand the core. You cannot determine, where your data can be used, but only whether. If you allow it, you allow it to all browser activity.

And c:geo does not keep your data, but a user. And he was allowed to do that too. And he can even do it after you said that the data should be deleted. Because it is simply the user's decision whether to delete your data or not. Like your data on my hard drive.

January 3, 2020

1 minute ago, 2Abendsegler said:

You do not understand the core. You cannot determine, where your data can be used, but only whether. If you allow it, you allow it to all browser activity.

And c:geo does not keep your data, but a user. And he was allowed to do that too. And he can even do it after you said that the data should be deleted. Because it is simply the user's decision whether to delete your data or not. Like your data on my hard drive.

You don't understand that it is my right tho choose who can use and where to use my data, and if I wish to block other apps, I should also be able to block C:geo

6.2k · January 3, 2020

2 hours ago, Keystone said:

Lawmakers believe otherwise. The ability to opt out of data selling/data sharing with third parties is a cornerstone of many privacy laws, current or proposed, including CCPA.

So where does this leave challenge cache owners who can no longer verify whether finders have qualified?

January 3, 2020

1 minute ago, cghove said:

You don't understand that it is my right tho choose who can use and where to use my data, and if I wish to block other apps, I should also be able to block C:geo

Sorry, but that what you want is not part of the GDPR.

Try it, to request this by GS. Maybe you found someone which implement it.

5.6k · January 3, 2020

Rather than arguing over c:geo -- which is very old news indeed, could we return to the immediate problem at hand? There seem to be quite a few folks here who can't even make use of the site at all.

January 3, 2020

4 minutes ago, barefootjeff said:

So where does this leave challenge cache owners who can no longer verify whether finders have qualified?

Personaly If I wish to log a challenge, I have to send the CO proof

8.6k · January 3, 2020

This is the core of the debate.

Everyone knows and agrees - once you put your data out into the public internet, it's effectively out in the public internet forever.

This LAW is forcing the right of an individual to keep their data private on to a service which they can choose to use. The law says now that a company which collects personal MUST allow a user to delete their data entirely from that service's storage. The Terms Of Use extend that to any APPROVED 3rd party service that may also make use of that data (implicitly given permission). The law is now reaching forcefully INTO companies' infrastructures. Therefore no, the above two apps are NOT allowed to download and store an individual's data from this website service because they have not been given express permission - just as the TOU also states that a person cannot download and use another user's data (see Pocket Queries) - and this is not the same as browsing or browser caches which do not have the express intent to store and use such data externally. So HQ now has to take a proactive stance for use of the data they collect - and allow approved 3rd parties to collect - by requiring agreeing to an updated TOU, with effects that extend to approved 3rd party developers.

The above apps are not approved, they do not seek permission to download and store other users' data. They are not in the right. And given the nature of viewing such data on the web, HQ is technically unable to implement solutions to block such nefarious apps from continuing to do so against the agreed upon terms.

If a user were to demand that their personal, private data, as protected by the GC TOU, be deleted, HQ would do so, and extend the demand to 3rd party developers who would also legally bound to do so (disclaimer: IANAL - this is my understanding). Those other apps are outside the scope of that demand. If that user were to find their personal data still being used by those unapproved apps, they could not hold Geocaching HQ legally responsible. They would have to seek legal action against those other rogue app developers.

It would be interesting to know what happens (or what might be expected by law to happen) if a user kills their profile, and the change proliferates to 3rd party apps like GSAK. Will previously downloaded data for use in GSAK databases be updated and zapped as well? Or is that information now in the hands of the GSAK user and not the responsibility of GSAK? (I haven't read GSAK legal agreements so I don't know how it deals with that sort of GDPR/privacy cascade)

6.2k · January 3, 2020

6 minutes ago, cghove said:

Personaly If I wish to log a challenge, I have to send the CO proof

That's fine if you do, but if you don't the CO can't require you to do so. That's the sticking point now.

13.4k · January 3, 2020

1 hour ago, cghove said:

https://www.geocaching.com/account/settings/authorizations?success=True

Excuse my ignorance, but has the app that violates the TOU ever been an "authorized" application ?

I thought that account setting was (and I clicked on it a long while ago...) for third-party sites like project-gc and gsak. Thanks.

January 3, 2020

3 minutes ago, cerberus1 said:

Excuse my ignorance, but has the app that violates the TOU ever been an "authorized" application ?

I thought that account setting was (and I clicked on it a long while ago...) for third-party sites like project-gc and gsak. Thanks.

No they have never been "authorized" they have been invited to use the API, but say that they won't...

8.6k · January 3, 2020

5 hours ago, thebruce0 said:

I'd just like to add, I'm not sure if it is because of the web-based scripting updates here, but I've also noticed that many of the website buttons and functions no longer work as immediately as they used to because of the passive loading of scripts. There's no indication that buttons are now 'active', so it looks like the page is loaded, you click the 'button' and are taken to the alternate url page (like a regular link) because the scripting hasn't loaded yet. IF the button has a link, otherwise it does nothing at all (see the "I agree" button doing nothing complaints).

Something has changed with the order of, or the asynchronous loading of, essential UI scripts, and it wasn't this way before the update... don't know if it's currently being looked into, but I just wanted to get my two (slightly annoyed) cents in ;P

I just want to double emphasize this... Example: a listing loads, and the browser may indicate it's loaded (no more loading dial) even though scripts are still being loaded asynchronously in the background that change the functionality of buttons on the page. So it's very annoying when the function you want to use happens to be the absolute last thing that's loaded and enabled - otherwise it takes you to an unrelated page. For example, editing a listing coordinate. The link URL is just the hash ("#"), so if the UI script interception isn't loaded and you click the coordinates link, it takes you to /seek - completely leaving the listing. And there's no way around it except to sit and wait until it looks like everything is done loading.

That ain't good... =/

January 3, 2020

26 minutes ago, ecanderson said:

Rather than arguing over c:geo -- which is very old news indeed, could we return to the immediate problem at hand? There seem to be quite a few folks here who can't even make use of the site at all.

Browser here is Firefox 71.0, Ubuntu Linux build, with the Ublock Origin and Decentreyes addons. WebGL is disabled and it is set to delete cookies on exit. I had no problem with the privacy prompt and it has not reappeared. After accepting the prompt, I have used the latest version of Waterfox on Windows 7 and managed to view and submit logs.

I suspect any problems with the privacy panel are due to the non-availability, or incorrect performance, of a javascript function which is meant to intercept clicks on the accept button. If that is happening on a "vanilla" instance of a currently supported browser (installed "out of the box" with no subsequent configuration) then I venture to suggest that that is a problem GS needs to address with some despatch. If people with addons are noticing it I would suggest trying the browser with addons disabled.

Edited January 3, 2020 by and1969

8.6k · January 3, 2020

You know, side thought, I wonder if the GDPR could potentially make the life of said unauthorized 3rd party apps much shorter? Were someone to demand their private data erased, and see that such apps have no obligation to do so having not implemented GDPR changes, could that be legal suicide? And if they do alter the workflow to adhere to GDPR, might that affect whether they continue to scrape data, or would that just be unrelated? That user would need to make the request of both HQ and those apps individually... hm. GDPR could muck things up for them. (might that be about the only good thing that comes of gdpr? ... *runs*)

January 3, 2020

7 minutes ago, thebruce0 said:

... They would have to seek legal action against those other rogue app developers. ...

I agree, only the developers of the scripts are not liable, of course, because the responsibility rests with the user. I know it of GClh. And the others would do well to do the same.

And now we're back to the user and not by apps or companies, which use private data. I, as a user, can download data. I can download all cache listings completely with all the logs. And it's allowed for my personal purpose. And i don't have to delete the data if someone decides not to make it public anymore. And that's the whole point with scripts.

January 3, 2020

... and c:geo, of course.

8.6k · January 3, 2020

You're not going to make any friends here arguing that you can do anything with data you can scrape from a website. It's private data provided by HQ for use in browser - not in a package application, whether compiled or selected scripts, for use externally. And, the more you defend the practice, my guess is the less likely we'll be to see you around much of these parts in the future... Just a fair warning.

HQ is legally required to take action now due to GDPR with data that it stores and uses if requested by someone in the EU. They extend that requirement to approved developers since the data they store and use is provided from this service under a usage agreement. Any service that takes that data without being approved will never be on good terms. IF such 3rd party services decide to adhere to GDPR, that's another matter - one that resolves the issue with the user and that app, but it does not resolve the issue with that app and this service. Sure, such apps can download and store data from the website, but as long as they do so, they are in violation of the TOU of this service and will never be on good terms.

As a web developer I'm fully aware of the technical and ethical issues with scrapers. Many websites that earn necessary funds from embedded advertising and partnerships are also quite aware of the technical and ethical issues with scrapers. I would highly recommend you reconsider your stance on the matter. From a technical, ethical, and privacy standpoint. Just sayin'.

Edited January 3, 2020 by thebruce0

January 3, 2020

I said: "I can download all cache listings completely with all the logs. And it's allowed for my personal purpose."

That is the law in Europe in GDPR. And that was starting point for the california thing.

Of course, I can not put something of this data into the internet or on other public positions. But I can use it on my private laptop.

I am an advocate of my privacy data, but the discussion here would limit my freedom, if it would come true. But it won't come.

9 minutes ago, thebruce0 said:

You're not going to make any friends here

Yes, I know. I have to live with that. If you defend your opinion, it is often the case.

6k · January 3, 2020

27 minutes ago, thebruce0 said:

You know, side thought, I wonder if the GDPR could potentially make the life of said unauthorized 3rd party apps much shorter? Were someone to demand their private data erased, and see that such apps have no obligation to do so having not implemented GDPR changes, could that be legal suicide?

I suspect not, because the developers of c:geo are not collecting any data, and there is no company behind them that is doing so. The only people collecting data are the individual users, so "someone" would have to be making the demand of every indivudual user, not the developers. In these respects c:geo is no different to firefox/chrome/IE all of which have the potential to collect and store that same data offline. This differs from the API developers in that it is ultimately Groundspeak that could be held responsible for the behavior of those APIs due to the agreement they have entered into.

Disclaimer: I am not a lawyer and I don't play one on TV.

Release Notes (Privacy law compliance) - December 31, 2019

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment