I just read the CoreSessionTracking proposal. I am very concerned about the "long living browser id". * Why should a browser id live longer than the session data maintained for the browser? This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. I do not see any reason why a site should be able to track my activity over a longer period of time -- at least no without my explicit consent. I tend to refuse long living cookies and as sites continue to send cookies on any request, I disable cookies all together. If this means, a site can not be visited, I stop visiting the site. If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them. Security: * I do not think "Annonymous" should have the permission "Add Session Data Objects". Session handling should be transparent, including allocation of a session data object. * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. Sessions may contain confident information that must not be revealed to other users. Again, session handling should be transparent, implemented by a mechanism that implements its own special purpose access policy (access to session data only by the session owner). Consistency: * sometimes "__zsession__" and sometime "_ZopeId" seems to be used to refer to an identifier used for session tracking * how is it possible to have nested "Session ID Managers" (necessary for delegation) with "getZopeSessionID" a singleton? As I understand it, the "singleton" property prevents any child to reimplement the method. I must be wrong with this assumption. Dieter