Chris McDonough writes:
Dieter Maurer wrote:
... serious privacy concers about long living browser ids ... ..... This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day.
Not if you want to associate a session with a browser across a long period of time. For example, if you wish to maintain a long-lived "wish list" of items in session storage without requiring a user to log in.
*IF* I wished to maintain a long-lived "wish list", I would understand the need for a long living browser id. However, when session data expires after several minutes idle time (discarding my wish list), I do not understand at all why the browser id should live for a year. I would suspect the issuer to be interested in malicious activity tracking, seriously affecting my privacy. I, at least, care much more about my privacy than about some wish list maintained for a longer term.
* 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.
The cookie lifetime is configurable, so this is up to the site manager or developer. This is not a problem endemic to Zope or the core session tracking proposal, but to the configuration imposed by the developer or site manager. Lots of people don't mind long-lived cookies, and it's not realistic to limit the functionality of the system based on something that's out of our scope of influence. If you choose not to visit sites that provide long-lived cookies, then perhaps that site's session manager will choose to reduce the cookie lifetime. Your default values are bad:
session inactivity timeout: 20 min browser id cookie expiration: 1 year As soon as I would recognize that my session data disappears after some minutes idle time I would question, why my browser told me the site wishes a cookie to be installed with a one year lifetime. What nasty things does this site want a such long living cookie for?
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.
The use case description that mentions "add session data objects" is incorrect. That permission will not exist. The overall permission "Access session data" will permit the creation of session data objects, as well as the manipulation of already-created session data objects. Anonymous must be granted this permission (or sessions would be completely worthless, as they would require users to log in). I disagree with this. Anonynous must only access *his/her* session data and must not access session data of any other Anonymous. You have the session id to ensure this. However, the Zope security model is not strong enough, to express this. Therefore, I think, the core should implement a module that handles this special case outside the current Zope security model.
* I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data.
How do you propose that we recognize one 'Anonymous User' from another? What do you have session id's for? To give a user access to his/her session data. Use it, too, to prevent access to others session data. Especially, he/she should be unable to determine what other session data is available.
Dieter