The A-Team

The main issues I have with the new dashboard are: Unnecessary whitespace Poorly-prioritized navigation options Poor performance (takes a while for changes to appear on the dashboard, at least the last time I checked) Lack of cache type icons If this project got reopened to deal with these issues, then I might actually start using the new dashboard.

If this is the case, then I would expect to see a banner on every page warning of this. That's what was done when support for earlier versions of IE was dropped, and it's the most efficient way of notifying a user that their browser isn't supported by the site anymore. Silently dropping support for a browser that is still supported by its manufacturer just leads to confusion, as evidenced by the many reports here in the forums (and likely to HQ Support too). Don't get me wrong. IE has always been a dog's breakfast* as far as web standards go, so I don't have a problem with a site dropping support for it in order to make development easier. I'd expect them to let a user know that they've done this, though, especially since the browser is still officially supported by its manufacturer and users would rightfully expect it to still be supported by the site unless told otherwise. *No offense to those reviewers for whom this is their standard meal

Actually, I don't think it rewrites the images. In one of my own puzzles, I use a special JPG, which has additional data after its JPEG end marker. I just checked, and the puzzle still works. I.e., I can right-click on the image in the listing and download it, and the result is bit-wise identical to the original file on my webspace. I have another puzzle, where the image link is actually a PHP script, which serves different images depending on the server date&time, and this also still works (which actually suprised me). Yes to expand on one comment I posted elsewhere, I recognized that some standard data is still retained, such as EXIF data. All we know is that what the proxy is sending through is not merely a redirection of the raw image data. For whatever reason the server is most likely opening and reading the source image file - not merely stripping cookies for the http request - and most likely if the server is having any problem understanding the file as an image (by its own understanding of a "valid" image), it's returning simply "Not found". That's what's getting broken. Interesting. So if it works, it works completely, in that the image you get is exactly what you expect. However, sometimes it just doesn't work at all. There doesn't seem to be any grey area in between (e.g. you get an image, but some expected content is damaged/missing). Hopefully there are some devs looking at all of the "Not found" reports and figuring out what isn't working.

We were told to expect a new souvenir last week (the 3rd Wednesday of the month), but that didn't happen. Instead, we got it on the 4th Wednesday. It's nice to see souvenirs for some of the less-visited regions. Being more rare, they're arguably "worth" more.

Yes, as thebruce0 hypothesized in the other release notes discussion, it seems like the proxy is doing more than just stripping the cookies and passing the data-stream through. Instead, it seems to be re-writing the images in some way that's breaking things. Some examples of where this could cause issues is when the image content format is different than the file in which it's wrapped, data is hidden inside the metadata or structure of the data, or various methods of steganography.

The organic or "do nothing" option was the route taken when Photobucket changed their terms and lots of puzzle images stopped working. While that change was outside of HQ's control, it would have been easy for them to identify listings with Photobucket images and notify the COs that they had a broken image.

Good point. That option was there, but I used "Save and preview" because I wanted to double-check that the listing looked right and didn't think to go back in there to submit. If the confusing process doesn't change, I'll have to keep this workaround in mind.

When can we expect this notification to be sent out to cache owners? You are planning to let COs know that their listing might be broken, right? The vast majority of COs don't follow the Release Notes section of the forums, so they wouldn't know about this important change. At the very least, you need to notify the COs of listings where a proxied image is broken. It should be trivial for you to check the output of the proxy server and watch for 0-length or non-existent files so you can let the respective COs know that their listing has been broken by this change. That won't help much if the change has broken the fundamental concept used for a puzzle, but at least the CO would know that they need to archive their cache.

I recently submitted a listing for review, but it wasn't able to be published because another hider had beat me to the area and their cache was published. I just moved the container to a new spot, updated the listing, and was then confused about how to submit the listing again. The only options I had available were "Edit cache" and "Respond", the latter of which allowed me to write a Reviewer Note. There wasn't any sign of a way to submit/enable the listing. I figured I'd just write the Reviewer Note with the updated hide details and then send a message to the reviewer letting them know that I had made changes. After submitting the Reviewer Note through the "Respond" button, I now get a "Resubmit for review" option. Clicking this pops up the same box as when you initially submit, prompting for details of the hide through a Reviewer Note. The requirement to post two Reviewer Notes in succession is redundant. This process was confusing. At the point that I had the listing ready to resubmit, I wasn't given an option to do so, and I was forced to provide the hide information twice due to the unnecessary second Reviewer Note. I think one of the following needs to be done: Offer "Resubmit for review" right away, rather than "Respond". This makes the process more clear and avoids one of the two Reviewer Notes. If you want the owner to respond first, then provide an explanation that you need to respond first before you'll be given the chance to resubmit. In this case, the final Reviewer Note should be bypassed because it would be redundant. Offer both "Respond" and "Resubmit for review" right away. That way further correspondence can occur via "Respond", or a ready-to-submit listing can be submitted via "Resubmit for review". In this case, the final Reviewer Note can remain and be used to describe the updated hide.

Yep, the proxy is in place again. @nykkole@Geocaching HQ: This is a significant change that can break a lot of cache listings (while trying to confirm that the proxy is in place, the first listing I checked had a broken puzzle image). You need to give COs notice that such a change is being made, what its implications are, and what they can do to fix their listings.

What would that ultimately accomplish, though? My understanding is that sandboxing inside an iframe just prevents you from modifying other parts of the page. As far as I can tell, that isn't what TPTB are trying to do, but rather are trying to block cookies through the use of a proxy.

This is largely due to the development methodology they've chosen to use, but not fully implement. As I understand it, they're using the Agile methodology. I'm not a developer, but my understanding is that under this methodology you roll out something as quickly as you can to the users, and then you iteratively refine the product to add functionality, account for user requests, fix bugs, etc. This explains why the product we're initially given often seems to be missing a lot of features. They do seem to go through a few iterations, but then development just stops long before the project is actually completed and we're left with these partially-completed features. Why this is happening, we don't know. Is it project managers that don't understand the methodology? Is it higher-ups changing priorities? Is it a lack of resources? Does HQ sincerely consider these projects completed?

Hey @Geocaching HQ, this past Wednesday was the third Wednesday of January, so we were expecting a new regional souvenir. Has that been delayed? I haven't seen any sign of a new souvenir.

That sounds like the same problem that's happening in a number of spots on the site. It seems to only happen if you're using Internet Explorer or Edge as your browser. If you have another browser you can use like Firefox or Chrome, it should work as expected in those.

No longer supported by Geocaching.com, or no longer supported by Microsoft? Because it definitely is supported by Microsoft, and will be for quite a while yet (source): To paraphrase the above, as long as you're running a supported version of Windows, then IE11 is officially supported by Microsoft. (This post was written using IE11 running with the January 14, 2020 cumulative security update for Internet Explorer)

Yes, there are a number of links across the site that won't work correctly if the username contains special characters. This has been an ongoing issue for a couple of years.

What browser are you using? I was able to replicate this issue with Internet Explorer 11, but it works as expected in Firefox, Chrome and Edge (old one, not Edgium).

@HQ: Just a friendly reminder that production isn't where you test things. That's what you use the dev and test environments for.

Presumably to block any cookies. By proxying the images, any cookies are blocked at the proxy server and won't reach the client.

Make sure to pass this back to the ill-informed cacher in question so they don't go bogus-logging caches all over the world.

Thanks for the explanation. While I don't personally subscribe to the current paranoia/fad surrounding cookies, some people do - including legislators - so I guess we have to live with that. It's a shame, though, because this eliminates a number of vectors for puzzle caches.

They moved their image storage to AWS S3 many years ago. Somewhere around 6 years ago, give or take a year or two.

The hypothetical situation you posed at the end of your post is exactly why involuntary adoption doesn't happen. That situation happened in reality many years ago, and that led directly to involuntary adoptions being stopped. It all comes down to ownership. Geocaching.com is just a listing site where owners of geocaches can list them. It's explicitly laid out in the Terms of Use that the cache remains the property of the owner. Geocaching.com simply does not have the legal authority to transfer property from one person to another.

Maybe I missed it in all of these posts, but are you saying that there are reviewers actually doing these? If so, I would consider that over-reach.

Thanks for the explanation. This is exactly what I was looking for, and frankly what HQ should have proactively provided to all members before making the changes. I wasn't aware that there was ongoing confusion surrounding the terms "sharing" and "selling", so that does help explain what happened. I understand that the Privacy Policy explains this (albeit far less concisely, and without the background surrounding the terms), but "we've made changes to the Privacy Policy, go read it" isn't a reasonable way of introducing changes. Members should be advised which changes are being made and for what reasons. I'm sure Legal will say "just tell them to read the policy and you're covered", but a diligent and caring company will explain what changes are being made and how they'll affect you. Anyway, I hope common sense prevails and "sharing" is defined as not being the same as "selling" (which, IMO, it clearly isn't). Considering that it sounds like many other states may follow what California does, let's hope that they get this sorted out quickly.