Google Photos is making photos semi-public
medium.com
medium.com
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.
If you share with a Google account a globally shareable link is created and is emailed to the person.
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.
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.
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 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.
Back in the days us geeks would just fire up a web-server and call it a day.
What happened?
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.
Most people have simply realized that isn't any fun. But if you want to, go ahead.
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?
What's my first name? John
Most people you share with would know that. It could add a small extra security layer.
I pretty much set all of my public links to expire after 30 days this way.
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").
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.
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?
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".
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.
There are none. Once an endpoint has something, it's on their machine. Right click, Save As...
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'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.
(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.
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.
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.
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.
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.
In fact, this UI is basically identical to the Drive UI, including separating the functionality of creating a public, shared link and sharing with a specific person. It's downright surprising that Google Photos acts in a different way than Drive here.
This looks like a bug. Is it documented anywhere?
This is very confusing to me, and I like to think I get authentication models. If having the link is the same as being a member, what's the point of being a member?
Just a guess, but I'm betting this is an issue with how compartmentalized Google is within itself, that it was just simply two different people had two different solutions to how "links to objects" should work and it simply never occurred to either of them to check what the other products are doing.
That said, I was under the impression Facebook's CDNs did support auth checks from cookies, such that passing URLs around didn't bypass this. So I kinda doubt the claim.
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.)
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?
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.
Not from a security point of view.
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)?
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.
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.
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.
https://alicebobandmallory.com/articles/2010/10/14/encrypt-i...
If 'you' here is the key holder, changing clock isn't going to help.
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?
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.
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.
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 would be an issue if it were mutable data.
{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 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.
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.
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.
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.
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
Either option feels incomplete without the other
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.
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.
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.
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.
I don’t think anyone has solved access control, not Facebook, Google, OneDrive, or even Apple.
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
Reading that one closer I found https://www.theverge.com/2015/6/23/8830977/google-photos-sec...
Which is from 2015.
That people keep rediscovering this issue and being surprised by it is says something.
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.
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.
But I do agree, google can do better messaging that
[1]https://www.theverge.com/2015/6/23/8830977/google-photos-sec...
Serious question
> 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.Barring something extraordinary, it would be acknowledged as intentional behavior and classified wontfix. For most purposes, no, this is not an actual risk.
Sorry, bad bug bounty memories. ;)
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.