Release Notes (Website: Solution Checker) - October 19, 2017

[+fizzymagic]

4 minutes ago, arisoft said:

This is not the only checker with many boxes. I have used years an another with same kind of user interface and it has proven sensitive for typing errors and difficult to use in mobile devices. I would use the same interface as the corrected coordinates is using. I think there was no one whining about why you have to enter corrected coordinates in a single box instead of splitting it to random number of separate boxes. Checker shoud check coordinates in every format as corrected coordinates are possible to enter.

 

Good point.  They figured out how to do it for the corrected coordinates input; why was that code not used here?

[+Isonzo Karst]

Agreeing with others on these two points:

• it's much too big,
• it should accept coords in multiple formats, just as other coords entry does on the site
  • (MinDec)(DMS)(DegDec) - formats now available for listings, waypoints, update coords.
  • Ideally, a single box, but two, one for lat and one for longitude would be okay.  

[+thebruce0]

Case insensitive matches, somewhat loose/flexible, values would still need to be validated after matching -

DDM: \b([NS])\s*(\d\d)\D*(\d\d)\.(\d\d\d)\D+([EW])\s*(\d?\d\d)\D*(\d\d)\.(\d\d\d)\b

DMS: \b([NS])\s*(\d\d)\D*(\d\d)\D*(\d\d)\D+([EW])\s*(\d?\d\d)\D*(\d\d)\D*(\d\d)\b

DD: \b(\d{1,2})\.(\d+)\D+(\d{1,3})\.(\d+)\b

Localization can match different cardinals. RX can be stricter to match proper numerical values (dealing with leading zeroes when allowed or not for degrees, or number values within explicit ranges (0-60 or 180) rather than checking in code after the match).

Easy to implement for a single input box.  Strictly speaking. Of course the GS backend is completely unknown to we out here.

ETA: Alternatively, strip any character not essential [^NSEW\d\.\s\,] and then run a match. You can see this is what geocheck.org when the coord is submitted.

Edited October 24, 2017 by thebruce0

[+dprovan]

7 hours ago, arisoft said:

This is not the only checker with many boxes.

This is part of what bothers me. Yep, for sure, other checkers have the problem of having individual fields, and anyone that's solved a few puzzle caches knows it makes the interface a real pain to use. So it's shocking that the developers didn't have the slightest idea about what anyone with any experience with checkers knew.

[+fizzymagic]

8 hours ago, Isonzo Karst said:

Agreeing with others on these two points:

• it's much too big,
• it should accept coords in multiple formats, just as other coords entry does on the site
  • (MinDec)(DMS)(DegDec) - formats now available for listings, waypoints, update coords.
  • Ideally, a single box, but two, one for lat and one for longitude would be okay.  

I disagree.  Two input is NOT okay for me.  It has to be one, so I can paste the entire coordinate string in.  I have invested a lot of time and energy building tools that generate coordinates in nice, neat forms and I don't want to have to unnecessarily snip pieces out and manually paste each one into a different box.

[+fizzymagic]

7 hours ago, thebruce0 said:

Case insensitive matches, somewhat loose/flexible, values would still need to be validated after matching -

DDM: \b([NS])\s*(\d\d)\D*(\d\d)\.(\d\d\d)\D+([EW])\s*(\d?\d\d)\D*(\d\d)\.(\d\d\d)\b

DMS: \b([NS])\s*(\d\d)\D*(\d\d)\D*(\d\d)\D+([EW])\s*(\d?\d\d)\D*(\d\d)\D*(\d\d)\b

DD: \b(\d{1,2})\.(\d+)\D+(\d{1,3})\.(\d+)\b

 

Those are almost right; they need to take into account single-digit degrees and minutes.  I would use (\d{1,3}) for the degree fields and (\d{1,2}) for the minutes instead.

Also, you can do UTM pretty easily.  I think this is correct (but I may have overlooked something):

UTM: \b(\d{1,2})([A-Za-z])\s+[Ee]\s*(\d+)\s+[Nn]\s*(\d+)\b

[+thebruce0]

1 hour ago, fizzymagic said:

Those are almost right; they need to take into account single-digit degrees and minutes.  I would use (\d{1,3}) for the degree fields and (\d{1,2}) for the minutes instead.

I've never seen DDM format with single digit degrees or minutes (N5 3.045? Rather N05 03.045; especially on gc.com, though I haven't tested on other checker sites). They always have leading zeroes that I've seen. There's no "almost right", since there are a wide variety of structures and strategies one could employ in regex to get the desired results. But again, I did say "somewhat loose/flexible, values would still need to be validated after matching".  Nonetheless, you can see the DD format includes flexibility for one or more digits, or 1-3 digits. So that can easily be adapting into the DDM if desired.  But that's all technicalities.

The point of my post was to show how easy it is to validate and parse out essential values from a single unrestricted string input, however one might want to construct a regular expression.  The 3 could even be combined into one more complex regex if desired.

 

1 hour ago, fizzymagic said:

Also, you can do UTM pretty easily.  I think this is correct (but I may have overlooked something):

UTM: \b(\d{1,2})([A-Za-z])\s+[Ee]\s*(\d+)\s+[Nn]\s*(\d+)\b

Probably. Should be easy enough to google for the proper validation syntax of UTM and most any coordinate format, and adapt to regex if desired.

Edited October 24, 2017 by thebruce0

[+on4bam]

9 minutes ago, thebruce0 said:

I've never seen DDM format with single digit degrees or minutes (N5 3.045? Rather N05 03.045; especially on gc.com, though I haven't tested on other checker sites). They always have leading zeroes that I've seen.

At least in geocheck I almost always use single digits as I'm E4 xx.xxx No leading zero's needed. After getting "green" or "red" the checker itself returns E004 xx.xxx

 

[+thebruce0]

#TMYK

I suppose yes allowing single digit entry would be absolutely fine

Edited October 24, 2017 by thebruce0

[+dprovan]

29 minutes ago, thebruce0 said:

I've never seen DDM format with single digit degrees or minutes (N5 3.045? Rather N05 03.045; especially on gc.com, though I haven't tested on other checker sites). They always have leading zeroes that I've seen.

Really? It's somewhat uncommon for an output to display the leading zeros -- although I don't know why since the programmer normally has to consciously decide to include the leading zero, and it makes perfect sense to leave it out, anyway -- but when working on puzzle solutions, I almost never type the leading zeros, and that's the case that's important here.

I don't recognize the format strings you guys are throwing about and I don't know why you're talking about them, but it looks to me as if you're forgetting that solutions don't have to have to have the full three digits of accuracy and, for that matter, they don't have to have a decimal point at all.

[+thebruce0]

See prior comment

Given there's really no way to confuse digits between cardinal and numerics if it's 1 or 3 digits, allowing 1 for input is fine. The 'conversion', as on4bam pionted out, can easily add them ( Ex y.zzz -> Exxxyyzzz ) if desired for display, even if not the values are the same whether 1 or 3 with leading 0's. So yeah, allowing 1 digit input would be fine.

18 minutes ago, dprovan said:

solutions don't have to have to have the full three digits of accuracy and

Well, ideally, given the standard gps format used on gc.com, I would be quite surprised to see a solution pump out N43 13.1 instead of N43 13.100. If that's what you're referring to. For the context of GC.com, I'd expect the results to show as X##° ##.### Y###° ##.### with 0 pads as seems fairly standard on listings.  Anyway,  I'm sure the 'gammers know how to do it all...

Edited October 24, 2017 by thebruce0

[+dprovan]

35 minutes ago, thebruce0 said:

Well, ideally, given the standard gps format used on gc.com, I would be quite surprised to see a solution pump out N43 13.1 instead of N43 13.100.

I guess I don't know what you guys are talking about. "Pump out"? I'm talking about a human typing coordinates into a checker field. No human that understands math -- and trusts the user interface -- is going to waste time typing "13.000" when he can type "13". A user interface that doesn't understand the two forms are equally valid and identical is broken.

[+_SWH]

please TAKE OUT the recapcha requirement. That is a strange thing to have for a checker. Also, pasting an entire coordinate is better than boxes to "TAB" to or type into. Most people are grabbing cords and want to plug one time into the new cords "pencil" on the page.

 

While you all are at it, make the app available to auto adjust the cords by placing them as a string of numbers into a new waypoint then it pulls it into automatically instead of typing each digit.

 

[+thebruce0]

2 hours ago, dprovan said:

I'm talking about a human typing coordinates into a checker field. No human that understands math -- and trusts the user interface -- is going to waste time typing "13.000" when he can type "13". A user interface that doesn't understand the two forms are equally valid and identical is broken.

Ok, sure, if the interface assumes that no number = 0 then it could allow a user to skip the trailing 0's. That's all just a matter of how strict the input is made; regex can be easily adjusted to allow 0-3 digits for the decimal in the DDM, or 0+ in the DD. Besides the point tho; all this chat just shows how (relatively?) simple it is to implement a full string coordinate input, and interpret and pull out valid values on the backend for the checker.

[+dprovan]

3 hours ago, thebruce0 said:

Besides the point tho; all this chat just shows how (relatively?) simple it is to implement a full string coordinate input, and interpret and pull out valid values on the backend for the checker.

Yep. I'd consider that point important except the more important point is that it's already been done.

[+thebruce0]

7 hours ago, dprovan said:

the more important point is that it's already been done

Indeed it has, which is why it can be done here; and it's already likely being worked on.  <side note, we need a thumbs up smiley =P>

[+NYPaddleCacher]

15 hours ago, dprovan said:

I guess I don't know what you guys are talking about. "Pump out"? I'm talking about a human typing coordinates into a checker field. No human that understands math -- and trusts the user interface -- is going to waste time typing "13.000" when he can type "13". A user interface that doesn't understand the two forms are equally valid and identical is broken.

If there coordinate format is Degrees Decimal Minutes, then the minutes portion should be expressed as a decimal value.  13.000 or 13.0 are both valid and equal decimal values.  Although 13 is equal to 13.000, without the decimal point it is an integer and thus not "Decimal Minutes".  Although most coordinate checkers require the hemisphere (N/S/E/W) coordinates expressed as DDM or Decimal Degrees one can omit the hemisphere and, instead use a negative value for a location south of the equator.  Latitudes west of the Greenwich mean time line can be express as a negative latitude.

[+thebruce0]

13 minutes ago, NYPaddleCacher said:

coordinates expressed as DDM or Decimal Degrees one can omit the hemisphere and, instead use a negative value for a location south of the equator

Which reminds me, forgot to add "-" as a valid optional lead character in the DD regex.

[+dprovan]

2 hours ago, NYPaddleCacher said:

If there coordinate format is Degrees Decimal Minutes, then the minutes portion should be expressed as a decimal value.  13.000 or 13.0 are both valid and equal decimal values.  Although 13 is equal to 13.000, without the decimal point it is an integer and thus not "Decimal Minutes".

You think that makes sense to the user? It doesn't. That's pure programmer thinking, and, by the way, just the kind of mistake that pops up too often in these new GS user interfaces. The user is entering a number. It's the programmer's job to deal with the distinction between a whole number and a decimal number.

[+fbingha]

11 minutes ago, dprovan said:

You think that makes sense to the user? It doesn't. That's pure programmer thinking, and, by the way, just the kind of mistake that pops up too often in these new GS user interfaces. The user is entering a number. It's the programmer's job to deal with the distinction between a whole number and a decimal number.

Yes, but I would say what we have here isn't a programmer problem but a designer problem. Being a programmer, I see the work of the UI person here, wanting that large thing with two boxes based on some UI spec they've subscribed to.

[+noncentric]

One of my concerns about the new native Solution Checker is that some CO's will use it INSTEAD OF using one of the 3rd party checkers.

What's the problem with that?

Problem: Someone viewing that cache in the app won't be able to check their solution, since the Solution Checker doesn't appear in the app.  They won't even SEE that the cache has a checker.  Other geocheckers, like Certitude and geocheck.org, are visible in the cache descriptions within the app.  Cachers viewing those caches in the app can see that there's a checker and can click on the link to it (if they have wifi/cell service) if they want to use it.

Temp fix: Until the native Solution Checker functions in the app, which would hopefully also work while Offline (if feasible), then please include a notification in the official app's cache description that alerts cachers that the cache has the native Solution Checker. Cacher's can then open the cache in their browser if they want to use the Solution Checker. Maybe something like "This cache has a Solution Checker. Open this cache in your phone's browser to use it.".   ETA: Maybe even make that notification a link to open the cache in their browser, like when selecting "Open in Browser" in the menu options.

 

Edited October 25, 2017 by noncentric
one more idea

[+hzoi]

8 minutes ago, noncentric said:

Until the native Solution Checker functions in the app, which would hopefully also work while Offline...

Disclaimer: I am not a programmer, or even close.  But to work offline, wouldn't the coordinates have to get sent to the phone for all caches made available offline?  Without sufficient encryption or some other safeguard, I wonder how difficult that would be to exploit.

[+noncentric]

19 minutes ago, hzoi said:

24 minutes ago, noncentric said:

Until the native Solution Checker functions in the app, which would hopefully also work while Offline...

Disclaimer: I am not a programmer, or even close.  But to work offline, wouldn't the coordinates have to get sent to the phone for all caches made available offline?  Without sufficient encryption or some other safeguard, I wonder how difficult that would be to exploit.

Good point, so maybe not function offline.

But still have the 'notification' be visible within the cache description offline. The 'notification' is really my main concern anyway with viewing applicable caches in the app.

[+Team DEMP]

36 minutes ago, hzoi said:

Disclaimer: I am not a programmer, or even close.  But to work offline, wouldn't the coordinates have to get sent to the phone for all caches made available offline?  Without sufficient encryption or some other safeguard, I wonder how difficult that would be to exploit.

Not a challenging situation to overcome. The actual coordinates aren't sent but a hash of those coordinates are. You can determine if the coords match but not the reverse. It's the same approach to how passwords are stored.   

Edited October 25, 2017 by Team DEMP

[+niraD]

32 minutes ago, Team DEMP said:

Not a challenging situation to overcome. The actual coordinates aren't sent but a hash of those coordinates are. You can determine if the coords match but not the reverse. It's the same approach to how passwords are stored.   

This works for checkers that use an exact match (whether that match is a set of coordinates or a keyword).

But it would be nice if Groundspeak's in-house checker didn't rule out the possibility of allowing soft matches (e.g., accepting any coordinates that are within 25ft of the final location waypoint).

[+thebruce0]

1 hour ago, noncentric said:

Problem: Someone viewing that cache in the app won't be able to check their solution, since the Solution Checker doesn't appear in the app.  They won't even SEE that the cache has a checker.

Another temp fix would be to append the necessary HTML to the description (providing it's an HTML description).  However that also assumes that the app renderer can submit forms from the description, since currently forms are not allowed, and are sanitized out of, cache desctiptions.  So maybe that's not a quick temp fix...

On second thought I'll second the fix of showing a text-based notification that there is an associated coordinate checker that will only work if viewing the listing on the website.

 

1 hour ago, Team DEMP said:

Not a challenging situation to overcome. The actual coordinates aren't sent but a hash of those coordinates are. You can determine if the coords match but not the reverse. It's the same approach to how passwords are stored.   

...until someone comes up with an auto-checker once the has method is determined. The hash is sent, now out of gc.com's hands, and a computer with an app can run through a range of coordinates and their hashes to brute force the correct solution in second or minutes. Theoretically.  GS will want to maintain control of the checking mechanism and keep a reign on any format of the solution.

[+Harry Dolphin]

1 hour ago, niraD said:

This works for checkers that use an exact match (whether that match is a set of coordinates or a keyword).

But it would be nice if Groundspeak's in-house checker didn't rule out the possibility of allowing soft matches (e.g., accepting any coordinates that are within 25ft of the final location waypoint).

Yes.  I had a puzzle cache, where, if you could find the puzzle, read:  Due West One Mile.  Getting that exact might be difficult.  Geochecker allowed me 35' of leeway.  

[+dprovan]

2 hours ago, hzoi said:

Disclaimer: I am not a programmer, or even close.  But to work offline, wouldn't the coordinates have to get sent to the phone for all caches made available offline?  Without sufficient encryption or some other safeguard, I wonder how difficult that would be to exploit.

Actually, It would be easy to exploit even with "sufficient encryption". There are only so many possible answers to any puzzle cache, so it's a simple matter of programming using whatever mechanism the app is using to quickly check them all and see which one is right. By handing over the answer, however encrypted, you've lost the ability to control how often and how quickly someone can check an answer against it.

[+arisoft]

5 hours ago, dprovan said:

 

7 hours ago, NYPaddleCacher said:

If there coordinate format is Degrees Decimal Minutes, then the minutes portion should be expressed as a decimal value.  13.000 or 13.0 are both valid and equal decimal values.  Although 13 is equal to 13.000, without the decimal point it is an integer and thus not "Decimal Minutes".

You think that makes sense to the user? It doesn't. That's pure programmer thinking, and, by the way, just the kind of mistake that pops up too often in these new GS user interfaces. The user is entering a number. It's the programmer's job to deal with the distinction between a whole number and a decimal number.

 

This is not a "programmer thinking" at all. It's called mathematics and this thing is taught in elementary school to all students. More information is available here

Edited October 25, 2017 by arisoft

[+Team DEMP]

3 hours ago, thebruce0 said:

4 hours ago, Team DEMP said:

Not a challenging situation to overcome. The actual coordinates aren't sent but a hash of those coordinates are. You can determine if the coords match but not the reverse. It's the same approach to how passwords are stored.   

...until someone comes up with an auto-checker once the has method is determined. The hash is sent, now out of gc.com's hands, and a computer with an app can run through a range of coordinates and their hashes to brute force the correct solution in second or minutes. Theoretically.  GS will want to maintain control of the checking mechanism and keep a reign on any format of the solution.

Eh? Someone is going to write an app to access the Geocaching.com apps database on your smartphone? It doesn't work that way - you can't access another apps DB unless that app grants access. 

Or an official API app developer is going to build into their application a brute force approach?

Are we creating a problem scenario that doesnt exist, like most threads in the forum seem to do?
 

[+dprovan]

8 hours ago, arisoft said:

This is not a "programmer thinking" at all. It's called mathematics and this thing is taught in elementary school to all students. More information is available here

You're being ridiculous. You won't find a single math lesson anywhere that says "3.000" is not equal to "3".

[RuideAlmeida]

4 hours ago, dprovan said:

You're being ridiculous. You won't find a single math lesson anywhere that says "3.000" is not equal to "3".

 

Considering different places and numeral standards, 3.000 is different from 3,000.

3.000 = 3000

3,000 = 3

[+thebruce0]

11 hours ago, Team DEMP said:

15 hours ago, thebruce0 said:

16 hours ago, Team DEMP said:

Not a challenging situation to overcome. The actual coordinates aren't sent but a hash of those coordinates are. You can determine if the coords match but not the reverse. It's the same approach to how passwords are stored.   

...until someone comes up with an auto-checker once the has method is determined. The hash is sent, now out of gc.com's hands, and a computer with an app can run through a range of coordinates and their hashes to brute force the correct solution in second or minutes. Theoretically.  GS will want to maintain control of the checking mechanism and keep a reign on any format of the solution.

Eh? Someone is going to write an app to access the Geocaching.com apps database on your smartphone? It doesn't work that way - you can't access another apps DB unless that app grants access. 

Or an official API app developer is going to build into their application a brute force approach?

Are we creating a problem scenario that doesnt exist, like most threads in the forum seem to do?

We're talking offline use. If a checker works offline, and as suggested GC sends a hash of the coordinates so the offline checker and pass it against an input coordinates (which itself is then hashed for comparison). The idea is that the raw/plaintext coordinates are never visible, they remain unknown. They're 'lost' essentially in the hash. But without the online component that can throttle check requests, all one needs to do is write a script to brute force the hash check through a series of coordinates until there's a match.

And, even if the hash algorithm is proprietary, it's no longer controlled by GC since the offline checker has to employ the code. And if that's true, then it's inevitable that someone will get a hold of it somehow.

In short, if GC gives up 100% native control over the hash/checking algorithm (the ability to throttle and verify correct answers), in this case for offline use, it'll be hacked and there will be sites that provide a "Enter coordinate hash [or GC code so the hash can be retrieved] here:" prompt and likely within minutes provide the final solution.

Edited October 26, 2017 by thebruce0

[+Team DEMP]

3 hours ago, thebruce0 said:

We're talking offline use. If a checker works offline, and as suggested GC sends a hash of the coordinates so the offline checker and pass it against an input coordinates (which itself is then hashed for comparison). The idea is that the raw/plaintext coordinates are never visible, they remain unknown. They're 'lost' essentially in the hash. But without the online component that can throttle check requests, all one needs to do is write a script to brute force the hash check through a series of coordinates until there's a match.

And, even if the hash algorithm is proprietary, it's no longer controlled by GC since the offline checker has to employ the code. And if that's true, then it's inevitable that someone will get a hold of it somehow.

In short, if GC gives up 100% native control over the hash/checking algorithm (the ability to throttle and verify correct answers), in this case for offline use, it'll be hacked and there will be sites that provide a "Enter coordinate hash [or GC code so the hash can be retrieved] here:" prompt and likely within minutes provide the final solution.

Reread my previous responses. WHO is writing this imaginary brute force hacking program you made up? Access would only be available to a ln official API partner - how else would the data be downloaded offline? The official partner will write this hacking program? You made up a problem that wouldn't exist.

[+The Jester]

2 hours ago, Team DEMP said:

Reread my previous responses. WHO is writing this imaginary brute force hacking program you made up? Access would only be available to a ln official API partner - how else would the data be downloaded offline? The official partner will write this hacking program? You made up a problem that wouldn't exist.

I'm not a phone/tablet programmer, but I can think of a couple of ways to do the hack off the top of my head.  Writting an app to replace screen touch input with electonic input seems the easiest.  Or just examine the machine code and pull the routines needed from the app code, write a wrapper app and poof! there's the brute force engine.

 

Edited October 26, 2017 by The Jester

[+Team DEMP]

30 minutes ago, The Jester said:

I'm not a phone/tablet programmer, but I can think of a couple of ways to do the hack off the top of my head.  Writting an app to replace screen touch input with electonic input seems the easiest.  Or just examine the machine code and pull the routines needed from the app code, write a wrapper app and poof! there's the brute force engine.

 

It doesn't work that way. Like I posted, you don't have access to the offline data downloaded by an API partner app from outside the app so there's no underlying access permitted. Never seen an app acess the UI of another app either. 

[+Team DEMP]

I'll let all the doomsday folks keep pontificating about how, without themselves understanding technology, the info could be hacked. Carry on with addressing a problem that wouldn't exist - I'll ignore the thread like I ignore many others where a topic is considered a problem that needs to be solved where no problem even exists.

[+Gill & Tony]

3 hours ago, Team DEMP said:

Reread my previous responses. WHO is writing this imaginary brute force hacking program you made up? Access would only be available to a ln official API partner - how else would the data be downloaded offline? The official partner will write this hacking program? You made up a problem that wouldn't exist.

Access is available to non-API programs.  Think of the app which must not be named.  Who would do it?  The same smart Alecs who already publish puzzle solutions online.

[+on4bam]

Of course it will be hacked, just the way the existing checkers are hacked all the time

 

[+niraD]

I recently configured a Certitude checker for my puzzle cache. While I was at it, I experimented a bit with the new built-in solution checker.

The main advantage of the new built-in solution checker is that it is integrated with the site. To enable it, I just need to select one checkbox while editing my cache. If I edit the waypoint for the final location of my puzzle, then the solution checker is updated automatically. And vice versa.

Like all new systems, there is room for improvement. Here are the features that I would like to see.

• On the cache page, display a LINK to the solution checker, rather than displaying the solution checker itself. You don't need to consume the screen real estate for the checker every time you display the page, and you certainly don't need to load the reCAPTCHA code every time you display the page. Although reCAPTCHA seems like overkill anyway, given the fact that someone is already logged in on the geocaching.com site.
• Allow coordinates to be entered as a single copy-paste text field. This is easier and more reliable than copy-pasting four separate text fields. And for many puzzles (including my own), the main purpose of a solution checker is to confirm that you didn't fat-finger one of the digits while writing down the solution. Splitting up the coordinates into four separate text fields destroys much of the value of the solution checker for puzzles like that. You already do this for the edited coordinates; it shouldn't be hard to do for the solution checker.
• A list of who entered correct the correct solution and when they entered it would be nice. So would a list of incorrect solutions, so you can see if there is any pattern to the mistakes people are making when solving your puzzle, or to see if someone might be battleshipping your puzzle. But you should probably make all incorrect solutions anonymous, and allow the option for correct solutions to be anonymous too.
• Other solution formats would be nice, specifically: keyword solutions (with the coordinates provided when the correct keyword is entered) and fuzzy coordinates (e.g., with any coordinates within 25ft/7.5m of the official solution being accepted). And multiple solutions per puzzle cache would be nice for multi-stage puzzle caches.
• It would be nice to be able to provide bonus information to those who enter the correct solution. For example, I use the rot13 hints on the cache page as puzzle hints, and I provide the hints for the hide in the bonus information given to those who enter the correct solution.

Thanks for adding this feature. I look forward to seeing it mature in the future.

[+barefootjeff]

1 hour ago, Gill & Tony said:

5 hours ago, Team DEMP said:

Reread my previous responses. WHO is writing this imaginary brute force hacking program you made up? Access would only be available to a ln official API partner - how else would the data be downloaded offline? The official partner will write this hacking program? You made up a problem that wouldn't exist.

Access is available to non-API programs.  Think of the app which must not be named.  Who would do it?  The same smart Alecs who already publish puzzle solutions online.

The app that shan't be named doesn't access the API, it scrapes the website pretending to be someone using a browser. It, or anything else like it, wouldn't have access to hashed final coordinates sent via the API to official apps for off-line checking.

[+The A-Team]

32 minutes ago, niraD said:

Here are the features that I would like to see.

<snip>

The only item I would add to niraD's wishlist would be the ability to turn off the automatic updating of the corrected coordinates (including making it sticky). I solved a puzzle that used the new checker this past weekend, and the first thing I found I had to do was edit and remove the corrected coordinates that had been helpfully added for me.

FWIW, the reasons why I don't use the website's corrected coordinates feature include:

• I store my corrected coordinates offline in GSAK. When the corrected coordinates are also set on the website, odd things happen.
• When corrected coordinates are set on the website, the cache type icon is replaced by a generic puzzle icon on the map. I prefer to see the cache's type on the map. "Has corrected coordinates" is an additional attribute on top of the cache type and should be displayed in addition to the cache type, not in place of it. The cache type of an unfound cache is very important and should always be visible.

Edited October 26, 2017 by The A-Team
Speeling

[+Gill & Tony]

11 minutes ago, barefootjeff said:

The app that shan't be named doesn't access the API, it scrapes the website pretending to be someone using a browser. It, or anything else like it, wouldn't have access to hashed final coordinates sent via the API to official apps for off-line checking.

That's correct.  I was wrong.  The API would be necessary.

However, if the hash is passed through the API any GSAK user can download a shed-load of puzzles, get the hashes and write a macro to brute-force the answers.

 

[+barefootjeff]

50 minutes ago, Gill & Tony said:

That's correct.  I was wrong.  The API would be necessary.

However, if the hash is passed through the API any GSAK user can download a shed-load of puzzles, get the hashes and write a macro to brute-force the answers.

 

I'm sure it'd be possible to add an additional encrypted element to the API that wasn't accessible through GSAK but which could be read by the official app and any parter apps that sign the appropriate NDA.

[+Gill & Tony]

5 hours ago, barefootjeff said:

I'm sure it'd be possible to add an additional encrypted element to the API that wasn't accessible through GSAK but which could be read by the official app and any parter apps that sign the appropriate NDA.

I'm not sure,  but I don't think that the other checkers actually work offline.  You are probably right that they could put the effort into providing an encrypted section of the API , but if I were in their shoes, it would be a long way down the road.

[+niraD]

57 minutes ago, Gill & Tony said:

I'm not sure,  but I don't think that the other checkers actually work offline.  You are probably right that they could put the effort into providing an encrypted section of the API , but if I were in their shoes, it would be a long way down the road.

There are a number of other features that would be much easier to implement (and IMHO, much more useful) than a secure offline coordinates checker.

[+Pontiac_CZ]

NiraD: the Certified Solvers list is a nice feature of the Certitude. I guess that would involve changing the database structure (adding a table for storing successful solvers who opted for being recorded) so if Groundspeak ever decides to adopt this idea it will be among the last ones.

As for the bonus information, I thought it might be sufficient to put this to the final waypoint description and those who enter the correct coordinates would be provided its content. That way GS would not need to touch the database.

 

Edited October 27, 2017 by Pontiac_CZ
grammar

[+arisoft]

1 hour ago, Pontiac_CZ said:

NiraD: the Certified Solvers list is a nice feature of the Certitude. I guess that would involve changing a database structure (adding a table for storing successful solvers who opted for being recorded) so if Groundspeak ever decides to adopt this idea it will be among the last ones.

I followed closely a case where CO tried first time this new checker. After he noticed that there is no statistics available, he immediatelly switched over to ordinary geochecker.

As premium mebers can see who opened the cache page it would be logical addition to add similar detailed checker statistics available to CO, without opt out.

Edited October 27, 2017 by arisoft

[+The Jester]

12 hours ago, Team DEMP said:

It doesn't work that way. Like I posted, you don't have access to the offline data downloaded by an API partner app from outside the app so there's no underlying access permitted. Never seen an app acess the UI of another app either. 

I'm glad you are so confident that data downloaded to a device can never be hacked by anyone not using an API app.  And you don't have to use another app to access the UI if you hack the orginal app to change the UI access.  Now, is it worth the time to do something like this for a game?  Personally, I don't think so, but there are others who 'play' with apps for fun.

[+NYPaddleCacher]

15 hours ago, Team DEMP said:

15 hours ago, The Jester said:

I'm not a phone/tablet programmer, but I can think of a couple of ways to do the hack off the top of my head.  Writting an app to replace screen touch input with electonic input seems the easiest.  Or just examine the machine code and pull the routines needed from the app code, write a wrapper app and poof! there's the brute force engine.

 

It doesn't work that way. Like I posted, you don't have access to the offline data downloaded by an API partner app from outside the app so there's no underlying access permitted. Never seen an app acess the UI of another app either. 

Depends on what you man by access the UI.  I have written applications that "script" the submission of a form quite a few times.  It basically replaces the use of a form rendered in a browser with code which creates values for all the fields in the form and then makes a request to the form handler code on a server directly.  It would probably take me about an hour to write an application which iterated over a range of coordinates, submitting to the form handler and checking the result for "success".   The limit of 10 attempts in a day not prevents someone from using the UI to brute force the coordinate checker but also prevents applications which can run a lot faster from trying every possible solution until it got a "success".