But really - once you share an image to some one, there is no stopping them from downloading the image and sharing it out somewhere else anyways.. So I'm not sure the point of this.
In fact, this UI is basically identical to the Drive UI, including separating the functionality of creating a public, shared link and sharing with a specific person. It's downright surprising that Google Photos acts in a different way than Drive here.
This looks like a bug. Is it documented anywhere?
This is very confusing to me, and I like to think I get authentication models. If having the link is the same as being a member, what's the point of being a member?
Just a guess, but I'm betting this is an issue with how compartmentalized Google is within itself, that it was just simply two different people had two different solutions to how "links to objects" should work and it simply never occurred to either of them to check what the other products are doing.
That said, I was under the impression Facebook's CDNs did support auth checks from cookies, such that passing URLs around didn't bypass this. So I kinda doubt the claim.
This is a problem for people who might forward the link or otherwise share/leak it on accident, not understanding that the URL itself is a privileged token.
The authorization check might be incorporated into resource lookup. Imagine a table that maps many-to-one (very long) secret keys to non-secret object identifiers. Each sharing would create a new such secret key. If someone provides the secret key, and that key is (still) in the table, then you knowing that key constitutes you having authorization to whatever object that key maps to. (If, for example, you add a `valid_through` timestamp column to that table, then the authorization check might include more than just the table lookup.)
(I've had to design a similar thing in the past, as part of a big authentication and authorization framework, for working with browser plugins.)