I typically appreciate tptacek's security remarks, and agree that once you trust someone to view a photo, you're trusting them to not repost it.
However, I disagree that "everyone is doing it this way" is a good reason to do it this way.
Flickr, as I noted separately in this thread, doesn't do it this way. Changing privacy settings changes the URL, so someone using the URL (a common use case for images) can't use it any more. That's the "user expected" behavior. Facebook's behavior is a generally unwelcome surprise.
Additionally, since you're considering building image hosting: "token protected" URLs are well understood and often applied as a best effort solution to this problem. A token protected URL typically has an expiry, and in typical use is only valid briefly when issued for the visitor requesting the (authenticated) page containing embedded photos.
Of course, the CDN edge cache servers have to cache the object yet respect the tokens, which requires a bit more intelligence from the cache, which is why "general industry practice" is to take the easier shortcut of not protecting the URL and image object at all.
Disclaimer: We offer token protected video and image CDN delivery, calling it "deep link protection". Our DLP, and token schemes in general, protect the link from misuse, not the asset.
That link isn't about S3. That link is about CloudFront, the CDN edge caching layer above S3. S3 storage has always offered token protected links. CloudFront CDN introduced protected links only recently.
Customers and clients of CloudFront CDN (which uses S3 storage as its origin) wanted protected URLs, and AWS went to the time and expense to provide them. Content owners large enough to want or need CloudFront edge caching believe there are legitimate business cases for single use, expiring, IP restricted, or other classes of protected URLs for content.
As for Facebook:
Facebook operates web servers generating authenticated and authorized web pages. These pages are dynamic, generated per user, based on current privacy settings. These privacy-managed pages contain links to assets considered, by users, to be just as private as the page.
When the user changes privacy settings for the page, the linked assets privacy could easily be kept in line, as demonstrated by CloudFront CDN being able to support private content links.
Facebook's fault is that the privacy managed page links to public (non-privacy managed) assets, using links that do not respect the containing page's privacy settings.
To say the image shouldn't have privacy settings is to say the page shouldn't have privacy settings "because anyone could save it and repost it". (Which people do, via screenshots.) That's expected and accepted.
But once they change their privacy settings, users believe access permission changes. Access permission does change for the container page, but not the linked assets. That's a broken model.
Comments
I typically appreciate tptacek's security remarks, and agree that once you trust someone to view a photo, you're trusting them to not repost it.
However, I disagree that "everyone is doing it this way" is a good reason to do it this way.
Flickr, as I noted separately in this thread, doesn't do it this way. Changing privacy settings changes the URL, so someone using the URL (a common use case for images) can't use it any more. That's the "user expected" behavior. Facebook's behavior is a generally unwelcome surprise.
Additionally, since you're considering building image hosting: "token protected" URLs are well understood and often applied as a best effort solution to this problem. A token protected URL typically has an expiry, and in typical use is only valid briefly when issued for the visitor requesting the (authenticated) page containing embedded photos.
See: http://aws.typepad.com/aws/2009/11/new-amazon-cloudfront-fea...
Of course, the CDN edge cache servers have to cache the object yet respect the tokens, which requires a bit more intelligence from the cache, which is why "general industry practice" is to take the easier shortcut of not protecting the URL and image object at all.
Disclaimer: We offer token protected video and image CDN delivery, calling it "deep link protection". Our DLP, and token schemes in general, protect the link from misuse, not the asset.
Do people generally serve content directly out of S3 to the public? That costs money. We don't; we use S3 as a cache, and to serve files to customers.
Point being, S3 solves a different problem than Facebook does.
That link isn't about S3. That link is about CloudFront, the CDN edge caching layer above S3. S3 storage has always offered token protected links. CloudFront CDN introduced protected links only recently.
Customers and clients of CloudFront CDN (which uses S3 storage as its origin) wanted protected URLs, and AWS went to the time and expense to provide them. Content owners large enough to want or need CloudFront edge caching believe there are legitimate business cases for single use, expiring, IP restricted, or other classes of protected URLs for content.
As for Facebook:
Facebook operates web servers generating authenticated and authorized web pages. These pages are dynamic, generated per user, based on current privacy settings. These privacy-managed pages contain links to assets considered, by users, to be just as private as the page.
When the user changes privacy settings for the page, the linked assets privacy could easily be kept in line, as demonstrated by CloudFront CDN being able to support private content links.
Facebook's fault is that the privacy managed page links to public (non-privacy managed) assets, using links that do not respect the containing page's privacy settings.
To say the image shouldn't have privacy settings is to say the page shouldn't have privacy settings "because anyone could save it and repost it". (Which people do, via screenshots.) That's expected and accepted.
But once they change their privacy settings, users believe access permission changes. Access permission does change for the container page, but not the linked assets. That's a broken model.