+Geocaching HQ Posted January 14, 2020 Share Posted January 14, 2020 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. To remove a background image, click delete: 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 Posted January 15, 2020 Share Posted January 15, 2020 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 Posted January 15, 2020 Share Posted January 15, 2020 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. 4 1 Link to comment
+barefootjeff Posted January 15, 2020 Share Posted January 15, 2020 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. 3 3 Link to comment
+thebruce0 Posted January 15, 2020 Share Posted January 15, 2020 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! 1 1 Link to comment
+dedef Posted January 15, 2020 Share Posted January 15, 2020 This modification is incomprehensible !!! I can put lots of puzzle ideas in the trash !!! 3 1 1 Link to comment
Popular Post +CAVinoGal Posted January 15, 2020 Popular Post Share Posted January 15, 2020 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. 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! 9 1 Link to comment
+Birdie.NL Posted January 15, 2020 Share Posted January 15, 2020 Seattle calling - please explain why an external URL is depreciated as posters above have kindly asked. 5 1 Link to comment
+bluesnote Posted January 15, 2020 Share Posted January 15, 2020 If it's not broke, don't fix it. Please return this feature back to the way it was. 6 1 Link to comment
Popular Post +The A-Team Posted January 15, 2020 Popular Post Share Posted January 15, 2020 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. 8 2 Link to comment
+geoPetros Posted January 16, 2020 Share Posted January 16, 2020 (edited) GC server deleted all metadata from background image after upload Edited January 16, 2020 by geoPetros 1 Link to comment
+ardila.nl Posted January 16, 2020 Share Posted January 16, 2020 (edited) Why was I not informed of this as a cache owner? 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 Why have you removed existing images (All my caches had background images and now they don't) 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. All caches using the background images as part of their puzzle are now broken And because you've not informed caches owners they might not know that their puzzle is now broken. 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 January 16, 2020 by ardila.nl typo 3 3 Link to comment
Popular Post +CanUSeeIT Posted January 16, 2020 Popular Post Share Posted January 16, 2020 5 minutes ago, ardila.nl said: Can you please stop breaking stuff nobody asked you to change ^^^^^^ THIS ^^^^^^ a thousand times over!!! 10 3 1 Link to comment
+MartyBartfast Posted January 16, 2020 Share Posted January 16, 2020 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.:- Link to comment
+ardila.nl Posted January 16, 2020 Share Posted January 16, 2020 1 minute ago, MartyBartfast said: That's not true, e.g.:- 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 1 1 Link to comment
+31BMSG Posted January 16, 2020 Share Posted January 16, 2020 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 Posted January 16, 2020 Share Posted January 16, 2020 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. 4 1 Link to comment
+IceColdUK Posted January 16, 2020 Share Posted January 16, 2020 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 Posted January 16, 2020 Share Posted January 16, 2020 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. 1 1 1 Link to comment
+Viajero Perdido Posted January 16, 2020 Share Posted January 16, 2020 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... 1 1 Link to comment
+fraggle_[DE] Posted January 16, 2020 Share Posted January 16, 2020 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. 4 1 Link to comment
+coachstahly Posted January 16, 2020 Share Posted January 16, 2020 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. 3 1 Link to comment
nykkole Posted January 16, 2020 Share Posted January 16, 2020 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. 9 Link to comment
+thebruce0 Posted January 16, 2020 Share Posted January 16, 2020 (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 Edited January 16, 2020 by thebruce0 6 1 Link to comment
+The A-Team Posted January 16, 2020 Share Posted January 16, 2020 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. 1 Link to comment
+The A-Team Posted January 16, 2020 Share Posted January 16, 2020 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. 1 Link to comment
+thebruce0 Posted January 16, 2020 Share Posted January 16, 2020 (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 January 16, 2020 by thebruce0 Link to comment
+31BMSG Posted January 17, 2020 Share Posted January 17, 2020 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. 1 Link to comment
+4cycle Posted January 17, 2020 Share Posted January 17, 2020 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 1 Link to comment
+thebruce0 Posted January 17, 2020 Share Posted January 17, 2020 (edited) 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 January 17, 2020 by thebruce0 1 Link to comment
+Viajero Perdido Posted January 17, 2020 Share Posted January 17, 2020 (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. 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 January 17, 2020 by Viajero Perdido 1 1 Link to comment
+CAVinoGal Posted January 17, 2020 Share Posted January 17, 2020 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. 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?? 1 Link to comment
+thebruce0 Posted January 17, 2020 Share Posted January 17, 2020 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. 1 Link to comment
+IceColdUK Posted January 17, 2020 Share Posted January 17, 2020 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
McKirni Posted January 17, 2020 Share Posted January 17, 2020 @Geocaching HQ: I think, you should "clean" then log-pictures, too. Because, there are sometimes final-coordinates in the exif-block ... Link to comment
+Boomshanka Posted January 17, 2020 Share Posted January 17, 2020 (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 January 17, 2020 by Boomshanka 1 Link to comment
+mustakorppi Posted January 17, 2020 Share Posted January 17, 2020 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. 2 Link to comment
+MartyBartfast Posted January 17, 2020 Share Posted January 17, 2020 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 ! Link to comment
+thebruce0 Posted January 17, 2020 Share Posted January 17, 2020 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. 1 Link to comment
+mustakorppi Posted January 17, 2020 Share Posted January 17, 2020 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. 1 Link to comment
+thebruce0 Posted January 17, 2020 Share Posted January 17, 2020 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. 1 Link to comment
+DoodleMaster Posted January 17, 2020 Share Posted January 17, 2020 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 Posted January 17, 2020 Share Posted January 17, 2020 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. 1 Link to comment
+The Lambs @ 9 Posted January 17, 2020 Share Posted January 17, 2020 (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 January 17, 2020 by The Lambs @ 9 Link to comment
+mustakorppi Posted January 17, 2020 Share Posted January 17, 2020 4 hours ago, thebruce0 said: stuff Dude... But also, wanna know how I know you just assumed something? Link to comment
+Boomshanka Posted January 17, 2020 Share Posted January 17, 2020 Looks like the three puzzles I had photo-related issues with are all now back up and working again Link to comment
+barefootjeff Posted January 17, 2020 Share Posted January 17, 2020 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
+mustakorppi Posted January 17, 2020 Share Posted January 17, 2020 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. 1 2 Link to comment
+thebruce0 Posted January 17, 2020 Share Posted January 17, 2020 (edited) 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 January 17, 2020 by thebruce0 1 Link to comment
+Boomshanka Posted January 17, 2020 Share Posted January 17, 2020 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? 1 Link to comment
Recommended Posts