Re: [DNSOP] Public Suffix List

[Henrik Nordstrom <[e-mail]>]

On ons, 2008-06-11 at 10:10 +0100, Gervase Markham wrote:

> Other list participants were warning about the possibility of people
> abandoning Firefox in droves if there were cookie-related problems
> caused by its use of public suffix list.

If you do this wronly yes.

> You, on the other hand, are
> suggesting that we can just make changes to the way cookies work and
> expect broken sites to fix themselves. These seem to be two
> irreconcilable views of the future.

No. Neither users or sites are completely static in nature.

> Long history and experience has shown us that we can't just break
> people's weFrom [e-mail]  Wed Jun 11 04:03:10 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 9E0A53A689D;
	Wed, 11 Jun 2008 04:03:10 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8E7FB3A689D
	for <[e-mail]>; Wed, 11 Jun 2008 04:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.171
X-Spam-Level: 
X-Spam-Status: No, score=-4.171 tagged_above=-999 required=5
	tests=[AWL=-1.572, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id p2Crh4oNijno for <[e-mail]>;
	Wed, 11 Jun 2008 04:03:04 -0700 (PDT)
Received: from vps1.henriknordstrom.net (vps1.henriknordstrom.net
	[195.20.207.177])
	by core3.amsl.com (Postfix) with ESMTP id E892E28C117
	for <[e-mail]>; Wed, 11 Jun 2008 04:01:49 -0700 (PDT)
Received: from henriknordstrom.net (183.159.216.81.static.tb.siw.siwnet.net
	[81.216.159.183])
	by vps1.henriknordstrom.net (8.13.8/8.13.8/Debian-3) with ESMTP id
	m5BB25Lh031815; Wed, 11 Jun 2008 13:02:06 +0200
Received: from henrik ([127.0.0.1]) (authenticated bits=0)
	by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id
	m5BB22Hv005523
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits8 verify=NOT);
	Wed, 11 Jun 2008 13:02:03 +0200
From: Henrik Nordstrom <[e-mail]>
To: Gervase Markham <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]> <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Date: Wed, 11 Jun 2008 13:02:02 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.3 (2.10.3-9.fc7) 
X-Virus-Scanned: ClamAV version 0.91,
	clamav-milter version 0.91 on henriknordstrom.net
X-Virus-Status: Clean
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0
	(vps1.henriknordstrom.net [195.20.207.177]);
	Wed, 11 Jun 2008 13:02:08 +0200 (CEST)
Cc: [e-mail], [e-mail], Wes Hardaker <[e-mail]>
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="=======21871920="
Sender: [e-mail]
Errors-To: [e-mail]

On ons, 2008-06-11 at 10:10 +0100, Gervase Markham wrote:

> Other list participants were warning about the possibility of people
> abandoning Firefox in droves if there were cookie-related problems
> caused by its use of public suffix list.

If you do this wronly yes.

> You, on the other hand, are
> suggesting that we can just make changes to the way cookies work and
> expect broken sites to fix themselves. These seem to be two
> irreconcilable views of the future.

No. Neither users or sites are completely static in nature.

> Long history and experience has shown us that we can't just break
> people's bsites like that.

Sites do break in upgrades. Problems arise if you break too many of them
and neither the site operators of users have an easy way around, or when
they do not understand why things broke. Fortunately the area we are
discussing is fundamentally broken by design, and sites do break today
differently in different browsers.

If you want something positive to come out of discussions like this you
have to have a little more open mind in looking where to find solutions.
There is at least 10 different solutions to the cookie domain problem,
of varying complexity and feasibility. Your proposed list is one, and
not a competely bad one, but very incomplete and too static to be
feasible as "the" solution to this problem. But it's a reasonable
interim step to patch things up while discussing how the actual problem
should be addressed.

In short the cookie problem is threefold:

a) Receivers of a cookie have no way of knowing who issued that cookie.

b) Receivers of cookies have no means of indicating who is allowed to
set cookies for them.

c) Issuers of cookies often want to issue a cookie to multiple domains
all of which is under their administrative control, but often have to
figth the very blunt domain based filters. As result we have many
designs using URL based transfer of the cookie details when moving from
one site to another when better operation would be seen if the cookie
could be managed as a single cookie valid for multiple sites. These "URL
based cookie tunnels" is often installed as a way around broken browser
cookie policies, and I would suspect they often create gaping security
issues from lacking awareness of why these policies even exists.

Regards
Henrik

_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop