Jump to content

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

Geocaching HQ
Followers 14

Recommended Posts

Geocaching HQ

+Geocaching HQ

Posted
Posted

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!

Link to comment
niraD

+niraD

Posted
Posted

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?

Link to comment
Camroo

+Camroo

Posted
Posted
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
Link to comment
barefootjeff

+barefootjeff

Posted
Posted
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
Link to comment
thebruce0

+thebruce0

Posted
Posted

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
Link to comment
  • Popular Post
CAVinoGal

+CAVinoGal

Posted
  • Popular Post
Posted
19 hours ago, Geocaching HQ said:

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.

:unsure: More convenient?  For less "tech savvy" hiders, perhaps.  All my cache page background images are uploaded and stored on my hosting/webmaster account where I host a number of websites.  I LIKE having them on my server!  Now, as niraD and others have stated, it's no longer possible to provide a URL, but you MUST upload to the GS servers.  I would like the option of providing my own URL, please!

 

For those who will benefit from the simplicity of the drag and drop or upload option, this is a good thing.  But please don't take away the ability to use our own storage for background images!

  • Upvote 9
  • Helpful 1
Link to comment
  • Popular Post
The A-Team

+The A-Team

Posted
  • Popular Post
Posted

I have no problem with a drag-and-drop function being added. That seems like a good idea.

 

However, I do have a problem with this being yet another change that removed functionality that members were using from the site.

 

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.

  • Upvote 8
  • Helpful 2
Link to comment
ardila.nl

+ardila.nl

Posted
Posted (edited)
  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
Link to comment
31BMSG

+31BMSG

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

Link to comment
thebruce0

+thebruce0

Posted
Posted

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
Link to comment
IceColdUK

+IceColdUK

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

Link to comment
lodgebarn

+lodgebarn

Posted
Posted

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
Link to comment
coachstahly

+coachstahly

Posted
Posted

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
Link to comment
nykkole

nykkole

Posted
Posted

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
Link to comment
thebruce0

+thebruce0

Posted
Posted (edited)

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
Link to comment
The A-Team

+The A-Team

Posted
Posted
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
Link to comment
The A-Team

+The A-Team

Posted
Posted
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
Link to comment
thebruce0

+thebruce0

Posted
Posted (edited)
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
Link to comment
31BMSG

+31BMSG

Posted
Posted
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
Link to comment
thebruce0

+thebruce0

Posted
Posted (edited)

: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
Link to comment
Viajero Perdido

+Viajero Perdido

Posted
Posted (edited)
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
Link to comment
CAVinoGal

+CAVinoGal

Posted
Posted
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
Link to comment
thebruce0

+thebruce0

Posted
Posted

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
Link to comment
IceColdUK

+IceColdUK

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

 

Link to comment
Boomshanka

+Boomshanka

Posted
Posted (edited)

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
Link to comment
thebruce0

+thebruce0

Posted
Posted
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
Link to comment
thebruce0

+thebruce0

Posted
Posted
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
Link to comment
DoodleMaster

+DoodleMaster

Posted
Posted

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

Link to comment
alan666notb

+alan666notb

Posted
Posted
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
Link to comment
The Lambs @ 9

+The Lambs @ 9

Posted
Posted (edited)
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
Link to comment
barefootjeff

+barefootjeff

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

Link to comment
Guest
This topic is now closed to further replies.
Followers 14
Go to topic listing
×
×
  • Create New...