I wonder whether this is limited to photos in the profile album, or whatever it is called, these days.
EDIT: I'll add this suggestion that I've made before, since you're going to have a LOT of people wanting to delete photos, if this problem proves to be significant. Delegate someone to spend a few hours writing a routine that will replace a cached photo with an identically sized, all white (or black, blue, whatever), no metadata generated image. So, you don't have to rebuild your image caches in order to ensure that a photo is really gone (well, except for the fact that it once existed, as demonstrated by the working URL and white image).
I've read the excuse made in the past that aggressive, large, integrated image caches made actual photo deletion "not an option". As long as you can overwrite existing bits in place, this should solve that. (Although I don't know about all the tagging you've now since overlaid onto the images.)
I haven't kept up, but IIRC that used to be the case. And that's what I'm addressing.
A few years ago, I believe, they explained that they generate these ginormous image caches where, IIRC, individual images are not distinct files.
My point is, regardless, if you can find the image (and its extent), and if the cache data are still write-able, then overlay a generated "blank" image onto the cached image, in place. You still have some data leakage, in that the working URL confirms that there was an image having that URL. But for most cases, I believe this would suffice.
I guess they'd also have to track down and overwrite the various thumbnail versions, but if their systems can already find these in the course of their normal work, this shouldn't be a problem.
As for overlaid tag data and whatnot, I'm not sure what to suggest. At a first pass, I'd suggest just deleting (or "offlining" or whatever, given that FB apparently never really deletes anything) that data. But I don't know what continuing dependencies that might break.)
EDIT: I should add that I don't know whether/how such image caches are replicated. And perpetuating such an overwrite against multiple replications might not be easy / something the existing design supports.
Nonetheless, I think it's something they should support. At a minimum, when a user really wants to delete an image, then overwrite its segment of whatever image cache file with a "blank" equivalent.
Although... then you get into what may be legally required and/or prudent, from FB's perspective, to retain.
I'll stick to the simplistic user perspective: When I say delete, I mean delete.
Maybe that was true in the past, but today when you delete your data it is gone. Trust me, I wrote it myself. The law enforcement guidelines that have been circulating recently corroborate this.
I deleted a couple of pictures this morning (nothing 'nekkid' ;-) and will have a look to confirm that they are indeed "gone" (inaccessible via direct URL -- albeit the URL of a CDN).
Would you happen to have the identity or URL of a specific guideline that you could point to?
EDIT: I just checked the URL of an image I deleted about an hour and a half ago, and that image is still accessible. It is under akamaihd.net; nonetheless, it is still accessible.
Is this true for all data - account details and whatnot? I deleted (not deactivated) my account a few months ago and just assumed everything would remain somewhere in FB's system.
I wonder whether this is limited to photos in the profile album, or whatever it is called, these days.
EDIT: I'll add this suggestion that I've made before, since you're going to have a LOT of people wanting to delete photos, if this problem proves to be significant. Delegate someone to spend a few hours writing a routine that will replace a cached photo with an identically sized, all white (or black, blue, whatever), no metadata generated image. So, you don't have to rebuild your image caches in order to ensure that a photo is really gone (well, except for the fact that it once existed, as demonstrated by the working URL and white image).
I've read the excuse made in the past that aggressive, large, integrated image caches made actual photo deletion "not an option". As long as you can overwrite existing bits in place, this should solve that. (Although I don't know about all the tagging you've now since overlaid onto the images.)