Re: lynx-dev [dev17 patch] cookie options documentation

[Klaus Weide]

On Mon, 22 Feb 1999, David Woolley wrote:

> Specifically, the most common use for persistent cookies is to construct
> a marketing profile on the user, whereas the most common use of 
> session cookies is to maintain information like shopping cart content
> within a single session (although a secondary reason for this is
> to legitimise cookies for their other use, as there are other ways of
> maintaining state data).

Thanks for that reminder (in parentheses).

> > It is not clear to me what kind of configuration option(s) *would* be
> > useful for David (although I could guess).  I sugesst he should specify
> > what would work for him.
> 
> To be honest, I'd probably just never enable persistent cookies, as
> Microsoft really won't work with anything except a GUI browser anyway.
> But if I could be bothered to maintain lists, I'd probably want a list of
> sites from which I'd accept session cookies when I'd require confirmation
> for, or refuse persistent ones.

You could get a very similar effect but just clearing the .lynx_cookies
file of all persistent cookies that you do not want, after each session.
That would effectively convert persistent cookies to session cookies.
Of course lynx could do that for you by not writing them to the file
in the first place, but since it's so easy to do outside of lynx
(essentially, for your case, a "grep -v microsoft" - yes, a realistic
pattern would be a bit more complicated), I think it would not be worth
the extra configuration bother and code.

That would be similar, but not exactly the same, for what you
(hypothetically) want.  You want to not accept the persistent ones at
all, not even for the duration of the browser session.  That seems to
be based on how specific tools currently give a different interface for
persistent vs. session cookies - which provides a heuristic for sorting
out "evil" from "harmless" cookies.  But it's really only a heuristic
(and I don't know how valid it is today).  As soon as an option like
"don't accept persistent cookies" became implemented in browsers that
are on the marketing profilers' radar screens, they would start using
cookies without expiration for their purposes as best as possible (if
they don't already), so that immediate rejection of persistent cookies
would loose any advantage it has over deletion at session end.

> > For one thing, I don't even know that there is a clear definition of
> > what a "session cookie" is.   The simple definition is probably "a cookie
> > without an expiration date", but that would exclude e.g. cookies with
> 
> That's what I'd understand, and what the tools like ASP use when they 
> are maintaining session state behind the application's back (An ASP 
> application sees variables that belong to the session, rather than the
> actual cookie - those variables  are just there and get saved without
> it having to do anything.   They are not held in the cookie; the cookie
> just indicates where the data for the session is held.).
> 
> > expiration in the past.  And cookies with expiration date can replace
> > cookies without (and vice versa).
> 
> I'd consider anything trying to upgrade a cookie from session to persistent
> as being highly suspect.

If session cookies are ever deleted, I expect that to be done with a
replacement cookie with expiration in the past.  (You can see I am
guessing - I don't know that much about real life cookie use.)
Then it's up to the vagaries of clock skew whether an incoming cookie
will be regarded as completely harmless or as suspicious, at least in
some border cases (very unlikely, but still have to be considered).

    Klaus