Release Notes (Website: Reverse Image proxy) - January 24, 2020

January 24, 2020

Release Notes (Website: Reverse Image proxy) - January 24, 2020

A recent change to the way images not hosted on our site are rendered is causing some unexpected issues. We apologize for any inconvenience.

We have updated the way third-party images are processed before displaying them on the website. Allowing images to be inserted via an external URL can result (intentionally or not) in third-party cookies on the computers of those who view pages with these images on them. With this recent release, any third-party cookies attached to those images are removed before the images are displayed on the website.

This release increases performance on pages that formerly contained these third-party cookies. It also supports security for users.

We are aware this release may break some images that are entirely dependent upon third-party cookies. In these cases, we encourage geocachers to upload images directly to their cache pages and to use the image URL hosted on geocaching.com to ensure no third-party cookies are attached to images. Please visit the Help Center for more detailed instructions on how to add images to your cache page.

Erin (Oceansazul) is watching this thread to answer questions whenever possible.

Any posts in this thread should relate to features in this release. Comments unrelated to the release may be removed. Please direct unrelated comments to other appropriate threads. Thanks!

2.7k · January 24, 2020

Thank you for protecting us from potential unknown cookie contamination.

9.2k · January 24, 2020

1 hour ago, Geocaching HQ said:

This release increases performance on pages that formerly contained these third-party cookies. It also supports security for users.

We are aware this release may break some images that are entirely dependent upon third-party cookies.

"may break some images that are entirely dependent upon third-party cookies"

However it doesn't appear to be only stripping cookies from the image requests. Reportedly normal images are also breaking, which aren't entirely dependent upon third-party cookies and which previously displayed without issue in every browser (assuming so, as this change prompted alerts that their images on active geocache listings were now broken)

"also supports security for users" - can you expand on this? This implies there is more going on than merely stripping cookies, and to many these are important pieces of information to know - whether for innocuous puzzles, or even technical reasons (especially if otherwise 'normal' images are breaking)

To note: This change isn't merely about stripping cookies, it's also effectively informing the community that who knows how many puzzle caches out there using certain strategies are now not possible (and it's up to each user to check their own puzzles and change or archive them). That's a pretty far-reaching effect... =/

Edited January 24, 2020 by thebruce0

January 24, 2020

Seattle calling (again) - Why are you breaking normally functioning cache pages without proper testing in test, acceptance and then finally production environment.

Since this release is not announced in a proper newsletter to the general geocaching community you will be bound to get a lot of flack.

January 24, 2020

Some advance notice would have been good. I've now got to check all the puzzles (again, after last week), and I see one already no longer works (and I'll have to see if I can find the original as I see in the source code that the link to the original picture has been changed)

7.8k · January 24, 2020

2 hours ago, Geocaching HQ said:

We are aware this release may break some images that are entirely dependent upon third-party cookies. In these cases, we encourage geocachers to upload images directly to their cache pages and to use the image URL hosted on geocaching.com to ensure no third-party cookies are attached to images. Please visit the Help Center for more detailed instructions on how to add images to your cache page.

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.

9.2k · January 24, 2020

I've attempted to do my part. :unsure:

January 24, 2020

I wonder how on Earth this change could ever be approved in the first time at HQ, as It was easily foreseeable that this would break many mysteries, e.g. those that rely on returning on-the-fly an image, maybe depending on the client's request...
Some of our puzzles are broken, some by fellow geocachers, some we have solved in the past...
Groundspeak please:
- roll back this unfortunate change ("We have rolled this update back"; no, it's still on)
- refrain in the future to change a service we are paying for without prior notice.
Thanks.

9.2k · January 24, 2020

Or at least provide a public newsletter announcement that due to regulations and changes in the way descriptions are handled, if you're an owner with a puzzle cache relying on images being hosted by a 3rd party website, such puzzles may no longer be technically functional.

And be ready for a wave of archivals from cache owners who won't be "fixing" their puzzles.

...that or let all the cache owners discover their broken images organically, and see if the community response is less ...critical

1.5k · January 24, 2020

On a local FB group, listing GC4TCFH was mentioned as "broken". According to the owner, there is nothing "special" about the images except that they are hosted on their own webspace. If you extract the original URL from the proxy URL, they display just fine in the browser. But in the GC listing itself, all images are broken.

So there is definitely a severe problem here. The change didn't break "only" some puzzles, but apparently also some plain vanilla image links.

7.8k · January 24, 2020

2 minutes ago, thebruce0 said:

...that or let all the cache owners discover their broken images organically, and see if the community response is less ...critical

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.

7.8k · January 24, 2020

1 minute ago, baer2006 said:

On a local FB group, listing GC4TCFH was mentioned as "broken". According to the owner, there is nothing "special" about the images except that they are hosted on their own webspace. If you extract the original URL from the proxy URL, they display just fine in the browser. But in the GC listing itself, all images are broken.

So there is definitely a severe problem here. The change didn't break "only" some puzzles, but apparently also some plain vanilla image links.

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.

1.5k · January 24, 2020

2 minutes ago, The A-Team said:

Instead, it seems to be re-writing the images in some way that's breaking things.

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).

9.2k · January 24, 2020

4 minutes ago, baer2006 said:

10 minutes ago, The A-Team said:

Instead, it seems to be re-writing the images in some way that's breaking things.

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.

And not knowing how or what the proxy server is using to "sanitize" what it assumes are "valid" images, we have no recourse, except to disable and potential archive caches with broken images, if uploading directly doesn't (or can't) fix the problem.

1.5k · January 24, 2020

3 minutes ago, thebruce0 said:

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.

Could be. But something else might be broken, too.

I downloaded two of the original images from the cache example I gave, and analyzed the files in a hex editor. They look like perfectly normal JPG files.

9.2k · January 24, 2020

Yup

7.8k · January 24, 2020

56 minutes ago, thebruce0 said:

1 hour ago, baer2006 said:

1 hour ago, The A-Team said:

Instead, it seems to be re-writing the images in some way that's breaking things.

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.

January 25, 2020

https://coord.info/GC88YN2 broken link

https://coord.info/GC8AF9M broken link

https://coord.info/GC86MMG broken link

https://coord.info/GC856NG broken link

...

January 25, 2020

I also use steganography myself, both with images and with sound clips.

I always try to host my files at Geocaching.com (= Amazon Web Services). Only in the cases that I use EXIF info or non image files I am forced to host the files elsewhere (hosting at my ISP).

One of my puzzles uses images with EXIF info. Alle the images have the exact name with a suffix number (1..8). The info in the EXIF and the number in the filename are necessary to go to the next step of the puzzel. With the introduction of the proxy the filename is broken. It still is there in the URL of the proxy, but when downloading the file it is gone. The EXIF info is still available. I solved the problem with the filename by also adding this in the EXIF info. I also could visually add a number on the image.

So far this puzzle can be solved again. However, when I look in the Android Geocaching.com app, these images are not displayed, they show broken. In the Apple Geocaching.com app, the images are shown correctly. To identify the problem I also viewed a friend's cache (with an image not hosted on Geocaching.com) via the Android Geocaching.com app. The image in his listing is shown correctly. I Know there are issues visualizing images in the Android Geoaching.com app. I posted a remark in the Android App specific bug reporting forum.

thebruce0's assumption that images get broken because the proxy's processing can't validate the file structure is a plausible thinking track for some cases. I think it could occur when people are editing the image file structure (writing data in the file structure instead of e.g. the EXIF) or when you use a file with an invalid file structure. The images in my case were not structural edited, I just added the EXIF. As far as I know the image I use have a valid file structure. At least they show up correctly in the web interface.

At this moment I don't Know what I do wrong or what goes wrong. I hope that clarity will come soon.

Fortunately I only have 1 partially affected cache, but there are cache owners with more affected caches.

I understand that Geocaching.com strips EXIF info by default. Still, it would be handy if we could upload images and keep certain EXIF info or add it afterwards (by stating it explicitly). That doesn't fix all the issues caused by the introduction of the proxy but it one of the many possible steps to fix them all.

January 25, 2020

Same problem here:

I have 2 caches where I embed images which are generated dynamically on my server:

https://www.geocaching.com/geocache/GC5DC9R_ja-wo-isse-denn

The code on the description page says

<img src="https://www.xctrails.org:9443" />

this gets rewritten now as

<img src="https://imgproxy.geocaching.com/ab78f50389ad69e6dd6dc249b5e493abd07368f9?url=https%3A%2F%2Fwww.xctrails.org%3A9443">

and doesn't work anymore. My endpoint on xctrails.org only generates a PNG, no cookies etc. This worked flawlessly for years and is now obviously broken with the imgproxy rewrite.

Same on https://www.geocaching.com/geocache/GC6B56W_in-7-tagen-um-die-welt

Do you intend to fix this and when (I'll eventually get asked by the reviewers when I can activate those caches again) or will this remain as is?

9.2k · January 25, 2020

9 hours ago, arminus said:
The code on the description page says
<img src="https://www.xctrails.org:9443" />

I might suggest, as a web developer, to add a filename to the url. In this case, browsers can indeed still display an image given that url, but they have to make assumptions, since technically the img tag is intended to identify an image file. In good syntax, the url would be better written something like src="https://www.xctrails.org:9443/image.png" (given you say it write PNG data) with the content-type response header as image/png. Presumably, the proxy is being very strict about proper syntax, and likely think the url is untrustworthy since the file type isn't provided by URL - and since a 'hack' may theoretically employ telling the browser a different file type than the data which is actually sent, it's kind of like a spam-score. If the file extension doesn't match the data type, then it could be considered potentially malicious.

So while I'm not saying it's all on you, it is something to keep in mind - if you're sending a PNG image, then provide a URL with the PNG extension so browsers can have a better sense that they should expect a PNG file, ensure the content-type of the http response matches the file type, and the data received is PNG data matching all of the above.

It's possible that if any of those items don't match, the proxy will not serve a valid copy of the image.

An argument could be made either way - the proxy is way to strict, or the proxy is maintaining good security against potential malicious content which browsers otherwise let slip through. (But IMO the proxy is being WAY to strict =P)

January 26, 2020

So, I guess I'll just thank HQ for throwing a bunch of COs under the bus. Besides my own 250 plus effected caches, I am a key member of a crew for a very popular GeoTour with 100 caches, every one of which links multiple images from Google Drive, all of which no longer work. Several historical mages we use belonging to others. We link them from their site, with their permission. We do not have the right to copy their photos to the geocaching site. I would like someone to offer more help than some gibberish about cookies. Please, HQ, please throw us a bone.

Explain to me what is wrong with this: <img width="650" height title="Michigan State Parks Centennial GeoTour:" src="https://drive.google.com/uc?export=&confirm=no_antivirus&id=1Raa4DiQz9wpAcKoliBBz3lT4irLOlsx-" style="border:7px ridge #AAAAAA;" /> Based on what I have read above, it doesn't have a file extension that identifies it as an image. Come on. imgproxy has to be able to tell the difference between an image and something that might have a cookie attached. Google doesn't give me the option of linking a file using its actual name. I think Google is trying to protect file owners by using its own hashing scheme.

If you tell me I have to rehost the photos and edit the links of 350 plus cache pages, thank you so much for ruining my winter. At least tell me HOW to fix them. We don't have a clue so far.

Edited January 26, 2020 by aghudley
fix a typo and add some content

January 26, 2020

This image proxy server has caused at least 23 mystery caches of mine getting unexpected outcomes since this week. As the result, all those puzzles have become unsolvable.

I contacted HQ and the only suggestion I received is "using 'Add image' in Edit page to upload all images to geocaching gallery". Thanks a lot! Why hadn't I thought of such wonderful idea earlier!

I believe it's no point to contact HQ again. I'm now working on my puzzles to make them solvable again.

Edited January 26, 2020 by uqam

January 26, 2020

10 hours ago, thebruce0 said:

I might suggest, as a web developer, to add a filename to the url. In this case, browsers can indeed still display an image given that url, but they have to make assumptions, since technically the img tag is intended to identify an image file. In good syntax, the url would be better written something like src="https://www.xctrails.org:9443/image.png" (given you say it write PNG data) with the content-type response header as image/png. Presumably, the proxy is being very strict about proper syntax, and likely think the url is untrustworthy since the file type isn't provided by URL - and since a 'hack' may theoretically employ telling the browser a different file type than the data which is actually sent, it's kind of like a spam-score. If the file extension doesn't match the data type, then it could be considered potentially malicious.

So while I'm not saying it's all on you, it is something to keep in mind - if you're sending a PNG image, then provide a URL with the PNG extension so browsers can have a better sense that they should expect a PNG file, ensure the content-type of the http response matches the file type, and the data received is PNG data matching all of the above.

It's possible that if any of those items don't match, the proxy will not serve a valid copy of the image.

An argument could be made either way - the proxy is way to strict, or the proxy is maintaining good security against potential malicious content which browsers otherwise let slip through. (But IMO the proxy is being WAY to strict =P)

Actually, I was beginning to think along the same lines after I've posted this yesterday. And lo and behold, adding an "image/png" content type header, "Content-Disposition", "inline; filename=\"image.png\"" for good measure, and accepting a URL like you suggested to my servlet-mapping's url-pattern solves the issue.

While the omission of the content type header was actually lazy on my part (it did work though for years), I think the need to have a request URL which matches .png/.jpg/... is in fact way too strict. Apparently, setting the Content-Disposition header only isn't enough.

And there's another change (probably unrelated to the proxy): Saving an img URL like the following

<img src="https://www.xctrails.org:9443/image.png?gcid=GC6B56W&stats=true" />

replaces it with

<img src="https://www.xctrails.org:9443/image.png?gcid=GC6B56W&amp;stats=true" />

This didn't happen the last time I saved that cache page and basically implies that you can't use more than one parameter for an image request anymore either. I can hack around that, but just FYI for anyone reading this.

Edited January 26, 2020 by arminus

3.1k · January 26, 2020

I would like to know the policy concerning extra cache maintenance required by these unsolicited changes. Who is the responsible party to fix broken listings?

Edited January 26, 2020 by arisoft

3.1k · January 26, 2020

On 1/24/2020 at 11:10 PM, The A-Team said:

at least the CO would know that they need to archive their cache

Archiving is not my primary solution. I am going to link broken cache pages to another listing service if required. I already have at least one listing that is served externally.

1.5k · January 26, 2020

2 hours ago, arminus said:

While the omission of the content type header was actually lazy on my part (it did work though for years), I think the need to have a request URL which matches .png/.jpg/... is in fact way too strict. Apparently, setting the Content-Disposition header only isn't enough.

An URL ending in .jpg/.png/etc. is apparently not necessary. In my cache, which links to a dynamically generated image (GC6V7BJ), the link goes to a folder on the server. i.e. there is no file extension at all. Per the configuration of the server, the file "index.php" in that folder is referred, and this in turn has code to select the image for download. The PHP code is as simple as it can get - it sets "Content-Type:image-jpeg" as header, and outputs the image with PHP's imagejpeg() function. No "Content-Disposition" header is defined.

Also, there are listings with broken images, which actually have URLs with standard extensions.

January 26, 2020

40 minutes ago, baer2006 said:

An URL ending in .jpg/.png/etc. is apparently not necessary.

For me it is. As soon as I omit the image.png part in the img src url, I get the 404 again, just double-checked that to be sure.

I have an Apache proxy in front of my Tomcat, maybe that's the reason (I remember some settings for Apache to pass headers or not, etc.) At any rate, I have a working solution, just reporting what works for me and what doesn't ;-)

January 26, 2020

14 hours ago, thebruce0 said:

I might suggest, as a web developer, to add a filename to the url. In this case, browsers can indeed still display an image given that url, but they have to make assumptions, since technically the img tag is intended to identify an image file. In good syntax, the url would be better written something like src="https://www.xctrails.org:9443/image.png" (given you say it write PNG data) with the content-type response header as image/png.

I don't have the option of adding a filename.type when posting photos hosted in Google Drive. My links look like this (I copied it just as it is in the page, without removing formatting stuff):

<img width="650" height title="Michigan State Parks Centennial GeoTour:" src="https://drive.google.com/uc?export=&confirm=no_antivirus&id=1Raa4DiQz9wpAcKoliBBz3lT4irLOlsx-" style="border:7px ridge #AAAAAA;" />

There is a lot of talk about content-type and content-disposition. For us lay-people, how do we use that. Searches I've done this morning lead to something far too detailed to know what to do with it.

Is there anything I can do to repair this short of rehosting every image (probably a couple thousand)? In many cases, rehosting is not possible. Would someone at HQ please offer some technical help other than "rehost your photos to the geocaching page"?

January 26, 2020

Just to let you know:
The listing mentioned above (GC4TCFH ) is now working again.
So perhaps the Proxy just needed some time to "proxy-out" some things.
I hope this remains fixed!

January 26, 2020

Just for the record, I noticed that the proxy removes other HTTP headers. For example, I know of a mystery cache which final coordinates are given by looking at the HTTP headers sent with an image (this is a custom header named X-Geocache or something like this). It can't break anything. There is absolutely no security risk with such a header (i.e. those beginning with "X-"). But the proxy removes it.

Edited January 27, 2020 by Tungstène
Typo & clarification

January 27, 2020

So with all this nonsense by HQ, I will archive my new puzzle cache which was relying on externally hosted pictures (some with EXIF) before it was even published.

Thanks for hours spent in vain. I might just throw out a bunch of trads to guardposts, it doesn't seem to be about quality at all...

9.2k · January 27, 2020

It seems tough to tell if the file extension alone will break the image or not. As noted, many prominent websites will embed image URLs that are dynamically generated without including a 'proper' image extension that matches the content and headers (most commonly in formats like loadimage.php?additional-parameters&querystring ). That leads me to believe it could still be a spam-score style system, where the ones that work haven't scored below a 'spam' threshold without the extension, and are still served, while other are close enough that removing the extension causes it to be blocked. Who knows. There's no indication from HQ about what is and isn't allowed as an image other than simply stripping cookies and security for users. :wacko: :blink:

I'm assuming from silence on these broken reports so far that someone or a team at HQ are digging into this and don't want to speak to soon. The alternative is the reports are being ignored (which I don't (want to) believe is true), or they're unheard (which is hard to believe as there have been lackey posts since this began). But as before, I'd hope that they'd either roll back the update if it is a problem they are working on, or are working up an official statement explaining what will no longer be permitted in geocache listing descriptions

...even though it only breaks on the website pages, not via API or external apps which still retrieve the raw description, afaik. =/

7.5k · January 28, 2020

On 1/27/2020 at 6:35 AM, thebruce0 said:

I'm assuming from silence on these broken reports so far that someone or a team at HQ are digging into this and don't want to speak to soon.

I'd like to believe that, but normally when that happens, someone posts here some kind of "we're looking at it" message. This seems more like what they do when they've done a change that they knew would be unpopular and are keeping their heads down because they know that's the easiest way for the issue to blow over when they've already made up their minds. This one, in particular, looks like it's being driven entirely on legal issues, so its popularity isn't a relevant consideration.

9.2k · January 28, 2020

Yet in that case one might expect some kind of explanatory or consoling announcement of the necessary change. Not silence and letting the chaos sort itself out over time... not very good practice to just "wait out" bad PR. =/

7.5k · January 28, 2020

3 hours ago, thebruce0 said:

Yet in that case one might expect some kind of explanatory or consoling announcement of the necessary change. Not silence and letting the chaos sort itself out over time... not very good practice to just "wait out" bad PR. =/

Well, I'd agree with you, but I don't have 20 years of experience rolling out changes to people that some might view as perpetual whiners. OK, OK, I put that in the worst possible way for all sides, but I think GS has seriously embraced the idea that they can never win, so they might as well just do what they think is right and move on without second guessing themselves. I don't like it, and I wish they didn't act that way, but I'm not really in a position to judge them. I think there are a few cases now where GS did it one way, got a lot of flak so changed it to the other way, and got just as much flak for that, so I can't blame them for deciding not to react anymore.

7.8k · January 28, 2020

26 minutes ago, dprovan said:

Well, I'd agree with you, but I don't have 20 years of experience rolling out changes to people that some might view as perpetual whiners. OK, OK, I put that in the worst possible way for all sides, but I think GS has seriously embraced the idea that they can never win, so they might as well just do what they think is right and move on without second guessing themselves. I don't like it, and I wish they didn't act that way, but I'm not really in a position to judge them. I think there are a few cases now where GS did it one way, got a lot of flak so changed it to the other way, and got just as much flak for that, so I can't blame them for deciding not to react anymore.

That's understandable for design decisions. As you said, you can never please everyone.

However, if something is broken, the expectations are different. Really, there's only one expectation: the broken thing gets fixed. This is a Boolean decision: it gets fixed (to some degree), or it doesn't get fixed.

If TPTB are looking into the issue, then it would be great if they could tell us that. I know they don't like saying things like that and making a commitment that they might not be able to meet, but the expectation from the users is already there anyway, so it won't hurt anything to actually tell us that it's being worked on. Being transparent and communicative is an excellent way to build a good relationship with your users.

On the other hand, if they've decided that the proxy is working well enough for their purposes and they won't be looking into the cases where it isn't, then we definitely need to know so affected owners can make the necessary changes to their listings or archive them.

As always, there's the "do nothing" option that seems popular, but the consequences of taking this option need to be taken into account (loss of trust from the users, confusion leading to a higher number of support requests, users making and spreading incorrect assumptions, etc.).

3.1k · January 29, 2020

1 hour ago, The A-Team said:

As always, there's the "do nothing" option that seems popular, but the consequences of taking this option need to be taken into account (loss of trust from the users, confusion leading to a higher number of support requests, users making and spreading incorrect assumptions, etc.).

I am going to do nothing until some authority tells me what I am supposed to do. Maybe the proxy will be limited to US citizens only in future to save money?

7.5k · January 29, 2020

1 hour ago, The A-Team said:

However, if something is broken, the expectations are different. Really, there's only one expectation: the broken thing gets fixed. This is a Boolean decision: it gets fixed (to some degree), or it doesn't get fixed.

It's not broken, it just doesn't do what it used to do. They withdrew an existing feature because it harbored a security hazard. Feel free to argue about whether the threat justifies withdrawing the feature. You don't like it, but that doesn't make it a bug.

2 hours ago, The A-Team said:

If TPTB are looking into the issue, then it would be great if they could tell us that. I know they don't like saying things like that and making a commitment that they might not be able to meet, but the expectation from the users is already there anyway, so it won't hurt anything to actually tell us that it's being worked on. Being transparent and communicative is an excellent way to build a good relationship with your users.

I agree with what you're saying and, again, I wish that was the way they saw it. But, having said that, I'm imagining that if they felt like they could respond to your criticism, what they'd say is that they tried being transparent in situations like this, and it just increased the amount of grief they had to contend with. It strikes me that now all they have to ignore are complaints about the lost feature. If they explained themselves, then they'd have to also face complaints about the reasons for their decision, which wouldn't be any more productive but would increase the volume by at least a factor of two. Furthermore, if they're quiet now, at least they can say they're just not engaging in the conversation. If they explained themselves and then tried to ignore reactions to that, that would be a way worse way to build a good relationship.

Just to point out that I'm only arguing this way to be impartial: as it happens, just last week, a day or two after reading about this change, I encountered a cache with a field puzzle that doesn't work precisely because of this change. Alas, I didn't know enough to pull the URL out of the proxy URL in order to get around the proxy. So the problems with this change are not just hypothetical to me.

7.2k · January 29, 2020

16 minutes ago, dprovan said:

It's not broken, it just doesn't do what it used to do. They withdrew an existing feature because it harbored a security hazard. Feel free to argue about whether the threat justifies withdrawing the feature. You don't like it, but that doesn't make it a bug.

Reading back through this thread, there are instances of what appear to be valid non-threatening images being rejected for reasons unknown. Until such time as HQ document what they think constitutes an acceptable image, beyond just using the buzzword "security", I'd consider that a bug. Not only are some existing caches now broken in ways that are difficult for the CO to figure out why, it makes it equally hard for anyone planning a new puzzle to know what will and won't work, both now and and in the near future.

January 29, 2020

4 hours ago, dprovan said:

Alas, I didn't know enough to pull the URL out of the proxy URL in order to get around the proxy.

As a matter of fact, this is exactly what I did yesterday in order to resolve a mystery. It is really easy to do. It probably could be scripted (hello @2Abendsegler

).

Edited January 29, 2020 by Tungstène

3.1k · January 29, 2020

1 hour ago, Tungstène said:

As a matter of fact, this is exactly what I did yesterday in order to resolve a mystery. It is really easy to do. It probably could be scripted (hello @2Abendsegler

).

What a clever solution. HQ encryps the site and users can use a script to decrypt the site on their own will.

January 29, 2020

3 minutes ago, arisoft said:

What a clever solution. HQ encrypts the site and users can use a script to decrypt the site on their own will.

Exactly. This way, users can tell their "cookie consents" to external image hosting.

By the way, HQ don't encrypt the site. They revamp a little part of it for security concern. More precisely, this is a privacy concern: "do I allow, as a geocaching.com user, the web server(s) to send me web cookies?"

Users who chose to install such a script would explicitly allow external sites to send cookies.

9.2k · January 29, 2020

8 hours ago, Tungstène said:

It is really easy to do. It probably could be scripted

It sure can, and I hadn't thought of that until you posted it. I might just update my own script with an IMG SRC rewriter. Then also add a glaring disclaimer on listings I view that have been altered in that way (just so I know whether it's another that had to be "fixed" or not)

Edited January 29, 2020 by thebruce0

January 29, 2020

Thank you for posting reports about broken images due to this release. We have a couple of updates:

Fixed issues

We have been working on identifying and fixing the bugs that have been reported here. The following updates have been made, which provide a fix for the majority of the reported issues.

Size of images - we increased the possible size of images that go through the proxy server
Google Drive and Dropbox support - images hosted on Google Drive and Dropbox should now display as expected
User agent - accessing images via the proxy server can result in unexpected responses from the hosting server. Of the reported issues, we have fixed those that were connected to this behavior.

Workarounds for issue we can’t fix

For some issues we will not be able to provide a solution. In such cases, consider either

Providing a text hyperlink to the website that hosts your image. This way other geocachers can choose to visit the external website to see the image.
Hosting your image on Geocaching.com, Google Drive, or Dropbox.

Why

This change was necessary to comply with changes in privacy law in the U.S. (California) and Europe. We do not plan to roll this update back again. However, we are actively working on identifying which of the surfacing issues we can fix.

If you are aware of any other broken images that might be connected to this release, please let us know in this thread which page (e.g. GC code) is affected.

9.2k · January 29, 2020

13 minutes ago, nykkole said:

Size of images - we increased the possible size of images that go through the proxy server

Google Drive and Dropbox support - images hosted on Google Drive and Dropbox should now display as expected

User agent - accessing images via the proxy server can result in unexpected responses from the hosting server. Of the reported issues, we have fixed those that were connected to this behavior.

re Sizes: Can you include instructions then about what image properties are allowed now for those hosted on a 3rd party website? Just like there are maximum requirements for uploading an image, if the proxy server is basically treating external images like an upload by restricting things like dimensions or byte size, that should be explained with the description editor. If the proxy server includes any restriction defining "non-valid" images, then cache owners should be informed of this.

re Host servers: That would make sense, these changes, and I hadn't considered that some web hosts may filter the image request itself through a spam score. The 3rd party server may check the useragent provided with the request.

Have you considered that your proxy server(s) may accrue a spam score by massive worldwide requests often from the same location or UA string, and potentially become blacklisted?

If every cache listing viewed worldwide 24/7 prompts your proxy server(s) to request images in a manner that does not appear to be a "real human/browser", then some web servers may consider that a negative.

13 minutes ago, nykkole said:

Providing a text hyperlink to the website that hosts your image. This way other geocachers can choose to visit the external website to see the image.

Basically treating images (especially 'special' ones) as another type of file with the off-site download disclaimer, essentially, which absolves HQ of any liability. Technically, it makes sense given these laws.

These stupidly overreaching privacy laws are just wreaking havoc. *sigh*

Edited January 29, 2020 by thebruce0

January 29, 2020

29 minutes ago, nykkole said:

Workarounds for issue we can’t fix

For some issues we will not be able to provide a solution. In such cases, consider either

Providing a text hyperlink to the website that hosts your image. This way other geocachers can choose to visit the external website to see the image.

Sounds like a perfect use of [Related Webpage]

7.5k · January 29, 2020

1 hour ago, thebruce0 said:

2 hours ago, nykkole said:

Providing a text hyperlink to the website that hosts your image. This way other geocachers can choose to visit the external website to see the image.

Basically treating images (especially 'special' ones) as another type of file with the off-site download disclaimer, essentially, which absolves HQ of any liability. Technically, it makes sense given these laws.

Actually, I'm not at all clear why the difference between an actual usable link to a web page and a text representation of that same link should make any difference whatsoever to these laws. Either GS is responsible for thwarting all evil links or they aren't. I'd be interested to learn how the distinction between a link naturally loaded by the user's browser and a link loaded by a script running in the user's browser or the user loading the link manually was written into the California law.

(As a Californian, I apologize to everyone about this, especially Groundspeak, but there's just no way to stop California's runaway nanny government.)

9.2k · January 29, 2020

33 minutes ago, dprovan said:

2 hours ago, thebruce0 said:

2 hours ago, nykkole said:

Providing a text hyperlink to the website that hosts your image. This way other geocachers can choose to visit the external website to see the image.

Basically treating images (especially 'special' ones) as another type of file with the off-site download disclaimer, essentially, which absolves HQ of any liability. Technically, it makes sense given these laws.

Actually, I'm not at all clear why the difference between an actual usable link to a web page and a text representation of that same link should make any difference whatsoever to these laws.

If I'm reading correctly, I think you're comparing something like visibly seeing the URL as non-clickable text, vs a clickable A link. I didn't get that from nykkole's comment. I took "text hyperlink" to mean a link like this instead of an embedded IMG image.

In that case, an embedded image is quite different than linking a user visible and clearly to a different website. There's no obvious indication with an embedded IMG that the media is on a separate website, unlike looking at the URL address and seeing that image is hosted on a different website. (especially if the source website includes a disclaimer about linking to something off-site before actually going there).

7.8k · January 30, 2020

27 minutes ago, thebruce0 said:

If I'm reading correctly, I think you're comparing something like visibly seeing the URL as non-clickable text, vs a clickable A link. I didn't get that from nykkole's comment. I took "text hyperlink" to mean a link like this instead of an embedded IMG image.

In that case, an embedded image is quite different than linking a user visible and clearly to a different website. There's no obvious indication with an embedded IMG that the media is on a separate website, unlike looking at the URL address and seeing that image is hosted on a different website. (especially if the source website includes a disclaimer about linking to something off-site before actually going there).

I think it's more about whether something is happening automatically or not. In the case of an img, the user doesn't choose to view the image or receive any related cookies; it just happens without their input. With a link, the user has to consciously click on the link. I guess choosing to click a link is implicitly accepting any possible consequences.

Release Notes (Website: Reverse Image proxy) - January 24, 2020

Recommended Posts