Re: lynx-dev Accepting invalid cookies - continuing discussion

[brian j. pardy]

*grumble* replying from the archive, so I broke threading...

Our system crash seems to be fixed, so I can hack again.

Klaus Weide wrote (a few days ago):

> On Mon, 4 Jan 1999, brian j. pardy wrote:
>> Klaus Weide wrote:
>> > On Tue, 29 Dec 1998, brian j. pardy wrote:
[even more snipping throughout]
>> > 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.)

Ah, okay.

>> 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.

Understood.

>> > 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.

Again, agreed.  Prompting makes it okay with me.

[...]
>> >   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?)

Yeah, I don't think it will be a problem.

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

They had their chance to complain :)

>> 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...

Thanks for the nice list.  I'll attempt to get at the least a) taken
care of today, it's a nice simple one.  I should be able to simply 
cannibalize my older patches.
 
-- 
<http://www.psnw.com/~posterkid/keys/> for DSA/ElG-E/RSA keys
DSA 0x0A641AA5:0B1E 37B7 ECCB FC96 B6C6  7242 0A59 F8D5 EFA9 4F81
RSA 0x4E65C321: 42 57 B3 D2 39 8E 74 C3  5E 4D AC 43 25 D2 26 D4