Google's Unguessable URLs

Google secures photos using public but unguessable URLs:

So why is that public URL more secure than it looks? The short answer is that the URL is working as a password. Photos URLs are typically around 40 characters long, so if you wanted to scan all the possible combinations, you’d have to work through 1070 different combinations to get the right one, a problem on an astronomical scale. “There are enough combinations that it’s considered unguessable,” says Aravind Krishnaswamy, an engineering lead on Google Photos. “It’s much harder to guess than your password.”

It’s a perfectly valid security measure, although unsettling to some.

Tags: , ,

Posted on July 20, 2015 at 5:25 AM • 73 Comments

Comments

Anura • July 20, 2015 5:45 AM

It depends on what you are trying to protect against. If you want to protect against external websites scanning for photos, it works great. If you want to protect against your so-called friends sending pics of you nekid to their friends, then, it doesn’t provide as much false-sense of security as a system that requires you log in to view the photo. Really, though, for the sake of satisfying people with concerns, for purely business reasons, they should require an account that is whitelisted.

JdL • July 20, 2015 6:10 AM

I’m trying to figure out how 40 characters becomes 10^70 combinations. That works only if there are about 56 possible characters. URLs are case-insensitive, so you get 26 letters, 10 numbers, and still need 20 special characters that are legal in URL names. Didn’t know there are that many.

Ezequiel • July 20, 2015 6:15 AM

@Anura: Requiring accounts has a cost, both to Google (access management ain’t free), to sharers (several clicks to select who to share with; can’t share with people not in a certain list…) and to receivers (grandpas being asked for a password to look at kids pictures, or annoyed with spammy emails asking to set an account to see some video).

I would say that the last one is the highest cost. I had to rethink my Google+ picture sharing because of that. I think that right-click > Copy link > new email > control-V is simple, efficient, ties with learned good behaviour.

Simon Brunning • July 20, 2015 6:16 AM

AFAIK the path component of URLs are case sensitive, or at least can be – it’s for the server to decide. The domain name (host) subcomponent is indeed case insensitive.

Anura • July 20, 2015 6:26 AM

@Simon Brunning, @JdL

Simon is correct, URLs are case sensitive (although the server software might treat them otherwise). 52^40 ~= 10^70

URLs in general are case-sensitive (with the exception of machine names). There may be URLs, or parts of URLs, where case doesn’t matter, but identifying these may not be easy. Users should always consider that URLs are case-sensitive.

http://www.w3.org/TR/WD-html40-970708/htmlweb.html

Peter • July 20, 2015 6:31 AM

It’s only secure with respect to any specific photo. If I told you I uploaded a photo and you had to try to find the URL of that specific photo, yes, that would be nearly impossible. But if your goal was just to access other people’s photos without their permission, that is very easy, so I wouldn’t say the system is entirely secure.

Clive Robinson • July 20, 2015 6:39 AM

The problem is how these supposadly unguessable URL’s are generated.

If you think about it, the process is going to be determanistic in some way. Simply generating a random number and using it is not going to work because of the risk of getting the same number twice, and with the number of photos Google has stored checking the random number has not been used is not realistic.

So it could be either a hash or a keyed crypto algorithm used in CTR mode. Thus if the counter value becomes known a third party can generate valid URLs if it’s a hash and the same for a crypto algorithm if the key becomes known as well.

However I think Google may have missed a trick… imagine if they used a crypto algorithm, where part of the seed value was a timestamp of some form. Because they know the key they could decrypt the URL and if the timestamp had expired not deliver up the photo. Thus they could ask a user how long they wanted the URL to remain valid.

A further trick they could add would be to watermark the photo with the IP address of the requesting client, thus adding a canary if the photo it’s self then gets used in a more public way.

Leigh • July 20, 2015 6:43 AM

Suppose it depends on the threat case – a targeted attack against an individual is infeasible, but your personal data being accessed by someone else is certainly possible at least.

Anura • July 20, 2015 6:49 AM

@Clive Robinson

Take a hash of the photo and you are probably pretty good. Add the user ID, post time with microseconds, and 16 bytes from /dev/urandom and I don’t forsee anyone being able to attack it.

Winter • July 20, 2015 6:50 AM

@Clive
I have used the same trick. It is easy to generate reasonably good strings that can be prepended to the filename.

dd if=/dev/urandom count=1 count=1 2>/dev/null |sha256sum | sed ‘s/ -//g’

You can also reformat the string into something that uses [A-Z0-9] io Hex to make it more compact (that is what I do).

Rusty • July 20, 2015 6:58 AM

Peter, that’s going to depend a lot on how sparse the dataset of photos is, and what Google is doing in the way of IDS. If Google receives 100 Billion photos a day, and randomly assigns a URL to each, it will take 10^(70-11) days to completely fill the possible dataset. I don’t know what Google’s actual volume of new photos is, but I do suspect that it’s fewer than that. If the set already includes a Septillion (10^18), that would suggest that within the dataset there is 10^52 possible combinations that are not in use.

On the IDS side, if over a 2 day period more than 10% of the queries you submit match one of the not-in-use entries, your address goes into a bucket of possible botnet hosts, and to get out of it, you need to either pay a fee associated with your account with Google, or you have to make 5 valid image requests that are not images that have been used to get out of the bot bucket. Repeat offenders within a period of time get to double that fee, or fill, each time they end up in the bucket.

lm • July 20, 2015 7:02 AM

What about the referer from the HTTP header?
The URL could be leaked and indexed by search engines or any other webserver…

Which means that high volume websites (such as google) would be able to obtain those anyway from their users headers anyway…

Leon Zandman • July 20, 2015 7:07 AM

Do these links expire? How can I prevent them to be accessed in the future? When someone has the URL, they have access to the photo forever. Even when I change my password or change sharing options.

Facebook has similar problems. When I have the CDN URL of an image, I can access it even when someone puts it back to private or unfriends me.

b • July 20, 2015 7:08 AM

It shouldn’t be public in first place, a random 40 char. string would reveal someone’s photo, If someone were to try say a handful 20 combinations it would result in say 5 photos, that can be uploaded to imgur or others, possibly revealing 5 different persons. Google would say not every combination would result in a photo, because it is not saturated yet.

Anura • July 20, 2015 7:19 AM

@b

A random 40 character, case sensitive, alphanumeric string is equivalent to approximately a 238-bit key, which you will never be able to upload enough images where one is guessable in a reasonable amount of time as long as it uses a good quality random number generator.

Winter • July 20, 2015 7:20 AM

@b
“It shouldn’t be public in first place, a random 40 char. string would reveal someone’s photo, If someone were to try say a handful 20 combinations it would result in say 5 photos, that can be uploaded to imgur or others, possibly revealing 5 different persons.”

40 character ~ 10^70 ~ 232 bits

As far as I know, 232 bits is safe.

I understand the Internet stores in the order of 10^20 ~ 2^66 bytes (give or take a few orders). That is around 10^50 ~ 2^166 tries for each byte if they all used this scheme.

Wesley • July 20, 2015 7:22 AM

For those people arguing that it’s a security hole because Alice can share a link with Bob and he can see the image without an established user session, this makes Alice a malicious (or dumb) user. She has access to the bytes, once that occurs she can download the image, screenshot it, use a clipping service such as evernote, the list goes on and on. The point is once you’ve given someone access to the bytes, there is very little you can do to prevent them from duplicating and distributing them.

I would even go so far as to argue that the simplistic nature of this security model, in many ways, makes it more secure than a dynamic web service that’s validating a user session before serving the bytes. That dynamic service is built a lot more infrastructure that accepts inputs which could ultimately be exploit the system. The static CDN model has far less. However this is just my opinion and ultimately speculation.

Winter • July 20, 2015 7:27 AM

@Wesley
“I would even go so far as to argue that the simplistic nature of this security model, in many ways, makes it more secure than a dynamic web service that’s validating a user session before serving the bytes.”

This system is as secure as access to the directory listings of the server. That is, the Web server. But that holds too for every online login scheme.

Winter • July 20, 2015 7:29 AM

PS:
The really big advantage of this scheme is that it can be made as fine grained as you want. You can add the “Secret” string at the file level, or any of the higher up directories.

Paul • July 20, 2015 7:34 AM

@Rusty/Peter I think that it is even more unlikely to guess an id: if there are 10^18 images out of a 10^70 space, then there is only a 10^18/10^70 = 10^-52 chance of guessing an id to any of them (assuming perfect randomness).

HacKan • July 20, 2015 7:35 AM

Yes, those kind of urls are like pwds. Usually i wouldn’t mind because realise they’re secure. However, given the infamous amount of pics that Google handles, I would require some extra proof that the prob of throwing a random url and getting a picture is negligible. Getting the pic you specifically want might be impossible tough. As long as those url are randomly generated. Do they depend on username? Is the combinations space 10^70 shared with everybody or per user?

JB • July 20, 2015 7:38 AM

As I understand it from the article, there are “around 40” characters in each URL. So it’s really 52^40 + 52^39 + 52^41 or so.

Not a significant increase from a security standpoint, but significant from a “we’re really far from saturation so querying a random URL is unlikely to reach any image at all” standpoint.

jbmartin6 • July 20, 2015 7:39 AM

A lot of the commenters are missing a key word in the article: “public” These are photos that are made public. i.e. the user has already decided that anyone can see them. The purpose of the URL pattern is to prevent someone from easily browsing through a specific user’s public photos. Since that is the case, this measure is more than good enough.

Leon Zandman • July 20, 2015 7:48 AM

No, you are missing the point. The photos aren’t always public. Instead, they are accessible thorough a public URL. Though this technically makes them public, the whole controversy about this is that even private photos can get such a public URL. Without the user making them explicitly public.

HacKan • July 20, 2015 7:55 AM

“only a tiny portion of Google Photos pictures are actually placed on public URLs”
That answers my question. It’s perfectly secure then… as much as we can have posting pictures online

Winter • July 20, 2015 8:23 AM

It would not do to use a hash of the picture itself to generate the URL (without a good secure “password”). Because then it would be possible to see whether a certain picture has been posted online.

I can see situations where that might be not be wanted.

Robert • July 20, 2015 8:29 AM

That kind of URLs are as secure as the old practice of using URLs with session ids parameters to avoid the use of cookies. People share them by mistake not knowing those were private pages not shared to the public.

Matt8 • July 20, 2015 9:00 AM

jbmartin6, you are incorrect. Any photo you upload to Google Photos, once clicked, is on a public URL. Has nothing to do with security settings.

(Read the article)

Sergiy • July 20, 2015 9:05 AM

As far as security is concerned, I think it’s exactly like storing passwords in plaintext on the server. Strong enough maybe, from the outside. But once inside you can list all the directories.

Roflo • July 20, 2015 9:19 AM

@JB I just counted 44 characters in one of my public images. I wonder if “around” could also be 36 chars.

Ian Eiloart • July 20, 2015 9:46 AM

Actually, JdL URLs are only case insensitive if that’s how the server is configured. The domains are case insensitive, as is the protocol, but the rest is not necessarily so. If you follow back to the reddit post that started this conversation, it links to a photo at https://lh3.googleusercontent.com/oi4G9ZBYeNfT88o-N4UxSjXHaFsUS51f6YY94gOXHQZQ=w493-h657-no which cannot be found at https://lh3.googleusercontent.com/oJ4G9ZBYeNfT88o-N4UxSjXHaFsUS51f6YY94gOXHQZQ=w493-h657-no (note I changed the case of the first “j” in the url.

George • July 20, 2015 9:50 AM

This isn’t new — Flickr and other P2P file sharing sites have been doing this for years. Why is Google getting this undeserved attention?

Thunderbird • July 20, 2015 10:18 AM

(note I changed the case of the first “j” in the url.

Well, to be precise, you changed the lowercase “I” to an uppercase “J”, so I don’t think you tested what you thought you did….

Daniel • July 20, 2015 11:54 AM

Bruce writes, “although unsettling to some”

To whom? Personally, I wouldn’t put a photo online to spare my life so it’s unclear to me why anyone would be unsettled by a practice that protects pictures online.

FOAMYPEER • July 20, 2015 11:55 AM

Isn’t this the same principle owncloud has been using for quite some time now to generate public urls?

FOAMYPEER • July 20, 2015 11:57 AM

Sorry, I hadn’t read George’s comment before posting mine, but yeah… this is not new, and it’s certainly not google’s concept.

Coz • July 20, 2015 12:01 PM

This seems like a terrible design decision and it’s not secure at all, in that you have a very good chance of getting a random image, maybe not the one you want but still a random image and there’s a possibility (however remote) you’ll hit the ‘jackpot’. The same happened with Imgur and random urls too: http://imgur.kosiru.com/

Curious • July 20, 2015 1:23 PM

I am wondering: could it possibly be a security issue of sorts, if the obscure url’s contained hidden information?

Clive Robinson • July 20, 2015 2:58 PM

@ Ryan,

224-bits of security? That’s better than… most things

No it’s not.

The assumption is “224-bits” of “random”, the reality is actually we don’t know.

It could be 224 bits out of a 40bit key cipher –that is weak to meet original US Wassenaar Agrement crypto limitations– that contains your account identifier and say a five digit number to identify which of your photos it is… Likewise it could be a copy of the state array of a stream generator say a minimised 6bit version of RC4 (ie 64x6bit giving a 384bit state array but only some values used).

We don’t know how the URL “unique” identifer string is generated, and untill we do we cannot say how strong or weak it is, in it’s own right and for this particular application.

We do know that Google has a very very preditory nature to peoples personal data, we assume for some form of financial gain, but we don’t know how. Thus linking people together by the URL identifier would provide very valuable information (think of refering page etc etc as a start point.).

Thus it’s not an unreasonable assumption to make that it’s not random, but just random looking and is an encrypted string for which Google has the key to convert it back to valuable plaintext.

Gweihir • July 20, 2015 3:26 PM

I have been doing that since running my own web-server, i.e. something like 10 years ago. Some understanding of security fundamentals required, but then it is a really obvious solution.

Thomas • July 20, 2015 4:01 PM

It’s as secure as a password that cannot be changed, i.e. “perfectly safe until it isn’t at all”.

Once the “password” is exposed (through sharing, deliberately or inadvertently (dodgy proxy (superfish), browser history, malicious browser plug-in, …)) you can’t change it to restore security (which, arguably, won’t matter much anyway because you can’t un-ring the bell).

Another way to expose the password is by password guessing, perhaps facilitated by knowing the password generation algorithm.
Something like “hash(secret|username|timestamp)” could be problematic if/when the secret is exposed.

Steven C. • July 20, 2015 4:21 PM

URLs (or rather URIs) like this should be secure in theory, but in some situations they will fail to remain private.

I seem to remember Skype (either its client or servers) was caught collecting https URLs shared via private chat, and then Microsoft servers would ‘scan’ them as a supposed security measure. They were therefore in a position to log and surveil private URLs such as these.

I guess there are many browser toolbars, auto-suggestion features – or corporate or public institution firewalls doing SSL MITM – that would happily collect private URLs or disclose them to third parties.

0110 • July 20, 2015 4:22 PM

This seems like a terrible design decision and it’s not secure at all, in that you have a very good chance of getting a random image

You are wrong.

Let’s just assume there a 10,000,000,000 (1e10) people living on Earth. (And not the actual count of around 7.28 billion on January 1st, 2015.)
And let’s just say everyone of them has a Google account.
Also let’s imagine that each and every one of those humans are going to upload 100,000… ok, scratch that, 1,000,000… ah whatever, 10,000,000 (1e7) photos.

So that’s 1e10*1e7=1e17 photos uploaded to the servers of Google.

Now let’s take this number and divide it by 62^40 which is the number of combinations (26 lowercase letters + 26 uppercase letters + 10 digits). 62^40 is by the way almost 5*1e71 which is even greater than the mentioned 1e70.

What you get is the possibility to find one photo: ~2*e-55
Or in percentage:
0.0000000000000000000000000000000000000000000000000000002015266196%

Which really is incredibly small.

Now take into account that:

  • Only after a user right-clicks on one of their own images it will be accessible through a URL. So a really high percentage of the 1e17 photos would actually not be publicly accessible.
    And this by the way makes sense because the reason for you right-clicking on the image in the first place is because you want to use/share it somewhere. Somewhere else than on the Photos app or website. Which is why you need a URL.
  • Google with all it’s knowledge from reCAPTCHA and it’s machine learning and stuff (hey, it’s Google!) will be able to effectively limit bots trying out every possible combination.

Which leaves me with the impression that this system is really really really secure.

Nathan • July 20, 2015 5:05 PM

On my Android phone, if the selection of photos that I want to share is large, Google arbitrarily sends the link via their URL shortening service. I’m usually trying to send via Gmail so might have hit the attachment size limit. However, the point is that the really long URL is made significantly shorter. I realise it’s still very complex, but it’s much shorter nonetheless!

Shortened…
https://goo.gl/photos/jSsG3KVvebh67tf41

Leads to…
https://photos.google.com/share/AF1QipPkxdamWChgUtwnzd-P4SL7SQApNzzU8bpiEiT6f1meynIpMg9x6KYGXiaQ0ExQBQ? key=SWVKYzBHbTFobGxZSUhu7yhugy54rdfyg78j92e3

I altered the URLs above so they don’t show you my cats and probably lead nowhere!

Rusty • July 20, 2015 5:19 PM

@PhilS – Your choice, correct for 10^24, or correct for whatever the mnemonic is for 10^18. As others have pointed out, the odds of finding a 40 character string that matches an image, whether sequentially, or randomly, is rather low. No, it’s not impossible, but if you’re getting images that way, you should probably be buying lottery tickets.

65535 • July 20, 2015 5:25 PM

@ Clive

“No it’s not. The assumption is “224-bits” of “random”, the reality is actually we don’t know. It could be 224 bits out of a 40bit key cipher –that is weak to meet original US Wassenaar Agrement crypto limitations– that contains your account identifier and say a five digit number to identify which of your photos it is… Likewise it could be a copy of the state array of a stream generator say a minimised 6bit version of RC4 (ie 64x6bit giving a 384bit state array but only some values used). We don’t know how the URL “unique” identifer string is generated…”

I agree. We simply don’t know how Google does it. But, I have a different angle.

Google most likely complies with CALEA and the NSA version [they use secret administrative warrants].

CALEA

“CALEA’s purpose is to enhance the ability of law enforcement agencies to conduct electronic surveillance by requiring that telecommunications carriers and manufacturers of telecommunications equipment modify and design their equipment, facilities, and services to ensure that they have built-in surveillance capabilities, allowing federal agencies to wiretap any telephone traffic; it has since been extended to cover broadband internet and VoIP traffic. Some government agencies argue that it covers monitoring communications rather than just tapping specific lines and that not all CALEA-based access requires a warrant.” -Wikipedia

https://en.wikipedia.org/wiki/Communications_Assistance_for_Law_Enforcement_Act

eugeny • July 20, 2015 6:19 PM

Yeah right, but browser(or extension) pass all urls to google and this lead a possibility to be indexed anyway

Jordan • July 20, 2015 6:55 PM

Why in the world would they go to the trouble of putting encrypted data into these URLs? That’s a pain, and somebody might figure out how to decrypt them. What, if they have the space to store a gazillion photographs they don’t have the space for a gazillion database records that say who each one belongs to?

Similarly, who’s to say whether those URLs are revocable? (I don’t happen to know whether Google’s are.) Maybe they are only aliases, and if you turn off the “public” flag they are simply deleted. If you turn the “public” flag back on, maybe you get the same URL, or maybe not. For that matter, again, they may or may not be using a dumb web server to serve those pictures. Maybe accesses through that URL are access-checked, so that only authorized people can access them… and for “public”, that list is “everybody”.

None of this is technologically hard, especially when you have the experience with scaling that Google does.

MITM • July 20, 2015 7:12 PM

It may be too difficult to guess a photo’s URL, but it is probably quite easy to harvest it if one can eavesdrop on the communication. Any man-in-the-middle, such as an ISP, malware-infested router, WiFi eavesdropper or nation state agency, can collect Google photo URLs. Even if the request to Google is secured by HTTPS, a friend forwarding the URL to a third party will leak it. Why guess when you can harvest?

Dirk Praet • July 20, 2015 7:26 PM

@ Winter

dd if=/dev/urandom count=1 count=1 2>/dev/null |sha256sum | sed ‘s/ -//g’

Thanks for that. Comes in handy from time to time.

Matt • July 20, 2015 7:35 PM

To everyone saying sniffing/MITM, etc. If they do that they have the picture anyway. Having the URL as well doesn’t give me much (any) more.

To those saying that the “password” is irrevocable, so is the photo. If you give them the photo once, you can’t revoke it, so I can’t see the benefit of revoking the URL.

To those worrying about referrer headers, unless you follow a link from the photo page, I don’t see the issue. Browsers also strip cross-domain referrer headers when navigating from HTTPS.

@Jordan: you are totally missing the point. This is about sharing without the overhead of setting up ACLs, or even requiring the recipient to have an account. As for irrevocability, see above.

@coz: No, the maths doesn’t add up. You have a better chance of winning the lotto than getting any picture by random guessing. If you think your point is still valid, please post up some maths.

Finn • July 20, 2015 8:08 PM

There’s an interesting offshoot from Google execs little chat with Assange of Europeans fame. Two opposing paradigms little summit talk of sorts that went over this topic if an “internet hash” where knowledge is presented as memes to the connected web of things. Impressions shared is friend of friend by access. Your meme is whoever you share it with plus whoever they choose to share with.

Anura • July 20, 2015 8:44 PM

@Winter, @Dirk Praet

If you want base 62, and you don’t really care how long it is, you can just do this:

head -c32 /dev/urandom | base64 | sed ‘s/[/+=]//g’
(I prefer head; less typing, no extra output, but the -c switch is non-standard)

If you are concerned about the quality of /dev/urandom, I guess you can output more and run through sha256, but it’s more typing that way:

head -c512 /dev/urandom | sha256sum | sed ‘s/[ -]//g’ | xxd -r -ps | base64 | sed ‘s/[/+=]//g’

Thoth • July 20, 2015 11:59 PM

Any direct URL in targeted or dragnet style gobbling is a bad idea.

Let’s say we issue something like “fakedomain/fakeimg.jpg”, anyone could directly link into it and grab the image. If the URL is “fakedomain/fakeimg/download”, it will be harder to target but not impossible as it is still linked to “fakedomain/fakeimg.jpg”.

Can a user do a sweep on “fakedomain/fakeimg/” folder to attempt to guess and grab all permutations of objects inside ? Does the server prevent something like a “bruteforce guessing” on the web objects ? These can be easily implemented on very high resources on targeted or even dragnet operations with enough motivation to compromise a website (not just individual web objects) and if the returns are high, why wouldn’t anyone build such approaches ?

Google needs to improve on it’s privacy and security mechanism to only generate a session based URL when requested by the user instead of predicting and placing a public URL in advance. The session based URL must have a timestamp limit for the other party to download the images and then dump or even recycle the session URL. An unlimited access without timestamp control meant that anyone can simply walk in to download the resource and can have bad consequences of the privacy (if it is dragnet prevention defense).

Winter • July 21, 2015 2:25 AM

@Anura
“head -c512 /dev/urandom | sha256sum | sed ‘s/[ -]//g’ | xxd -r -ps | base64 | sed ‘s/[/+=]//g'”

Thanks.

Werner Almesberger • July 21, 2015 5:45 AM

Funny that this would be considered “new”. Hidden directories or files are an ancient tradition on any system that can distinguish between looking up a name in a directory and listing that directory, and using a hash for the name is a pretty obvious extension. I’ve been using this for many years and I’m pretty sure I didn’t invent the concept.

The main weaknesses are that the recipients
– may not realize that the information (in this case, the picture), is meant to be kept non-public – after all, they didn’t need any login or such,
– may be unaware that the URL itself is to be treated as a secret,
– may not have proper operational security regarding URLs containing secrets (as Winter pointed out),
– will find it easy to share the information, whether they’re aware that it’s a secret or not.

The great benefits are of course its simplicity and convenience.

  • Werner

65535 • July 21, 2015 10:37 AM

@ Jordan

“…who’s to say whether those URLs are revocable? (I don’t happen to know whether Google’s are.) Maybe they are only aliases, and if you turn off the “public” flag they are simply deleted. If you turn the “public” flag back on, maybe you get the same URL, or maybe not. For that matter, again, they may or may not be using a dumb web server to serve those pictures. Maybe accesses through that URL are access-checked, so that only authorized people can access them… and for “public”, that list is “everybody”. None of this is technologically hard, especially when you have the experience with scaling that Google does.”

That is a good point. I suspect that if the government wants your pictures and other Google data they will get it. Google most likely falls under CALEA no matter how you look at it.

@ Matt

“To everyone saying sniffing/MITM, etc. If they do that they have the picture anyway. Having the URL as well doesn’t give me much (any) more. To those saying that the “password” is irrevocable, so is the photo. If you give them the photo once, you can’t revoke it, so I can’t see the benefit of revoking the URL.”

I agree. Once Google indexes your picture they can then sell it or turn it over to the government [for a fee] regardless of the “revocable” URL.

@ Thoth

“Let’s say we issue something like “fakedomain/fakeimg.jpg”, anyone could directly link into it and grab the image. If the URL is “fakedomain/fakeimg/download”, it will be harder to target but not impossible as it is still linked to “fakedomain/fakeimg.jpg”… An unlimited access without timestamp control meant that anyone can simply walk in to download the resource and can have bad consequences of the privacy (if it is dragnet prevention defense).”

Good point. I believe state actors and companies in the spy business figure out the long and supposedly encrypted URL but the average script kiddy cannot [but I could be wrong].

[other]

“A government task force is now preparing legislation that would fix all that by putting the screws on companies such as Facebook and Google, forcing them to enable law enforcement to intercept communications in real time, according to The Washington Post. The proposal is designed to expand the reach of CALEA, the 1994 Communications Assistance for Law Enforcement Act.” –nakedsecurity

https://nakedsecurity.sophos.com/2013/05/01/us-google-facebook-bacldoors/

CNET News.com asked telecommunications and Internet companies about cooperation with the Bush administration’s domestic eavesdropping scheme. We asked them: “Have you turned over information or opened up your networks to the NSA without being compelled by law?” -CNET via zdnet

Company: Google
Response: Declined comment

See CNET table:
http://www.zdnet.com/article/some-companies-helped-the-nsa-but-which/

Quake • July 21, 2015 12:06 PM

@JdL: Your platform bias is showing! 🙂 Windows IIS doesn’t distinguish case on URL params, and FQDNs are not case sensitive on any OS; however, on Linux the URL (after the FQDN) is case sensitive, there are ways to tune that out, but the OS and Apache are case-sensitive. Enjoy your number crunching …

65535 • July 21, 2015 5:45 PM

@ Quake

“…Windows IIS doesn’t distinguish case on URL params, and FQDNs are not case sensitive on any OS… on Linux the URL (after the FQDN) is case sensitive, there are ways to tune that out, but the OS and Apache are case-sensitive. Enjoy your number crunching …”

Good catch.

There are a lot of N-stack combinations. I have a client who runs Windows as the base OS, WAMP stack, and a very well know blogging software pack on the top.

Is this url thing a combination? Permutation or some odd Markov chain? Anyone here care to run the numbers?

Huckleberry • July 22, 2015 8:12 PM

What many ppl here do/don’t get is this isn’t useful for securing nor privacy your digits. This us making ease of keeping tabs on your links, relational, views, and impressions. Google’s mastering act to fame. Who seen it, who passed it on, virality, as memes and studies of hinges on going viral with your and our shared digits.

Tom Le • July 24, 2015 2:32 AM

Unguessable != access control.

Event logs anybody? Browser history? Networking sniffing for URL’s? Easy to discover the URL’s without guessing.

a name goes here • July 27, 2015 5:51 AM

Perhaps the odds of finding a specific photo are 1 in 10^70, but what are the odds of finding random private photos? Probably much higher.

Reminds me of a while back when some people who made a script that would automatically try random Imgur image deletion URLs and they actually forced Imgur to limit the number of deletion requests each IP address can make in a given period of time. They were successful in deleting some random images.

John • February 16, 2017 9:34 PM

Hello there!

Sorry to dig up this post… But I do want to point out one previous comment that – to my surprise – was not reacted to.

https://www.schneier.com/blog/archives/2015/07/googles_unguess.html#c6701301

E.g.
One shared album of mine has a URL of 115 characters after the “https://photos.google.com/share/” part. Eve when I click on “Sharing options” the link is reduced to 17 characters after the “https://goo.gl/photos/” by the google URL shortener.

How come this is not a problem? Isn’t the result that the URL is much more guessable?

The problem is even bigger since this is an ALLBUM link (exposing multiple photos), not “only” a 1-photo link.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.