Re: lynx-dev Accepting invalid cookies - continuing discussion

[Klaus Weide]

On Mon, 4 Jan 1999, brian j. pardy wrote:
> Klaus Weide wrote:
> > On Tue, 29 Dec 1998, brian j. pardy wrote:
> > 
> > > Okay.  I'll work for now on getting a proper flag for domains that are
> > > specified, and then we can decide on just what to do with it and how.
> > 
> > So here some thoughts on the other end of the problem, that is the
> > "what to do with it" end.
> 
> Okay, I put this aside a few days, networked Quake is an evil evil evil
> thing that can suck away hacking time...

Sorry for putting this aside even longer.

However, it seems we basically agree on everything:
[ summarizing quote snipping applied ]

> > We want to replace the dependence on the global LYAcceptAllCookies by
> > dependence on some per-domain or per-hostname flag(s), and also change
> > how the various checks are bypassed (or not) depending on the new flag(s).
> 
> Right.
> 
> Personally, I'm not one of the people that is wanting/needing the special
> behavior for invalid domains, so more input than mine is definitely 
> necessary.  I don't see any problems in your logic.
> 
> > The most detailed approach would be to have three possible behaviors for
> > [...] 
> > Basically, each of the
> >         if (FAILS_XXX)
> >             REJECT;
> >         }
> > above would be replaced by
> >             if (FAILS_XXX) {
> >             if (bv_XXX == REJECT_ALWAYS)
> > [...]
> > but this would be most certainly overkill.
> 
> Agree that that's overkill.
> 
> > The least detailed approach would be to have just one boolean flag
> > (but still per-domain or per-hostname), [...]
> 
> I'd definitely consider that overloaded, then.
> 
> [...]
> > bv_PATH_CHECK
> >   This one triggered the last round of loosening - at least one person
> >   had a need for it.  NS spec does not require rejecting.  Bad spec,
> >   does not protect separate /~users on same host from each others' cookies.
> >   (The name INVALID_DOMAIN_ALLOWED doesn't fit if flag covers this too.)
> 
> Have people actually seen cookies sent by users?  I never have, but I
> assume they exist.

Having had cookies completely off most of the time, I can't really say
whether they are encountered in practice.  I'm sure at least one
person must be using them somewhere.  But that was just as an example
anyway, there isn't anything special about URLs with path's containing
'~' as far as HTTP clients are concerned. (Except perhaps for the
question whether "~" and "%7E" should be regarded as matching.)

> Does the new(er?) spec require cookies that fail the
> path check to be rejected?

Yes.  It's one of the explicit requirements of section 4.3.2 of the
last draft:
    A user agent rejects (SHALL NOT store its information) if any of the
    following is true of the attributes explicitly present in the Set-
    Cookie2 response header:

    * The value for the Path attribute is not a prefix of the request-
      URI.
and it is also already in RFC 2109, same section number.

> > bv_HOSTDOT_CHECK
> > bv_COND2_CHECK
> > bv_COND3_CHECK
> 
> Agreed that none of these three should fall under accept_all_cookies'
> jurisdiction.
> 
> > bv_COND4_CHECK
>
> I agree that at *least* the original behavior of prompting should be
> retained.
> 
> I'm not sure, however, that COND4_CHECK and PATH_CHECK should be
> encompassed in the same variable, even though I'm slightly hesitant to
> have another one added.  If I simply want edit.my.yahoo.com to be able to
> set an invalid cookie, I don't always want this to mean /~user1 can set a
> cookie for /~user2 as well.

If the checking level can be set on a per-host/per-domain level, this
would only be an issue in the case where both kinds of invalidity
occur from the same host (or for the same domain).  And if the
behaviour is set to prompting, it could be made so that you would
still get two prompts, or one prompt indicating that there are both
problems.  So I think it is acceptable to have the same variable.

> > I am thinking of a variable with three possible settings:
> > INVALID_COOKIE_CHECKING with values STRICT, LOOSE, ASK:
> > 
> >                    STRICT          LOOSE              ASK
> > bv_PATH_CHECK     REJECT_ALWAYS   CONTINUE_ANYWAY    QUERY_USER
> > bv_HOSTDOT_CHECK  REJECT_ALWAYS   REJECT_ALWAYS      REJECT_ALWAYS
> > bv_COND_2_CHECK   REJECT_ALWAYS   REJECT_ALWAYS      REJECT_ALWAYS
> > bv_COND_3_CHECK   REJECT_ALWAYS   REJECT_ALWAYS      REJECT_ALWAYS
> > bv_COND_4_CHECK   REJECT_ALWAYS   CONTINUE_ANYWAY    QUERY_USER
> > 
> > Probably ASK should be the default; one could also add a 4th column
> > for the current behavior (see above) - probably not worth it
> > (or even add a CUSTOM columns, for which checks could be controlled
> > individually).
> 
> Customization seems like overkill -- [...]

Yes - I think I was just mentioning it to show that the general
approach doesn't preclude extension to even more detailed control.

> I do like the triple option idea.
> 
> > With those three possible settings, the invalid-cookie prompts could
> > then be made to act like the accept-cookie prompt currently: there
> > would be a four-way choice, the behavior could be set to STRICT or
> > LOOSE at the prompt.  Also this could be modified from the Cookie Jar
> > Page interface.  The way to permanently configure this could also be
> > analogous to the current COOKIE_ACCEPT_DOMAINS and COOKIE_REJECT_DOMAINS
> > lists: there would be two new list, INVALID_COOKIE_ACCEPT_DOMAINS and
> > INVALID_COOKIE_REJECT_DOMAINS (or some better names).
> > 
> > Does it make sence to have this level of control?  I think it does,
> > although few users would use it (or understand it - but that becomes
> > a question of explaining it properly, and using names for the options
> > describe the behavior well).
> 
> Erring on the side of more customization can rarely be a bad thing, IMO,
> and it's apparent that at least two people on this list would use it.
> 
> > One could argue that the whether-to-accept-(valid)cookies behavior
> > (for a given domain) should not be an independent property from the
> > whether-to-allow-invalid-cookies behavior; [...]
> >                                             but it would still be
> > interesting to have a way to auto-REJECT normal cookies but also be
> > alerted if an invalid cookie gets sent.
> 
> This would be nice, I agree.  
>
> >[...]
> Given your comments, I agree on this.  It made sense earlier...
> 
> >   struct _domain_entry {
> >     char *          domain;
> >     behaviour       bv;          /* normal, final accept/reject */
> >     invcheck_behaviour      invcheck_bv; /* for invalidity checks */
> >     HTList *        cookie_list;
> >   };
> > 
> > with check_behaviour either a BOOLEAN; or an enum with three values (as
> > I prefer); or an enum with more values (if we add evenmore detailed 
> > control).
> 
> I think some more thought needs to come in from the people who will
> actually use this (I only accept cookies from about 3 specific sites 
> anyways), but I pretty much agree with your triple-option approach with
> the possibility/probability of making them permanently configurable
> (perhaps also with a global flag), with the possible caveat of splitting
> it up into separate variables for PATH_CHECK and COND4_CHECK.

(Is the caveat sufficently addressed above?)

Since nobody else has foolowed up on this, I guess we can declare that
consensus is reached...

> Sounds like a lot of work.

a. The configuration and program startup side could be basically just
copied from the existing stuff: COOKIE_ACCEPT_DOMAINS and _REJECT_DOMAINS
lists etc., with appropriate renaming.  
b. The changes for actual usage of the new behavior variable would affect
only a limited section of the code, in a first approach (in store_cookie,
probably with help from HTAlert).
c. Adding control via links from the Cookie Jar page could be deferred till
later.
d. The messages and prompts have to be tweaked until they make sense.
e. Proper explanation in lynx.cfg, help file(s).

I am doing some other stuff now, but if you take a. now (I leave you the
boring stuff :) ), I'll follow up with b. if you want...

       Klaus