
Google Photos is making photos semi-public - robertwiblin
https://medium.com/@robertwiblin/google-photo-is-making-your-photos-semi-public-and-you-probably-dont-realise-6fcc74e40ac6
======
pkulak
This is exactly what I, and everyone else I know, wants to happen when you
share a link to a photo. Do we not remember what the alternative is? Sharing
with someone's Google account, I suppose? Oh, but now when you send that link
to your iMessage group, you have to know every one's Google account name. And
then half of them will be logged into their work accounts (or not logged in)
at the time and it will fail, and the whole message thread turns into a
discussion of how 3/4 of the people can't see the photo.

What are the easier alternatives? Emailing maybe? But then you've moved the
bits into someone else's account and they are there forever and can be
forwarded anywhere. Maybe print a physical copy? Then that copy is around
forever and can be handed to anyone else.

They only extra security I would tolerate is an optional expiration, defaulted
to a year or so. I love taking photos, I enjoy sharing them, and it's
important to me to keep that simple and accessible. I think of these share
links as bearer auth, which is used all over the web and is a perfectly valid
way to secure a resource.

~~~
nlawalker
In my opinion, the main problem is that the interface doesn't make it
abundantly clear that you're generating and sharing an unauthenticated link to
the photo.

Compare this with OneDrive/Office 365, where all the language around this
functionality is explicitly about _links_ ("Get a link", "share a link", as
opposed to "share with this user"), and the UI prompts that appear are very
explicit about what the link does ("Anyone with the link will be able to edit
the file", "Anyone in this organization with the link will be able to view the
file").

~~~
tsbinz
I agree that office has a nice granularity there, but the UI is not very good.
People don't understand that they have to share a specific link to a document
and they can't just copy & paste the address of the page they are seeing ...
Link shared -> "don't have permission" -> sender replies confused that the
link works for him is an exchange I have seen way too many times.

------
spydum
Once you have the full URL to the image, you can share that too -
authorization checks dont happen when fetching the image.. from
googleusercontent.com as far as I can tell..

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.

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

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

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

------
tzs
It's too bad HTMLMediaElement seems to only be for audio and video. If it also
could do photos you should be able do a photo sharing site that lets you
upload encrypted photos, distribute the URLs of those uploads, and have them
only be viewable to people you also distribute the key to, without those
people needing any special software to decrypt the photos. Such software is
already built into the major browsers, as part of the Encrypted Media
Extensions (EME).

People mostly think of EME in the context of DRM, providing a uniform
framework across browsers for proprietary DRM plugins for streaming movies
from services like Netflix.

But EME can actually be used without any plugins. The spec requires
implementations to support a thing called "Clear Key", where you provide the
decryption key directly to EME instead of it coming from some DRM plugin. See
this article for more information [1].

I've tried this with video and it works fine. I took an encrypted video, put
it on my web site along with a page that had an HTMLMediaElement containing
the video, and a text box that let you enter the decryption key, and could
play it back when I supplied the right key.

I wonder if doing a photo as a 1 frame looping video would work?

[1]
[https://www.html5rocks.com/en/tutorials/eme/basics/](https://www.html5rocks.com/en/tutorials/eme/basics/)

~~~
TheDong
What google is doing now is not too far off from that.

The URL contains a long string which is the shared secret (functionally
equivalent to a decryption key), and each person you share that URL with may
view it without needing any special software.

Anyone you don't distribute that URL to can't view it.

~~~
JaRail
> functionally equivalent to a decryption key

Not from a security point of view.

~~~
gregmac
Why? What's the threat vector that's specifically enabled by the key in the
url?

And why is that vector defeated by submitting the "decryption key" (password)
as part of a POST body (or some other method you can explain)?

~~~
JaRail
Google doesn't embed a decryption key in their URL. AFAIK, they are just long
lookup keys that are unguessable.

The difference between that and local encryption is if you trust the storage
provider. If you were a journalist in China, you wouldn't want your documents
accessible by your hosting provider.

In the above scenario, you obviously wouldn't want to submit a decryption key
to the server as part of a URL/POST. Look at how services like mega.nz are
designed. They popularized an approach where the decryption key is in the
URL's label, which is not submitted to the server. The files are decrypted
with javascript locally.

------
martythemaniak
Semi-related: I had a very creepy bug come up recently. Amongst all the
collages, animations and videos Assistant makes, this auto-generated video
came up: [https://streamable.com/bd2y1](https://streamable.com/bd2y1)

There's no image/video source for this (accidentally syncing downloaded
folders etc) that I could find and typically the jangley music the videos come
with don't include any narration, so the source must be a video? This is the
first thing I've ever contacted Google Support over, and obviously, there's a
0.001% chance of anything being resolved.

~~~
rolltiide
Its a Deep Mind induced messaged from the future

------
jit_hacker
This is a non-issue. The URLs are way to unique to guess (you'd have an easier
time guessing an email/pass/2FA). And ones ability to access the URL at all is
the same as their ability to access the bytes of the image. Once accessed,
they could capture and share either.

This would be an issue if it were mutable data.

~~~
faitswulff
Agreed, I was looking for something more substantial than this, too. I was
thinking it was some clever unpatched way to scrape semi public Google photos
links. Turns out it's just the sharing feature working as expected.

------
kyrra
He says the easy thing is to use the Google drive sharing model, which only
works with other people that have Google based accounts that can be
authenticated. The sharing model in Photos is meant to lower the barrier for
sharing with people with non-Google accounts. It's also worth noting in the
demo he showed, many of the recommended sharing links were sharing with a user
account and not via link (which would be gated behind authentication still).

~~~
chaosite
The point of the video is that he is sharing with a user account and not via
link, and that is not being gated behind authentication.

~~~
ggggtez
If you share a google doc to public, it does the same thing. This is at best a
case of user confusion, but is hardly insecure. Photos aren't even mutable, so
having continued access after you see it once isn't relevant.

~~~
chaosite
Yes, but here you aren't sharing the picture to the public, you're sharing it
to a specific person.

------
shepwalker
You can get similar behavior with Dropbox
[https://www.dropbox.com/s/pcutvzhj8nc4auu/indy_asleep.jpeg](https://www.dropbox.com/s/pcutvzhj8nc4auu/indy_asleep.jpeg)
And OneDrive:
[https://1drv.ms/u/s!AqxVBILuAH4kssIAdGJhBtwUCm5DhA](https://1drv.ms/u/s!AqxVBILuAH4kssIAdGJhBtwUCm5DhA)

{I assume Box has something similar but I don't feel like finding my creds}

Screenshots of the dialogs:
[https://imgur.com/a/lijzeli](https://imgur.com/a/lijzeli)

The big difference I see is that that the Google Photos share model feels
related more to mobile-sharing scenarios than access control - ie, you're
sending your buddy a link! Vs you're granting access, and that distinction
isn't super blatantly called out.

Disclosure: I work on OneDrive for Microsoft

------
scarface74
If I share a link to the photo and the link gets shared by the recipient it is
“semi-public”.

If I share an authorized link to the photo the recipient can still share the
photo if by no other way, taking a screen shot.

If in the case of the Google Photos iOS app, if I share a photo via the share
shortcut and send it in a message, that photo can also be shared.

All that to say, no matter how you share the photo - it’s out of your control
after that.

------
godelski
This is a perfect example for things like:

Techies: Well duh... what did you expect? Magic?

Non-techies: WHAT?

I think people often forget that most don't actually know how computers or the
internet work. Since this topic keeps coming up it really seems like we need
to think clearly about this and do a better job of informing people how things
work.

~~~
truculent
More like they want the same UI as Drive, as stated multiple times in the
article?

------
tomasyany
Every uuid image link would be public, but virtually private. You would need
to know the exact link to see the image.

Can't see how this is different from images stored in FB or other services.

There's no reason to panic, guessing the URL's is (virtually) impossible.

~~~
jdnenej
Exactly. If it's a long enough url then the url is basically a secure
password.

------
carapace
"Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in
the Cloud" (2014)

Abstract

> Controlled sharing is fundamental to distributed systems; yet, on the Web,
> and in the Cloud, sharing is still based on rudimentary mechanisms. More
> flexible, decentralized cryptographic authorization credentials have not
> been adopted, largely because their mechanisms have not been incrementally
> deployable, simple enough, or efficient enough to implement across the
> relevant systems and devices.

> This paper introduces macaroons: flexible authorization credentials for
> Cloud services that support decentralized delegation between principals.
> Macaroons are based on a construction that uses nested, chained MACs (e.g.,
> HMACs) in a manner that is highly efficient, easy to deploy, and widely
> applicable.

> Although macaroons are bearer credentials, like Web cookies, macaroons embed
> caveats that attenuate and contextually confine when, where, by who, and for
> what purpose a target service should authorize requests. This paper
> describes macaroons and motivates their design, compares them to other
> credential systems, such as cookies and SPKI/SDSI, evaluates and measures a
> prototype implementation, and discusses practical security and application
> considerations. In particular, it is considered how macaroons can enable
> more fine-grained authorization in the Cloud, e.g., by strengthening
> mechanisms like OAuth2, and a formalization of macaroons is given in
> authorization logic.

[https://ai.google/research/pubs/pub41892](https://ai.google/research/pubs/pub41892)

------
TazeTSchnitzel
Ah, and it would be so easy to fix this in one way or another:

1) Make the link temporary, only working for X days

2) Make the link only bring up a page which lets you link to a Google account,
and after that you need the account to view the images and the link has
effectively expired

3) (2) with a time limit

et cetera

~~~
macspoofing
But why?!??! Why would you want them to do any of that.

Of course Google _could_ add more 'secuirty' controls on top of the sharing
feature. They could require a password, or passphrase, or make the link one-
time use only, or only available to Google accounts.... But for every extra
control they add, thousands of users would get frustrated and essentially be
shut out from the feature. Somebody's grandfather wouldn't be able to open
pictures of their grandkids, somebody's aunt would get frustrated sharing
pictures of her cooking.

Security is like marketing in that it can be a big black hole that you can
dump more and more resources into with no benefit. There is a very real cost
to security.

------
macspoofing
This 'security issue' is of the same category as a previous article about
Trello desktop app storing an authentication token locally ... that is, a non-
issue that let's the author pretend like they found a security issue in a
major consumer product.

Google Photos is a consumer product meant to be used by regular by tech savvy
and non-tech savvy consumers. You can always add more security-based workflows
but then your grandparents will get frustrated when they can't see pictures of
their grandkids you emailed to them, or can't figure out how to send you
images that they took of their garden.

What is the alternative that the author proposes? Use Google account access
controls? Great idea if everyone has a Google account and is logged into the
right browser. But that's not reality. I see proposals in this thread about
sharing encryption keys or passwords, or using Google accounts sometimes, but
not other times. Suggestions that range from Kabuki theater, to frustration of
regular consumers.

There is no issue here, and Google has the right idea.

------
kpU8efre7r
What are the odds of guessing that URL? It appears it would be far more
difficult than guessing the user account password.

URL consists of uppercase, lowercase, 0-9 and is 17 characters in length-
that's 1.28E65 dudes. That's enough combinatholions you could probably make a
URL for every photo ever taken for all of human history and never find one in
a billion years.

~~~
zmmmmm
> What are the odds of guessing that URL

Very high when someone accidentally forwards it in an email, copy / pastes too
much into a document etc. The attack vector isn't someone randomly guessing
the URL.

~~~
jdnenej
I can also accidentally share a file of the image.

~~~
zmmmmm
Pretty hard without explicit / malicious intent.

------
ozzmotik
in all fairness, what would one expect the app to do in the first place?
sharing through the app is fundamentally different than sharing through, say,
your photo gallery, as that just shares the image itself. within the app, and
the general ecosystem that surrounds it, the method of sharing is by exposing
that image as a resource to external parties, and given that http(s) is the
transport that makes the world go round, it would stand to reason that a url
would be created and associated with that resource, and furthermore that
anyone that gets that url would be allowed to access that resource. of course
that's just generalized sharing, there's also more granular sharing at the
level of Google accounts where you can provide specific access to specific
individuals etc. but either way. i see no reason to be surprised or even
particular bothered by this. if anything it's to be expected

------
dvdbloc
This has been covered so many times by so many different people that I’m
surprised this is at the top of hacker news yet again.

------
suchire
I used to be the tech lead for the sharing and permissions side of a file
storage service. In my experience with designing systems, participating in
user studies, trying to problem solve with coworkers, and so on, this is an
extremely hard problem to solve, because (as can be seen in the comments),
there usually isn’t a right answer. Different people expect very different
defaults, and get frustrated and upset when things don’t match their a priori
expectations. The temptation is to solve these differing use cases with lots
of configurability, precise descriptions, and lots of user education but users
don’t read (usually), and rarely do they understand the tricky implications of
different settings. Not only that, but mistakes they make in configuration or
use will understandably cause them to be more scared of using your service.

I don’t think anyone has solved access control, not Facebook, Google,
OneDrive, or even Apple.

------
Forge36
2017*

Since this article didn't include instructions to fix this:

On desktop (I couldn't find a way through the app) Go-to
[https://photos.google.com/sharing](https://photos.google.com/sharing)

You can see what's shared Select an album, go to options (is a menu under the
three vertical dots in the upper right)

Uncheck share. Then click delete

~~~
chaosite
What does "2017" mean here? It's not the year of the article, it's from today.

~~~
Forge36
It's not new news, it looks like a rehashed version of this article I found
[https://www.alexkras.com/do-not-share-your-google-
photos/](https://www.alexkras.com/do-not-share-your-google-photos/)

Reading that one closer I found
[https://www.theverge.com/2015/6/23/8830977/google-photos-
sec...](https://www.theverge.com/2015/6/23/8830977/google-photos-security-
public-url-privacy-protected)

Which is from 2015.

~~~
chaosite
Ah, I see. But, this is a new article about an old issue, not a link to an old
article, so it shouldn't get a date in the title.

That people keep rediscovering this issue and being surprised by it is says
something.

~~~
asdfasgasdgasdg
Does it say something, though? If you have hundreds of millions of people
using a product, you'll find _someone_ surprised by any given behavior of that
product. Combine that with the fact that anything even tangentially related to
privacy gets bigtime upvotes on this site, and it's not hard to see how an
article like this gets written about a feature that is in fact behaving as
most people expect.

~~~
adamisom
"that is in fact behaving as most people expect"

Pretty subjective, what's your sample size? Oh, one? Look ,this is me being
equally as dismissive and contrarian, it's not too fun is it.

~~~
asdfasgasdgasdg
You're entitled to your beliefs and estimations, and I'm not offended by you
disagreeing with mine.

------
vladgur
This is old news though [https://www.theverge.com/2015/6/23/8830977/google-
photos-sec...](https://www.theverge.com/2015/6/23/8830977/google-photos-
security-public-url-privacy-protected)

But I do agree, google can do better messaging that

------
jdofaz
OneDrive lets you set an expiration when you share a photo with a url, I
usually pick a month with the assumption the other person will download the
photo to their own collection.

------
vassilyk
From what I remember this was in the original specs [1]. If people don't check
specs how can we expect society to work?

[1][https://www.theverge.com/2015/6/23/8830977/google-photos-
sec...](https://www.theverge.com/2015/6/23/8830977/google-photos-security-
public-url-privacy-protected)

------
teamski
This is the reason why I pay for Dropbox to host my pictures. The problem with
Google is often not about severe privacy problems, it's about 'you never know'
and getting educated and finding the right setting is hassle everytime. Worse
here is FB.

------
jxdxbx
iCloud sharing works the same way, however the public links expire. (When you
share photos with someone via iMessage and it creates an iCloud link rather
than iMessaging the photos, it's just a public, unguessable URL).

------
marmshallow
Facebook does the same thing right? Not necessarily defending the choice but
it’s standard. Wonder if there are similar examples outside of social media
sites, like for banking pdf statements generated or something like that...

------
walterbell
If you use an end-to-end encrypted messaging app like Wire (app.wire.com),
your photos will only be visible to the specific accounts _and devices_ which
were in the group at the time of sending the photo.

------
netdur
Not an issue, it will only became an issue if you can predict the photo URL.

~~~
edoceo
Or, any of the other ways for a URL to leak, which is the authors point.

------
erwan577
Is there any practical way to review all the links to my shared Google Photos
and maybe disable sharing of most of them quickly ?

------
sidcool
Are there any good alternatives to Google photos?

~~~
mceachen
_ahem_

------
modzu
for what its worth, github suffers from the same issue. it's a "feature"

------
robertAngst
Is this an actual risk? you would need to guess a link.

Serious question

~~~
thaumasiotes
This is actually a pretty common type of report to public bug bounty programs.
("Anyone can see your private data if they can guess the GUID in the URL".)

Barring something extraordinary, it would be acknowledged as intentional
behavior and classified wontfix. For most purposes, no, this is not an actual
risk.

~~~
jeffk_teh_haxor
The Earth will be swallowed by the sun before you guess that GUID.

~~~
thaumasiotes
Ah, but if you network a bunch of cloud computing resources to guess in
parallel...

Sorry, bad bug bounty memories. ;)

~~~
jeffk_teh_haxor
What if, like, you had a quantum computer that could guess every password
simultaneously? Checkmate, nerd. Give me my bounty.

------
akras14
Glad to see it trending again. I raised the same concern years ago, and was
mostly ridiculed. Nothing has changed since then.

I’ve been using Google Drive integration to share photos securely, but Google
just announced that this will be going away.

In addition I realized that Google strips out metadata from my files during
conversion. Common sense, but not something I thought about before.

Time to switch. If anybody has good alternatives I am all ears.

[https://www.alexkras.com/do-not-share-your-google-
photos/](https://www.alexkras.com/do-not-share-your-google-photos/)

