Here on the Vault team, we like Star Trek as much as the next group of computer programmers, which partly explains how we came up with the name "Cloaked" for one of the File properties. The concept is that there is a file in the Vault that the logged-in user does not have read access to. At an API level, you can detect that the file exists, but you can't get any useful information from it. When this happens, we refer to the file as Cloaked.
In order for a file to be cloaked, there must be an ACL on the file and that ACL must evaluate to the current user not having read access.
There are only 3 pieces of information you can get from a cloaked file: The File ID, the File Master ID and the Cloaked bit. All other properties are removed or set to useless information.
To illustrate things further, here is a comparison of the same File object accessed by different users. One user has read access and the other one does not. 
Hidden Files
A cloaked file is very different than a hidden file. The hidden bit is just meta-data that suggests whether a file should be visible to the user or not. At the API level, a hidden file is exactly the same as a non-hidden file (except for the Hidden bit). The hidden bit does not change the security settings or the functionality. There are a few API search functions where you can choose to omit hidden files, but that's about the extent of this property.
Testing
When testing, make sure to use a non-administrator account. Administrators always have read access, regardless of the ACL. Therefore you will never run into a cloaked file as an administrator. Depending on your view of things, the "administrator sees all" feature is either a pro or a con.
Kaaaaaaaaaaaaaaaaaaaahhhhhhhhhhnnnnnnn!!!!!!
If you liked this article, you might also like:
Security
Subscribe