Jump to content

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


Recommended Posts

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

  • Helpful 1
Link to comment
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.

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

  • Upvote 2
  • Funny 2
Link to comment

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.

  • Upvote 1
  • Funny 1
  • Surprised 1
  • Helpful 2
  • Love 1
Link to comment
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.

  • Helpful 1
Link to comment
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 by arisoft
  • Upvote 1
  • Helpful 1
Link to comment

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 by TheVoytekBear
  • Upvote 2
Link to comment

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.

  • Upvote 2
  • Helpful 1
Link to comment

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.

  • Upvote 3
Link to comment
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.

 

  • Upvote 2
  • Helpful 1
Link to comment

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 by arisoft
  • Upvote 2
Link to comment

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. 

  • Helpful 1
Link to comment
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.

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

  • Helpful 1
Link to comment
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 by thebruce0
Link to comment
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.

  • Helpful 1
Link to comment

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.

  • Helpful 1
Link to comment
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. 

  • Helpful 1
Link to comment
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.

  • Helpful 1
Link to comment
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. 

  • Upvote 2
  • Helpful 1
Link to comment

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.

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

Link to comment

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.

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

Link to comment

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... =/

  • Upvote 1
Link to comment
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 :)

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

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

  • Upvote 3
  • Helpful 1
Link to comment
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.

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

 

  • Helpful 2
  • Love 1
Link to comment
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?

  • Helpful 1
Link to comment
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.

Link to comment

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.

  • Upvote 1
  • Helpful 2
Link to comment

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

 

 

  • Upvote 1
  • Helpful 1
  • Love 1
Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...