Re: [Zope-dev] mailing list 'noise'
I dont see this as a problem: You only create a new list when the traffic for that proposal gets too great for zope-dev. Threading is good enough before that point. Yes, but zope-dev has a relatively high traffic load... Why should you have to put up with all that 'noise' if you're only interested in posts for your comparatively small discussion? I read the 2-10 articles that I'm probably interested in, and miss the 95% which is almost always noise. The question is why you'd want to receive all this if you don't have to (as remarked above). ...because it is usually a mistake to categorize any discussion as small, to exclude it from the mainstream zope-dev. I started this thread with a request that developers use zope-dev in the way requested by the Fishbowl Process document - but (I assume) it has also been valuable to people thinking about a next-generation wiki. That would not have happened if discussion was partitioned into Wikis (Todays wikis - not VaporWikiNG) unless some WikiNgWiki person was (by coincidence) keeping up with the FishbowlWiki. Are you really advocating that? No, did I sound like I did? as long as you can follow it. But for prolonged and diverging discussions? Not quite IMO/Experience. Can you explain why? Because discussion change topics. Because most people only answer parts of the post. Because you throw away parts of the posts (I know you shouldn't but the mail client is not under your control). Because you loose overview and you can't step back and take a look at the whole thread.. Because no one ever summarizes the discussions. They could, but they won't. I have done these kind of summaries for several intricate Zope related discussions and when you start summarizing it gets very clear that for a larger discussion only parts of the issues involved ever get discussed. Or, to summarize my point, maillist discussion are hardly ever consolidated. It's like having a meeting without an agenda or a chairman who gets the thing going. In the case of a meething once in a while a good chairman/moderator takes back the discussion, summarizes and puts up the open points for further discussion. If you ever experience a meeting that needed someone to guide it, but didn't have one, then you probably know what I mean. Or for discussions that you fall into in the middle? Agreed - Todays Wikis are better than todays email list archives. Ha! ;-) And what if you want to follow discussions at different places, with different tools and you depend on a POP Server or differential access (POP/IMAP/Web) to a mailserver? Its true that the web model is increasingly becoming a lowest common denominator. Are your suggesting that a majority of Zope developers actually need that? Um, I couldn't tell with any certainty. In light of the adoption of Wikis, I suppose so yes. People seem to have been unsattisfied by the maillist and or other discussion tools. It's also remarkable that DC did not adopt Squishdot as a discussion forum, yes. And apart from this, a WikiNG would benefit a much larger community, of which I _am_ sure that it needs it. (Agreed, a VaporWikiNG that does both would be nice) Agreed that for now there are no tools that do such thing. That is also why it's worthwile to get WikiNG out of the vapor notwithstanding the myriad of discussion tools that have been around for many years already. As I understood it, the discussion is less about tools and more about modes of discussion. But we couldnt be having this discussion (in any mode) without tools. did I say that? *My* email and news tools support the mode of discussion that we are advocating *better* than *Todays* Wikis I think everyone agees about that, but at least some of the participants in this discussion also agree that most of the existing discussion tools for any mode of discussion are frustrating and insufficient at times. Moreover, apparently not everyone favours the same mode of discussion and this alone would be more than enough justification for a product that would cater different modes of discussion _at_the_same_time_. Rik ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking proposal
At 10:44 PM 9/30/00 -0400, Chris McDonough wrote: However, as prompted by a Digital Creations "jam session", there are going to be changes to the use cases which actually make the "Browser Id Manager" into a "Session Id Manager" which will generate a "session token" that will carry both a "browser id" (meant to semipermanent) *and* a "session key" (meant to exist for the duration of a "session" as bounded by a "global" timeout period). This is purely an implementation Huh? I don't get it. It's still just an opaque key from the POV of the session data managers, right? It doesn't matter how you assign the key, just as long as it's unique. The concept of a "browser id" was purely a *metaphor* on my part to show why you only needed one key, whose lifetime only needed to be as long as the longest session handled by the session data managers. That's also why in the docs I wrote up on the Wiki, I called the ID handler a "session ID manager", not a browser ID manager. As far as I can see, there isn't any need for a *real* browser ID, it was just a metaphor. detail, driven by the somewhat specious requirement that we allow people to associate a "session" bounded by one session data manager with a "session" bounded by another in the same system. (The implementation is also driven by my reluctance to store session key state related to a browserid inside Zope itself... it could be handled internally, but I've decided to put the "session" state on the client instead, it's easier). I'm still lost. Reluctance to store what state? Why do you need to store anything? Keep in mind that a session data manager just throws away its record for a given ID when it wants to expire it. If the user "comes back" and still has a session cookie, that particular session data manager will just start a new session with the old key. No harm, no foul. If a specialized session data manager wants to keep permanent records of expired sessions, it can simply move the record somewhere else and/or give it a permanent key when it expires. Or it can give every session a permanent ID, but simply look up active sessions using the session cookie. I assume from the use cases, however, that a permanent record of an expired session is a rarity, not the rule. So it seems wrong to me to add complications just to handle that case. As for associating sessions between two session data managers, why can't the simple session cookie concept handle that? It's only one ID, and so is shared, right? I'm not quite clear on what the requirement is here. This will be an opt-in feature for session data manager implementations, Now I'm really lost. What does the feature have to do with the session data managers at all? token. However, it also means that session tokens (which replace browser ids as a identification value) will be prone to change much more frequently, as a new session token will be constructed every time the "global" session timeout expires, and it will contain both the "browser key" (potentially recycled out of a received token) and a new "session key". This sounds to me again like the "browser id" concept is being taken too literally. I assumed that the global "session ID" would expire and be reset just as described above. It sounds to me like you're "changing" to what I thought we agreed on in the first place. :) This may actually be beneficial (in some twisted, baroque way :-), because it means that people will be less tempted to set the cookie expiry time far into the future, as the cookie will be reset more often. I think you're actually making things more complex than they need to be. It sounds like the misunderstanding probably stems from the part of the SessionIDManager Wiki page that reads: "Session ID's provided by a Session ID Manager never expire. The cookie may expire, or data associated with the session may expire, but the session ID never does. It can be thought of as being like a "browser serial number" that sometimes changes (when a cookie expires, or user reloads a non-session URL in URL mode)." What this means is that there is never any reason to issue a new global session identifier value when one already exists. However, if the cookie which *carries* that global session identifier expires, then one may consider that global session identifier to have expired. What I was trying to emphasize is that *you don't need to know when the 'global' session has expired*. Only session data managers need to know something has expired, and they do it by timeout on their local session data objects, and they don't need any info from the SessionIDManager in order to do that. That's why I described it as the session ID never expiring. The SessionIDManager just issues ID's. It doesn't have to remember them, expire them, or anything else. It *just* gets the current ID or issues a new one if it doesn't exist. That's all. The properties on the SessionIDManager control the cookie expiration, which thus
Re: [Zope-dev] mailing list 'noise'
"Rik Hoekstra" [EMAIL PROTECTED] writes: I think everyone agees about that, but at least some of the participants in this discussion also agree that most of the existing discussion tools for any mode of discussion are frustrating and insufficient at times. Moreover, apparently not everyone favours the same mode of discussion and this alone would be more than enough justification for a product that would cater different modes of discussion _at_the_same_time_. Hear hear! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking proposal
Chris McDonough writes: The random element of the token is currently five characters. I may need to "up" this. The secure cookie requirement is already reflected in the use cases and in the current implementation. Anybody have any other bright ideas about how to make session tokens harder to guess? Hash them as GUF does. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: CoreSessionTracking proposal
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: CoreSessionTracking proposal
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking proposal
Dieter Maurer wrote: Phillip J. Eby writes: The actual lifetime of a browser ID will be controllable by the Zope site manager. I agree with you, however, in that the default lifetime should be reasonable. Indeed, I would suggest that the default simply be to use cookies with no expiration date, and which therefore only live so long as the user's browser is open, be it minutes or days. I would be very happy with this. Good, that's what it is now. :-) As I understand it, the "Access Session Data" permission gives you the right to call a method that returns you the session data for the current request, but does not give you the right to access arbitrary session data. Thus, one only has permission to see one's own session data. Do we need a special permission for this? All users will have it (when sessions are used at all). Thus, why clutter the (already cluttered) security management screen with an additional permission. It is advantageous to prevent certain users from accessing session data (such as nonanonymous, non-management users with TTW scripting capabilites) so they cannot arbitrarily examine session data values. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
