thomfre
-
Posts
571 -
Joined
-
Last visited
Posts posted by thomfre
-
-
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...
-
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?
-
Are you really sure that you agree?
Did you take the time to read both the Terms of Use and the Privacy Policy from start to finish?
Maybe the site recognized that you scrolled through it too fast? Or maybe you only clicked on one of the links?
Just joking, this is a known bug reported in numerous threads already
-
8 minutes ago, barefootjeff said:
The guidelines say we can't ask a finder to document their qualification on post-moratorium challenges, so do we have to just take their word for it that they qualify? Or can we delete such a log as being unverifiable? Some clarification of this would be helpful.
Maybe this will change the type of challenges we're allowed to create. This is from the challenge cache guidelines:
Quote- Challenge owners will need to make sure that cachers can show that they have completed the cache requirements without compromising their privacy.
But they also say:
Quote- Cachers may sign a challenge cache's physical log at any time. However, the challenge cache may be logged as found online only after the log is signed and the challenge tasks have been met and documented.
- For cache pages published after April 21, 2015 with a challenge checker, the owner can confirm the finder's qualification with the checker when the cache is logged as found. No further documentation is required from the finder.
So unless you're able to verify with a checker, I will say that it's up to the finder to prove that they are qualified. If not, you should be allowed to delete the log.
-
.png)
3
-
1
-
5 minutes ago, barefootjeff said:
I'm just wondering how this impacts challenge cacher checkers for cachers who have opted out. Specifically, since COs are now responsible for determining whether or not someone has qualified for a challenge, if the required information isn't available to project-gc how is this meant to work? My own challenges rely on acquired attributes and this information isn't readily available on the geocaching website even if the cacher still shows their statistics on their profile.
Unless Project-GC is given special permissions, you can't check it anymore for opted-out-users.
Edit: just tested. Challenge checkers doesn't work for opted-out-users. And they won't be able to run them themselves either.
To be honest, this is just stupid. And has nothing to do with privacy.-
1
-
2
-
-
12 minutes ago, niraD said:
That app does not use the API, and deliberately acts like a regular browser so it can scrape data from the site.
I know very well how it works. My question is how Groundspeak can continue to allow that to happen now.
Edit: There are ways to detect c:geo, Groundspeak can block the app - if they want to.-
1
-
-
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?
-
2 minutes ago, hcy said:
Website is completely unusable - I click on "I agree" but nothing happens.
I recommend trying https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm?hl=en and/or https://pi-hole.net/
It will make the whole internet better for you. And it will make geocaching.com work again, if you block cookiebot.com. -
3 minutes ago, arisoft said:
Adoption is also possible in the new version.
Are you sure about that?
https://www.geocaching.com/help/index.php?pg=kb.chapter&id=38&pgid=54
QuoteGeocaching HQ will not process a transfer without permission from the original cache owner.
-
1
-
1
-
-
4 minutes ago, L0ne.R said:
My guess is they don't care. It will be interesting to see if there's any reaction from COs who set-em-and-forget-em.
I think they never intended to pick up their caches and may be happy that that job will go to CiTcO (cache in - trash cache out) volunteers.
You're probably right. Most of them won't ever know. And in the end, this is for the better for all of us.
But since this has been added:Quote... you agree to hold harmless and release from any and all claims both Groundspeak and any person who has adopted, removed, and/or disposed of your geocache.
I guess that the owners that haven't accepted this, still can make claims towards Groundspeak. I'm just curious if this has been given any thought by Groundspeak. Cleaning up the playing board is in the best interest of all of us.-
1
-
-
3 minutes ago, L0ne.R said:
Do you mean all the already abandoned containers of archived caches that are currently out there?
Yes.
I guess most owners of those won't ever log in and accept the new terms. -
But how will this be handled with the existing geocaches out there? The ones where the owners haven't accepted the new ToU...
-
1
-
-
6 minutes ago, on4bam said:
Then, doesn't it look like a language problem? GDAK uses private data but the author doesn't collect it, it's used internally (no other way GDAK can work without it to access the API).
I think this is a combination of a language barrier and misunderstanding from the GDAK developer.
On 8/15/2019 at 6:07 AM, thomfre said:I suspect that there's a language barrier here as well. The app does collect personal information, so it need a privacy policy - even if all it says is that the information never leave the app.
9 minutes ago, on4bam said:I hope no bridges where burned because Wout was also thinking about writing a platform independent GSAK like program (should GSAK not survive there would at least be an alternative). In all, it's the community that's losing, not GS.
I hope so too. GS is a part of the community, I don't think they enjoy disabling API access for a partner. I hope a privacy policy can be created, and that this will be enough to get GS to reenable the access. But I don't know anything about the discussions that led to this, so I don't know if this is enough, or if the bridge has burnt down.
-
22 minutes ago, on4bam said:
Enlighten us if you have more info on this. The info on why GDAK's API access was axed came from the author on another forum and since HQ hasn't reacted it's the only info we have.
Sure, no problem. It has already been stated in this thread that the reason for this was that HQ required a privacy policy:
On 8/7/2019 at 2:35 PM, on4bam said:Just to put this in perspective: GS demands the author of GDAK to declare how and for what he collects data from users (privacy policy). As the author claims not to collect any data there is nothing to declare and GS refuses to accept this. Maybe it's too hard for a US commercial company to understand that people write software for the good of the community without any personal gain.
Geocaching.com has a significant amount of European users. They have to both take GDPR seriously, and take the measures required to be compliant. The API provides access to user's personal information, so they are obliged to have a written agreement with all API partners. This agreement require the partner to follow a set of rules. §4.10 say:
QuoteYou must maintain and observe a separate privacy policy for your API Client that is consistent with and provides at least the level of protection of the current Geocaching HQ Privacy Policy.
It's really that simple. If a partner won't do that, HQ has no other choice than to disable the API keys.
And for the argument that the app is not collecting any information, it is. It has access to the API, and just by authorizing, it will get access to personal information. The privacy policy need to explain how that information is used. If it never leaves the device, the policy should say so. If the app use third party services, like analytics, the privacy policy will also need to mention that.-
1
-
-
HQ is not hard to work with. The lackies are really nice people, and they don't try to be evil.
It's clear that GDAK is valuable to a lot of people. So this sucks. But the GDAK developer is the one to blame here. He has to follow the same API agreement as the rest of us. And HQ have to take care of their legal obligations. They didn't really have any choice here.
Maybe someone can persuade him to write a privacy policy? I'm willing to help him write it, if that will make any difference...
-
1
-
4
-
-
On 8/13/2019 at 3:10 PM, Yellow ants said:
Thanks again to Groundspeak for doing what they can to ruin geocaching. This is immensely frustrating.
If this really is about the lack of a privacy policy, there's really not much Groundspeak can do. They have too many European users to not take GDPR as serious as they can. And having control over all their partners is a vital step in maintaining their own GDPR compliance. This is a legal issue, and not something Groundspeak do to ruin geocaching.
I suspect that there's a language barrier here as well. The app does collect personal information, so it need a privacy policy - even if all it says is that the information never leave the app.-
1
-
4
-
-
6 minutes ago, thebruce0 said:
...but if you want to see the next level clues, you'll need to log the required caches to register the current level clues and move on to the next.
That is not quite true. Try looking at the end of the query string on the map after you've added the clue filter
-
56 minutes ago, HiddenGnome said:
I am not going to make excuses for releasing code that has bugs, but we also cannot always cover every single permutation that might arise. What I will promise is that we will try to catch as many bugs as possible before a release and then fix the bugs that do make it to the community quickly. We are a small team and are moving quickly to address issues. I apologize for inconveniences that anyone has experienced and I thank you for your patience.
As a developer myself, I know it is close to impossible to not release code that has bugs - unless you don't release at all. That is not any better. But the really great developers monitor and fix those bugs, just like you have done now - including keeping us updated here. That is very much appreciated!
The speed in which you fixed the bugs this time (which also was fewer than we have seen with other promotions) at least felt a lot faster than before. If that was simply because you kept us informed, or if it was because you actually did it faster doesn't matter. I felt a lot better than it has done before.
Thank you!-
4
-
-
Just out of curiosity, what kind of app are you looking at building?
-
5 minutes ago, BlackRose67 said:
I launched G4L and it was able to import a bookmark list ok
The old API is still active. It won't be shut down until June 1st.
-
33 minutes ago, edscott said:
All well and good if I could get there. All the new "maps" offer me is a bank screen. I can manually delete the "play/" in the URL and get a map, but it is centered on my home coordinates not the cache I'm attempting to study or map. I'm basically mapless which for me means no longer geocaching.
I have adjusted my user script to replace /play/map with /map, both in the menu and on the "View large map" link on cache pages. This hides the new map completely for me, and might be useful for you as well: https://thomfre.net/en/tech/adjusting-the-new-experience/
-
1
-
-
2 hours ago, lodgebarn said:
Click, click, click, click is what happens every time I use a map to remove my hides and finds. Sure it is good to see them sometimes but I am convinced the defaults should be OFF. Surely anybody who wants to find caches does this, especially around their common caching area? Why is this sot of usability issue not picked up in the dev/test phase?
I want to see all caches, including my hides and finds, 90% of the times I open the map. The few times I want to hide something, it's cache types - not hides/finds.
The best would have been if the map remembered your last filter, and just used that. That way both you and I would have gotten the starting point we wanted.
-
2
-
1
-
-
2 minutes ago, thebruce0 said:
Why is your opinion not to do anything to make cheating harder (why not just give everyone the completion code and make it all honour system then?) more relevant than the people who create these experiences and want cheating to stop from the get-go?
It's not. It's simply my opinion. We have an adventure lab in our household as well, so I am very much aware of how annoying the cheaters are.
QuoteAre you against having to complete the lab in order to get the completion code? Would you rathere there be, at the beginning and end, a prompt asking "Have you completed the lab?" answering yes to get credit for it? If so, then why "put the work" into having a completion in the first place? That's there to ensure people do it "as intended". So why the arbitrary requirement for a completion code differing from the arbitrary requirement for being online, on location, app-only? Yeah, the latter is more work the former; but the former is more work than no work.
Either there's effort to thwart cheating - and a decision made about how much should be thwarted - or there's nothing. And if there's nothing, then, well, just give'em a yes/no prompt to get credit for completion. Let's see how well that goes over...
Absolutely not. But we are talking about geocaching. Why spend a lot of time making lab caches very hard, when it's so easy to cheat with the millions of normal geocaches in the world? The current app, with the current implementation, could very easily support offline, without making it easier for "the ordinary geocacher" to cheat. The cheaters will cheat anyway, so just detect and block them.
This is how *I* would like it to be. This is not the only possible solution, just the one I would prefer. I don't have any issues with people disagreeing with me about that.QuoteBut again, developers to blame, not smartphones.
I don't disagree with that.
-
Just now, thebruce0 said:
...then why put any work into trying to thwart cheating before it happens? At all?
Exactly! This would be the perfect solution! Don't waste time on preventing it (we'll just get better cheaters). But detect and block instead.
.png)
Release Notes (Privacy law compliance) - December 31, 2019
in Geocaching HQ communications
Posted
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.