Facebook will use any open graph meta tags if present for the title, and image etc (eg, og:title). The facebook documentation for Open Graph Protocol explains this in more detail:
The Open Graph protocol defines four required properties:
og:title - The title of your object as it should appear within the graph, e.g., "The Rock".
og:type - The type of your object, e.g., "movie". See the complete list of supported types.
og:image - An image URL which should represent your object within the graph. The image must be at least 50px by 50px and have a maximum aspect ratio of 3:1.
og:url - The canonical URL of your object that will be used as its permanent ID in the graph, e.g., http://www.imdb.com/title/tt0117500/.
In addition, we've extended the basic meta data to add two required fields to connect your page with Facebook:
og:site_name - A human-readable name for your site, e.g., "IMDb".
fb:admins or fb:app_id - A comma-separated list of either Facebook user IDs or a Facebook Platform application ID that administers this page. It is valid to include both fb:admins and fb:app_id on your page.
It's also recommended that you include the following property as well as these multi-part properties.
og:description - A one to two sentence description of your page.
I'm not sure how they do it for pages lacking these tags. If you're trying to duplicate this functionality then this is no help, sorry. But if you're trying to ensure your pages show up in the Publisher as you want then maybe this will.
You can also use the facebook opengraph debugger, which will provide info about your preview as well as (super handy) update their cached link if you make changes. Otherwise you can make changes to a link you want to share and the changes will not show up for days:
https://developers.facebook.com/tools/debug
May 2015
http://mashable.com/2015/05/29/facebook-gif-support/
The first thing to keep in mind is that the feature works with GIF links, not GIF uploads. At least for now, attempting to upload your favorite GIF will not result in a usable, playable GIF on Facebook.
[...]
Services such as Giphy, Imgur, GFYcat and others are trying to make it easier to embed large GIFs all over the web
[...]
make sure you're using the full GIF url from Giphy or other GIF services.
April 2012 - Current Exploit uses the mobile text application to pass images
http://www.facebook.com/connect/uiserver.php?app_id=2915120374
&method=stream_publish
&redirect_uri=http://www.facebook.com
&from=SENDERID
&target_id=RECEIVERID
&action_links=[{"text":"Your Text Here",
"href":"http://www.blank.com/"}]
&attachment={'media':[{'type':'image',
'src':'animationurl',
'href':'anyurl'}],
'description':'LongDescription',
'properties':{'Anything':{'text':'Anything',
'href':'anyurl'}}}
The only thing really needed is the animationurl
, which needs to be a Facebook hosted image.
These are the ways that were previously possible
- Changing filename to GIF
- Changing file dimensions to around 120 px to bypass compression
- Changing header data or adding bytes (example the ending 3B in the GIF data) to the end of the file to bypass Facebook image tools
- Via Facebook FBML
- Via Facebook HMTL tags in notes
The first working way seems to be somehow sharing the currently available set of gifs on Facebook servers via tagging users in it. I have not seen any new GIFs appear apart from those that currently circle around.
The second utilizes an abuse of the Facebook API via a Facebook Application. The developer hid the GIFs in a video embed preview.
Now, assuming one were to figure it out, you would be banned... because this means the image upload system is flawed and dangerous code can be executed by being concealed in a GIF or picture. It seems that Facebook Photo Team will ensure that GIFs do not stay around anymore.
Nathaniel Roman
And previously in the old Facebook Dev Wiki some of this may have changed by now but the gist remains the same
Facebook Platform handles img tags in a special manner. When publishing a page, Facebook servers request any image URLs and then serves these images, rewriting the src attribute of all img tags using a *.facebook.com domain. This protects the privacy of Facebook's users and allows them to better control the quality of service of their images.
There are several reasons for the existence of the image cache:
- We need a way to ensure some degree of quality and uniformity in the images displayed on users' profiles (no animated images, no 50 MB images, etc.)
- We need to protect users' privacy and not allow malicious applications to extract information from image requests made directly from a viewing user's browser
- Probably most important to you, the image cache shields developers from the potentially enormous load of serving these images, putting the burden on Facebook's resources instead
And in the end as I have mentioned elsewhere
Also although not stated anywhere in the TOS,
By uploading a file you certify that you have the right to distribute this picture and that it does not violate the Terms of Service
So you may get a pat on the back for testing on a Test User Account but using an exploit (if found) on a personal account. I am certain you will end up seeing a termination of your account.
P.S. Don't think because that when you are browsing sites that Facebook Employees do not see this information. The moment an exploit is known publicly, in the same amount of time it will be shut down
Best Answer
If the photo has been removed there will not be a way to trace back to the ID (that's a good thing in terms of privacy)
https://www.facebook.com/photo.php?fbid=10155011880340063&set=gm.891218424251397&type=1&theater
broken down is
fbid=10155011880340063
The Photo IDgm.891218424251397
The Group Permalink Post ID associated with itWithout the UID or Group ID it will be difficult to impossible to trace back the user who posted this.