Re: [DNSOP] Public Suffix List

Wes Hardaker <> Mon, 09 June 2008 14:06 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id D4F0D3A6C6D; Mon, 9 Jun 2008 07:06:56 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2854D3A6C69 for <>; Mon, 9 Jun 2008 07:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ccy7+0Je85M0 for <>; Mon, 9 Jun 2008 07:06:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 31D843A6B10 for <>; Mon, 9 Jun 2008 07:06:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2331C399BDB; Mon, 9 Jun 2008 07:07:11 -0700 (PDT)
DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed;; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=hiahOHVEtBtSLJJXs2MxWFKdQpQ=; b=G6JLWjewGZODD/oOCWZYFdkpxu2IyJMZyxCpx6MxJVXHP+wUtDI+1WRA+5pk5d21baMU2t823ZFLCHF/CxTrN2bTgEyu/PhtpRVY+CNwmm1wsq+ugUtnFGOTF9DdFoIy6zCu4nmlj6h56Jp+mg9sGrYlGbsc8hTgNrt/Keq4VHw=
Received: by (Postfix, from userid 274) id E9020399BDC; Mon, 9 Jun 2008 07:07:10 -0700 (PDT)
From: Wes Hardaker <>
To: Gervase Markham <>
Organization: Sparta
References: <> <> <>
Date: Mon, 09 Jun 2008 07:07:10 -0700
In-Reply-To: <> (Gervase Markham's message of "Mon, 09 Jun 2008 12:48:19 +0100")
Message-ID: <>
User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE)
MIME-Version: 1.0
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 Mon, 09 Jun 2008 12:48:19 +0100, Gervase Markham <> said:

GM> Fortunately, Firefox has an extremely good and fast update and uptake
GM> rate. This is partly because we don't give users a choice about taking
GM> non-major-version updates.

And how long to do you maintain the older versions?  Are you forever
going to ship updates to your older branches?

I think a better policy would be to fix the HTTP protocol so that it
could specify an incoming cookie policy.  Rather than having every site
under the sun be able to set cookies and block that by some random list
of hard coded "within" list, allow each site to specify where they
accept cookies from.  The browser would need to track the source of each
cookie, but that would be helpful for other tracking reasons anyway.

EG, if I had "" and I received cookies in a request from
"", "" and "" I could determine
based on the source which ones I wanted to accept.  The current issue
with cookie usage is that sites don't have the ability to not accept
data from external sources.  Fix that problem instead and you'll have a
much better and more scalable solution.  It'll require work on both the
server side and the browser side but in the end is a better solution.

(and DNSSEC will be useful for assuring that the cookie creation site
isn't spoofing their address)
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
DNSOP mailing list