+1

The URL's generated by your server are unique to your server and encrypted with a per-server key. There is NO way for someone outside of your server to find out what URL's (or generate new URLS) they can use to download things. If you are using HTTPS the url can not be sniffed. The only way for something to find the URL's is to run locally within the browser or something malicious running on the server itself. In either of those two cases, changing how we download something wouldn't change those attack vectors. The real crappy hard to address issue here is the inability to control Google's grabby little hands on any piece of private information they can get their hands on despite us issuing the required Headers and endpoints that should dissuade them from accessing/indexing this information in the first place.

But I agree this is still kind of a security issue, just a very specific one that can't be abused. Maybe we could investigate doing stuff with cookies, expiring the download link after a couple hours, requiring 2 calls to download an object (send a auth request and get a temporary download link), downloading the data via an authed POST request then combine the data in browser and download that version of the file. Many of these come with some drawbacks, tons of browser memory when downloading things, tab crashes on large objects, inefficient downloads, and bad links when a user tries to download from webmail after being on the page for a long time (laptops waking up). But among this there is likely a better solution.

EDIT: Many links in the product are generated this same way. The gal and contact images, file storage, downloads from workspaces, and soon attachments on calendars, tasks, contacts, and notes.