Dieter Maurer wrote:
I, at least, care much more about my privacy than about some wish list maintained for a longer term.
Sure. That is why you're free to not continually visit sites that implement this policy. (and boy are you gonna hit the roof when you read my explanation of why I changed the implementation to accomodate global session keys! :-)
Your default values are bad:
Yes, you're absolutely right. I've changed them. The default value in the constructor form signifies that the session id manager should not send persistent cookies at all. There will be knobs to adjust this, however, allowing folks to crank up the cookie lifetime to whatever they please.
< I said >
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).
<Dieter replied> 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.
Token obscurity is the best we can manage. It should really not be thought of as security. (But if you came up with a truly secure web identification mechanism that does not require any authentication/client certificate, doesn't rely largely on security through obscurity, and that's completely 100% transparent to any number of end users that may be using any number of stock browsers, I'm sure somebody at RSA would be willing to pay you hundreds of millions of dollars. I'd even give you a couple thousand! :-)
How do you propose that we recognize one 'Anonymous User' from another? What do you have session id's for?
Session tokens, AFAICT, cannot be secured. They can only be obfuscated, which mitigates the risk that they will be guessed. However, there's no way to completely secure them, no matter how many MD5 hashing algorithms you run on them. If a session token is stolen, that's the key that the "attacker" needs to visit the website "as you". I've addressed this in the implementation by giving the session token a random element, and this mitigates a guessing attack, but not a theft attack. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org