Facebook photo get parameters and photo available for how long

Question

When I request a photo from Facebook, some urls are like this:

https://{hidden_for_privacy}79141548_n.jpg

And others are like this:

https://{hidden_for_privacy}23364315_n.jpg?oh=c566c56ca9fd7eb1ed5d8bfca4255e84&oe=544AF123&__gda__=1414682395_6d2cb778f5b2c857d1be1c781e81cdfa

The second one has a few extra GET parameters (oh, oe and __gda_ _ (space is there to prevent bold).

When these parameters exist, the image will be invalid after a few days because those values will be different (you can check this by doing a new API call to get the same photo).

What do these parameters mean and how are they linked to the maximum timeframe?

Thanks!

Answer 1

I know some history and its purpose.

Originally facebook image url look like this
https://{*snipped*}/XXXXXXXXXXX_b.jpg
but there are more than on size of image available so people have access to thumbnail image can simply replace suffix _b with _n
(So now it is https://{*snipped*}/XXXXXXXXXXX_n.jpg)
to access to larger version of the image (if available).

Some time later facebook implements central image system that can dynamically crop and resize image on the fly upon request.
The url provided by facebook at this point of time may look like this:
https://{*snipped*}.fbcdn.net/hprofile-xxx1/v/t1.0-1/p32x32/12345678_123412341234123_4123412341234123412_n.jpg
And when people see the url their curiosity arise.

Let's try remove some parameter from the url.
https://{*snipped*}.fbcdn.net/hprofile-xxx1/v/12345678_123412341234123_4123412341234123412_n.jpg
And what they get is the largest and most complete version of the image they can possibly get from facebook server.

This method was working for a long time.
When people see image in their email (mostly profile picture) they can get complete version of image without even log into facebook.
It was working everywhere include private profile picture.

The quick fix and cheapest solution for facebook is to sign request path with some signature algorithm.
I guess they use HMAC as the core algorithm and derive HMAC input from various source including request path.
This will ensure that the only party who can generate valid url is the one who have HMAC key. (presumably just facebook)

Now old issue is fixed you can not use it anymore but there are more than one issue that can be fixed by adding MAC.

It is invalidation of access to images.
Let say people once publish their photo (now other can have both valid request path plus signed signature from facebook) and later on they change their mind and make the photo private.

However, people with valid url and signature can still fetch the image from facebook server.
To solve this issue with super cheap resource considered that they already implements HMAC calculation.
(And to obscure the fact that facebook does not actually delete your image from their system when you delete it.)
They decided to mix value derived from timestamp into input of HMAC.
(See RFC-6238 for similar usage)

So signature refreshing from facebook is periodically required to gain access to photo.
This solved the latter issue with very cheap additional resource.

And here you have it.
Some of history and rationale behind facebook's parameters.

I'm certain that there is no official document about the time frame but it should not be difficult to do some experiment yourself considered that now you know that the value of time frame you want is fixed and predictable.