Re: [DNSOP] Public Suffix List

[Gervase Markham <[e-mail]>]

Andrew Sullivan wrote:
> Is there any way to turn this off in Firefox 3?  

Not that I know of.

> RFC 3696 explains, I think, most of the reasoning that I would offer
> for why I think this is a bad idea.  I urge you and others who are
> planning to ship this kind of feature to go (re)read that RFC.

Why do you think that the negative consequences explained in that RFC
would apply in this case? Please think carefully about the consequences
of possible failure scenarios.

> I know that you have a security problem, which is that cookies are
> widely used for some purposes in such a way that they can be
> subverted.  That's a problem with the cookies specification, which was
> always broken. 

This isn't just about cookies. For example, we would like to group
together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in
history. Grouping together all sites in ".co.uk" does not provide for an
optimum user experience.

> If you're not going to fix the cookies specification (which is what I
> think you ought to do, but I understand why people are reluctant to
> take that on), then there should at least be some way to publish data
> about the relationship you want to permit.  One way to do this would
> be to figure out a way to publish lists of domains for which a given
> domain publishes cookies, and from which a given domain accepts
> cookies. 

As I noted in an earlier message, this may solve security problems but
does not solve privacy ones.

> I still run into problems with email addresses in .info domains not
> being accepted, because the From [e-mail]  Mon Jun  9 07:43:47 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 5B5163A6C3B;
	Mon,  9 Jun 2008 07:43:46 -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 06C7D3A6C3B
	for <[e-mail]>; Mon,  9 Jun 2008 07:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.063
X-Spam-Level: 
X-Spam-Status: No, score=-4.063 tagged_above=-999 required=5
	tests=[AWL=-0.464, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 F1WzOZvTSd3t for <[e-mail]>;
	Mon,  9 Jun 2008 07:43:39 -0700 (PDT)
Received: from jet.mythic-beasts.com (jet.mythic-beasts.com [193.201.200.50])
	by core3.amsl.com (Postfix) with ESMTP id 166E83A67EA
	for <[e-mail]>; Mon,  9 Jun 2008 07:43:39 -0700 (PDT)
Received: from grmarkham.plus.com ([80.229.30.161] helo=[192.168.1.6])
	by jet.mythic-beasts.com with esmtpsa
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50)
	id 1K5ias-0003MD-T7; Mon, 09 Jun 2008 15:43:53 +0100
Message-ID: <[e-mail]>
Date: Mon, 09 Jun 2008 15:43:29 +0100
From: Gervase Markham <[e-mail]>
User-Agent: Thunderbird 3.0a1 (X11/2008050714)
MIME-Version: 1.0
To: Andrew Sullivan <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
In-Reply-To: <[e-mail]>
X-BlackCat-Spam-Score: -17
Cc: [e-mail], [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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Andrew Sullivan wrote:
> Is there any way to turn this off in Firefox 3?  

Not that I know of.

> RFC 3696 explains, I think, most of the reasoning that I would offer
> for why I think this is a bad idea.  I urge you and others who are
> planning to ship this kind of feature to go (re)read that RFC.

Why do you think that the negative consequences explained in that RFC
would apply in this case? Please think carefully about the consequences
of possible failure scenarios.

> I know that you have a security problem, which is that cookies are
> widely used for some purposes in such a way that they can be
> subverted.  That's a problem with the cookies specification, which was
> always broken. 

This isn't just about cookies. For example, we would like to group
together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in
history. Grouping together all sites in ".co.uk" does not provide for an
optimum user experience.

> If you're not going to fix the cookies specification (which is what I
> think you ought to do, but I understand why people are reluctant to
> take that on), then there should at least be some way to publish data
> about the relationship you want to permit.  One way to do this would
> be to figure out a way to publish lists of domains for which a given
> domain publishes cookies, and from which a given domain accepts
> cookies. 

As I noted in an earlier message, this may solve security problems but
does not solve privacy ones.

> I still run into problems with email addresses in .info domains not
> being accepted, because thtop level domain label is "too long".

Which is why the list is soft-fail - e.g in the cookie case, if a new
TLD is added which is not on the list, we simply fall back on the
current behaviour.

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


e top level domain label is "too long".

Which is why the list is soft-fail - e.g in the cookie case, if a new
TLD is added which is not on the list, we simply fall back on the
current behaviour.

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