The point is that it's an arbitrary user submitted script. In this case it was just the time, but it could have easily been a botnet command and control message or some other malicious content.

It's standard security practice to serve user submitted content on a separate domain, so I'm a little surprised that Google isn't following it.

>It's standard security practice to serve user submitted content on a separate domain, so I'm a little surprised that Google isn't following it.

But it is being served under googleusercontent.com?

The parent comment isn't talking about the payload being returned, it's about what domain Google is hosting user content on.

The response from script.google.com is a 302 redirect to script.googleusercontent.com. IOW, google.com itself does not serve that user content.

But why does Google redirect that? Why not just return an error?

It's not like users will accidentally type in script.google.com and get mad if it fails. Those script URLs are being used only by app developers, who will test their apps and fix script source URLs that are broken. Calling a googleusercontent script at google.com should return a 4xx status code telling them to use the googleusercontent domain.

Google.com is a trusted domain. I don't think it should be 302'ing to untrusted domains for arbitrary URLs.

>Google.com is a trusted domain. I don't think it should be 302'ing to untrusted domains for arbitrary URLs.

I think you should read this again and then take a moment to think about the services people primarily visit google.com for.

Also, what exactly are "trusted domains"? Why do they matter to users clicking links?

On a website there's no way for an user to verify where a link is going to take them without actually clicking the link. The tooltip for example tends to be relatively easy to spoof.