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.
Comments
Change the "s" to an "n" of the image name in the URL and you can still view full versions of the pictures in question.
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.
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.
I believe that, now, they resample the images prior to upload. Perhaps to save bandwidth as well.
Client side resample ? I would love to know how they do that. With AJAX it does not seem possible.
With Javascript (AJAX) it wouldn't be, but with a little Java or Flash it is. (I'm not 100% sure on Flash, but I bet it's possible)
I think Facebook uses Java for this bit (not totally sure, and I don't want to have to log in just to check)
Facebook uses the Aurigma Image Uploader, which is implemented both in Java and as an ActiveX control.
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.