The first is inadequate because of the lack of control over what permissions are enabled for anonymous users at the root folder. If a particular permission is added to the root folder the next day, anonymous users now have a permission in /private which they should not have.
How will this permission be added? Who is defining permissions for your site? Are you talking about permissions defined by products your download and install or are you talking about permissions defined by products you create?
I'm not sure why this matters. Let me regroup for a moment, and tell me if I'm mis-understanding the security model. Within any sub-folder, one can do the following to a given role: * Inherit the permission for all roles, but override to grant permission for this role. * Inherit the permission for all roles, including this one. * Do not inherit the permission for all roles, and grant for this role. * Do not inherit the permission, and don't grant. What's missing is this: * Inherit the permission for all roles, but override to deny permission for this role. I can't think of any other security system that makes it difficult to deny access. The only way to deny access at a local level is to duplicate and tweak the security information from the parent node, and duplication of information is anathema to manageability. -John