Jump to content

EXIF data should be removed


one.man

Recommended Posts

All EXIF data should be removed from all uploadet to the log photos.

It is necessary because it is one way of cheating while puzzle solving.

 

Players do some photo of the logbook or some stuff around the cache (not spoiler photo)

but with geotag from EXIF data puzzle is simply compromised.

 

It is not fair, that the D5 puzzle is "solved" because of photo in the log.

Cache owner has no control of that situation.

 

Another argument is: EXIF data are part of privacy and are automatically removed in most web sites (except photo sites) and in all messengers.

Link to comment

All EXIF data should be removed from all uploadet to the log photos.

It is necessary because it is one way of cheating while puzzle solving.

But some puzzles use the EXIF data as part of the puzzle solution

 

It is not fair, that the D5 puzzle is "solved" because of photo in the log.

Cache owner has no control of that situation.

 

The CO can delete any pictures if they think it gives away the puzzle.

Link to comment

 

The CO can delete any pictures if they think it gives away the puzzle.

 

Not a good idea as the watchers will receive a notification that contains the link to the deleted photo. This typically will alert much more people

than keeping a photo with exif information or asking the logger to delete it.

 

If immediate action is aimed for, then rather rigourously delete the entire log and ask the person to relog without photo.

Edited by cezanne
Link to comment

Not a good idea as the watchers will receive a notification that contains the link to the deleted photo.

You information is misleading/inaccurate. I just tried it, and no trace of the image can be seen or viewed once the image is deleted per the Help Center article that I linked to. The link in the email notification from a Watchlist gives a link to the Log Entry. If the associated image has been deleted, there is no trace of it.

Edited by Touchstone
Link to comment

Regarding caches that are demanding or of high difficulty or seem unsolvable, many watchers interested in such caches are curious and monitor everything new on the listing page. No owner can be faster and remove pictures including coordinates or other spoilers before watchers also get a chance to see the spoiler. And even more people have notifications for Reviewer Notes in their homezone and notice such deletions.

 

And although links to photos are not included in gpx they are delivered when cache descriptions are saved from the website or 'updated' in GSAK and apps and stay there regardless of any owner action and get lost only when the saved content is lost for some reason.

 

Deleting a spoiler photo only deletes the link to it and everybody who had downloaded the link and not noticed the spoiler in the picture before deletion still has the link and can access the 'deleted' photo until the program/app is asked to run an update for logs/cache pages.

 

Some years ago, at least in 2012, the note accompanying image deletion had also the link to the image in it, at some point this was changed and the link is no longer included.

 

"relaxx01 posted a reviewer note for Hofburg Palace (Traditional Cache) at 5/11/2012

...

Reason for deletion: Spoiler

Image link: http://img.geocaching.com/cache/log/large/ ...

...

Visit this log entry at the below address:

http://coord.info/GL ...."

 

This picture is still available in 2016, but as this is a traditional, it doesn't matter whether coordinates are included, it is actually showing the container.

Link to comment

Not a good idea as the watchers will receive a notification that contains the link to the deleted photo.

You information is misleading/inaccurate. I just tried it, and no trace of the image can be seen or viewed once the image is deleted per the Help Center article that I linked to. The link in the email notification from a Watchlist gives a link to the Log Entry. If the associated image has been deleted, there is no trace of it.

 

Ok, then they have changed it meanwhile. The issue that still remains is the one mentioned by AnnaMoritz.

 

My message was and that's true anyway (and I can provide many examples that proof it):

Deleting spoiler pictures (in such cases like the exif example) can be more dangerous than doing nothing or waiting a bit until the logger acts directly.

Link to comment

For multis and ? even without coordinates and even worse are spoiler images that show that a cache is placed near a spot nearly everybody knows or where place information can be seen on signs.

 

Like prominent sightseeing sites, memorials, nearby street signs, prominent summit crosses or rock formations, bridges, cave entrances with their reference numers shown ...

Link to comment

For the purposes of this discussion, more examples would be useful.

 

I do not think that anyone will point out caches in public where such incidents happened that made it possible for cachers to circumvent the cache stages and or involved puzzles.

There are a number of incidents where deleting spoiler pictures has attracted more attention than the alternative actions I mentioned would have created.

 

In any case it's preferrable however if no spoiler pictures get posted but that's not under our control.

Link to comment

All EXIF data should be removed from all uploadet to the log photos.

It is necessary because it is one way of cheating while puzzle solving.

But some puzzles use the EXIF data as part of the puzzle solution

I've never seen a puzzle solution intentionally hidden in a log photo. I can imagine it being done, of course, but I don't think the need to allow it holds a candle to the impact of the stated problem. I don't actually know the numbers, but I think it's reasonable to guess that more and more innocent pictures are being tagged with coordinates without the person taking and posting the picture having any idea it's happening.

 

As it happens, I'm neutral about the OP's proposal, but I don't think it's remotely reasonable to say that a good or equivalent solution is for COs to continually monitor all pictures posted and delete any with revealing EXIF information.

Link to comment

A disengenuous post I think, as AnnaMoritz has clearly demonstrated that it's very simple to cite examples without being explicit. If you care not to engage in the conversation, you can always state so.

 

Well, AnnaMoritz keeps records of such incidents. I don't. I do not even keep coordinates of the caches I visited. I'm completely disorganized. I do not use any database, do not use watch lists, I'm not a PM etc. I only can use my memory and the only links I can provide are to caches that still have an issue. However AnnaMoritz and myself cache in the same country and it's the same sort of incidents we know about.

 

BTW: I happen to know a number of caches where the owners uploaded spoiler photos which contained the coordinates without knowing this and of course it has been exploited within minutes both for challenging mystery caches as well as for multi caches which cover quite a long distance (for this cache the first finder exploited this

https://www.geocaching.com/geocache/GC2Y7QZ_motor-biking-in-styria-9-rug but after his find informed the cache owner without making it public what he has exploited).

Edited by cezanne
Link to comment

As I see it, if someone is going to look at images posted in logs for EXIF information that might reveal the actual location of a cache, they're not interested in solving the puzzle, but just want the coordinates so that they can find the cache. They're probably not going to hesitate using a phone-a-friend network to ask someone just to hand them the final coordinates, or look at various puzzle solution sites which have coordinates, or some other group that "helps" people solve puzzles. There's nothing a CO can do to prevent that from happening either.

 

The only thing that a CO can really do is request that finders of the cache not post photos taken at the cache location, and if someone does it anyway, there really isn't anything that they can do other than deleting the photo.

 

 

Link to comment

All EXIF data should be removed from all uploadet to the log photos.

It is necessary because it is one way of cheating while puzzle solving.

But some puzzles use the EXIF data as part of the puzzle solution

I've never seen a puzzle solution intentionally hidden in a log photo. I can imagine it being done, of course, but I don't think the need to allow it holds a candle to the impact of the stated problem. I don't actually know the numbers, but I think it's reasonable to guess that more and more innocent pictures are being tagged with coordinates without the person taking and posting the picture having any idea it's happening.

 

As it happens, I'm neutral about the OP's proposal, but I don't think it's remotely reasonable to say that a good or equivalent solution is for COs to continually monitor all pictures posted and delete any with revealing EXIF information.

 

Actually your first point occured to me shortly after I'd posted, but I decided to let the post stand as it's certainly possible, and I suspect the same bit of code is being used to upload log photos as is used to upload photos to the cache page.

 

I'm also neutral about the concept, but I think that there are far too many other things that need fixing or developing before coding time is devoted to this idea.

Link to comment

As I see it, if someone is going to look at images posted in logs for EXIF information that might reveal the actual location of a cache, they're not interested in solving the puzzle, but just want the coordinates so that they can find the cache. They're probably not going to hesitate using a phone-a-friend network to ask someone just to hand them the final coordinates, or look at various puzzle solution sites which have coordinates, or some other group that "helps" people solve puzzles.

 

For long multi caches the number of cachers who is willing to share final coordinates is considerably smaller than for puzzle caches. The majority of those who happen to post photos with exif information for such caches do it without knowing that their photos contain coordinates. That makes a huge difference to puzzle caches and the situations you describe above.

Link to comment

All EXIF data should be removed from all uploadet to the log photos.

It is necessary because it is one way of cheating while puzzle solving.

But some puzzles use the EXIF data as part of the puzzle solution

 

 

They could allow it on cache pages but strip it off for photos uploaded to cache logs (or alternatively cache logs not from the owner).

Link to comment

 

They could allow it on cache pages but strip it off for photos uploaded to cache logs (or alternatively cache logs not from the owner).

 

Yes they could, but all that takes more coding effort, and I don't think it's worth doing and there are many more problems deserving of that effort. You may disagree, and I expect others do too, but I think it's worth stating an opposing view to the OP.

Link to comment

 

They could allow it on cache pages but strip it off for photos uploaded to cache logs (or alternatively cache logs not from the owner).

 

Yes they could, but all that takes more coding effort, and I don't think it's worth doing and there are many more problems deserving of that effort. You may disagree, and I expect others do too, but I think it's worth stating an opposing view to the OP.

 

Actually, I think that such things are much more worth the coding effort than all the visual changes we have seen implemented over the last years.

Link to comment

The policy regarding EXIF data has been quietly flipped back and forth several times over the years. While it's currently left intact, there have been several periods where EXIF data was silently being stripped without any notice.

 

Personally, I don't have a strong preference either way. I always strip EXIF data myself if uploading a photo from my iPhone to a log on a puzzle/multi/etc. However, whichever way it works, users should know what to expect. If EXIF data is going to be left intact, there should be warnings on the image upload page indicating as such and reminding users that images from some devices may be geo-tagged with the location. If EXIF data is going to be stripped, there should be warnings on the image upload page indicating as such so users can prepare accordingly for the loss of data.

Link to comment

All EXIF data should be removed from all uploadet to the log photos.

It is necessary because it is one way of cheating while puzzle solving.

But some puzzles use the EXIF data as part of the puzzle solution

Those puzzles are only "one of thousands"

You can use the external link for your photo with stored EXIF data to insert that link into your cache description.

 

It is not fair, that the D5 puzzle is "solved" because of photo in the log.

Cache owner has no control of that situation.

 

The CO can delete any pictures if they think it gives away the puzzle.

It is a monkey business to delete the photos..

Moreover CO do not receive new notofications about adding new photos to the log - the photos are uploadet often after some time after the text log (no notifications about the log after the first one is another annoying drawback of official website)

Link to comment

It is a delayed reaction - CO is not a watchdog to check and postmoderate all the photo..

Correct. Even more so given that the CO is not even notified when a photo is added to a log.

 

In my opinion, EXIF data (at the very least, location data) should always be stripped from log photos.

 

Images in the cache description shouldn't be touched (EXIF data is a valid thing to use in a puzzle, after all) but for logs? I can't see it ever being necessary there.

 

If there is a use case for it, the log can always be hosted elsewhere and referenced with a link....

 

[edited because words put I cannot order in the right]

Edited by EngPhil
Link to comment

Cache owner has no control of that situation.

 

Link for reference:

 

How to delete a spoiler image.

 

It is not a control.

It is a delayed reaction - CO is not a watchdog to check and postmoderate all the photo..

 

Ummm...Yes, they are. From the Guidelines:

 

As the owner of your cache listing, your responsibility includes quality control of all posts to the cache listing. Delete any logs that appear to be bogus, counterfeit, off-topic or otherwise inappropriate.

 

If a cache owner can't/won't fulfill these basic duties, they either have too many Listings to manage, or aren't really cut out for the job.

 

I'm not really disagreeing with the premise of the topic, I'm just not convinced by the various arguments supporting the change. Social media plays a much bigger role with this issue IMO.

Link to comment

If a cache owner can't/won't fulfill these basic duties, they either have too many Listings to manage, or aren't really cut out for the job.

 

it's pretty unrealistic to expect any cache owner to constantly watch all their caches for newly uploaded photos.

 

I sometimes upload photos months after having written my logs and sometimes I do that in several runs. So maybe 5 photos for a cache on May 1, another 5 a month later etc.

 

 

I'm not really disagreeing with the premise of the topic, I'm just not convinced by the various arguments supporting the change. Social media plays a much bigger role with this issue IMO.

 

Actually, there hs been a back and forth change anyhow. Sometimes exif was stripped off without warning, right now it is kept in the file but with no warning to those uploading photos and having no at idea at all that their Iphones (just an example) include coordinates into the photos and that these are kept in the uploaded photos. With the increase in smartphone cachers who are not technology affine, we experience an increase in the number of spoilers which end up on the site without any intention.

 

It's not the same to encounter spoiler pictures on a social media site and directly on the cache page.

Link to comment

it's pretty unrealistic to expect any cache owner to constantly watch all their caches for newly uploaded photos.

 

A fairly simple solution then, which is supported by the TOU, is to request on the Listing page, that no *spoiler* photos be loaded to the Listing page. Seems like a pretty simple task to periodically check the photo gallery on the page to assure compliance. Or at least, sounds easier than replacing a logbook or container at any rate.

Link to comment

it's pretty unrealistic to expect any cache owner to constantly watch all their caches for newly uploaded photos.

 

A fairly simple solution then, which is supported by the TOU, is to request on the Listing page, that no *spoiler* photos be loaded to the Listing page. Seems like a pretty simple task to periodically check the photo gallery on the page to assure compliance. Or at least, sounds easier than replacing a logbook or container at any rate.

 

With exif data the problem is that many cachers are not aware that what might seem harmless to them is a spoiler.

When browsing through the gallery of my caches, I also do not become aware of such issues. I would need to apply an exif reader to each photo individually.

Link to comment

 

Ummm...Yes, they are. From the Guidelines:

 

As the owner of your cache listing, your responsibility includes quality control of all posts to the cache listing. Delete any logs that appear to be bogus, counterfeit, off-topic or otherwise inappropriate.

 

If a cache owner can't/won't fulfill these basic duties, they either have too many Listings to manage, or aren't really cut out for the job.

 

Then why not notify owners immediately when pictures are uploaded or logs are changed?

No owner can look continously whether something was uploaded or changed.

 

And why not rethink Reviewer Notes for deleting logs/pictures? Why notify all watchers and everybody who has notifications on Reviewer Notes? Isn't it sufficient to send a notifation only to the cacher who is affected by deletions?

 

When only 10% are caches where photos containing GPS-data can spoil a final, this might be no big problem, but in areas with many (demanding) Multis and Unknowns spoiling by providing coordinates in photos can ruin the game and is a bigger problem.

 

At least remind cachers to remove EXIF-data (and visible parts) that give away to much information when pictures are uploaded.

Link to comment

I'm assuming you can make the distinction between periodic vs continuous. If someone is that concerned that a periodic check wouldn't suffice, perhaps the puzzle concept needs a more rigorous treatment to withstand such an elementary hack.

 

Maybe an alternative approach would be for cache owners to have the ability to toggle on/off the gallery option to their listing page. Removing the ability to post all photos would seem to be the most secure method to defeat this issue.

Link to comment

I'm assuming you can make the distinction between periodic vs continuous. If someone is that concerned that a periodic check wouldn't suffice, perhaps the puzzle concept needs a more rigorous treatment to withstand such an elementary hack.

 

The issue affects longer multi caches at least as much than puzzle caches and so it is not a question of puzzle design. It's extremely annoying if people can obtain the final of a say 500km hiking cache by looking at a photo which has been posted by someone who did not even do it intentionally.

 

Moreover, the unfortunate situation that photo deletions alert people who should not be alerted remains an issue regardless of which type of cache is affected.

Link to comment

Here's are two counter arguments for keeping EXIF data.

 

First, unless a cache page includes information on how long a multi will take, I am hesitant to start one. With EXIF information, I may be able to glean time/distance information for the cache. My personal integrity wouldn't allow me to 'cheat' in this manner, I would still complete the multi as it was originally intended. I did something similar with a local multi-cache, the photos included a few reference points. Using Google Earth, I was able to get an approximation of the final location. The length of the multi-cache was around 20 miles. Now I know.

 

The second argument has to do with finding a parking place. Knowing the general area of the final location will allow me to determine how I will approach the cache. In my above example, just plugging coordinates into the TomTom would have put me on a road that ran within a tenth of a mile of the cache. However, coming from that direction was dang near a 500' vertical cliff. On the other hand, parking half a mile away from GZ on a back country road is a much easier hike. It still has a couple of hundred feet of elevation change, but it was a hike I would have a better chance of completing without injury. It was also about 10 miles of driving to get from the location below the cliff, to the one above the cliff.

 

My suggestion is to allow the cache to be marked 'allow EXIF' or 'strip EXIF'? The CO would mark the cache as they desired, and the upload routine would act accordingly. Also, when uploading any picture, add a check box to the dialog to have the system strip the EXIF information.

 

Skye.

Link to comment

Long hiking caches mostly follow a very simple concept. The Owner wants geocachers to hike anlong the route and then find the cache, otherwise it would suffice to place a traditional at the final when the intention is to show the final only.

 

Think about a cache that requires 50 hours minimum (no puzzle). FTF writes a log. Owner reads the log and looks at the website every day for one week. Later once in a week. No other finds for a while, as this a demanding cache and FTF aready gone. Then FTF adds photo. Unnoticed by owner, but not unnoticed by others.

 

Can't happen? Happened. Third party tools alert for changed logs and added pictures (once a day), why can't Groudspeak do this also?

 

One of my caches had a GPS-tagged photo from the third or fourth finder on. If someone wants to skip a not too difficult puzzle that is not too far from the header, why not, if I know about the spoiler and don't delete it?

 

But why allow comprimising a 80km or 500km hiking cache by a single unthinking geocacher that can't be bothered to be informed that their phone does geotagging where no coordinate sharing is going on, at least not until the first person linked to coordinate sharing manages to find the cache?

 

Especially for really long multis toggling on/off the gallery seems not very useful because owner, finder and watchers typically enjoy pictures made on the hike.

 

Deleting coordinate information when pictures are uploaded, allow toggling on/off pictures, let owners 'unlock' entries for their caches, remove Reviewer Notes for deletions, alert owners of log changes and photo uploads - there would be a lot that can be done.

 

None of this of course has priority where caching is mostly about finding short and easy caches with convenient parking lots and where kayaking/climbing/diving caches are 'protected' by their environment anyway, regardless of spoilers.

 

But even without multis and ? there are owners everywhere that are not amused seeing their tricky hides and elaborate containers given away in the gallery.

Edited by AnnaMoritz
Link to comment

Maybe an alternative approach would be for cache owners to have the ability to toggle on/off the gallery option to their listing page. Removing the ability to post all photos would seem to be the most secure method to defeat this issue.

 

The gallery is a nice feature and in particular for hiking caches.

It would make sense to allow cache owners to set up their preferences whether and how often they want to be notified about newly uploaded photos.

That would be a feature (often demanded, but never implemented) that would be helpful also in a much wider context than exif, spoilers etc

 

If photos get uploaded months after a log many cache owners will miss them and that could be a loss also in case of 100% harmless but nice photos.

Link to comment

After thinking about it some more, I think EXIF data needs to be stripped from images. Here's why:

  • The forum regulars know how long it takes for requested features to materialize, if ever. The ideal situation would be preferences on each cache, notification of uploaded images, etc., but I think we all know these are unlikely to be implemented anytime soon. However, as has been demonstrated in the past, the functionality to strip EXIF data is already in place and simply needs to be turned on. In addition, with the CDN they're now using for images, it may be a setting they could easily turn on with that service (it already automatically resizes images).
  • With the smartphone apps being pushed so heavily and Geocaching.com sculpting the site to cater to those users, there has already been an increase in the number of photos uploaded from smartphones, and this will only continue to increase. With this higher probability of a geotagged spoiler photo being uploaded, the passive monitoring solutions will become less effective at catching problematic photos in time. Automatically stripping the EXIF data would reduce the probability of a geotagged spoiler photo to zero.

Link to comment

We just had two photos deleted as we had inadvertently posted geotagged pics from around GZ, pics didn't spoil the hide themselves, but the geotag would have. No problem to us, I've edited the geotag and re-uploaded them - I had actually thought the geotags were being stripped, as in the past I've tried looking at photos in logs around GZ, hoping for a 'hint', but never found any..... Maybe those finders had been more careful than we were...

Anyway, the makers of 'EXIF editor' just sold a piece of software.....

 

Maybe Groundspeak/GC could make it more interesting and allow COs to edit the geotags of log photos, drop in some red herrings for the unscrupulous??

Link to comment

The log deletion notice that goes out to watchers NO LONGER includes a link to the image.

The link in the watchlist email is to the log. The log, which is the explanation of the image deletion, posts as a Reviewer Note, under the cache owner account. That log is auto-archived.

 

I did some experimenting with deleting an image, using my Premium account to post a log and an image to a cache that my Basic Member account owns, watchlisting that cache.

Edited by Isonzo Karst
Link to comment

It seems to me that the thread is about exif information embedded in photos on logs of puzzle caches. The log is the property and responsibility of the log's author. Generally logging a puzzle cache has the expectation that the puzzle solution is not revealed. Clearly the geocaching.com site must not transmit puzzle solutions; either knowingly or unknowingly.

 

The log with exif in a photo is placed by the author who either (A.) knows that the exif information is there and is posting the information knowingly, or (B.) is not aware of the exif information and posts it without knowing it. There are no other possibilities. In case B., stripping the exif information is consistent with what the log author intends. In case A, the log author either (A.1) has malicious intent to compromise the puzzle or (A.2) does not have malicious intent. In case of A.2. stripping the exif takes nothing away from the log author because the log author can post coordinates explicitly, either in the log text or as a feature of the log or both. This is out in the open where any cache owner can deal with it.

 

In case A.1 stripping the exif makes good sense for sake of the game. In fact, failure to strip in case A.1 makes the website a facilitator of the malicious intent, because they actually delivering it to persons who should not have it. It is relevant that exif can contain much more than just coordinates and I would say that all exif should be stripped.

 

It is relevant also that stripping does not have to happen during upload (which was presented as the solution). What is necessary is that stripping happen when the log photo is delivered to anyone other than the log author or cache owner. It makes sense to us that having it happen during upload is a lot simpler than doing it every time a photo is delivered. But there are many examples here where this sort of logic is not used.

Link to comment

Bumping this thread due to recent discussion on the "Geocaching Discussion" forum.

 

I believe it would be a good enhancement to remove (or obscure by setting to 00 00.000) the location information on photos posted on logs. So to not result in the current situation where the final coordinates (for a puzzle/multi/etc) can be included when a photo near GZ is posted in a log.

Link to comment

It seems to me that the thread is about exif information embedded in photos on logs of puzzle caches. The log is the property and responsibility of the log's author. Generally logging a puzzle cache has the expectation that the puzzle solution is not revealed. Clearly the geocaching.com site must not transmit puzzle solutions; either knowingly or unknowingly.

 

The log with exif in a photo is placed by the author who either (A.) knows that the exif information is there and is posting the information knowingly, or (B.) is not aware of the exif information and posts it without knowing it. There are no other possibilities. In case B., stripping the exif information is consistent with what the log author intends. In case A, the log author either (A.1) has malicious intent to compromise the puzzle or (A.2) does not have malicious intent. In case of A.2. stripping the exif takes nothing away from the log author because the log author can post coordinates explicitly, either in the log text or as a feature of the log or both. This is out in the open where any cache owner can deal with it.

 

In case A.1 stripping the exif makes good sense for sake of the game. In fact, failure to strip in case A.1 makes the website a facilitator of the malicious intent, because they actually delivering it to persons who should not have it. It is relevant that exif can contain much more than just coordinates and I would say that all exif should be stripped.

 

It is relevant also that stripping does not have to happen during upload (which was presented as the solution). What is necessary is that stripping happen when the log photo is delivered to anyone other than the log author or cache owner. It makes sense to us that having it happen during upload is a lot simpler than doing it every time a photo is delivered. But there are many examples here where this sort of logic is not used.

 

This seems to cover it nicely :)

Link to comment

This seems to cover it nicely :)

Except for points being made elsewhere that location information could be used for other guides, without being a spoiler, such as access points, parking, or general perception of cache length/requirements.

Of course, those are all outside the intent of the cache owner, with a user making use of another user's potentially unintended info. However, point being that GPS location in images isn't always a cache spoiler and can have some beneficial use.

 

All that to say, I'd still prefer exif data be stripped on upload along with the auto-resizing :)

 

A fairly simple solution then, which is supported by the TOU, is to request on the Listing page, that no *spoiler* photos be loaded to the Listing page. Seems like a pretty simple task to periodically check the photo gallery on the page to assure compliance. Or at least, sounds easier than replacing a logbook or container at any rate.

A photo of beautiful weather near GZ may not be considered a spoiler photo, if the uploader doesn't realize that GPS location or EXIF data itself may be a spoiler. Most people see "spoiler" and think visual content only.

 

Personally, I don't have a strong preference either way. I always strip EXIF data myself if uploading a photo from my iPhone to a log on a puzzle/multi/etc. However, whichever way it works, users should know what to expect. If EXIF data is going to be left intact, there should be warnings on the image upload page indicating as such and reminding users that images from some devices may be geo-tagged with the location. If EXIF data is going to be stripped, there should be warnings on the image upload page indicating as such so users can prepare accordingly for the loss of data.

A few suggestions have been provided, but I do think one of the better ones is to provide an option for the uploader. It can default to "Off" (strip the EXIF or GPS-specific data), but if the user wants to keep the data they have that option.

Alternatively, an option for the owner to force-strip all EXIF data from log gallery uploads and not give loggers that option.

 

Or another option but one that I think would be great for maintenance with no change to the front end uploading user experience - on uploading, flag it if the image has exif/gps data. If you're the owner and viewing the gallery it can indicate images that have EXIF or GPS locations. Then you can easily see the images and decide whether one needs to be deleted, without having to manually check every potential spoiler image.

 

This way no exif stripping has to be added on the backend during upload, just add a checker and a flag that is indicated on the owner's view of a gallery. (the only downfall is that images with spoiler coordinates can still be seen if a watcher is faster than the owner at 'clean up')

 

The only way to guarantee that no one ever has a chance to see spoiler GPS info is for the owner to require EXIF stripping on log image uploading.

Link to comment

I would prefer to have the same function I get from my paid membership at project-gc.com -- warn me when a photo is added to one of my caches with location data. That way I can determine whether it needs to go or not.

There's at least one extension for Chrome that shows EXIF by hovering a mouse over a web page photo. If I can devine that a photo has been uploaded :yikes:, that's a way to at least do a quick check.

 

Having a button for the CO to kill (or change!) the Coordinates line inside the EXIF would be handy. Maybe for all of a particular cache's logs upon upload and by default for Puzzles or Mysteries. The photo may be fine, the spoiler is not.

 

It's a complicated issue, since most people (even COs) don't even know a photo can provide a spoiler waypoint, or they don't realize their camera App's "No EXIF GPS" setting got changed to "Yes EXIF GPS", etc. Or they know the site strips all EXIF -- well, that it once did but today it doesn't... they didn't know that. Cache Owners may want to make a puzzle that uses EXIF, or make red herrings or whatever, a plan which would then be spoiled if EXIF is always stripped away.

Edited by kunarion
Link to comment
I would prefer to have the same function I get from my paid membership at project-gc.com -- warn me when a photo is added to one of my caches with location data. That way I can determine whether it needs to go or not.
This would be a nice addition to a notification system for cache owners when photos are posted to their caches.

 

For the process of posting photos, I think a balanced approach would be to include an option for whether to strip EXIF data, with the default being to strip it. That way, it could be left in when appropriate, but that would take conscious action on the part of the poster.

Link to comment

I just solved a puzzle GC3HQ7Z and took a picture of the log to prove that I was there. I used the web site to do the log, and I was horrified to see that I just posted the corrected coordinates in bold, coloured font. I was sure that this issue had been discussed before, and the conclusion was that there was never any good reason to keep the coordinates on uploaded photos, let alone display them boldly.

Now I have to figure out how to post my photo without the coordinates.

Link to comment

I just solved a puzzle GC3HQ7Z and took a picture of the log to prove that I was there. I used the web site to do the log, and I was horrified to see that I just posted the corrected coordinates in bold, coloured font.

It sounds like you're describing the "Add a coordinate to this log" function, but that function is completely separate from the EXIF location data in photos. Uploading a geotagged photo shouldn't add the other setting unless you're using some 3rd-party tool that happens to do just that.

 

I'm assuming you've already edited your log, because I don't see the coordinates anywhere and the image that's attached doesn't have any location data.

Link to comment

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...
×
×
  • Create New...