File data URIs are currently undiscoverable (contain a large, random, unguessable secret) but not inaccessible: if you know the URL, you can download the data.
This approach makes the data CDN'able, and is similar to the system used by Facebook and Google for user content.
It's also unsafe to serve files from the primary domain, and installs with exposure should configure security.alternate-file-domain. We should also urge installs to do this more strongly (see T2380, T2382). One specific attack which serving file content from the same domain makes possible is that iPads which do not respect Content-Disposition will just execute Javascript in HTML file content, even when the server tells them to download it. There are similar attacks with Flash and Java which are more complicated but can affect more user agents.
I'm not aware of any practical attack against this system. It is computationally infeasible to enumerate the secrets.
That said, some installs find it uncomfortable that knowledge of a URL is sufficient to retrieve file data, and it is possible for these URLs to leak through side channels (log files, screenshots, accidental indexing, etc.) more easily than the file data itself can. We could pursue partial solutions (like generating URLs that are valid for a short duration) easily, but this won't address the root issue of the scheme "feeling" insecure because it lacks a formal authentication step.
Adding a formal authentication step is complicated. Particularly:
- Normal session cookies can not be present on the domain the file is served from, because this permits the class of user-content attacks above.
- Doing some sort of session handshake will break and/or ruin performance for files like profile images.