Re: lynx-dev Accepting invalid cookies - was: cookie bug (not in lynx)

[brian j. pardy]

On Tue, 29 Dec 1998, Klaus Weide wrote:

> On Mon, 28 Dec 1998, brian j. pardy wrote:
> > On 27 Dec 1998, Klaus Weide wrote:
> > > These are conceptuallt two different things, they should be controllable
> > > by separate options.  Either an additional flag/option is needed, or
> > > even a way to allow (some) invalid cookies on a per-domain basis.
> > 
> > Perhaps a new option similar to COOKIE_ACCEPT_DOMAINS to specify
> > servers that are specifically allowed to set invalid domains?
> 
> I'm all for giving the user fine-grained control over cookies, but
> there are some difficulties with this.  Part of the checks is
> comparing two domain names (the one from the cookie and the actual
> server hostname).  Should that hypothetical new option set a property
> of (1) the domain given in the set-cookie or (2) of the hostname?  You
> seem to have (2) in mind, but (1) would be more equivalent to what
> COOKIE_ACCEPT_DOMAINS does.

With (1), unless I'm missing something, a user could set "yahoo.com" as
a domain which can be set via invalid cookies -- which it seems would
allow *any* hostname to set a cookie for "yahoo.com".

Under (2), "edit.my.yahoo.com" could be a domain which has the (currently
not existing) "I can set invalid domains" flag, and be allowed to set 
cookies for domains below it (ie for "yahoo.com").

I'm about halfway through implementing a skeleton of (2), enough to 
provide an extra attribute which can then be checked once each test is
hashed out as to which we want to ignore for cookie swith this flag.

> > I can't
> > think of any way to allow such things without violating the
> > specification, but it's pretty obvious that some people want such
> > things to be allowed.
> 
> (depends on which specification, of course.)

The nice thing about specifications is that there are so many to choose
from. :)

> > There seem to be problems with the spec as it now exists.  A few posts
> > on BUGTRAQ have pointed out some of the problems -- it seems like a
> > browser following the spec will still be open to problems.
> > 
> > See:
> > 
> > <URL:http://www.geek-girl.com/bugtraq/1998_4/0741.html>
> 
> There have been huge problems with the Netscape spec ever since it existed.
> That's why a better spec was and is needed.
> 
> And then the work on the "better spec" was basically ignored by Netscape and
> nearly everyone else.  AFAIK that is still the case up to today.  It's a
> sad story.

It is.

> > > The behavior of ACCEPT_ALL_COOKIES is also not consistently documented:
> > > The Users Guide says that "... Lynx will accept all cookies."  The
> > > comment in lynx.cfg says that "... Lynx will accept cookies from all
> > > domains with no user interaction."  Nothing is said about the effect on
> > > checking or validity.
> > 
> > I'm not sure which is the best description.  I didn't intend to bypass
> > the checking/validity in the first place, so either comment explains
> > my original intent -- "Behave as if 'A' were pressed whenever prompted 
> > for a cookie".
> 
> We should first change the behavior and then document what is implemented. :)

:)

> > > [...]
> > > To summarize, IMO Lynx should (1) have at least something like an
> > > additional flag/option -accept_some_invalid_cookies (or
> > > -relaxed_cookie_checking?  or -something_completely_different?), and
> > > (2) don't accept all cookies completely unchecked _even if_ that flag
> > > is set.
> > 
> > Agree with (2), possibly agree with (1).  I personally don't think 
> > a server should be allowed to violate spec by sending illegal cookies
> > (I think the original problem was with my.yahoo.com), but the Big
> > Browsers seem to allow this, and at least one person wanted it.
> 
> I think (1) would be ok if it defaults to off (even if that means we are now
> more restrictive than 2.8.1 for ACCEPT_ALL_COOKIES).

What I presently have (patch will be at [0] in about 10 minutes, if you're
interested) makes an option for lynx.cfg and .lynxrc in the same style as 
COOKIE_ACCEPT_DOMAINS (ie, just a big list) which is checked (not securely
yet, I want to do this as a domain attribute instead of basically a list
being grepped) when a new cookie comes across.

As for being more restrictive than 2.8.1, I'm all for it after thinking this
over again.


[0] <URL:http://www.psnw.com/~posterkid/code/lynx-invaliddomains.patch>

-- 
GPG & PGP public keys: <URL:http://www.psnw.com/~posterkid/keys/> 
PGP fingerprint: 42 57 B3 D2 39 8E 74 C3  5E 4D AC 43 25 D2 26 D4