I'm cross posting an issue here to let you guys know of this way:
Private and Public File Access
Banner.module isn't really guilty here. There are a lot more modules that do not work with private file access. If you need a quick workaround for a new site then setup your site with public file access and add a .htaccess file containing
SetHandler This_is_a_Drupal_security_line_do_not_remove
Deny from allto the directory below
/files containing your protected files, i.e. /files/protected or /files/store. If you're using E-Commerce file.module then you will find an separate option where files shall be stored in file settings. This way you'll have public file access to any files that are free (images and the like) and private file access to all protected, i.e. sold, files. Although file.module appends the real file path to the purchased file download link URL it won't be accessible by entering that file path directly.
If you already have a running site I badly suggest you to create a devel copy of it, change the global file handling, create some new protected files and have a look which files need to be moved and what needs to be changed to convert (fix) your productive site.
Some additional thoughts
I came to this solution for a site today. There were a lot more thoughts in the game - here comes the braindump:
- Only files to sell are likely to be private. No - Everyone who wants to protect a intellectual property might want to restrict downloading of files for certain user roles or the like.
- Global private file access does not provide a second location for public available files, i.e. images, documents and the like. Just one global public or private file access won't work out.
- Any module supporting private files should neither include a file path nor a file name. File access control has to be managed by $fid (currently) or $nid (if files were nodes or file access inherits node access).
- If each module would place its files to a separate folder, file access issues could be solved much easier.
All thoughts address default file access control which you'll find in use cases like selling files, where each file for sale has to have one default behaviour of file access. They do not bother with custom access for individual files which might be more in the spotlight of File API.

Comments
thoughts
Good reading. Some thoughts I have...
I was looking at E-Commerce file.module today, and I am relatively happy with how it is working. I have the files outside the webroot. I am interested in knowing more about potential security issues though.
Also, I am inclined to have the file.module name changed to ec_file.module so as to free up the "file" namespace for a more generic solution.
Sure it works
Yes, file.module is working. But having a publicly readable file path for purchased downloads isn't very secure. That opens up ways for attacks. Therefore private files should always retrieved by file id. Regarding ec_files I doubt that anyone really wants to store buyable files in a public area.
+1 for renaming files to ec_files. Definitely. I was somewhat surprised when I first installed it.
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
Another module
sIFR is another module that needs a public file storage to deliver automatically generated CSS files from /files.
So a new file API should be able to handle private files in a subdirectory of /files, f.e. /files/private.
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
I know this thread was
I know this thread was started a couple of years back but I don't think the file management issue has improved much since then - it is still very difficult to manage permissions for files, which can be very important in a security critical site.
what about the using x-send
what about the using x-send files http://drupal.org/project/xsend
Senior Drupal Developer at DrupalConnect
and the private_upload module
and the private_upload module ? http://drupal.org/project/private_upload
and this http://www.onyxbits.de/content/drupal-and-problem-protecting-uploaded-files