Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's not about url space or load balancing, but security. You do not want to serve user content from your primary domain:

* Even if you serve it with the correct content type and no-sniff headers some browsers can be tricked into running JS, and then you have XSS.

* Even in modern browsers it's defense in depth, in case you mess up your configuration or they have a bug.

* If malware gets past your scanners then your primary domain can get flagged.

* It looks like it's coming from a trusted domain: a PDF that claims to be from Google Drive and where the URL bar says drive.google.com looks legit in a way that one where the bar says googleusercontent.com does not.



I guess that’s all fair, but to be clear, I’m not proposing to host public-facing content. Only private content that can be viewed by authorized users who have the right first party cookie to allow it.

Public facing content could easily be hosted on the other domain for all of the reasons you listed, and third party cookies won’t matter then.

I appreciate you outlining the arguments. I know some other sites like Dropbox do the exact same thing with a user content domain.


Content that's limited to specific users can still be used for targeted attacks, so it doesn't help very much.


It would still say “drive.google.com”, not “google.com”, and if that isn’t enough of a hint for the target, googleusercontent.com won’t be either. In fact, people have heard of Google Drive. They know that means it isn't from Google. "googleusercontent" could be "Google content intended for users" for all someone knows.

So, I disagree here. The well-known name of Google Drive as a user file sharing service is much more meaningful as a warning at a glance.

There are also mitigations that could be put in place for file sharing, like requiring the user to have accepted a file sharing request from that account before (via Google sent notification email) for a direct link to actually work. This would be a great thing to have in place regardless of domain, for defense in depth. Unsolicited links to private files arguably should not work.

Obviously people may have different opinions on this stuff.


> There are also mitigations that could be put in place for file sharing, like requiring the user to have accepted a file sharing request from that account before (via Google sent notification email) for a direct link to actually work.

That sounds pretty annoying? I upload something, give access to coder543, and ping you a link in Slack or whatever tool we use. But you can't open it until you go into your email and click through?


Maybe my phrasing was awkward, but I said you would only have to do this once for a given account. So, if I've never accepted a share from you before, your links won't work. When you share something with me for the first time, I would have to accept it via a Google-sent email containing a link that only Google knows (not something that can be sent via slack), and then all your future share links would work for me on slack. The error page denying access could even indicate that the user should check their email for additional verification.

You can think of it as the equivalent of a friend request. "This person tried to share a file with you. Do you know this person? Are you sure you want to receive files from them?"

This is not some outlandish solution. This should not be "pretty annoying". Based on my own experience, most people would go months or years between seeing these emails, since people tend to share files with (and receive files from) the same people over and over.

Moreover, in a work context, you would probably be sharing links to files that are on a shared google drive that I have equal access to already, so that would not require additional verification. It's not an unsolicited link to someone else's Google Drive... it's a link to a drive that I already have read/write access to.


Do people want to have friend requests in Google? If I wanted to share a file to your Google account, would you like to trust the future shares automatically as well? It doesn't seem like the superior alternative to just using 3rd party cookies—other than that it works if 3rd party cookies are disabled.

It also provides a new attack vector (your friends) if such people are able to create more credible documents (e.g. due to an attack, not due to a deliberate intent to mislead you).


The alternative is trusting all shared links, which is currently what Google does. Third party cookies have nothing to do with it. Having some form of revokable authorization to be able to click on links from a person is superior to "all sketchy links working instantly."

If you get a Google Drive link by someone claiming to be a friend you know, you could download malware right now, because Google trusts all of these links equally. With this mitigation in place, you would be stopped: “hey, this isn’t someone you’ve ever received files from before.” Because they aren’t actually your friend using your friend’s account which you’ve received files from before. It would add a serious obstacle to a lot of these impersonation attacks, and I see impersonation attacks all the time.

My comment awhile ago said that this mitigation would be nice regardless of whether Google kept using their separate domain or not.

It absolutely doesn’t provide a new attack vector. It strictly serves to reduce the attack surface, not to increase it.


It’s not security for the end user

It’s security for Google

Back in the day, you could upload, for an example, a specially-crafted HTML file with your own malicious JS code to, for an example, an image hosting service and basically use them to serve your attack upload. You could more or less abuse any website upload form to host any file that that you wanted. It was bad.

Browsers have drastically improved but why risk it? Using a separate domain makes a lot of scary scenarios completely impossible.


This is correct.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: