The same is true for a document, someone could just download it and share it out somewhere else, but Google Docs does not work like 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?

OK, if you go in the album options, the share option is labelled: "Anyone with the link can see these photos and the people who've been invited or joined".

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?

I think if you're a member, it sill show the photo under https://photos.google.com/sharing for you. So you don't need to store the link yourself to find the photo later.

But that's like a "favorites" list. What's the point of showing the member list of an album if technically everyone is a member?

It still helps you remember who you've shared with, and the likely list of people who can see it.

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

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.

I noticed that Facebook does this too. If you share a photo or video in a secret or closed group, then you do have to be a member of that group to view the post. But the raw photo and video have URLs that anybody in the world can access with no authentication checks at all.

A long URL is essentially an authentication check. It's long/complex enough it can't be guessed, same as an auth token in your cookie. I'm not sure what guarantees they have regarding changing access, deleting images, etc but those would be the trade-offs. The advantage is the CDN doesn't have to perform auth checks which speeds up response times.

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.

Alternate model for how I would guess this works: Facebook CDN urls are unauthed (in the sense that the CDN probably doesn't know how to evaluate the entirety of Facebook's permissions model). Instead, the web/api server that enforces permissions checks will hand an authorized client a signed CDN url that expires in some bounded time. If that url leaks, anyone can view the underlying image, but only for a short window, after which a client would have to go back to the auth-aware web/api server to get a new signed CDN url.

It can't be guessed, but it can be shared, which is a vulnerability for content that would otherwise be inconvenient to share e.g. large videos.

Which is actually a way worse security model, Facebook is public. Period.

You are thinking of a malicious actor when the real concern is ignorance. A lot of people don't understand security/privacy mechanics and need it explained, which is why the author complains not just about the mechanic itself, but how it isn't spelled out how it works to the user.

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.

Just to expand on this... It sounds like the URL contains a shareable secret for read authorization for a particular resource, with no authentication. Which might be appropriate.

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

If you believe the UI and think the link is limited to the other user, you likely will not take care that it isn't seen by others. That's a different angle than "but you have to trust the receiver anyways".

There is no point to this. This exact issue comes up regularly around here. Same for the "My Activity" page showing all your Assistant queries or your "Timeline" page showing your location history. Unfortunately, it's really hard to balance user experience with user expectations, and people will be always be outraged about things they don't understand.