[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev [dev17 patch] cookie options documentation
From: |
David Woolley |
Subject: |
Re: lynx-dev [dev17 patch] cookie options documentation |
Date: |
Mon, 22 Feb 1999 23:45:25 +0000 (GMT) |
>
> Although that may at first seem strange, it isn't necessarily: Everyone
> who uses Lynx wants HTML parsing; not everyone wants cookies, some want
> some cookies, getting cookies wrong has potentially worse results (sending
> personal info where it shouldn't be sent) than getting parsing wrong.
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).
>
> 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.
> 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.