Why are we able to share any Facebook photo by copying its URL
6 comments
Their photos are stored in a CDN as static files, not served using a script. Hence, by design, it is not possible to block photo URLs to a subset of people.
I don't think the model is too bad. You have to get hold of a pretty complex URL, so only those who can see it in the first place can share it. A static CDN model makes scaling easier.
Ultimately, it means the user has to share content with only those he can trust, and I think that's fair.
Ultimately, it means the user has to share content with only those he can trust, and I think that's fair.
> It seems that we can just copy its URL and then anybody can access it
In much the same way you could copy the image itself and distribute it.
In much the same way you could copy the image itself and distribute it.
There is nothing private about facebook. So, no.
I have my friends Facebook page open at work. Multiple people walk by seeing his photos on my monitor. I also choose to show a colleague a funny pic off his timeline. Are these 2 scenarios acceptable? If so, you have your answers otherwise interesting discussion is ahead of us.
Additionally, my wife noticed this flaw in Facebook security a while back. You share a picture and choose "friends only" and since I'm your friend, I can see it. I can also click "share" and choose "everyone" to sidestep your security setting. Of course I could have right clicked your image and downloaded it to achieve the same effect, but Facebook makes it much easier.
This should not apply to such heavy weight companies, but if you're little application suddenly becomes an overnight success you will have trouble scaling it.
The easiest step would be to store your static data on a commercial CDN. There isn't much logic running. If you would set up one yourself you would use a webserver that is extremely fast at serving static content. The only "thinking" part of the chain would probably be a load balancer.
You're server is now somewhat outside of the boundaries your application server "creates" and deleting old data requires new functionality (although storing too). Functionality that might not readily exist in the framework you use.
If the whole thing is growing too fast for you to keep up you might say to yourself "This and that is now far more important, have the data lying around for a while, it's too much work for now".
The easiest step would be to store your static data on a commercial CDN. There isn't much logic running. If you would set up one yourself you would use a webserver that is extremely fast at serving static content. The only "thinking" part of the chain would probably be a load balancer.
You're server is now somewhat outside of the boundaries your application server "creates" and deleting old data requires new functionality (although storing too). Functionality that might not readily exist in the framework you use.
If the whole thing is growing too fast for you to keep up you might say to yourself "This and that is now far more important, have the data lying around for a while, it's too much work for now".
Doesn't it breach the privacy of the owner?