The problem is that the random number is static. As Aegan says, anyone allowed to see a photo can leak its URL. It would be better if the URL would depend on the user to whom the picture is served. But that'd be expensive.
Sure, in practice there's not much of a difference, I'm nitpicking, but it's not exactly the same thing.
People might leak the URL unintentionally, for instance by sending the link to others, not knowing that the photo owner doesn't want them to see the photo.
One can also use URLs in places where images are not allowed, for example when submitting them to community websites, without first uploading the photo somewhere and leaving a trail.
Thomas, I agree with you on all points you've posted _except_ the difficulty of attacking the system. It cannot be a truly random number of "X" bits because it is used as a permanent unique identifier. If it was actually a random number, then you have the potential of overwriting files and/or reusing URLs/UIDs.
For every UID discovered, the entropy shrinks and the system becomes easier to attack. Of course, I'm not saying the shrinking entropy would make it feasible to attack the system, just easier. ;)
This is a great noodley point, but note that they can just increase the width of the identifier to maintain a constant threshold level of entropy. They won't, of course. But they could.
We can rest assured that facebook simply doesn't care about this non-issue of image access, so increasing the bit width is not worth their time, but assuming someone actually had this need, doing it right is a lot more complicated than it seems at first glance. --Again, this is admittedly another annoying "noodley point" but it could be important for someone.
ASSUMING: The systems are most likely run in virtual machines, and the UID's are most likely the keys for a key-value store. Whether or not the UID are specific to just images, or are also used for other things (wall posts or whatever) is unknown.
The first question is whether or not your key-value store can handle the increase in key length (UID). Since this is fixable, the safe assumption is "yes" albeit there might be undesirable (or even unsurmountable) performance penalties.
A good PRNG is fed by a system entropy pool, and the pool is populated by various system entropy sources. Some believe virtualization can make the system entropy pool more predictable, but some believe virtualization can make the system entropy pool less predictable. It doesn't really matter which is true. The important point is if you can exhaust the system entropy pool, one of two things will happen; (1) the system will get bogged down waiting on the pool, or (2) a poorly written PRNG will start giving you less random numbers.
Of course, "less random" is the most accurate way to phrase it, but in some cases, the actual result is the (faulty) PRNG gives you "predicable" numbers if the system entropy pool is exhausted.
To do it right, you'd have to evaluate the frequency/pressure on the system entropy pool before increasing the key/UID width or you might suffer some highly undesirable effects. There are essentially two places where you might need to add hardware; (1) performance penalties of increased key width in the key-value store, and (2) performance penalties from exhaustion of the system entropy pool (with a well written PRNG). With the former you'd be paying for more servers, and with the latter you'd be paying for more entropy sources to feed the pools. I'm not sure how one would add specialized entropy source hardware in a virtualized environment, but with enough cost and effort, it might be doable (device mapping?). Needless to say, in either case or both, the costs could be prohibitive.
The admittedly "noodley" point here is correctly maintaining a constant threshold level of entropy is occasionally easier said than done. Of course, in other cases, it might be brain dead simple to maintain a constant threshold. The only way to figure it out is proper testing.
The non-power-of-two 136 bit length you mentioned seems interesting. I might be (incorrectly) reading more into it that is actually there, but I believe it hints at a far more cost effective solution, namely, just add more k-v stores. For example, the key/UID could only be 128 bits wide, and the extra eight bits indicate a particular k-v store. With the k-v stores being located "close" to the user, this could also improve bandwidth costs, usability/latency, and load balancing, in addition to the benefits of the CDN.
I don't have a facebook account, so I can't check, but if there's some degree of predictability in a single byte (leading, trailing, middle, ?) of the UID, it would be further support of the above theory of operation. It doesn't need to be perfectly consistent, since at each location there are probably multiple k-v stores.
Even on a collision of a generated key/uid in a particular k-v store, the UID might not be thrown out unless it was already used in _all_ of the local k-v stores. This would further reduce the pressure on the system entropy pool, but due to the need for replication/redundancy/backup, I seriously doubt this is the case.
Though going from 128 bit to 136 bit (or similar) _is_ an increase of the width of the identifier, it probably has nothing to do with maintaining a constant threshold of entropy. It's probably just a smart business decision to reduce hardware/bandwidth costs.
PLEASE NOTE: The above is only mindless speculation about how the 136 bit UIDs/keys might work, and (hopefully) no one at facebook will confirm or deny it.
Comments
Requiring attackers to guess a 128 bit random number (actually, fbcdn seems to use 136 bit random numbers) isn't "psuedo" security.
The problem is that the random number is static. As Aegan says, anyone allowed to see a photo can leak its URL. It would be better if the URL would depend on the user to whom the picture is served. But that'd be expensive.
Anyone allowed to see a photo can leak the photo. Why waste time protecting the ID?
Sure, in practice there's not much of a difference, I'm nitpicking, but it's not exactly the same thing.
People might leak the URL unintentionally, for instance by sending the link to others, not knowing that the photo owner doesn't want them to see the photo.
One can also use URLs in places where images are not allowed, for example when submitting them to community websites, without first uploading the photo somewhere and leaving a trail.
Thomas, I agree with you on all points you've posted _except_ the difficulty of attacking the system. It cannot be a truly random number of "X" bits because it is used as a permanent unique identifier. If it was actually a random number, then you have the potential of overwriting files and/or reusing URLs/UIDs.
For every UID discovered, the entropy shrinks and the system becomes easier to attack. Of course, I'm not saying the shrinking entropy would make it feasible to attack the system, just easier. ;)
This is a great noodley point, but note that they can just increase the width of the identifier to maintain a constant threshold level of entropy. They won't, of course. But they could.
We can rest assured that facebook simply doesn't care about this non-issue of image access, so increasing the bit width is not worth their time, but assuming someone actually had this need, doing it right is a lot more complicated than it seems at first glance. --Again, this is admittedly another annoying "noodley point" but it could be important for someone.
ASSUMING: The systems are most likely run in virtual machines, and the UID's are most likely the keys for a key-value store. Whether or not the UID are specific to just images, or are also used for other things (wall posts or whatever) is unknown.
The first question is whether or not your key-value store can handle the increase in key length (UID). Since this is fixable, the safe assumption is "yes" albeit there might be undesirable (or even unsurmountable) performance penalties.
A good PRNG is fed by a system entropy pool, and the pool is populated by various system entropy sources. Some believe virtualization can make the system entropy pool more predictable, but some believe virtualization can make the system entropy pool less predictable. It doesn't really matter which is true. The important point is if you can exhaust the system entropy pool, one of two things will happen; (1) the system will get bogged down waiting on the pool, or (2) a poorly written PRNG will start giving you less random numbers.
Of course, "less random" is the most accurate way to phrase it, but in some cases, the actual result is the (faulty) PRNG gives you "predicable" numbers if the system entropy pool is exhausted.
To do it right, you'd have to evaluate the frequency/pressure on the system entropy pool before increasing the key/UID width or you might suffer some highly undesirable effects. There are essentially two places where you might need to add hardware; (1) performance penalties of increased key width in the key-value store, and (2) performance penalties from exhaustion of the system entropy pool (with a well written PRNG). With the former you'd be paying for more servers, and with the latter you'd be paying for more entropy sources to feed the pools. I'm not sure how one would add specialized entropy source hardware in a virtualized environment, but with enough cost and effort, it might be doable (device mapping?). Needless to say, in either case or both, the costs could be prohibitive.
The admittedly "noodley" point here is correctly maintaining a constant threshold level of entropy is occasionally easier said than done. Of course, in other cases, it might be brain dead simple to maintain a constant threshold. The only way to figure it out is proper testing.
The non-power-of-two 136 bit length you mentioned seems interesting. I might be (incorrectly) reading more into it that is actually there, but I believe it hints at a far more cost effective solution, namely, just add more k-v stores. For example, the key/UID could only be 128 bits wide, and the extra eight bits indicate a particular k-v store. With the k-v stores being located "close" to the user, this could also improve bandwidth costs, usability/latency, and load balancing, in addition to the benefits of the CDN.
I don't have a facebook account, so I can't check, but if there's some degree of predictability in a single byte (leading, trailing, middle, ?) of the UID, it would be further support of the above theory of operation. It doesn't need to be perfectly consistent, since at each location there are probably multiple k-v stores.
Even on a collision of a generated key/uid in a particular k-v store, the UID might not be thrown out unless it was already used in _all_ of the local k-v stores. This would further reduce the pressure on the system entropy pool, but due to the need for replication/redundancy/backup, I seriously doubt this is the case.
Though going from 128 bit to 136 bit (or similar) _is_ an increase of the width of the identifier, it probably has nothing to do with maintaining a constant threshold of entropy. It's probably just a smart business decision to reduce hardware/bandwidth costs.
PLEASE NOTE: The above is only mindless speculation about how the 136 bit UIDs/keys might work, and (hopefully) no one at facebook will confirm or deny it.