Release Notes (Website: Background image on cache pages) - January 14, 2020

9.2k · January 17, 2020

Just tested both image changes:

1. Background image uploads DO strip EXIF data

2. The image proxy server used in the rewritten description HTML IMG SRC does not strip EXIF data.

If that's the case, why are they are they even using the proxy there? One thing is still certain: My puzzle is still broken (it doesn't use meta data, but it does require the user's browser to request the image directly from my server).

January 17, 2020

Just a thought but have you considered moving the users out of the test environment?

7.8k · January 17, 2020

14 minutes ago, thebruce0 said:

If that's the case, why are they are they even using the proxy there?

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

9.2k · January 17, 2020

1 minute ago, The A-Team said:

18 minutes ago, thebruce0 said:

If that's the case, why are they are they even using the proxy there?

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

True, along with the direct http request from the user's browser.

7.8k · January 17, 2020

23 minutes ago, Boomshanka said:

Come on GCHQ... first the puzzles won't work (I disable them), then they do work (I enable them)... now they don't work! What's going on?

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

January 17, 2020

Thank you for reporting the broken images in the cache description. This is not related to the background image feature, but rather to another project to improve security.

As some of you have noted, the images were routed through a proxy server to strip them of 3rd party cookies. The expected behavior was for all images to continue to be displayed.

We have rolled this update back so that we can investigate the cause for the unintended broken images.

9.2k · January 17, 2020

27 minutes ago, nykkole said:

We have rolled this update back so that we can investigate the cause for the unintended broken images.

In the case noted above, your proxy would need to recognize that the file linked as an image isn't an image, and opt to pass it through untouched in order for the browser to deal with it as originally intended. If your proxy only removes cookies, then this shouldn't be a problem really.

But, it still breaks the functionality of images that test the image request's source. But it is otherwise good to know that nothing else is being changed via the proxy.

3.1k · January 18, 2020

20 hours ago, nykkole said:

As some of you have noted, the images were routed through a proxy server to strip them of 3rd party cookies. The expected behavior was for all images to continue to be displayed.

I have some puzzle caches that depends on cookies. For example,

https://www.geocaching.com/seek/cache_details.aspx?wp=GC60P4D&title=tic-tac-toe

https://www.geocaching.com/geocache/GC6NC11_joulukalenteri#kalenteri

If this standard HTTP feature is prevented, I am forced to create another web page to have exactly same sourcecode and link this external web page to the description.

Are you going to prevent all links to external http sources? In that case I can still spell the link like h t t p : / / w w w . w e b . a d d r e s s

Edited January 18, 2020 by arisoft

January 18, 2020

Runtime Error after upload and saving.

Edited January 19, 2020 by geoPetros

9.2k · January 18, 2020

The background image change hasn't rolled back, just the description HTML IMG proxy change.

January 19, 2020

You're "fixing" things that weren't broken and nobody asked for changes, but setting the new cache notifications still has the ergonomy of a 20 yo web page despite this topic being raised on this forum.

Besides, adjusting things to "less savvy" people without leaving alternatives is never a good thing because you're creating a thing that is less functional.

On 1/17/2020 at 10:47 PM, The A-Team said:

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

But, but... testing on the production is the fastest and gives you the best results, as it has the closest configuration to the live system :blink:

Edited January 19, 2020 by TheVoytekBear

January 19, 2020

Geocaching HQ please think before acting. This change renders a lot of puzzle ideas useless and makes quite a few existing caches insolvable...

Please revert this change that does not help the community.

A geocacher who has placed hundreds of mysteries.... To tell you the truth, I do not know which of my mysteries can no longer be solved.... You caused the problem... You fix it. I am not disabling anything now.

January 19, 2020

I also own mysteries that send a cookie with the coordinates... Nothing tracking... But simply coordinates are sent... Using an intermediate proxy makes this also more complicated..

Rendering a few puzzles insolvable...

22.2k · January 19, 2020

As someone who had personal information compromised by a player who used cookies in images maliciously, I thank Geocaching HQ for this change to improve privacy and security. It is about 16 years too late, but I appreciate your effort to help protect the community.

9.2k · January 19, 2020

*wants to compare to another real-world analogy* *doesn't, because that could really derail the thread :P*

3.1k · January 19, 2020

8 hours ago, Keystone said:

As someone who had personal information compromised by a player who used cookies in images maliciously, I thank Geocaching HQ for this change to improve privacy and security. It is about 16 years too late, but I appreciate your effort to help protect the community.

A cookie is not personal information. The cookie is set solely by the server and not by the user. Only if the user submits personal information to the server, the cookie can have this information, not the other way around.

3.1k · January 20, 2020

Suggestion: If security is really an issue behind this nonsense, please embed the user editable cache description in <iframe> capsule from a separate domain. Then it has no relation to the geocaching.com framework and can not compromise any personal data.

Edited May 13, 2020 by arisoft

9.2k · January 20, 2020

Just as done with public profile content.

January 20, 2020

All I know is I just tried to submit my first cache with this and I don't like it. It wouldn't accept my .jpg so then I had to convert it to a .png and then it was too big. And even then, now the image can't be viewed by looking at it at the bottom of the page by clicking on it so I would likely have to upload it and host it again. Pretty lame.

9.2k · January 20, 2020

3 minutes ago, elrojo14 said:

All I know is I just tried to submit my first cache with this and I don't like it. It wouldn't accept my .jpg so then I had to convert it to a .png and then it was too big. And even then, now the image can't be viewed by looking at it at the bottom of the page by clicking on it so I would likely have to upload it and host it again. Pretty lame.

There are a few unanswered questions here... Are you sure it's a jpg? What program did you use to create it and how? How big is it in KB? You're referring to uploading as a background image, yes? Are you dragging and dropping (and from where are you dragging it) or using the Upload button to select it?

A standard, proper JPG file that's <5MB should be draggable and droppable from a windows explorer into the upload box in the edit form, or selected from the file selection popup that appears when you hit the Upload button. Anything other than that and there's no guarantee it'll work.

January 20, 2020

1 minute ago, thebruce0 said:

There are a few unanswered questions here... Are you sure it's a jpg? What program did you use to create it and how? How big is it in KB? You're referring to uploading as a background image, yes? Are you dragging and dropping (and from where are you dragging it) or using the Upload button to select it?

A standard, proper JPG file that's <5MB should be draggable and droppable from a windows explorer into the upload box in the edit form, or selected from the file selection popup that appears when you hit the Upload button. Anything other than that and there's no guarantee it'll work.

.jpg taken from my iPhone. I resized it to less than 5 MB. It would not drop and drag nor upload link. I will try it again on the next cache I am I working on in a few minutes. I just uploaded another .jpg no problem so I think it doesn't like my iPhone photos. They are .jpg.

9.2k · January 20, 2020

4 minutes ago, elrojo14 said:

.jpg taken from my iPhone. I resized it to less than 5 MB. It would not drop and drag nor upload link. I will try it again on the next cache I am I working on in a few minutes. I just uploaded another .jpg no problem so I think it doesn't like my iPhone photos. They are .jpg.

So you're uploading a background image on your iOS Safari, directly from your camera roll? Or have you copied the image from your phone on to your desktop and you're using a desktop browser?

Are you sure the image is in the JPG format? iOS can now store HEIC files which are not JPGs but a proprietary Apple image format that needs to be converted to JPG. If you upload the image directly to the listing edit page from the camera roll within Safari the image should be converted automatically, but if you have it on your desktop as an HEIC file, you'll need to convert it, or use an app that will save the image as a JPG directly.

Edited January 20, 2020 by thebruce0

January 20, 2020

3 minutes ago, thebruce0 said:

So you're uploading a background image on your iOS Safari, directly from your camera roll? Or have you copied the image from your phone on to your desktop and you're using a desktop browser?

Are you sure the image is in the JPG format? iOS can now store HEIC files which are not JPGs but a proprietary Apple image format that needs to be converted to JPG. If you upload the image directly to the listing edit page from the camera roll within Safari the image should be converted automatically, but if you have it on your desktop as an HEIC file, you'll need to convert it, or use an app that will save the image as a JPG directly.

Yup. I turned off HEIC when I got my new phone. Just tried again and no go. Here is the file. https://www.dropbox.com/s/x1vl73b221m7c29/IMG_5935.JPG?dl=0

I just opened it in Paint and downsized it to a smaller size and saved as .png and it went right in. Lame.

9.2k · January 20, 2020

I'm not seeing anything wrong with the jpg. I opened it, resaved it as a barebones JPG, about the same size, and it wasn't accepted either.

The only thing I can think of is perhaps they have a maximum dimension also defined for the upload, which they aren't stating on the page, and the error message doesn't take that into account... try shrinking it to a smaller scale if that doesn't ruin the listing.

January 20, 2020

Just now, thebruce0 said:

I'm not seeing anything wrong with the jpg. I opened it, resaved it as a barebones JPG, about the same size, and it wasn't accepted either.

The only thing I can think of is perhaps they have a maximum dimension also defined for the upload, which they aren't stating on the page, and the error message doesn't take that into account... try shrinking it to a smaller scale if that doesn't ruin the listing.

I tried that too. Got it down to 1000 pixels wide and it still said no. The .pngs are uploading that size no problem.

I think the worst part of this is that I cannot upload the image like I used to and describe the image and give it a title. That way it was displayed on the cache page and people could see the image in its entirety and get a description. I don't like this format at all. I am sure it is great for the technologically inept. However, most of us are not and like our function and flexibility.

9.2k · January 20, 2020

2 minutes ago, elrojo14 said:

I think the worst part of this is that I cannot upload the image like I used to and describe the image and give it a title. That way it was displayed on the cache page and people could see the image in its entirety and get a description. I don't like this format at all. I am sure it is great for the technologically inept. However, most of us are not and like our function and flexibility.

Ignoring the issue with the JPG upload for a second (I can't see to get this one to upload either) -- the background URL field never had a description. You might be describing uploading it to the listing gallery first, then using the URL for the background. Technically you can still do both - upload to the gallery and give it the description, but now also upload it as the background image. (yes, that shows how inconvenient it is not to have the URL field =/ )

As for the JPG, I have no idea why it's not being accepted (I tried horizontal and landscape versions at 320x240, even). Without going into crazy technical analysis of file, it may be well be a bug on the server end, and HQ should know about it.

January 20, 2020

1 minute ago, thebruce0 said:

Ignoring the issue with the JPG upload for a second (I can't see to get this one to upload either) -- the background URL field never had a description. You might be describing uploading it to the listing gallery first, then using the URL for the background. Technically you can still do both - upload to the gallery and give it the description, but now also upload it as the background image. (yes, that shows how inconvenient it is not to have the URL field =/ )

I am aware of that. Stupid as can be. I am not sure I should even upload photos as background anymore. There really is no point. You cannot see them and why would I want to upload them twice? When my caches publish we can check out how dumb this is.

9.2k · January 20, 2020

Well, at least your upload problem is confirmed

A valid JPG is not being accepted.

I tried with a JPG of mine and it was fine; it even has meta data just like your original.

Very weird.

January 21, 2020

On 1/17/2020 at 10:26 AM, thebruce0 said:

ETA: (yes: the source HTML in some of my older descriptions which used uploaded images refers to imgcdn.geocaching.com - the Canada server presumably - and images are loaded via redirect to amazonaws)

@thebruce0: imgcdn means the server is part of a Content Delivery Network (if it was country-based, it would have been imgca )

9.2k · January 21, 2020

goodpost.gif.121ce91ec8a20d33b3b8f5ef5c8c7f7b.gif

(also yeah, I've been bitten by that as well in the past; an acronym or short form that initially reads like something else; related to this, another company)

January 21, 2020

I have 1 puzzle where I host images on my own website because they use EXIF info (which is removed when hosting on Geocaching itself).

I now see that the URL has been changed to "https://imgproxy.geocaching.com/09a44c6d4fac8f92622d4a4177f23e18450f0693?url=http...". When I download the image, the EXIF info is still present.

For another puzzle I use an mp3 file. I cannot host this on Geocaching. The link to this file on my website has not been changed.

January 21, 2020

On 1/20/2020 at 9:03 AM, arisoft said:

Suggestion: If security is really an issue behind this nonsense, please embed the user editable cache description in <iframe> capsule from a separate domain. Then it has no relation to the geocaching.com framework and can not comporomise any personal data.

Which means that you have to provide the cache page on your own hosting?

I suspect that this will be a problem for many people. Not everyone is able to set up their own website and edit html. There are indeed tools for that, but I fear it could be a bridge too far. :huh:

9.2k · January 21, 2020

Ahh, I see the dreaded image proxy for description HTML is back.

Just now, Bergloper said:

Which means that you have to provide the cache page on your own hosting?

No, HTML can be written into the iframe, so HQ simply writes the custom HTML content into that iframe, essentially contained in its sandboxed element. The same is done with your public profile HTML content, embedded within an iframe.

January 21, 2020

1 minute ago, thebruce0 said:

Ahh, I see the dreaded image proxy for description HTML is back.

No, HTML can be written into the iframe, so HQ simply writes the custom HTML content into that iframe, essentially contained in its sandboxed element. The same is done with your public profile HTML content, embedded within an iframe.

Thanks for the clarification.

I wrote HTML with IFrames in the past, but today it is no longer common for several reasons (security, layout, ...).

I also assumed that you always refer to another domain via an IFrame.

I know the example of how to use the profile on Geocaching and I honestly thought that the user suplied content in the listing worked in a similar way.

9.2k · January 21, 2020

Yeah it's kind of a hack, but just as javascript can write content to an open document in any window, iframe is treated as a distinct document so it can be written, thus contain HTML content that's in a sense not hosted anywhere.

That would be a better solution to the embedded image issue than rewriting all the image URLs and breaking puzzle that really don't need to be broken... =/

January 21, 2020

Links modified on my puzzles by Groundspeak without warning and without precautions. Result: "not found" !!!!!

If I continue to geocach, I will stop being premium !!!

January 21, 2020

6 minutes ago, thebruce0 said:

Yeah it's kind of a hack, but just as javascript can write content to an open document in any window, iframe is treated as a distinct document so it can be written, thus contain HTML content that's in a sense not hosted anywhere.

That would be a better solution to the embedded image issue than rewriting all the image URLs and breaking puzzle that really don't need to be broken... =/

I agree

7.8k · January 21, 2020

12 minutes ago, thebruce0 said:

Yeah it's kind of a hack, but just as javascript can write content to an open document in any window, iframe is treated as a distinct document so it can be written, thus contain HTML content that's in a sense not hosted anywhere.

That would be a better solution to the embedded image issue than rewriting all the image URLs and breaking puzzle that really don't need to be broken... =/

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.

7.8k · January 21, 2020

33 minutes ago, thebruce0 said:

Ahh, I see the dreaded image proxy for description HTML is back.

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.

9.2k · January 21, 2020

18 minutes ago, The A-Team said:

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.

Yes the DOM is sandboxed, but I thought that did also block cookies from the domain-end, since in this case the original source is about:blank... is not the embedded iframe script blocked from accessing the main document cookies as well? That was my understanding. Silly me for not checking... It would depend, it seems, on whether they set up the iframe properties correctly, if I'm reading correctly. I haven't used iframe in a specific circumstance like this.

January 21, 2020

The Groundspeak chainsaw massacre !!
22 puzzles that no longer work !!!

January 22, 2020

If only they had some sort of dev & test environment they could use to check basic things like links working.

January 22, 2020

Why did they even bother taking the proxy offline ? Not to implement changes or to communicate the unannounced change to affected COs...

6.2k · January 22, 2020

2 hours ago, BethDaddyKaty said:

If only they had some sort of dev & test environment they could use to check basic things like links working.

they do: https://staging.geocaching.com/ give it a try.

I'd like to see all changes deployed to the staging site, then give the community a chance to try it and feed back; there must be several hundred years of accumulated IT/developer knowledge amongst just those I regularly see on the forums, not to mention the accumulated geocaching experience - they could make good use of that experience at no cost to help improve the quality of releases, but I don't know to what degree changes are tested on there and who performs the testing.

January 22, 2020

image.png.195d32db436316e1b4a9d9305ada48cc.png

https://imgproxy.geocaching.com/14ea8503e8d3373b190f70929a00a59a88db4e68?.......

Results when tested in a production environment.
Not the least consistent thought.
( GC8GKB7 Nötknäckarkalendern 2019-10 Kul i jul )

Edited January 22, 2020 by svegrim

January 22, 2020

23 hours ago, Bergloper said:

I have 1 puzzle where I host images on my own website because they use EXIF info (which is removed when hosting on Geocaching itself).

I now see that the URL has been changed to "https://imgproxy.geocaching.com/09a44c6d4fac8f92622d4a4177f23e18450f0693?url=http...". When I download the image, the EXIF info is still present.

For another puzzle I use an mp3 file. I cannot host this on Geocaching. The link to this file on my website has not been changed.

Yesterday I checked the new behavior for external hosted images via the website and everything seemed to be okay.

This evening I checked the puzzle via the app and I only see broken links to the images.

That's not good.

Should I report this separately or wil this picked up here?

9.2k · January 22, 2020

23 hours ago, Bergloper said:

For another puzzle I use an mp3 file. I cannot host this on Geocaching. The link to this file on my website has not been changed.

Since you can't embed an mp3 file as an <img src>, I assume you mean you're linking to the external MP3 file as a link - that should still be possible, those links aren't being changed.

9.2k · January 22, 2020

Workaround discovered (until they close this hole too):

You can refer to an external image and apply it as a background image to an element using the STYLE attribute for CSS. As in, for example:

Instead of <img src="http://website.com/image.jpg" width="50" height="50" />

Use <div style="width:50px;height:50px;background:url(http://website.com/image.jpg);"></div>

and play around with it until it works. If you know CSS.

January 22, 2020

1 hour ago, thebruce0 said:

Since you can't embed an mp3 file as an <img src>, I assume you mean you're linking to the external MP3 file as a link - that should still be possible, those links aren't being changed.

Indeed, I use de <a href=http://...> ... </a>

January 23, 2020

>>>> the images were routed through a proxy server

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.

Release Notes (Website: Background image on cache pages) - January 14, 2020

Recommended Posts