ACL permission interactions with Bitcache

I am using the ACL project "http://drupal.org/project/acl" as well as the View Own "http://drupal.org/project/view_own"
I am using rules/triggers/actions to change permission states based on time, workflows, publish states, etc..
I would mention role delegation for the record, but it shouldn't have anything to do with this.

By "bypass" I am referring to setting the permissions on the File such that the user cannot view, edit, or admin.
The bitcache list seems to show files that they should not be able to access, I can still view the file from: /bitcache/[id].
Perhaps it it showing only files that they themselves created, I will test and confirm this asap.

The design I am having to deal with is that a set of users can upload files but nobody, including the submitter, can view the file until some set time.

After repeatedly turning on and off permissions over a day or so, I noticed some cases where they do work as desired and where they do not.
I might have too many permission based modules installed and there may be some conflicts going on.
I'll have to create a clean server somewhere, do controlled tests, and then I will report anything I discover or close this as not a problem.

Before I get started, I tried both bitcache-beta2 and fileframework-alpha4.
I had issues with even the super-user being able to access any files at all.
I decided to perform all my tests with bitcache-beta1 and fileframework-alpha3.

The Test System
- A clean installation of drupal under a mysql database
- The following modules are the only modules added and installed:
acl bitcache cck content_access fileframework rdf views
- The test system contains two different users.
- The two different users each attached a single file to the same post, this was tested after the initial case tests were completed.

The Test Cases
I tested the following 3 permissions: View Attachment, List Bistream, and Access Bitstream.
These tests were performed on a single file owned by the tester.
During these tests, the View Any ACL is set to true for the pages and files being tested.
There are a told of 8 cases:
Case Number) View Attachment - List Bistream - Access Bistream
1) Y - Y - Y
2) Y - Y - N
3) Y - N - Y
4) Y - N - N
5) N - Y - Y
6) N - Y - N
7) N - N - Y
8) N - N - N

Test Case Results
1)
User could download file, User could view file, User could see /bitcache/
2)
User could download file, User cannot view file, User cannot see /bitcache/
3)
User could download file, User could view file, User could see /bitcache/
4)
User could download file, User could view file, User cannot see /bitcache/
5)
User could download file, User could view file, User could see /bitcache/
6)
User could download file, User could view file, User cannot see /bitcache/
7)
User could download file, User could view file, User could see /bitcache/
8)
User could download file, User could view file, User cannot see /bitcache/

Interpretation of Test Case Results
I was interpreting /bitcache/ as what the List Bistream permission was referring to, which is not the case.
In all cases where I could see /bitcache/, I was able to see the files that were uploaded by both users.
The /bitcache/ is clearly directly related to the Access Bitcache permission
I was originally interpreting the View Attachment as the ability to see the file that was uploaded.
This is not true, the View Attachment permission does not affect whether the file itself is viewable, but whether or not the file attachment is viewable from the page in which it is attached to. (That is to say, irregardless of the View Attachment setting, the File itself can be directly accessed by its node id)

Further Testing
Given that I have multiple users, I began to test when I only had View Own ACL on files instead of View All ACL on files as the above case had.
In these tests, I should not be able to see files owned by other people.
Using the same system as above:

1)
User could see own file; User cannot see others file; User could view /bitcache/; User could view own file via /bitcache/id/; User could view others file via /bitcache/id/
2)
User could see own file; User cannot see others file; User cannot view /bitcache/;
3)
User could see own file; User cannot see others file; User could view /bitcache/; User could view own file via /bitcache/id/; User could view others file via /bitcache/id/
4)
User could see own file; User cannot see others file; User cannot view /bitcache/;
5)
User could see own file; User cannot see others file; User could view /bitcache/; User could view own file via /bitcache/id/; User could view others file via /bitcache/id/
6)
User could see own file; User cannot see others file; User cannot view /bitcache/;
7)
User could see own file; User cannot see others file; User could view /bitcache/; User could view own file via /bitcache/id/; User could view others file via /bitcache/id/
8)
User could see own file; User cannot see others file; User cannot view /bitcache/;

These results are very straightforward.
If the user has no permissions to see the file, the file itself can still be accessed directly via bitcache.

Summary
While I misinterpreted the purpose of the List Bitstream and the View Attachments permissions, there still seems to be a problem with being able to access a File via bitcache despite the File permissions allowing such a thing to be done.

Unexpected Issue
While doing all of these refreshing and downloading for these tests, I noticed that the View & Download counters never went above 1.
I'll have to open a separate bug report when I get the chance to investigate this unexpected issue.

I managed to identify and solve the issue with using beta2 of bitcache, for the record see: http://drupal.org/node/408504#comment-1381136