Anyone with the link could also share the link publicly. I think if your document contains sensitive information you should be restricting the access anyway.
Google Drive Found Leaking Private Data
51–60 of 78 posts
Re: Google Drive Found Leaking Private Data
#52Earlier quoted context omitted.
That's not the issue. Let's say Alice shares a link to a Drive doc with Bob, https://drive/secretlink . If that document has an embedded link to Eve's website, http://some/thirdparty , and Bob clicks the link, then Eve (as the administrator of the third-party site) will see the HTTP Referer as https://drive/secretlink , and she will be able to access Alice's document.
I think rishabhsagar's metaphor of security through obscurity is indeed the issue. If the secretlink protected only by the difficulty in guessing the URL, and not an additional layer authentication for the person you are sharing it with, then it amounts to hiding something (a key) in plain sight and hoping for the best. Granted, I'm unsure if Google has a mechanism to throttle/block attempts at guessing Drive URLs.
Google doesn't really need to throttle attempts at guessing Drive URLs - they are long enough that it is totally infeasible for anyone to guess them. The guessability of these links is not the weakest link in finding these documents - it's that they can easily be shared around and you don't know who has the link and who doesn't. This may be okay for your usage - it's a tradeoff between usability (it's easy to share such a link with your friends instead of granting each one permission individually) and security (your friends could forward the link to others without you knowing, which they couldn't do if you'd only granted them the permission).
Re: Google Drive Found Leaking Private Data
#53I've always wondered what percentage of people understood what "anyone with the link" meant as a security setting.
Re: Google Drive Found Leaking Private Data
#54HTTP referers are evil. I've been using RefControl[0] to block 3rd party referers for years now. [0] http://www.stardrifter.org/refcontrol/ The web wasn't built with privacy in mind. 3rd party cookies and HTTP Referers are just the low hanging fruit.
Why do you consider them evil? It's useful for a destination server to be given insight into the previous url and it doesn't expose any private information. I suppose one might consider their previous url private information, but if that's the case you've go a lot more to worry about than http referers.
More to worry about, such as?
URLs aren't protected any less than cookies are, and cookies are the standard way of securing login tokens.
Heck with URLs you get the 'secure flag' cookie option for free!
Re: Google Drive Found Leaking Private Data
#55I think the referrer info itself is a security hole. Browsers should disable it. Or, you can use a plugin for now.
Re: Google Drive Found Leaking Private Data
#56I didn't think "Anyone with link..." setting promised any kind of security. Honestly, I don't think this was a 'security hole', more like a digital equivalent of a home owner hiding house keys under the carpet, hoping no one will look.
If you had 2^64 carpets then the key would be pretty safe.
Re: Google Drive Found Leaking Private Data
#57Earlier quoted context omitted.
Yes, but it's reasonable to assume that if I keep a URL secret and it's a very long and complex URL, that nobody will be able to guess it and find the document. I mean after all, we assume that's true for passwords.
But we're more accepting of someone crawling our site trying random URLs than we are of people trying hundreds of passwords.
Not really. If you try to guess a long and complex URL or a long and complex password you will either move at a glacial pace or DOS the site.
URL-shortened links can be an issue, but raw google docs links have crypto-length randomy numbers.
Re: Google Drive Found Leaking Private Data
#58HTTP referers are evil. I've been using RefControl[0] to block 3rd party referers for years now. [0] http://www.stardrifter.org/refcontrol/ The web wasn't built with privacy in mind. 3rd party cookies and HTTP Referers are just the low hanging fruit.
Why do you consider them evil? It's useful for a destination server to be given insight into the previous url and it doesn't expose any private information. I suppose one might consider their previous url private information, but if that's the case you've go a lot more to worry about than http referers.
It's a violation of browsing privacy. It's noone's business how or why I arrived at a webpage.
Re: Google Drive Found Leaking Private Data
#59Earlier quoted context omitted.
That's not the issue. Let's say Alice shares a link to a Drive doc with Bob, https://drive/secretlink . If that document has an embedded link to Eve's website, http://some/thirdparty , and Bob clicks the link, then Eve (as the administrator of the third-party site) will see the HTTP Referer as https://drive/secretlink , and she will be able to access Alice's document.
I think rishabhsagar's metaphor of security through obscurity is indeed the issue. If the secretlink protected only by the difficulty in guessing the URL, and not an additional layer authentication for the person you are sharing it with, then it amounts to hiding something (a key) in plain sight and hoping for the best. Granted, I'm unsure if Google has a mechanism to throttle/block attempts at guessing Drive URLs.
I expect that they have a throttling mechanism, but nevertheless ...
I just checked one of my shared documents. It has a 44 long “random” string, it’s alphanumeric with a few symbols. It looks like a version of base64, but let’s assume that it has only 50 characters to choice, so there are 50^44 = 5.7E74 possible addresses (2.9E79 if we assume base64). (Assuming they are using something like a cryptographically secure pseudorandom number generator.)
There are 7E9 live person, and assume that each one share less than 1000 documents, so there are less than 7E12 used addresses. Only one in 5.7E74 / 7E12 = 4.2E66 address has a document.
For a brute force attack, lets assume that the attacker use each valid ipv4 address 256^4 = 4.3E9 to do 1000000 tries per second, so there are 4.3E15 tries per second.
So the expected time to guess an address is 4.2E66 / 43.E15=9.8E50 seconds, that is 3.1E43 years. (For comparison, the universe is only 1.4E10 years old.)
Re: Google Drive Found Leaking Private Data
#60That's a very poorly worded security setting. If you're building a service where people can share something set as "Anyone with link...", you really ought to make it very clear that means it's open for anyone to download. The setting should really be named 'Remove privacy settings - allow anyone to download'. 'with link' implies some level of security that just isn't there. Even if Google proxy links within the docum…
I've always thought of 'Anyone with the link' as functionally equivalent to 'Anyone.' I will continue to think so after this referrer-header change. The first time you email that link out, you have technologically released your ability to predict who will view the document (was the e-mail sent over secure channels end-to-end? Did it go to a trusted party who won't reshare it? Did you typo the e-mail address and send…
It provides as much security as you have trust in the people you share it with. If I set one of my documents to "anyone with the link" just so that I can access it when I'm not logged in, and I'm careful to not share the link with anyone else, then I'd argue that it's still provides some security because I trust myself.
If I shared a document with only you (directly, not using the "anyone with the link" permission), I couldn't stop you from taking a screenshot and sending that to whomever you pleased (or printing them out and leaving them in a conference room, like you suggested). Sharing documents online in general can be troubling if you don't trust the people you send them to. It's easier to share a link than share a screenshot, though, and a link would provide continued access going forward, and could remove deniability that the screenshot was faked.