This would largely be applicable when profiles are deemed private and all you can do is view the small profile picture. In the grand scheme of things, it is minor but it should still be fixed.
Wow, I've just lost a great deal of respect for the programming skills of Facebook and its employees. This is really obvious stuff. I can understand a junior programmer missing something like this (or a non-junior one, everyone makes stupid mistakes sometimes) but surely someone should be checking?
I've just set up a similar system (non-public media served from a faster server without access checking) and the fact that the urls needed to be non-guessable was pretty damn obvious. The timeout thing is also really really obvious if you don't want people to be able to pass around a permanent link.
Whn I interviewed at Facebook I was kind of thrown back by the lack of engineering discipline. If I remember the quote accurately (this was about 1.5 years ago), they averaged 1 hour of downtime per subdomain (i.e. <college>.facebook.com) per week, which may or may not effect all users associated with that domain. To make scaling issues easier, race conditions are also all over. There is no data integrity of any sort. Some/all of these design decisions I could see being justified, because it is afterall just social profiles... but I was a little surprised. The weird thing is they release some really cool open source stuff and have some pretty great engineers there, so I'm not sure where this stems from.
Interestingly, a few years ago I discovered that you could also change the "t"/"s"/"n" (tiny/small/normal) to a "b" (big) and access the full-resolution image which was uploaded.
They seem to have discontinued the "b" prefix shortly after I found it (perhaps to save space?). It was a bit of a privacy concern that they retained the full-resolution image, considering that most users probably do not crop their images before uploading them.
you can't access uploaded images in flash. you have to send the full image to a server, then re-download it, do your manipulation, and then upload the final version.
particularly annoying when uploading to S3, since you have to go client->server->client->server->S3.
There is an additional privacy "hack" that I noticed a few years ago. The surprising thing is that as of about a month ago the hack no longer works -- not because Facebook stopped it, but because your data on Facebook is now less secure by default, removing the need for the hack!
It used to be that when a friend was tagged in a photo album of a non-friend, you could only view those photos that your friend was in. By removing the "id=xxxxxx" from the URL, you could view ALL photos from the non-friend's album.
As of recently, you can now view ALL photos from any non-friend's album if a friend is tagged in only one of the photos (alleviating the need for the "hack")! Hence, for all their talk about privacy and their very complicated privacy settings, it seems that in some ways your Facebook data is becoming subtly less secure!
I do think that fb's current approach makes sense when you want to share photos to people who are not on facebook, and that the marginal return from that being possible outweighs the "information leakage" of the current setup
This has been around. I remember discovering this when I wanted to share pictures found on facebook with others. A simple "View image location" and copy/paste and they could see it.
I remember finding this about videos too. Was going to try and work out the naming scheme, but never got round to it. Presumably it's a similar system.
Look at my history. I've been talking about OurDoings here for years. If somebody wants to say every such comment should include a disclaimer I'll listen, but I won't be lectured on transparency from an account like izboyd created just for posting this one comment.
This vulnerability is an example of Facebook's failure to think things through. It does push my buttons and I'm going to say something. Just because it's popular doesn't mean it's good.
My issue with your comment is that you jumped on a /bug/ in Facebook to push your cause.
Analogy: Let's say I had a car company that competed with a fictitious competitor, Toyonda. There was a news story on HackerNews about a software bug that caused all Toyonda Freerunners to crash whenever somebody pushed the gas too long. I then posted a comment that my car, the Legendary Esquilax, doesn't have that bug. It's self-serving and adds nothing to the conversation.
Now, if you said something like, "Our Esquilax line of cars uses an O(1) lookup on the rotor hashtable to avoid a backup of 'gas' events which caused the bottleneck bug at the root of the Toyonda issue." That would be interesting, provide useful news about competing products, and potentially spark a discussion about the "right" gas pedal algorithms.
About your comment on lecturing: I signed up with Hacker News to post a comment. Every person needs an impetus to join a community, and your comment provided that for me.
Thanks for following up. I understand where you're coming from now. Unfortunately in this instance there's not a lot of potential for interesting discussion about the "right" way to form semi-private URLs on a host that isn't doing authentication. You need enough randomness; that's obvious. Apparently it wasn't obvious to Facebook.
Yet another reason why nobody should be using facebook.
In any case we can't expect a website as big as facebook to implement encrypted urls which dynamically change with each user's session, which the session data server-side is used to decrypt and execute. Its not necessarily the best way to do things (like say ensuring the given user HAS permission to access the photo before serving it.)
O well I guess if the problem is too big for facebook, it must be too big for the rest of us. I am going to go to work tomorrow and rip it out of our application since this should not be a solvable problem.
Take one of my photos for example:
http://photos-b.ll.facebook.com/photos-ll-snc1/v2339/95/113/...
to:
http://photos-b.ll.facebook.com/photos-ll-snc1/v2339/95/113/...
This would largely be applicable when profiles are deemed private and all you can do is view the small profile picture. In the grand scheme of things, it is minor but it should still be fixed.