Hi Chris, in an earlier message, you defended the existence of a separate permission "Access Session Data" (in the CoreSessionTracking proposal) by the following case: There may be (authenticated) users with (TTF?) scripting rights that should be prevented to screen session data (by withdrawing the "Access Session Data" permission from them). This will only be effective, when not all users automatically have the "Anonymous" role. There was a discussion about the "Anonymous" role some months ago in the list: * The (outdated) Content Manager Guide mentions that any user has the role "Anonymous". * A role "Anonymous" with the meaning "not authenticated" will make management for sites with authenticated, non-manager users more difficult, as those users should have most rights of "Anonymous". Only in exceptional cases, e.g. for session data, they will have less priviledges. If the meaning of "Anonymous" changes in this direction, then this role should be explicitely assignable to users in the "Change User" view to avoid such difficulties. I would be much in favour of a solution that does not entail new permissions. This would be possible, if session id management and access to session data would be melted together. In the current proposal, both are separate modules linked by the application: the application obtains a session id from the id manager and then accesses the session data, usually with the id, but in principle with anything it likes, e.g. a stolen session id. It seems that the new permissions should help to control such abuses. If the session id becomes an implicit (not DTML-forgable) parameter for session data access, then the session data need not to be protected by new permissions. However, I agree with you, that even making session id management implicit, will not provide strict security. Why am I against new permissions? This has partly to do with the current Zope permission management. As soon as you have more than a few products installed and created a few additional roles, permission management becomes a nightmare: it is very difficult to keep the overview with the current unstructured, non-batched permission setting view. Dieter