Google Photos is making photos semi-public(medium.com)
medium.com
Google Photos is making photos semi-public
https://medium.com/@robertwiblin/google-photo-is-making-your-photos-semi-public-and-you-probably-dont-realise-6fcc74e40ac6
149 comments
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").
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").
Would be intersting to see a user study of the two services to measure the number of people who actually understand what the "sharing" is doing.
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.
[deleted]
I could be a lot happier if they gave me access to the analytics data (which they most definitely do log). It would let me freak out if there's an unexpected amount of traffic or any referrers from crawlers/reddit/social media.
But otherwise, this seems like another story about how nontechnical people are being surprised by underlying details behind technology. In the sense of "omg we are being tracked" except in this instance it's just realizing that even if you have an unguessable url, someone can access it if you accidentally give it out... big whoop.
But otherwise, this seems like another story about how nontechnical people are being surprised by underlying details behind technology. In the sense of "omg we are being tracked" except in this instance it's just realizing that even if you have an unguessable url, someone can access it if you accidentally give it out... big whoop.
> I could be a lot happier if they gave me access to the analytics data (which they most definitely do log)
Back in the days us geeks would just fire up a web-server and call it a day.
What happened?
Back in the days us geeks would just fire up a web-server and call it a day.
What happened?
We found better and/or more enjoyable things to do with our time.
That's presumably part of it, but dotcom wealth mostly comes from gaining centralized power over people.
So most energy of the last 20 years has been focused on creating and entrenching middlepersons, rather than on developing decentralized approaches.
And most of what decentralization you hear lately is mostly cryptocurrency-style scams, attempts to ride blockchain hype for an incredibly crappy database, and solutions focused on the priorities of people doing illegal things.
Rather than very simple ideas from the original Web, like "everyone can have their own Web servers, and we build from there," for example.
So most energy of the last 20 years has been focused on creating and entrenching middlepersons, rather than on developing decentralized approaches.
And most of what decentralization you hear lately is mostly cryptocurrency-style scams, attempts to ride blockchain hype for an incredibly crappy database, and solutions focused on the priorities of people doing illegal things.
Rather than very simple ideas from the original Web, like "everyone can have their own Web servers, and we build from there," for example.
Dat/Beaker Browser and many others can do all you described.
They're just not popular because only us geeks care or understand the value of esoteric and worthless stuff like privacy and data ownership.
Also, unfortunately if someone shares a photo and then turns their computer off, the recipients then can't download the photo. If you share a photo from your phone, then accidentally drop it into the toilet, the recipients then can't download the photo. Those are inconveniences.
The popularity of facebook despite it's innate, deep-rooted and well-publicized privacy horrors makes it obvious that convenience and inertia always wins.
So the geeks need to produce something compelling that includes privacy and decentralization at its core, and only then will people switch. Pretty please?
They're just not popular because only us geeks care or understand the value of esoteric and worthless stuff like privacy and data ownership.
Also, unfortunately if someone shares a photo and then turns their computer off, the recipients then can't download the photo. If you share a photo from your phone, then accidentally drop it into the toilet, the recipients then can't download the photo. Those are inconveniences.
The popularity of facebook despite it's innate, deep-rooted and well-publicized privacy horrors makes it obvious that convenience and inertia always wins.
So the geeks need to produce something compelling that includes privacy and decentralization at its core, and only then will people switch. Pretty please?
OK, so I'm working on something that could be like that, and looked at dat and ipfs, but only IPFS is reasonable for filesystem access, and both have decidedly nontrivial access latency. DAT/IPFS experts: how would you apply it to something like a Google photos app, where the majority of assets are private, and subsets of assets are shared? How do you propagate edits (like adding and removing assets or changing asset metadata, like "hidden" or reactions) with reasonable propagation assurances?
Why are you assuming you can't do that? Google will index your page if you want, Facebook and Twitter will share your links if you want. Nothing prevents you from making anything you want (Google will even sell you servers to do it!).
Most people have simply realized that isn't any fun. But if you want to, go ahead.
Most people have simply realized that isn't any fun. But if you want to, go ahead.
Convenience and mobile devices happened. With Google photos and similar I can share photos from my phone within seconds from pretty much anywhere. For example while I'm still on vacation in a foreign country. It's much lower friction than uploading the photos to a server, likely creating some kind of album, generating looks work tokens in them, etc.
These are not incompatible with private servers. I can imagine a world where, on setting up your phone, you set up the location of the backup server, which can be a server that you own. On taking a picture, instead of syncing with Google/Apple photos, it syncs with the server that you have chosen. When you share a photo, it indicates that that photo should temporarily be moved from a private folder to a public folder on the backup server.
Apparently everyone on HN wants the benefits of consumer products but with "geek" features included.
No one is stopping you from doing that.
Agreed. This is exactly how I figured it would work, and how I would want it to work, and for these exact reasons.
The only thing this story reveals to me is the apparent disconnect between how things actually work and how people think they ought to work-->magic.
The only thing this story reveals to me is the apparent disconnect between how things actually work and how people think they ought to work-->magic.
Honestly the majority of the "outrage articles" in the past few years have been based on that exact premise. Should companies gives people the experience and features they expect, or should they dumb down and simplify these services so that everyone knows exactly what's going on?
Is the fact that average people don't know that there's a "My Activity" page Google's fault or on the user? I don't think there's an easy answer but tech sites sure love milking it for views.
Is the fact that average people don't know that there's a "My Activity" page Google's fault or on the user? I don't think there's an easy answer but tech sites sure love milking it for views.
>>But then you've moved the bits into someone else's account and they are there forever and can be forwarded anywhere.
Once you've shared a link to a photo you have shared the data with said person forever. They can simply download it into their computers, or take a screen shot, or take a picture of the picture. It is futile to worry about stuff like this if you are sharing it in the first place.
Once you've shared a link to a photo you have shared the data with said person forever. They can simply download it into their computers, or take a screen shot, or take a picture of the picture. It is futile to worry about stuff like this if you are sharing it in the first place.
This exact "vulnerability" is very commonly reported to public bug bounty programs. You've given one of the two major reasons it's almost always rejected.
(The other being "sure, you can see the photo if you know the URL, but the URL is impossible to enumerate or guess". If you posit that the recipient discloses the URL to a malicious third party... you're back at scenario 1, where the recipient directly discloses the photo instead.)
This finding doesn't appear to be listed on Google's master page of ineligible vulnerabilities ( https://sites.google.com/site/bughunteruniversity/nonvuln ), but the most likely outcome of this Medium post is that... it gets listed, and nothing else is done.
(The other being "sure, you can see the photo if you know the URL, but the URL is impossible to enumerate or guess". If you posit that the recipient discloses the URL to a malicious third party... you're back at scenario 1, where the recipient directly discloses the photo instead.)
This finding doesn't appear to be listed on Google's master page of ineligible vulnerabilities ( https://sites.google.com/site/bughunteruniversity/nonvuln ), but the most likely outcome of this Medium post is that... it gets listed, and nothing else is done.
This is a crucial distinction between physical and mediated worlds.
If I show a snap in my wallet, or even displayed on my screen (mobile, desktop, projection), I'm providing a physical object or representation, and the recipient visualises it directly via reflected or emitted light. Cue childhood games over "can I see it" vs. 'can I hold it".
This also plays on the brain's very poor performance at photographic (figuratively and metaphorically) recall. Digital devices not merely excel at this, they'd be unusable without it.
Online "sharing" is actually a form of publishing, encoding, distribution, storage, retrieval, decoding, and projection, with, as a direct consequence, the possibility for further redistribution and modification. "Bradley Chait" and The Fappening, among far too many others.
A webpage isn't a book, it's a printing press (and presses are not archival mechanisms, though archives may have presses).
This distinction, between direct vs. mediated experience, lies at the heart of many misunderstandings and mishaps of online and digitised information, hitting the lay public, organisations and institutions, and domain experts alike. Our metaphors, mental models, laws, and social norms fail us
But there is no technical way to provide remote access to bits -- a publishing and distribution transaction -- without relenquishing control over the contents.
There are technical means of watermarking or tracing such leaks, and time-limited access helps somewhat, but absent changes to underlying social and legal norms, those alone are grossly insufficient.
If I show a snap in my wallet, or even displayed on my screen (mobile, desktop, projection), I'm providing a physical object or representation, and the recipient visualises it directly via reflected or emitted light. Cue childhood games over "can I see it" vs. 'can I hold it".
This also plays on the brain's very poor performance at photographic (figuratively and metaphorically) recall. Digital devices not merely excel at this, they'd be unusable without it.
Online "sharing" is actually a form of publishing, encoding, distribution, storage, retrieval, decoding, and projection, with, as a direct consequence, the possibility for further redistribution and modification. "Bradley Chait" and The Fappening, among far too many others.
A webpage isn't a book, it's a printing press (and presses are not archival mechanisms, though archives may have presses).
This distinction, between direct vs. mediated experience, lies at the heart of many misunderstandings and mishaps of online and digitised information, hitting the lay public, organisations and institutions, and domain experts alike. Our metaphors, mental models, laws, and social norms fail us
But there is no technical way to provide remote access to bits -- a publishing and distribution transaction -- without relenquishing control over the contents.
There are technical means of watermarking or tracing such leaks, and time-limited access helps somewhat, but absent changes to underlying social and legal norms, those alone are grossly insufficient.
Why not do it exactly like Drive, where you can choose between sharing by link, or sharing with Google accounts?
And then you get dozens of email from every friend requesting access to the photo, which you have to manually approve? Might work nicely for a document, but that would be a really shitty UX for sharing photos with friend group and relatives.
Why not do it like Facebook and make it totally impossible to turn a private photo into a public link without downloading the image and re-uploading it?
This isn't really about dealing with the case where the person you're sharing with is sharing without your consent.
The problem is really a case of data vs. metadata. If I get your browsing history it shouldn't give me access to all your private messages and private photos. As-described, getting access to metadata (urls) gives full access to data, which is not a good default behavior.
This isn't really about dealing with the case where the person you're sharing with is sharing without your consent.
The problem is really a case of data vs. metadata. If I get your browsing history it shouldn't give me access to all your private messages and private photos. As-described, getting access to metadata (urls) gives full access to data, which is not a good default behavior.
Facebook has an entirely different usage model. People have "profiles" and when you connect to someone's "profile", you see all their photos. Google Photos doesn't have an equivalent. Photos are in your account, and whenever you want, you share single ones, or group of them in an album, with friends. There's no concept of "friends" on Photos.
Well, you can already share photos with other Google accounts. It's even the default. You have to specifically click the "Create Link" button on the share page to do differently.
That is not what happens in the video.
In Photos, it looks like you can choose between the two, but actually sharing to a Google account also creates a link without making it explicit.
Oh, I see what you mean. It looks like if the person you share to doesn't use Photos, they get a link sent by email. It takes a pretty deep understanding to avoid sending a link.
It doesn't matter if the person you're sharing with is using Photos or not. Either way, a link is created, and you can access it without being logged in to a Google Account at all.
No, that's wrong, and that's the thing that's surprising here.
If you share with a Google account a globally shareable link is created and is emailed to the person.
If you share with a Google account a globally shareable link is created and is emailed to the person.
We all know as soon as content is presented to a user it can be copied, and I think with photos in particular users know how to do this easily (via screenshot, if nothing else). I could see the argument could be made that doing anything that makes it appear like you can revoke access in the future would be somewhere between misleading and pointless. Not saying the Google Photos sharing UX can't be improved, but doing much more than improving wording is probably not worthwhile.
I'm personally happy with URLs and text like "anyone with this url (including anyone they share it with) can view, download and copy the photo(s) you've selected".
I'm personally happy with URLs and text like "anyone with this url (including anyone they share it with) can view, download and copy the photo(s) you've selected".
I assumed that sharing photos the way he does in the video would limit access to that user, logged-in. I've been going to a lot more hassle by getting the URL, then manually creating an email with that link. So this interface is bad for people who want to make a sharable link and people who didn't want to make a sharable link. It should be clearer.
> 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.
The second these pictures are on anybodys devices they can be exported and forwarded... Are you implying Google Photos can stop them from doing this? Because it cant.
The second these pictures are on anybodys devices they can be exported and forwarded... Are you implying Google Photos can stop them from doing this? Because it cant.
> 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.
The problem is that it acts differently from and less transparently than a similar Google service for no apparent reason. You disagree with the offered solution that the behavior of Photos should match that of Drive, but do you agree there's a problem?
The problem is that it acts differently from and less transparently than a similar Google service for no apparent reason. You disagree with the offered solution that the behavior of Photos should match that of Drive, but do you agree there's a problem?
Ok, but the UI could easily offer both.
1) share with specific people
2) make public
It's not hard to understand, and it would be more explicit about what it is doing.
As it is it should provide a subtle notification imo, that the link generated is viewable by anyone.
1) share with specific people
2) make public
It's not hard to understand, and it would be more explicit about what it is doing.
As it is it should provide a subtle notification imo, that the link generated is viewable by anyone.
I mean they could just provide a link and a code and non-google accounts require the code... It should probably at least be an option.
I guess once you've shared those photos it's only trust that protects them anyway and in a group where you don't have full trust, you should assume that the photos are essentially public with only security by obscurity.
I mean the hash lengths and the blocking of people hitting random hashes is probably more significant and I imagine Google have considered it.
I guess once you've shared those photos it's only trust that protects them anyway and in a group where you don't have full trust, you should assume that the photos are essentially public with only security by obscurity.
I mean the hash lengths and the blocking of people hitting random hashes is probably more significant and I imagine Google have considered it.
FWIW when you create a public link for a photo or document or folder from OneDrive, you get an option to set an expiration date on the link.
I pretty much set all of my public links to expire after 30 days this way.
I pretty much set all of my public links to expire after 30 days this way.
Could add a simple security question. So when you want to share, you could create a question and an answer like:
What's my first name? John
Most people you share with would know that. It could add a small extra security layer.
What's my first name? John
Most people you share with would know that. It could add a small extra security layer.
If someone can see the photo they have the bits. Making them an explicit copy via email isn't really different. Most messaging apps even support saving the photos shared in them.
This isn't the link. It's the share to account
> perfectly valid way to secure a resource.
There are none. Once an endpoint has something, it's on their machine. Right click, Save As...
There are none. Once an endpoint has something, it's on their machine. Right click, Save As...
Flickr has had a feature for a long time now that tries to defeat "Save as". Of course, browsers' Dev Tools are a trivial workaround.
FWIW if you have a Flickr CDN URL then that too seems to work without any authentication. For instance: https://live.staticflickr.com/65535/48274947792_bf34cdc98a_o...
FWIW if you have a Flickr CDN URL then that too seems to work without any authentication. For instance: https://live.staticflickr.com/65535/48274947792_bf34cdc98a_o...
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.
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.
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?
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?
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.
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.
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.
[deleted]
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.
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.)
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.
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/
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/
What's the attack model under which this is better than what Google Photos does?
- You still have to give the people who access the photos the key, they can share it (just like the secret link)
- By entering it on the site, they also implicitly share it with the hosting provider (who morally shouldn't grab it, but that's not a security guarantee).
One attack model is the one described in the article, that the links leaks to someone where it shouldn't be. In that case, an encryption key that is set to expire[1], would limit the scope of that leak. Of course, if someone would screenshot the image it could be too late, so the attack model does not include people that know the key will expire...
[1]: https://www.w3.org/TR/encrypted-media/#expiration-time
[1]: https://www.w3.org/TR/encrypted-media/#expiration-time
Or you can make the link set to expire.
Your approach isn't solving any problems, but adds to confusion. Keep in mind Google Photos is a consumer product meant to be used by everyone between tech savvy teenagers and your grandmother.
Your approach isn't solving any problems, but adds to confusion. Keep in mind Google Photos is a consumer product meant to be used by everyone between tech savvy teenagers and your grandmother.
Unless you change your clock?
Why would the verifier change the clock?
If 'you' here is the key holder, changing clock isn't going to help.
If 'you' here is the key holder, changing clock isn't going to help.
What verifier? The scenario here is embedding an encrypted blob inside a static web page, and having the user input a key to decrypt inside their browser, right?
If you're going to have a server checking anything, you're on a whole different wavelength than this scheme. Why even use encryption at that point?
If you're going to have a server checking anything, you're on a whole different wavelength than this scheme. Why even use encryption at that point?
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.
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.
> functionally equivalent to a decryption key
Not from a security point of view.
Not from a security point of view.
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)?
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)?
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.
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.
Any URL with sufficient entropy is as unguessable as a password. The primary danger would be revocation if the user doesn’t realize their “password” has leaked.
If you're sharing the key the same as you'd share a URL, it is the same.
It’s an access token not a decryption key. The difference is you can’t download anything without the token, and the provider isn’t storing or serving ciphertext.
From an implementation standpoint, it means it’s trivial to expire or revoke to token without having to touch the data it grants access to. It can be an entirely separate authentication service.
From an implementation standpoint, it means it’s trivial to expire or revoke to token without having to touch the data it grants access to. It can be an entirely separate authentication service.
You can do images with javascript. It's slow since you don't have any hardware decryption. Wouldn't be a great mobile experience. You could build a site around limitations but if nothing else, it would eat up battery. There are probably faster javascript encryption libraries than what this random blog I found uses.
https://alicebobandmallory.com/articles/2010/10/14/encrypt-i...
https://alicebobandmallory.com/articles/2010/10/14/encrypt-i...
Why couldn’t that be easily circumvented by taking a snapshot of a screen? Even if the operating system disallowed screen shots of protected content, you could always take a picture of the screen.
Generally, you shouldn't be sharing your private photos with people who are actually trying to spread them past the intended audience.
The encryption in this case would be to protect against accidental sharing. A group of people that wants to share private photos among themselves could agree on a key which they all keep a copy of. Then they can upload photos encrypted with that key and pass around the links to those photos. Once the initial key is distributed all that they are passing around are links to the photos. If someone goofs and passes one of those links to someone outside the group, no harm done.
The encryption in this case would be to protect against accidental sharing. A group of people that wants to share private photos among themselves could agree on a key which they all keep a copy of. Then they can upload photos encrypted with that key and pass around the links to those photos. Once the initial key is distributed all that they are passing around are links to the photos. If someone goofs and passes one of those links to someone outside the group, no harm done.
But then these giant corporations do not have any incentive to provide service like photos for free. Currently Google is feeding all these user photos to create ML models. There AI is getting stronger with every photo upload. With the approach you suggested its impossible for them to use this data.
How does merely possessing a photo help ML? Wouldn’t you have to have known-to-be-correct metadata on the image as well for it to be useful?
Through something called Unsupervised Learning[1].
Have you ever noticed something in the world, and then later someone gives it a name, and you immediately understand how to identify it?
For example, did you know the little plastic table in the middle of a pizza is called a "box tent"? Now you know its name, but you've noticed it before and understood what it was just by seeing it, and combining those experiences with a bunch of other real-world knowledge that you've accumulated.
Same thing for unsupervised learning.
edit: and to underline how that can be scary, remember that people are uploading tons of personal photos, and so google's neural networks can learn to identify anything in those photos, add them to knowledge about who those people are, who they talk to and say over email or hangouts/video chat, where they go every day with their phone, the things they read about on the internet, etc, and someday (when the algorithms further improve) end up with a more complete understanding of who that person is than even their family members can possibly know.
And they are a publicly-traded company, so they have a "fiduciary duty" to use all that knowledge for profit, and we can rest assured our "the internet is a series of tubes" legislators aren't going to come up with reasonable rules about all this.
[1] https://en.wikipedia.org/wiki/Unsupervised_learning
Have you ever noticed something in the world, and then later someone gives it a name, and you immediately understand how to identify it?
For example, did you know the little plastic table in the middle of a pizza is called a "box tent"? Now you know its name, but you've noticed it before and understood what it was just by seeing it, and combining those experiences with a bunch of other real-world knowledge that you've accumulated.
Same thing for unsupervised learning.
edit: and to underline how that can be scary, remember that people are uploading tons of personal photos, and so google's neural networks can learn to identify anything in those photos, add them to knowledge about who those people are, who they talk to and say over email or hangouts/video chat, where they go every day with their phone, the things they read about on the internet, etc, and someday (when the algorithms further improve) end up with a more complete understanding of who that person is than even their family members can possibly know.
And they are a publicly-traded company, so they have a "fiduciary duty" to use all that knowledge for profit, and we can rest assured our "the internet is a series of tubes" legislators aren't going to come up with reasonable rules about all this.
[1] https://en.wikipedia.org/wiki/Unsupervised_learning
Thanks for this. Truly unexpected and fascinating!
[deleted]
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
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.
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.
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.
This would be an issue if it were mutable data.
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.
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).
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.
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.
Yes, but here you aren't sharing the picture to the public, you're sharing it to a specific person.
It's interesting to me that photos shares a link to a website, and doesn't send the photo itself to an app when shared. While Google's way allows for better privacy by allowing us to revoke access, this isn't clear to users
You can get similar behavior with Dropbox https://www.dropbox.com/s/pcutvzhj8nc4auu/indy_asleep.jpeg
And OneDrive: 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
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
{I assume Box has something similar but I don't feel like finding my creds}
Screenshots of the dialogs: 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
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.
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.
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.
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.
More like they want the same UI as Drive, as stated multiple times in the article?
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.
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.
Exactly. If it's a long enough url then the url is basically a secure password.
"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
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
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
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
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.
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.
I like 1 if it includes extended access available if you link an account (Option 2)
Either option feels incomplete without the other
Either option feels incomplete without the other
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.
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.
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.
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.
> 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.
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.
Sharing a photo means the recipient could be careless or malicious Ok? That's not Google's problem. The issue was that these are public facing URLs but at the end of the day the URL itself isn't what the user should worry about.
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
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.
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.
I don’t think anyone has solved access control, not Facebook, Google, OneDrive, or even Apple.
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
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
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
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
At the very bottom, the author mentions why the issue has become more relevant now: automatic sync between Photos and Drive has been turned off, so you can't workaround anymore by sharing the photo from Drive.
What does "2017" mean here? It's not the year of the article, it's from today.
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/
Reading that one closer I found https://www.theverge.com/2015/6/23/8830977/google-photos-sec...
Which is from 2015.
Reading that one closer I found https://www.theverge.com/2015/6/23/8830977/google-photos-sec...
Which is from 2015.
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.
That people keep rediscovering this issue and being surprised by it is says something.
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.
If people keep being being surprised by this and writing articles about it, I think it suggests that the behavior is not being communicated clearly.
And I do think that it isn't. It's reasonable behavior, and it might be expected by most people, but I still think that it is not being communicated clearly. I did expect the photos to still be gated behind an auth check, and they're not.
And I do think that it isn't. It's reasonable behavior, and it might be expected by most people, but I still think that it is not being communicated clearly. I did expect the photos to still be gated behind an auth check, and they're not.
"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.
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.
You're entitled to your beliefs and estimations, and I'm not offended by you disagreeing with mine.
[deleted]
This is old news though https://www.theverge.com/2015/6/23/8830977/google-photos-sec...
But I do agree, google can do better messaging that
But I do agree, google can do better messaging that
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.
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...
[1]https://www.theverge.com/2015/6/23/8830977/google-photos-sec...
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.
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).
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...
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.
Is there any practical way to review all the links to my shared Google Photos and maybe disable sharing of most of them quickly ?
for what its worth, github suffers from the same issue. it's a "feature"
Is this an actual risk? you would need to guess a link.
Serious question
Serious question
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.
Barring something extraordinary, it would be acknowledged as intentional behavior and classified wontfix. For most purposes, no, this is not an actual risk.
The Earth will be swallowed by the sun before you guess that GUID.
Ah, but if you network a bunch of cloud computing resources to guess in parallel...
Sorry, bad bug bounty memories. ;)
Sorry, bad bug bounty memories. ;)
What if, like, you had a quantum computer that could guess every password simultaneously? Checkmate, nerd. Give me my bounty.
Read the article?
> How could the ‘secret’ link end up in the wrong hands? Some possibilities:
> How could the ‘secret’ link end up in the wrong hands? Some possibilities:
1. An email thread / document with a link to the photo or album is forwarded or shared with the wrong person, or accidentally posted somewhere public.
2. The recipient naturally thinks the link is only works for them (as would be the case for Drive) and doesn’t take care to prevent it becoming public.
3. Links sent by emails are semi-public because they move across the internet unencrypted and are simple to intercept. It’s only OK to link to sensitive things by email if the recipient needs to be logged in to actually view them.
4. A database of these links is one day leaked or hacked, or people figure out a pattern in how the ‘secret’ URLs are generated.
5. Someone’s emails or other documents are hacked or leaked, with the link in them.[deleted]
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/
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/
[deleted]
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.