Upcoming privacy changes

There will be some privacy changes made "soon". This is to comply with laws that Geocaching HQ must respect. This time we have discussed solutions with Geocaching HQ and we are happy with the agreement we have made. At least when considering circumstance.

We don't have an exact date for when this will go live yet, but it could be anything from within a week from now to a month from now I guess. Most likely 4th-5th of February or 11th-12th of February.

The relevant part of Challenge checkers. One won't be able to execute a challenge checker with a name belonging to a player with hidden data. When we implement this there will most likely be quite a lot of players with hidden data. However, they will need to open up their data for Project-GC to be able to use the site themselves, we expect that most (a clear majority) will do that within a month or two.

The next culprit is that, as a challenge checker script developer knows, many of the API methods can be called with an arbitrary `profileId`. Meaning, even if someone put USER-X into the `profile name` box, the checker can run `GetFinds(12345678)`. This is where the next interesting part comes. All api methods are also protected, and they will return a boolean false when the data isn't accesible. I assume most scripts doesn't handle this. On the other hand, it will be a very few script that fetches data for another profileId than the one coming in as an argument.

This sounds like a redo of the debacle of a few months ago, unless I'm misunderstanding?

Quote

This time we have discussed solutions with Geocaching HQ and we are happy with the agreement we have made.

In other words, it's not the same as last time.

Will Geocaching HQ inform all users about this change?

I expect there will be some discussions coming up when I start deleting find logs on my challenges for users where I can't verify with the checker that those users qualify.

We believe and hope that you will be able to run a challenge checker for more or less everyone that logs a challenge cache. They can't be run on all geocachers today either so. But time will tell. If not, it's a question for Geocaching HQ.

These two statements seem in contradiction with one another:

Quote

One won't be able to execute a challenge checker with a name belonging to a player with hidden data. When we implement this there will most likely be quite a lot of players with hidden data.

Quote

We believe and hope that you will be able to run a challenge checker for more or less everyone that logs a challenge cache.

If you're expecting that most users will just turn their privacy settings off... they won't. I don't think people were being hyperbolic last time, when they said this will be the end of challenges.

bmuzzin Wrote:
-------------------------------------------------------
> If you're expecting that most users will just turn
> their privacy settings off... they won't. I don't
> think people were being hyperbolic last time, when
> they said this will be the end of challenges.

I do, but it's because I know of details that I can't disclose yet. I could be wrong, but I won't be wrong with the vast majority. Last attempt was reverted, as you know. Both sides (Project-GC and Geocaching HQ) took some time to think about what we should do. In the end we came back to each other with basically the same solution. We'll most likely know if it will work in about a month from now, before that there is no need for speculation to be honest.

Last time Project-GC did what we were ordered to. This time we are doing this together, in a way that both parts believe should and will work.

I have almost no confidence in HQ. They make terrible decisions at every opportunity. I have more confidence in you/PGC, but I'm confused why this post was made with incomplete information.

There is one relevant part in this post, most methods can return false. The rest is context to why.

Focusing on the API difference... will GetHides(1234) for any random user now potentially return false?

I do that in my script in several places, most commonly, if you're doing a top list (oldest / most favorite / highest elevation). For example, oldest caches with the boat attribute. I need to call GetHides, because PGC.GetOldest does not return the attributes. I wouldn't think that a user's hides are a privacy concern, since you can go to the geocaching map and directly search for anybody's hides... but just confirming.

bmuzzin Wrote:
-------------------------------------------------------
> Focusing on the API difference... will
> GetHides(1234) for any random user now potentially
> return false?

It actually will. At least as it is now (well, soon). One of the reasons is that these users will be treated the same if they explicitly check a checkbox to not share with 3rd parties. We are therefore making a big difference of fetching data belonging to user X, or going the reverse direction and finding data by him, which belongs to something else. It's fairly similar to how Geocaching HQ does it, but maybe not exactly the same in this particular case.

For this particular case I think it would be the easiest if we just added `attributes` to the relevant API methods. I assume it would be very easy to add that to the ones you list.

If that sounds like something you agree would be better, could you double-check which methods you need it for, then I can look into implementing it.

Yes, it would be better - having to get the attributes this way was a hack of sorts, but it was the only way with the current API. But, I personally have several challenges based on this behavior (and I think others have used it as well). The methods are:

PGC.GetOldestCaches
PGC.GetFavorites
PGC.GetHighestCaches
PGC.GetLowestCaches

It might be best, if you could just provide a "fields" array like you can in GetFinds, and then just return all those fields (and if it's not provided, give back what it currently gives for the fields).

I agree that they should have supported a `field` param. It requires more refactoring though. For now I will add the attribute fields. It's coming in next release.

So, quite a few of my checkers are now broken because of the GetHides change went live... did the getting the attributes from GetOldest et. al get added? (Don't see any change in the documentation).

bmuzzin Wrote:
-------------------------------------------------------
> So, quite a few of my checkers are now broken
> because of the GetHides change went live... did
> the getting the attributes from GetOldest et. al
> get added? (Don't see any change in the
> documentation).

Regarding `GetHides()`, the scripts has to handle the response. The scripts shouldn't become broken. They will however not return data for cache owners with privacy setting, but that is just an effect of Geocaching HQs privacy policy. Users with privacy settings breaks challenges in multiple way, nothing Project-GC can do about that.

I will look into adding the attributes to the following methods today.
PGC.GetOldestCaches
PGC.GetFavorites
PGC.GetHighestCaches
PGC.GetLowestCaches



Edited 1 time(s). Last edit at 03/19/2026 11:29AM by magma1447. (view changes)

Actually the four methods are already returning attributes. It has been implemented. The documentation just doesn't mention the returned data. Neither before the change or after.



Edited 1 time(s). Last edit at 03/19/2026 11:41AM by magma1447. (view changes)

I just cut out the GetHides call, because it doesn't need to fetch the attributes anymore.... all good, thanks.

We now have some news, and some more details. We do not have an exact release yet, but most like around 1.5 weeks from now (the 17th is indicated in the information that exists, but not set in stone).

---

After discussions with Geocaching HQ we will soon, in collaboration, make some changes to how Privacy settings at Geocaching.com affect Project-GC.

On Geocaching.com there are two pages one can adjust privacy settings:
- https://www.geocaching.com/account/settings/authorizations
- https://www.geocaching.com/account/settings/userprivacy

As it works today, the first of the above partly affects Project-GC. Not the least the fact that one cannot login to Project-GC with a `Do not share my personal information with Authorized Developer geocaching applications` checked. The options at the second page do not in general affect third parties at all. Geocaching HQ wishes for them to be respected by third parties, like Project-GC.

With the upcoming changes some of the detailed Privacy settings at the second page will affect Project-GC, just as the setting on the first page does. The five specific settings are:
- Geocaches found
- Trackables
- Souvenirs
- Gallery
- Statistics

These five must be set to Public to be able to use Project-GC. The rest aren't relevant since Project-GC does not handle that information.

However, a new setting will be added to the User privacy page. There will be an override which allows sharing the data with Project-GC specifically, regardless of the Privacy settings on the same page. So to be able to use Project-GC in the future you must:
- Allow sharing data with third parties (Authorizations page). This is already the case today.
- Have the five Privacy settings set to Public, ALTERNATIVELY have the Project-GC override enabled.

Any geocacher who has any of their five privacy settings "too restricted" and an active auth-token with Project-GC will get their "Project-GC override" enabled automatically, unless they fill in a form. Geocaching HQ has started to send out an email with this information. Geocaching HQ is (directly) e-mailing a form to those affected, alongside additional details.



Edited 3 time(s). Last edit at 02/06/2026 08:41PM by magma1447. (view changes)