8 comments

  1. Seifeldin AlKhedir says:

    Dear Mr.Carel
    I looking for same your topic, i have image but the some part metadata not existed because downloaded from Facebook, i want to know who first man uploaded it on faceback and take it by owns camera.
    Please can you help me?
    Kind regard
    Seifeldin AlKhedir
    saifeldinkhedir@gmail.com

    • Carl Seibert says:

      If, IF, the person who uploaded the image to Facebook put his or her name and copyright information on the photo in the appropriate IPTC fields, that information should still be on the image when you download it. The Creator and Copyright fields are the only ones that survive a trip through Facebook. If the original uploader did not fill in those fields, you’re pretty much out of luck. All the Exif and all the other IPTC fields will have been removed. Your best chance at finding anything out about such a picture is to try to find the picture with reverse image search, either through Google or TinEye. Of course, Facebook knows exactly who uploaded it. But they won’t tell you 🙁

  2. Carl Seibert says:

    I had a bit of a databse issue on this site and I had to restore a backup, taking the site back a couple days. In the process I destroyed a comment from reader JB on this post. So, I’m rescontructing it from the notification email the server sedns out when you post a comment. Apologies to JB!

    From JB:

    This is slightly an “aside” comment because it pertains only to website links uploaded to Facebook, of which pictures are a subset.

    Facebook has also been adding a parameter to HTTP GETs when users click on uploaded links. In other words, if I post a link to direct users to a photo gallery on my website, and another Facebook user clicks on it, a similar long encoded string is sent to my website along with their request. It looks like this:

    GET /GALLERY/index.php?cat=10&fbclid=IwAR3DDgRkLMZicMTiaqrF19qdmsr4MIMfncNIQ3qDMd9MJUSdWJ-taXtfb4A

    Everything after the “&” was added by FaceBook.

    It seems to be unique per user, and it seems to be static. In other words, if the same user connects a month from now, the encoded “fbclid” string will be the same.

    I don’t see how Facebook itself would benefit from doing this. Website owners might benefit from this because now they can determine how many hits came through the Facebook platform, and how many different IP addresses and web bowzers they have. If the website owner is a Facebook partner, then there could be some business collaboration based on that number. But it seems benign compared to Google, Akamai, and all the other H.Pylori Web Monsters out there.

    Some web developers complain about the added parameter because sometimes they write code that depends on the exact format of the URL passed to the server.

  3. Carl Seibert says:

    Indeed. It seems backwards to me, too.

    Whatever it is, Facebook is doing it openly. Which is either transparency or arrogance. Who knows….

  4. Michael H says:

    Looks like Facebook is stripping everything now. I’ve entered several fields into the metadata of .jpg files, and everything is being stripped during the upload. 🙁

    • Carl Seibert says:

      Yes. Sadly. Some people over on the IPTC list have noticed something going on as well. Not only does Facebook screw over content creators but their behavior just gets worse. What do you bet they refuse to communicate with anybody – stakeholders or journalists – about it? If I turn out to be too cynical about this, I’ll post back to gladly eat crow.

  5. David M says:

    Hi Carl,
    Thank you for your hard work. I’ve been researching metadata in images as a path for malware intrusion.
    This is one article: https://null-byte.wonderhowto.com/how-to/hacking-macos-hide-payloads-inside-photo-metadata-0196815/

    Like many, I’ve written my own image uploader and resizer and wanted to ensure that I’m not going to get something I didn’t ask for.
    So far, it appears that PHP’s GD library will ‘clean slate’ an image of much of the metadata. This means that the process is to upload the image, make a copy of it, delete the original and then work on the copy.

    Is it possible that Facebook is removing metadata for security reasons?

    • Carl Seibert says:

      Ah! It’s a feature, not a bug! Yes, GD strips metadata. In the midst of a raging epidemic of copyright infringement and mis/disinformation, this presents a significant problem for society, given that GD is used on a majority (granted, an ever-shrinking majority) of websites. When I last spoke with GD’s maintainer, he was aware of the issue and had roadmapped metadata support for a future release – presumably user-configurable, or defeatable for those who have special needs.

      That said, there is metadata and metadata. Programs that “strip” don’t necessarily strip every last bit of metadata. Too heavy a hand and the file won’t even open. That would be something to bear in mind in your endeavors. Checking with Exiftool or a hex editor might be in order to see what’s left over after a given program does its stripping.

      As I understand it, at this point, metadata payloads are only a supply vector into systems that are already compromised. So, not too frightening just yet.

      Of course, destroying the very data we mean to protect is a pretty blunt way to protect it. In short order I expect anti-virus/firewall programs to be able to inspect metadata on image files and detect potential threats. There aren’t that many places in a photo header to hide nasty payloads. This seems to me to be a door that’s only briefly open – until security measures slam it shut and hackers move on to their next brainstorm.

      Facebook makes revenue from trafficking in stolen content and misinformation. From its perspective, the term “security” may have an entirely different meaning than it might to the victims of those behaviors.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.