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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -