We could use a tool to highlight different dates between observations and image EXIF data

I’ve been reviewing CNC observations (no particular locality) and a trend that has become apparent this year, now that finally casual observations are excluded, is observations with a falsified date, changed from what the EXIF on the images says to fit within the CNC time frame.

I’ve come across both ends of the spectrum: people uploading photos taken in the past (up to 6 or 7 years ago) and creating observations with a date within this year’s CNC, and people continuing to take new observations and uploading fresh photos from as much as 10 days after the CNC, with the date changed to fall within the allowed time frame.

It would be great to have a tool to search for images in, say, a CNC project, to find ones where the EXIF data on the main image and the observation date differ by more than a certain period, for example 24h.

Not all of these would be a case of data falsification, but it would really help to be able to search for them, rather than manually opening the image info page for each observation and comparing the dates.

Given the breadth of talent we have here, someone’s probably already developed something like this, if not, it would be a worthwhile tool to have for curation, if anyone is looking for a project.

Thanks for confirming, that this “ideas” were used. I had the same impression from the daily new uploads made after CNC field work had closed.

I can’t help with a tool, but I do have a second wish, which could perhaps be added. O:)

Perhaps it is possible to integrate a function, to search for identical pictures used by different users? As I understood, the “interaction with nature” should be personally from each user. If not, please correct me.

i don’t think this is possible, but it might be possible to show the EXIF date and some sort of indicator when it differs a lot on the observation photo, in a way that is similar to this:

Just noting that I have also seen this behavior (posting photos with false dates to meet the inclusion criteria for CNC) this year, and I can’t remember it from years past (at least not multiples).

I will also note that, as far as moderation goes, while it’s not explicitly listed/itemized under the Community Guidelines, adding observations with intentionally false dates/locations is a “suspendable offense.” So if a user continues to do this after being warned, they can/should be suspended.

“We expect you to submit information that you believe is an accurate assessment of the evidence provided, and not intentionally false.”

A tool like the extension above would help to some extent as it would at least not require the additional clicks to the photo pages.

I find that sometimes users will upload photos of the same species (or what they believe to be the same species) from multiple dates or times in one observation, either because they misunderstand what observations are supposed to represent or because the photos were in the same folder and they conflated multiple days without noticing.

A tool like this would make it somewhat easier identify such cases and sort out which photos belong together (I often leave a comment indicating which photos need to be changed because observers seem more likely to fix observations correctly if I do so, and it is rather tedious to check each photo timestamp when I have to click back and forth between the observation page and the photo info)

But users may just forget to adjust the date and time of their camera.

Time, if it is off by a few hours, is a common mistake/issue with time zones. Random numbers of days off seems very unlikely, and vanishingly so when the image comes from a smartphone which should have a correct date pretty much all the time.

Having different dates is often legitimate for collected specimens. The date of observation is not necessarily the date on which the photographs were taken. I sometimes photograph collected specimens days or even years after they were collected, for example, https://www.inaturalist.org/observations/358153830, but I set the observation date to the date collected. Also, cameras very commonly have incorrect dates set which must be manually corrected when uploading to iNaturalist. Shouldn’t we be trusting that our users are acting in good faith rather than trying to police them (and potentially driving them off the platform)?

I’m willing to give a non-app user a lot more benefit of doubt on this than an app user since it takes significantly more effort and knowledge to take a photo with a camera (even a point-and-shoot) and upload it in the browser than it does to take photos with your phone (which should automatically have the correct date) and upload it in one of the apps.

That’s a good point.

Yes, there can be a variety of reasons why times might differ and it’s not deliberate data falsification.

The particular cases I am dealing with are clear. Some observations have the correct date and time, others, photographed with the same device, do not.

Same, I’ve come across hundreds (maybe thousands) of images with seemingly falsified dates set during this year’s CNC window. The instances in which I am generally ignoring these discrepancies are:

  1. it seems like the user’s camera just has the wrong date set (e.g., their photos dated May 1 have EXIF showing April 1, and photos dated May 2 have EXIF showing April 2, etc, etc)

  2. anything post-processed in Photoshop or similar, since I believe that the EXIF data shows the edit date, not the shoot date

  3. observations with a “time of observation” that’s not either blank or 12:00 AM

  4. anything with an observation date outside the CNC timeframe, since that seems (to me) to be the genesis of most of this

IMO the situations you described are totally understandable, good faith mistakes, and are fairly easy to discern from some of the more problematic behavior we have been seeing. It is harder to assume good faith when we are talking about users (some experienced) uploading photos from months and years prior to CNC, and/or after CNC, but dating all of them during CNC. And in at least one instance, this behavior seems to have spread from a CNC project admin to many of their project participants, which has resulted in a small mountain of bad data and a lot of manual cleanup work. It would be helpful to have a tool to speed up this work.

Edit - Among other reasons, I think it’s important to rectify this because if one goal of CNC is to help monitor climate-change driven shifts (e.g., bloom times, migration patterns/timing), a slew of observations with falsified dates will skew that data.


In my plugin I actually introduced that already: The time difference between the picture EXIF data and the observation time is shown (after the :twelve_o_clock: emoji).

In theory, I could also display this information in the explore/identify tab on the individual observations (say the maximal time difference between all the pictures).

For the purposes of assessing intentionally incorrect times, it would probably be more useful to show the specific dates and times (e.g., so users can easily assess whether the image was altered to be in the CNC “window” or any other specific date/time range). But this would definitely help as a first pass to see if there is a large discrepancy.

I really like this, but my work would never whitelist a browser extension for me. Sadly.

While I agree that some users may have legitimate reasons to provide a different date of observation in certain circumstances, I’ll stick to the actual intent/context of this post.

We need a tool for sure that can quickly display the EXIF data. Perhaps there’s something in what Tony Rebelo posted here a while ago- use of AI!

I like the browser extension too, that is simpler. There may be a catch however, and I’ll use this screenshot of a recent CNC observation to demonstrate the potential complexity (nothing directly identifiable there I think, and I’ve blurred out the ‘artist’ bit too just to be sure):

I’ll post one example of my own observation made from a phone:

Any tool that reads metadata needs to potentially look at several different dates- one is the date of observation provided by the user, and then the three from EXIF. From what some of us have seen during this CNC, these dates can often vary depending on software/app used for editing, image processing techniques, how users transfer or share images, when they were ‘digitized’, image format, etc.

More often than not, all these dates match, especially when smartphones are used. But here are legitimate observations where they don’t. I know why mine shows a different ‘Date time’ at the top, that’s because I tend to upload observations months after I made them; those dates would have all matched if I hadn’t used Lightroom.

What I’ve gathered is that ‘Date/time Original’ is the one to look for, when available. The other dates can vary based on other factors. Needless to say, all this is possible only when full EXIF data is available.

Yes. My extension primarily fetches DateTimeOriginal (according to spec for when the photo was actually taken) and falls back to DateTimeDigitized (for when an analog photo was digitized) and DateTime (for when the file was modified) if not present (or in a different order, have to look later).

That said, any tool can just aid in discovering potential frauds, but further investigation into the EXIF data has to be done anyways to be sure.
So I think looking at DateTimeOriginal (or as fallbacks the others) should be sufficient.

The only other potentially useful piece of evidence is if DateTime < DateTimeOriginal/Digitized, which would hint at a doctored file, because a file for a photo can only be created after it has been taken, obviously.

Perfect. And thank you for working on this extension. I will try it for a few days, and report back.

And what you said about any tool only being an aid is absolutely true.

I’ve installed the extension, and it works as designed. Thanks again for working on this.

One thing we noticed during this CNC, and this was actually a bit of a giveaway that date/time was potentially falsified, was the absence of user-submitted time altogether. When one manually alters date/time, some users added a new date but not the time. And so, we’d just see an abridged date ‘Apr 24, 2026’ and that made us dig deeper into that observation/observer.

On the extension, this still shows up as -0s on the timer even if there’s full EXIF available inside. And that makes sense as there’s no time to compare with. I know your original intent of displaying EXIF was different, but would it be possible to display the actual date/time that it reads from the EXIF? Perhaps in place of image resolution/dimensions? Or add a set of selections in the settings?

I looked through the settings, and apologies if I’ve missed something obvious.

Thanks, thanks.

(I’ve read the comments under the main thread for the extension)