Re: [DNSOP] Public Suffix List

David Conrad <> Tue, 10 June 2008 16:29 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id DE1A23A6850; Tue, 10 Jun 2008 09:29:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 872F83A6850 for <>; Tue, 10 Jun 2008 09:29:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bcauI4-xDSaM for <>; Tue, 10 Jun 2008 09:29:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8FF8C3A67E9 for <>; Tue, 10 Jun 2008 09:29:48 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTP id ED3D623A8FA; Tue, 10 Jun 2008 09:30:10 -0700 (PDT)
Message-Id: <>
From: David Conrad <>
To: Gervase Markham <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Tue, 10 Jun 2008 09:30:09 -0700
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.924)
Subject: Re: [DNSOP] Public Suffix List
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


On Jun 10, 2008, at 3:09 AM, Gervase Markham wrote:
> Yes, basically. For best results we'd get the data directly from those
> in the know, but if they don't want to keep us informed, they don't  
> have to.
> If you think this is unreasonable, what is the alternative position?

The concern I have isn't in collecting the data (others may feel  
differently), rather it is how you are proposing to distribute it (I  
have no comment on the use of the data because I don't understand the  
problem well enough).  The data you will be collecting will likely be  
out of data within a very short time after you cut a release and it  
requires you to re-release all the data every time there is an update,  
regardless of how small.  Presumably, you'll be batching up the list  
updates with other code updates, so the frequency of pushing out  
changes will likely be relatively low and thus, there will be periods  
when there is known bad data being used by every up-to-date  
implementation of Firefox.  Given the likely increase in the number of  
TLDs, this problem will only get worse over time.

Assuming there is an association of cookie trust policy with domain  
(which seems a bit of a reach to me, but again, I don't understand the  
problem well enough), then it would seem to me that a better way of  
proceeding would be as Jamie Lokier suggested (although I'd skip  
distributing the hard-coded list).  That is, probe for a policy  
statement for each level in the domain tree from the leaf up to the  
TLD.  As far as I can see, this would not introduce any additional  
privacy concerns and would resolve (pun intended) any data staleness  
issues.  It would also give zone administrators the ability to have  
fine grained control of cookie policy for names they administer.  Of  
course, the downside is the additional DNS lookups -- don't know how  
many lookups since I don't understand the problem well enough (but I  
have difficulty imagining the load would be that significant, all  
things considered).



DNSOP mailing list