2

Why companies like Facebook do not require authenticated HTTP/HTTPS requests to access content (like images) using CDNs?

In a way, once one "friend" can access the image URL, he/she can effectively publish that URL to the world, allowing anonymous access. This is literally "security through obscurity", as it only relies on the URL consisting of a (UUID-like) fbID being secret. I believe Facebook calls this a Capability-based security model, but wouldn't it make sense to tie URLs to particular users to have attribution, as well as employ some form of periodic URL/fbID rotation?

  • 3
    That "friend" could also save your image, put it on their own website, and publish that to the world. – paj28 Jul 3 '16 at 19:07
  • 3
    Tie the URL to the viewer? Then the viewer could do exactly what I just said and still not be traced. Now, maybe you're asking "Why not watermark every image on a social network to identify leaks?" That is potentially interesting - but it is not what you asked, and it is sufficiently different that you should ask a new question rather than edit this one. – paj28 Jul 3 '16 at 19:27
  • @paj28 I refer to the last part of the question-- but wouldn't it make sense to tie URLs to particular users to have attribution. e.g. make the fbID incorporate the viewer's user ID. – Jedi Jul 3 '16 at 19:28
  • 1
    I refer to the first part of the comment - Tie the URL to the viewer? Then the viewer could do exactly what I just said and still not be traced. – paj28 Jul 3 '16 at 19:29
4

The reason for this is large scale applications. When you have large scale applications, checking for authorization takes unacceptable amount of resources. Thats why static resources, like pictures, videos and other content, are stored externally on static CDN servers using a random token, and then the authorized response can include this token.

This means they only need a few replicated database servers, and then they can have large amounts of CDN servers that cache each other permanently.

Distributed servers is what makes rotation difficult aswell, as then the static CDN servers need to be told to rotate that value. And that incurs unacceptable resource usage, as that needs to be done periodically. As opposed to a random value only needs to be set at upload.

Even calculating a md5 hash, generating a random value or something that seems "simple", can be a heavy lift for a distributed CDN server to do.

So the server is a simple storage of files. Basically, all authentication and generating of random values happen on the "active servers" (that run code), while the static servers only store files based on filenames, and serves files based on filenames.

  • Making one part of the file identifier tie into to the user who is viewing it may cost a little more in terms of storage and lookup time, but at least ties the user to the content. Is that still infeasible? – Jedi Jul 3 '16 at 19:26
  • Yes, because then you would need to store the picture once for each user that wants to see the picture. Remember that the CDNs basically don't execute code, they just serve static content directly from a drive. See it as a internet connected harddrive. – sebastian nielsen Jul 3 '16 at 19:27
  • Right, and think of this as symlinks... – Jedi Jul 3 '16 at 19:29
  • 1
    Yeah, symbolic links would work, but the caching servers would still receive the full content when the caching servers gets a request for a picture that is not part of their cache. And then you should rewrite all the caching servers to tell the other caching servers wherever to request a softlink or when to to request the full content. What if the caching server don't have the base content? It quickly becomes the largest mess in the world, considering the amount of users Facebook have. – sebastian nielsen Jul 3 '16 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.