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
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.