Jump to content
Sign in to follow this  
Followers 15
Geocaching HQ

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

Recommended Posts

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

 

With this release, we have made it more convenient for cache owners to add background images to their cache pages.

 

As a cache owner, you can now add a background image to your cache page in two ways: Drag and drop your background image to add it to your cache page, or browse your computer to select an image.

 

 

CffnACWOAiImdOXuEpUvsuXpCZvlA82xiOhHfqXy

 

 

To remove a background image, click delete:

 

 

qpIpjpppnnLLPDSKeO_9UzOXcS4mZMBNUOOU2BBZ

 

 

This change is in place for all new and existing cache pages. If your cache page currently has a background image, you can delete it and add a new one using the new feature.

 

Please note that due to compatibility issues, Microsoft Edge users will not be able to drag and drop background images. Microsoft Edge will show the native “Browse” feature to select images from your computer.

 

Nicole (nykkole), Associate Product Manager, 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!

Share this post


Link to post

If I want to use the same background image for multiple caches, then it looks like I now need to upload the image repeatedly, once for each cache. It looks like it is no longer possible to provide the URL of an existing image as a background image.

 

Is that a correct understanding of this change?

Share this post


Link to post
43 minutes ago, niraD said:

It looks like it is no longer possible to provide the URL of an existing image as a background image.

if this is true, that sucks. i use that feature alot and im sure many others do too. Who knows though. maybe its for the better.

  • Upvote 4
  • Helpful 1

Share this post


Link to post
1 hour ago, niraD said:

It looks like it is no longer possible to provide the URL of an existing image as a background image.

 

I've done quite a few puzzles where part of the puzzle is concealed in the background image. With the stripping of EXIF data now and possibly other processing of images uploaded to the site, this could be problematic. I see that on cache pages where I've used an external background image, I can no longer edit or even see that URL.

  • Upvote 3
  • Helpful 3

Share this post


Link to post

Yes this functionality may have just grandfathered existing active geocaches with an external background image.

 

Can TPTB explain the reasoning why the background image is now forced to be uploaded? (curious!)

If it was a matter of security/privacy, that can make sense, and if the intent was indeed to grandfather existing caches and no longer allow external background images, it would be good to know.

 

Kind of like how the explanation for the removal of the "Related URL" was rolled out.  Without that explanation, one could interpret that the use of external background image URLs wasn't considered and may be brought back... please let us know! :)

  • Upvote 1
  • Helpful 1

Share this post


Link to post
This modification is incomprehensible !!!
I can put lots of puzzle ideas in the trash !!!

 

  • Upvote 3
  • Helpful 1
  • Love 1

Share this post


Link to post

Seattle calling - please explain why an external URL is depreciated as posters above have kindly asked.

  • Upvote 5
  • Helpful 1

Share this post


Link to post

If it's not broke, don't fix it. Please return this feature back to the way it was.

  • Upvote 6
  • Helpful 1

Share this post


Link to post

GC server deleted all metadata from background image after upload:(

Edited by geoPetros
  • Helpful 1

Share this post


Link to post
  1. Why was I not informed of this as a cache owner?
    1. If you change things that directly impact the cache listings themselves instead of general functionality on the site it seems a email telling cache owners you've done so would be the proper thing to do
  2. Why have you removed existing images (All my caches had background images and now they don't)
    1. I used to have a cache with a rotating background because I set a directory/index.php as background so it would serve a random background from the list every time you visited the cache page. This is also no longer possible.
  3. All caches using the background images as part of their puzzle are now broken
    1. And because you've not informed caches owners they might not know that their puzzle is now broken.
  4. I use external images in my cache pages (background as well) from my own site because it has happened in the past that GC deleted/lost a lot of images resulting in a lot of banners for caches disappearing so I don't fully trust the GC image storage

 

It might be a good idea when posting release notes to include the reasoning behind them. I can guess some possible reasons but without a explanation they are just guesses.

 

Can you please stop breaking stuff nobody asked you to change

Edited by ardila.nl
typo
  • Upvote 3
  • Helpful 3

Share this post


Link to post
2 hours ago, ardila.nl said:

Why have you removed existing images (All my caches had background images and now they don't)

That's not true, e.g.:-

 

image.thumb.png.68b8a98553eb0c0cdbc3d79b00ba898e.png

Share this post


Link to post
1 minute ago, MartyBartfast said:

That's not true, e.g.:-

 

image.thumb.png.68b8a98553eb0c0cdbc3d79b00ba898e.png

 

Sorry my mistake. Some of them. I shouldn't have said All.

 

But the point still stands. They should not have removed the existing background images

  • Upvote 1
  • Helpful 1

Share this post


Link to post
17 hours ago, The A-Team said:

I think we at least deserve an explanation for why this has been done. There doesn't seem to be an obvious reason to remove the URL field, so we'd like to know the reasoning behind this decision.

I downloaded an image from my gallery yesterday and noticed it was hosted on Amazon web services, if this is new I wonder if it would account for the change. When moving images in the past I don't recall Amazon being involved.

Share this post


Link to post

The move to AWS wouldn't have directly affected the reason for allowing an external background image (though that would have been a nice point to include in a release note, even if it's periphery - many people link directly to images that were hosted on gc's image servers that might want to or need to make a change).

 

Again the only remotely related reason I could see for intentionally removing that URL option (though done without telling anyone and breaking many things) would be maybe possibly somehow related to the whole privacy thing, or maybe just web security, or something in that big vague realm of stuff. As in, someone might try to make an argument for that, but I don't see it. That field is a big loss, and changes things. :(

  • Upvote 4
  • Helpful 1

Share this post


Link to post
44 minutes ago, thebruce0 said:

or maybe just web security


That’s what I was wondering.

 

4 hours ago, ardila.nl said:

I used to have a cache with a rotating background because I set a directory/index.php as background so it would serve a random background from the list every time you visited the cache page.


I’ve no idea whether a technique like this could be used maliciously but maybe...

Share this post


Link to post

The headline point was "making it more convenient" i.e. a benefit for everyone. In my world it is common to maintain existing functionality when doing radical changes. Experience suggests that Groundspeak like to do the exact opposite, thus end up upsetting existing users. Moreover this is done without any initial communications and seemingly without a care in the world. We are surely used to this approach by now.

  • Upvote 1
  • Helpful 1
  • Love 1

Share this post


Link to post
4 hours ago, ardila.nl said:

Why have you removed existing images

 

I'm not seeing that.  I have a puzzle that depends on the background image.  Just checked; it's still intact, EXIF and all.

 

But now I'm afraid to ever edit the page...

  • Upvote 1
  • Helpful 1

Share this post


Link to post
On 1/14/2020 at 11:22 PM, Geocaching HQ said:

we have made it more convenient for cache owners to add background images

 

I have to disagree.

 

If you want to add new upload functionality it's ok, but please restore the possibility to enter an URL.

  • Upvote 4
  • Helpful 1

Share this post


Link to post

I have never included any information in my background pictures but, like others have stated, that option is now gone.  While the drag and drop (and select from file) is nice, it should be an additional option, not the only one.  This limits options, not enhances them.  Thankfully, none of my background images have been affected but like VP, I'm not going to ever edit them.

  • Upvote 3
  • Helpful 1

Share this post


Link to post

Thanks for all the questions. We appreciate the desire to know more about the reasons behind this release. Here are the main ones:

  • Security - Allowing a background image to be inserted via an external URL can result (intentionally or not) in third-party cookies on the computers of those who view the cache page. This is a security risk that we were able to close with this release for all caches going forward.

  • Easier for non tech savvy - As some mentioned in this thread, not every player knows how to or has a server to store their own images. This type of image uploading functionality is standard on many websites and cache owners have asked us for this functionality.

  • Issues with broken images in the past - When an image hosting service becomes unavailable, cache owners don’t always notice this. This causes the image to disappear and some puzzles become unsolvable.

While we wanted to ensure that these three points are addressed going forward, we also wanted to make sure that existing cache pages are not affected. If you have a existing puzzle that relies on the background image, the puzzle is not affected by the changes.

 

The behavior for caches with existing background image is that the edit page will show a thumbnail of the image. Behind the scenes, this is still the URL you entered. You can make changes to your cache page without impacting the background image. But if you delete the existing background image, then the new upload functionality is your only option for a new background image.

  • Helpful 9

Share this post


Link to post

It's quite unfortunate that the decision came to that. But thanks for the clarity.

 

Now how would you handle all the geocache descriptions now that use an IMG tag to link to external media?  Will IMG be sanitized to disallow external images from this point forward? If not, then really the removal of the background image URL is ... needless. I wouldn't say "non-tech savvy" would be a good reason, because you can add the ability to upload an image, or allow a "savvy" user to override that and provide a distinct URL.

 

But, the only reasonable purpose I can understand is if HQ wants to crack down on security with having their hosted web pages load any external content - but that would mean extending that background image implementation to externally embedded images in description HTML, which is effectually exactly the same thing as providing a distinct background image URL.

 

Please do not do disallow external image embedding!  That would be a drastic change for the community.  I'd rather live with the inconsistency of blocking custom background URLs while allowing custom external description images than having them ALL blocked :P

Edited by thebruce0
  • Upvote 6
  • Helpful 1

Share this post


Link to post
6 hours ago, 31BMSG said:

I downloaded an image from my gallery yesterday and noticed it was hosted on Amazon web services, if this is new I wonder if it would account for the change. When moving images in the past I don't recall Amazon being involved.

 

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

  • Upvote 1

Share this post


Link to post
2 hours ago, nykkole said:
  • Security - Allowing a background image to be inserted via an external URL can result (intentionally or not) in third-party cookies on the computers of those who view the cache page. This is a security risk that we were able to close with this release for all caches going forward.

 

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.

  • Upvote 1

Share this post


Link to post
35 minutes ago, The A-Team said:
7 hours ago, 31BMSG said:

I downloaded an image from my gallery yesterday and noticed it was hosted on Amazon web services, if this is new I wonder if it would account for the change. When moving images in the past I don't recall Amazon being involved.

 

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

 

I don't believe the URLs fort he gallery images have changed until recently.  They used to be hosted at img.geocaching.com.  They have moved servers long ago, but perhaps they just recently changed how the images are referenced.  In any case, there are caches still using img.geocaching.com to host gallery images, both uploaded and embedded in the listing.  I would think much like other changes, these are grandfathered and attempting to do the same would alter the image URLs to the AWS domains where they are now hosted.

 

One of my old caches having img.geocaching.com still works, not broken, so I would assume the grandfathering factor applies just like the background image URL.

 

ETA: Strange, testing out some stuff, the url shown on the page on uploading images, or viewing the gallery, still shows as img.geocaching.com. I swear I just tested an upload and the image was loaded from that url. Now it seems that the img.geocaching.com domain is redirecting to s3.amazonaws.com.  So I'm not sure if they retained the original domain for backwards compatibility and moved everything to amazonaws, or if that redirect has always been there... I'm mostly confident that redirect is new... =/  I do know in the past I've referenced uploaded images by img.geocaching.com.

 

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)

Edited by thebruce0

Share this post


Link to post
2 hours ago, thebruce0 said:

 

I don't believe the URLs fort he gallery images have changed until recently.  They used to be hosted at img.geocaching.com.  They have moved servers long ago, but perhaps they just recently changed how the images are referenced.  In any case, there are caches still using img.geocaching.com to host gallery images, both uploaded and embedded in the listing.  I would think much like other changes, these are grandfathered and attempting to do the same would alter the image URLs to the AWS domains where they are now hosted.

 

One of my old caches having img.geocaching.com still works, not broken, so I would assume the grandfathering factor applies just like the background image URL.

 

ETA: Strange, testing out some stuff, the url shown on the page on uploading images, or viewing the gallery, still shows as img.geocaching.com. I swear I just tested an upload and the image was loaded from that url. Now it seems that the img.geocaching.com domain is redirecting to s3.amazonaws.com.  So I'm not sure if they retained the original domain for backwards compatibility and moved everything to amazonaws, or if that redirect has always been there... I'm mostly confident that redirect is new... =/  I do know in the past I've referenced uploaded images by img.geocaching.com.

 

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)

Thanks for checking. I uploaded some images for a cache last summer and when I went to copy and past on the cache page I know they had an GC.com URL. I was a bit surprised when I saw the URL yesterday since I try to avoid any URL with Amazon, Google, or Facebook in it.

  • Surprised 1

Share this post


Link to post

Does the change also effect images that are in the cache description that are remote hosted?  I notice all my caches that have images hosted on my server are not longer displayed - WHY

 

  • Helpful 1

Share this post


Link to post

:o:o:o

THEY DID

 

The first cache I checked that RELIES on external hosting on my server is broken.

 

This is not good...

 

ETA: Thankfully the other one that relied on this setup I archived a while back or it too would be DOA.

Edited by thebruce0
  • Helpful 1

Share this post


Link to post
32 minutes ago, thebruce0 said:

The first cache I checked that RELIES on external hosting on my server is broken.

 

Oh shoot, you're right!  I just checked a local cache with the same setup - an external image in the body of the cache listing.  The URL's been rewritten into

https://imgproxy.geocaching.com/...blah...blah...?url=http%3A%2F%2Foriginal.site/clever.jpg

We can't have nice puzzles.  :unsure:

 

ETA: I'll have to assume the "imgproxy" caches a copy of the external image.  If it passes the request through every time, no worries, no drama, carry on and keep caching.  If.

 

Edited by Viajero Perdido
  • Upvote 1
  • Helpful 1

Share this post


Link to post
46 minutes ago, Viajero Perdido said:

Oh shoot, you're right!  I just checked a local cache with the same setup - an external image in the body of the cache listing.  The URL's been rewritten into


https://imgproxy.geocaching.com/...blah...blah...?url=http%3A%2F%2Foriginal.site/clever.jpg

We can't have nice puzzles.  :unsure:

 

ETA: I'll have to assume the "imgproxy" caches a copy of the external image.  If it passes the request through every time, no worries, no drama, carry on and keep caching.  If.

 

I just checked a few of my puzzles that have background images, and images in body of the cache description, integral to solving the puzzles.  They are all there, so far, but the URL when I "open image in a new tab" begins with https://imgproxy.geocaching.com/ ... url=(eventually mysite.com/my file.jpg)

 

I kinda, sorta, see why they did this, but I think those of us that use our own servers for images really do know what we are doing, and are not going to be collecting cookies or whatever, (just to display an image? ) and PREFER to host our own images.  UGH.  Why couldn't they have just ADDED the option to drag and drop, and left the rest alone??  

 

  • Helpful 1

Share this post


Link to post

I've published a brief look at the updates and how they affect things in a new video.

 

A few things have just been discovered as well through this.  For example, coordinate checker images are also affected.  BUT, it appears that the image is reloaded and refreshed to the proxy server with every view of the geocache listing.  It's likely that external images are NOT HOSTED on AWS servers, but rather loaded dynamically via the proxy server. The original URL is included in the rewrite, which may explain why the image is loaded freshly with every view of the description, and this allows the proxy server to still strip extra meta (exif) data.

  • Helpful 1

Share this post


Link to post
8 hours ago, thebruce0 said:

The first cache I checked that RELIES on external hosting on my server is broken.


Do you know what it is about your ‘broken’ image that’s stopping the proxy from displaying it?  I’ve checked a few of my caches and they all seem fine, but clearly you and @4cycle have found issues...

 

I have external image links to my own website and to GeoCheck.com that both make php requests to deliver dynamic content.  I was concerned that this might be an issue, but apparently not.

 

Share this post


Link to post

@Geocaching HQ:

I think, you should "clean" then log-pictures, too.

Because, there are sometimes final-coordinates in the exif-block ...

Share this post


Link to post

Hmmm... two of my puzzles need reconfiguring and one (GC6F9V8) now just goes to an 'Error 500' page. Seems this change also affects pictures in the cache page and not just the background image. Bit of a pain shall we say?  

 

Edit: It means that I can't even access GC6F9V8 to try to resolve any issues as a result of these changes.

 

Edit 2: https://coord.info/GC6F9V8 has just come back to life... perhaps things are going on in the background :)

Edited by Boomshanka
  • Helpful 1

Share this post


Link to post
11 hours ago, thebruce0 said:

The first cache I checked that RELIES on external hosting on my server is broken.

I just checked a few of @arisoft's that I've been working on and they're now broken too. I mean of course people can still decipher the url to the original image, but what a mess.

  • Helpful 2

Share this post


Link to post
13 minutes ago, mustakorppi said:

I just checked a few of @arisoft's

Well he must be off grid at the moment, I'm sure he'll have something to say on this !

Share this post


Link to post
3 hours ago, IceColdUK said:

Do you know what it is about your ‘broken’ image that’s stopping the proxy from displaying it?  I’ve checked a few of my caches and they all seem fine, but clearly you and @4cycle have found issues...

I have external image links to my own website and to GeoCheck.com that both make php requests to deliver dynamic content.  I was concerned that this might be an issue, but apparently not.

 

Correct - to be more clear - the image SRC url is re-written to their proxy image server, which does request the original image on each load, however via the proxy server, so all meta data can be filtered and stripped off. The images will still (ideally) display properly, but two things are no longer available: Meta-data, and dynamic content and/or tracking that may rely on the image request coming from the user's browser - that request will now always come from the proxy server.

 

When I say my image is broken I don't mean it doesn't display at all, I mean it doesn't display the way it's supposed to, because it's retrieved via the proxy server, not the user.  If I archive the cache I'll likely explain the puzzle and the details, but I can confidently say the update has broken the puzzle.

  • Helpful 1

Share this post


Link to post
23 minutes ago, thebruce0 said:

The images will still (ideally) display properly

The images I referred to (one example here) currently don’t display at all. I’m sure many of you will immediately spot the likely cause, but probably best not to discuss it so as not spoil anything.

  • Helpful 1

Share this post


Link to post
3 minutes ago, mustakorppi said:
30 minutes ago, thebruce0 said:

The images will still (ideally) display properly

The images I referred to (one example here) currently don’t display at all. I’m sure many of you will immediately spot the likely cause, but probably best not to discuss it so as not spoil anything.

Well, "ideally" - as in if visual image data is (syntactically) properly output, then it will display. Obviously instances of dynamic content or making use of syntax loopholes (like the example above) will be broken. Without spoiling too much - that image src technically isn't an image, so the resulting output is correct.  I guess we can also add to the list of things the proxy source does: Ensure that an image being requested is an image being displayed. :P

  • Helpful 1

Share this post


Link to post

I am trying to add a photo to the BODY of my cache description (not worried about the background)

Before I did this

 

<p><img alt src="https://s3.amazonaws.com/gs-geo-images/448ab7dd-0fb6-4c43-a34f-9e69b0068883.jpg" /></p>

Now it seems I need to do this

<p><img alt src="https://www.geocaching.com/seek/image.aspx?imgid=5209334" /></p>

HOWEVER - that does not display the image in my description 

What do I need to do instead ?   (not an HTML expert btw)

Tks

Share this post


Link to post
5 minutes ago, DoodleMaster said:

I am trying to add a photo to the BODY of my cache description (not worried about the background)

Before I did this

 

<p><img alt src="https://s3.amazonaws.com/gs-geo-images/448ab7dd-0fb6-4c43-a34f-9e69b0068883.jpg" /></p>

Now it seems I need to do this

<p><img alt src="https://www.geocaching.com/seek/image.aspx?imgid=5209334" /></p>

HOWEVER - that does not display the image in my description 

What do I need to do instead ?   (not an HTML expert btw)

Tks

 

Try pasting the 2nd URL into a browser window, it should redirect to the s3.amazonaws.com site and you can then cut&paste the URL it ends up at.

  • Upvote 1

Share this post


Link to post
38 minutes ago, DoodleMaster said:

I am trying to add a photo to the BODY of my cache description (not worried about the background)

Before I did this

 

<p><img alt src="https://s3.amazonaws.com/gs-geo-images/448ab7dd-0fb6-4c43-a34f-9e69b0068883.jpg" /></p>

Now it seems I need to do this

<p><img alt src="https://www.geocaching.com/seek/image.aspx?imgid=5209334" /></p>

HOWEVER - that does not display the image in my description 

What do I need to do instead ?   (not an HTML expert btw)

Tks

 

For the background

 

Type this into your browser window

 

 https://s3.amazonaws.com/gs-geo-images/448ab7dd-0fb6-4c43-a34f-9e69b0068883.jpg

 

Copy the picture to your own computer then upload the image for the background of your cache page

 

If it for your cache page you will need to host the image on the GS server. Put the image on an archived cache page and copy the location from there.

 

 

 

 

 

 

Edited by The Lambs @ 9

Share this post


Link to post
4 hours ago, thebruce0 said:

stuff

Dude...

 

But also, wanna know how I know you just assumed something?

Share this post


Link to post

Looks like the three puzzles I had photo-related issues with are all now back up and working again :)

Share this post


Link to post
5 hours ago, thebruce0 said:

Correct - to be more clear - the image SRC url is re-written to their proxy image server, which does request the original image on each load, however via the proxy server, so all meta data can be filtered and stripped off. The images will still (ideally) display properly, but two things are no longer available: Meta-data, and dynamic content and/or tracking that may rely on the image request coming from the user's browser - that request will now always come from the proxy server.

 

I just went to one of my puzzle caches, which has an image in the description containing some EXIF meta-data, right-clicked on the image, did a Save As to my hard drive and all the meta-data is still there.

Share this post


Link to post
33 minutes ago, Boomshanka said:

Looks like the three puzzles I had photo-related issues with are all now back up and working again

The image url’s are back to normal, so looks like they rolled back that change. 

  • Upvote 1
  • Helpful 2

Share this post


Link to post

Neat, just verified, the proxy server is no longer being used for HTML descriptions' embedded IMG SRC files.

 

ETA: Wait... now it's back... what's going on.  :(

Edited by thebruce0
  • Helpful 1

Share this post


Link to post

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?

  • Helpful 1

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  
Followers 15

×
×
  • Create New...