Re: [DNSOP] Public Suffix List

[Doug Barton <[e-mail]>]

Gervase Markham wrote:
> Hi Doug,
> 
> Doug Barton wrote:
>> Coming as it does late in your development cycle (and especially given
>> the "enthusiastic" reaction you've received here today) the temptation
>> would be for you to dig your heels in and insist on moving forward as
>> planned. I urge you to resist that temptation.
> 
> Just as a matter of fact, Firefox 3 ships in a week; there is no
> possibility of further change in that release.
> 
> The fact that I am working on this question now is not to present a
> /fait accompli/; I've just been too busy to get to it.

Is it just me, or do those two statements seem to contradict one another?

I would also like to point out that even if you sent the message you 
proposed to the admin and tech contacts of every TLD yesterday, you 
won't get a response from even a significant percentage of them before 
you ship. (That's not a pejorative statement, these are busy people.) 
So effectively what you'll be saying to them is, "We have already done 
this, so if your data is accurate, fine. If not, you'll want to get 
our list updated so that we may get it into the next version, whenever 
that ships." I guarantee you, this will not be received well.

>> It may help you at least
>> update your current list, and help keep it up to date:
>> http://data.iana.org/TLD/tlds-alpha-by-domain.txt
> 
> Thank you. I believe something like that was used initially.

The fact that your list seems to be missing some of the recent updates 
to thFrom [e-mail]  Tue Jun 10 17:46: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 7E9863A68FD;
	Tue, 10 Jun 2008 17:46:02 -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 1739F3A67E7
	for <[e-mail]>; Tue, 10 Jun 2008 17:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5
	tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6]
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 pgyITjgs-Stj for <[e-mail]>;
	Tue, 10 Jun 2008 17:45:33 -0700 (PDT)
Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6])
	by core3.amsl.com (Postfix) with ESMTP id A6AED3A686A
	for <[e-mail]>; Tue, 10 Jun 2008 17:45:29 -0700 (PDT)
Received: (qmail 28420 invoked by uid 399); 11 Jun 2008 00:45:51 -0000
Received: from localhost (HELO lap.dougb.net) ([e-mail]@127.0.0.1)
	by localhost with ESMTPAM; 11 Jun 2008 00:45:51 -0000
X-Originating-IP: 127.0.0.1
X-Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 10 Jun 2008 17:45:49 -0700
From: Doug Barton <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080606)
MIME-Version: 1.0
To: Gervase Markham <[e-mail]>
References: <[e-mail]> <[e-mail]>
	<[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.6
OpenPGP: id=D5B2F0FB
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]

Gervase Markham wrote:
> Hi Doug,
> 
> Doug Barton wrote:
>> Coming as it does late in your development cycle (and especially given
>> the "enthusiastic" reaction you've received here today) the temptation
>> would be for you to dig your heels in and insist on moving forward as
>> planned. I urge you to resist that temptation.
> 
> Just as a matter of fact, Firefox 3 ships in a week; there is no
> possibility of further change in that release.
> 
> The fact that I am working on this question now is not to present a
> /fait accompli/; I've just been too busy to get to it.

Is it just me, or do those two statements seem to contradict one another?

I would also like to point out that even if you sent the message you 
proposed to the admin and tech contacts of every TLD yesterday, you 
won't get a response from even a significant percentage of them before 
you ship. (That's not a pejorative statement, these are busy people.) 
So effectively what you'll be saying to them is, "We have already done 
this, so if your data is accurate, fine. If not, you'll want to get 
our list updated so that we may get it into the next version, whenever 
that ships." I guarantee you, this will not be received well.

>> It may help you at least
>> update your current list, and help keep it up to date:
>> http://data.iana.org/TLD/tlds-alpha-by-domain.txt
> 
> Thank you. I believe something like that was used initially.

The fact that your list seems to be missing some of the recent updates 
to e IANA list does not fill me with hope.

>> There is also another issue which I haven't seen addressed, although
>> admittedly it's a corner case, of TLD NICs that establish a firm policy
>> preventing user registration at the top level, but allow themselves to
>> operate sites such as www.nic.tld.
> 
> That would be fine if (again, using cookies as an example) they set them
> for www.nic.tld and not nic.tld. Or, they could add an exception to the
> public suffix data they submitted.

And what if they decide that it's not up to you to dictate how they 
set their cookie policy, and don't cooperate?

>> I'm also not sure you quite understand the magnitude of the task you're
>> undertaking. It's a matter of fact that any sentence including the
>> phrase "all TLDs" is doomed from the start. :)  
> 
> If the scheme relied on getting explicit responses from them all, then
> yes, it would be doomed.

My impression is that you seem to think that having domains not on the 
list treated differently from domains on the list is Ok. I'm pretty 
sure most of us would disagree with you on that, but since you seem 
determined to press forward (and the value of what you're doing may 
outweigh that issue, not sure) then that's something that we'll have 
to live with.

The case that I don't think you're giving enough weight to is the one 
where you have published code that says, "You cannot set cookies for 
SLD.TLD, only SLD.$foo.TLD" and the registry changes their policy. Now 
every single domain that registers at the second level in that TLD 
will not be able to set cookies for their domain that your browser 
will permit. (Unless I've dramatically misunderstood the concept.) As 
both a user and as someone who deals with web sites, cookies, and 
domains on the administrative level, I regard that as a pretty serious 
problem. Several people have told you that this exact problem (or 
related problems) WILL be happening now, and WILL be happening with 
more frequency as time goes on.

> (That's why I think a model of getting the TLDs
> to publish the information via DNS or some other mechanism is doomed.)
> But in the absence of their input, we can use public sources and
> deduction to make a good guess - or just not give them an entry. There
> aren't many ad networks who are setting cookies for .com.je to track
> visitors across different Jersey websites.

There's two problems with that statement. First, if I ran the JE 
registry there's a pretty good chance that I'd be offended (not 
speaking for them, just following your example). I don't know any TLD 
operators who don't think that their domain has substantial 
significance, even if it is "only" to their user community.

The other, more important problem is that you're totally discounting 
the possibility that the bad guys will simply move their websites to 
TLDs that you don't have a policy for (or for whom your policy is too 
permissive). Given the fairly open registration policies at most TLDs 
I'd say that's a non-trivial issue. And since the data will be hard 
coded the bad guys will know what's there, and have a fairly well 
defined period of time in which to operate.

>> Now all THAT said, let's look at what you're planning to do. Leaving
>> aside the "nice to have" stuff like history grouping, I'm very
>> interested in your concerns about cookie policy. Is the threat you're
>> trying to guard against (cookie collusion) something real that you've
>> seen in action, or something that you perceive to be a potential threat?
>> Please forgive my ignorance on this topic, it's been a while since I've
>> had to deal with cookie issues.
> 
> It's real. I recently checked my list and had cookies for both .co.uk
> and .com.au.
> 
> Yngve probably knows more about this than me, though.

I'd love to see some references that define the scope of this problem. 
I'd also like to see some discussion of how large this problem is vs. 
the issue that someone else raised that there are other ways that 
theoretically bad actors can (and already do) use to share cookie 
data. (Hint: I would lay significthe IANA list does not fill me with hope.

>> There is also another issue which I haven't seen addressed, although
>> admittedly it's a corner case, of TLD NICs that establish a firm policy
>> preventing user registration at the top level, but allow themselves to
>> operate sites such as www.nic.tld.
> 
> That would be fine if (again, using cookies as an example) they set them
> for www.nic.tld and not nic.tld. Or, they could add an exception to the
> public suffix data they submitted.

And what if they decide that it's not up to you to dictate how they 
set their cookie policy, and don't cooperate?

>> I'm also not sure you quite understand the magnitude of the task you're
>> undertaking. It's a matter of fact that any sentence including the
>> phrase "all TLDs" is doomed from the start. :)  
> 
> If the scheme relied on getting explicit responses from them all, then
> yes, it would be doomed.

My impression is that you seem to think that having domains not on the 
list treated differently from domains on the list is Ok. I'm pretty 
sure most of us would disagree with you on that, but since you seem 
determined to press forward (and the value of what you're doing may 
outweigh that issue, not sure) then that's something that we'll have 
to live with.

The case that I don't think you're giving enough weight to is the one 
where you have published code that says, "You cannot set cookies for 
SLD.TLD, only SLD.$foo.TLD" and the registry changes their policy. Now 
every single domain that registers at the second level in that TLD 
will not be able to set cookies for their domain that your browser 
will permit. (Unless I've dramatically misunderstood the concept.) As 
both a user and as someone who deals with web sites, cookies, and 
domains on the administrative level, I regard that as a pretty serious 
problem. Several people have told you that this exact problem (or 
related problems) WILL be happening now, and WILL be happening with 
more frequency as time goes on.

> (That's why I think a model of getting the TLDs
> to publish the information via DNS or some other mechanism is doomed.)
> But in the absence of their input, we can use public sources and
> deduction to make a good guess - or just not give them an entry. There
> aren't many ad networks who are setting cookies for .com.je to track
> visitors across different Jersey websites.

There's two problems with that statement. First, if I ran the JE 
registry there's a pretty good chance that I'd be offended (not 
speaking for them, just following your example). I don't know any TLD 
operators who don't think that their domain has substantial 
significance, even if it is "only" to their user community.

The other, more important problem is that you're totally discounting 
the possibility that the bad guys will simply move their websites to 
TLDs that you don't have a policy for (or for whom your policy is too 
permissive). Given the fairly open registration policies at most TLDs 
I'd say that's a non-trivial issue. And since the data will be hard 
coded the bad guys will know what's there, and have a fairly well 
defined period of time in which to operate.

>> Now all THAT said, let's look at what you're planning to do. Leaving
>> aside the "nice to have" stuff like history grouping, I'm very
>> interested in your concerns about cookie policy. Is the threat you're
>> trying to guard against (cookie collusion) something real that you've
>> seen in action, or something that you perceive to be a potential threat?
>> Please forgive my ignorance on this topic, it's been a while since I've
>> had to deal with cookie issues.
> 
> It's real. I recently checked my list and had cookies for both .co.uk
> and .com.au.
> 
> Yngve probably knows more about this than me, though.

I'd love to see some references that define the scope of this problem. 
I'd also like to see some discussion of how large this problem is vs. 
the issue that someone else raised that there are other ways that 
theoretically bad actors can (and already do) use to share cookie 
data. (Hint: I would lay signifant money down on a bet that there is 
already way more cross-site tracking done now affecting way more 
users, way more sites, and way more data than this cookie policy could 
ever hope to solve. Hint hint: It's a sucker bet, I already know the 
answer.)

>> Others have already said that the proper place to deal with this is in
>> the cookie spec, so I won't belabor that. Assuming that you are going to
>> go forward with some form of this no matter what, I would urge you in
>> the strongest possible terms to reconsider your plan to make it a static
>> list that is built into the binary. 
> 
> We can certainly look at that for the next release.
> I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=438304 .

The audit trail for that is pretty interesting. First, I think it 
would be useful for you to include a link to this discussion so that 
your colleagues could read it for themselves. 
http://www.ietf.org/mail-archive/web/dnsop/current/msg06100.html

Second, the followup from Dave Townsend seems to indicate that at one 
point in the past this data was being read from a file. Perhaps that 
code could be resurrected?

Finally, there is a middle ground here. Ship what you have (since that 
seems inevitable), but disable the cookie policy portion of the code 
by default. Make it an about:config option so that those who want to 
try this feature (and are knowledgeable enough to judge the results) 
can do so, but don't enable it by default until you can get the list 
dynamically updated.

>> I would further suggest that this should be a user-configurable option.
> 
> As a usability person rather than a security person, I think that a good
> principle is to only expose preferences which a significant proportion
> of your users will be able to understand.

Heh, if that's your criteria, then the options you have already would 
be significantly reduced. :) Seriously though, my suggestion was to 
hide this on the Advanced page, which sounds reasonable to me, but 
it's your ball game. I do hope that there will be a config option for 
it at least (ala IDN?).

>> Finally, I'd like to make a suggestion that I know you will reject, but
>> I feel compelled to make it anyway. :)  You could solve this problem
>> much more easily by making the default policy to deny cookies, and ask
>> the user to choose to accept cookies from domains that they have a trust
>> relationship with. 
> 
> As you know, I do reject that :-) It's not one user in a thousand who
> has the ability to correctly judge whether accepting a particular cookie
> is "safe" or not.

Yeah, that's why I didn't suggest making this a warning. Users would 
blow past it just like they blow past SSL warnings now.

> In one sense, they are all safe. You won't lose any
> money by accepting a cookie, and your box can't get rooted. And cookies
> don't come with must-be-truthful purpose statements. "OK, I'll accept
> the one which says it's required to make the shopping cart one work, and
> reject the one that tracks me for advertising purposes."

The CookieSafe plugin uses domain granularity by default, which is 
good enough for me. As for "safety," those of us for whom privacy is a 
concern would disagree with your assertion. But we can leave that bit 
aside, neither of us will be changing our minds. :)

>> I know this was a long post, but I hope you found the information
>> valuable. Please let me know if I can be of any further assistance.
> 
> Thanks :-)

Whether we ultimately reach the same conclusions or not, it's obvious 
to me that you've been giving the discussion some thought, and for 
that I thank you as well.

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


icant money down on a bet that there is 
already way more cross-site tracking done now affecting way more 
users, way more sites, and way more data than this cookie policy could 
ever hope to solve. Hint hint: It's a sucker bet, I already know the 
answer.)

>> Others have already said that the proper place to deal with this is in
>> the cookie spec, so I won't belabor that. Assuming that you are going to
>> go forward with some form of this no matter what, I would urge you in
>> the strongest possible terms to reconsider your plan to make it a static
>> list that is built into the binary. 
> 
> We can certainly look at that for the next release.
> I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=438304 .

The audit trail for that is pretty interesting. First, I think it 
would be useful for you to include a link to this discussion so that 
your colleagues could read it for themselves. 
http://www.ietf.org/mail-archive/web/dnsop/current/msg06100.html

Second, the followup from Dave Townsend seems to indicate that at one 
point in the past this data was being read from a file. Perhaps that 
code could be resurrected?

Finally, there is a middle ground here. Ship what you have (since that 
seems inevitable), but disable the cookie policy portion of the code 
by default. Make it an about:config option so that those who want to 
try this feature (and are knowledgeable enough to judge the results) 
can do so, but don't enable it by default until you can get the list 
dynamically updated.

>> I would further suggest that this should be a user-configurable option.
> 
> As a usability person rather than a security person, I think that a good
> principle is to only expose preferences which a significant proportion
> of your users will be able to understand.

Heh, if that's your criteria, then the options you have already would 
be significantly reduced. :) Seriously though, my suggestion was to 
hide this on the Advanced page, which sounds reasonable to me, but 
it's your ball game. I do hope that there will be a config option for 
it at least (ala IDN?).

>> Finally, I'd like to make a suggestion that I know you will reject, but
>> I feel compelled to make it anyway. :)  You could solve this problem
>> much more easily by making the default policy to deny cookies, and ask
>> the user to choose to accept cookies from domains that they have a trust
>> relationship with. 
> 
> As you know, I do reject that :-) It's not one user in a thousand who
> has the ability to correctly judge whether accepting a particular cookie
> is "safe" or not.

Yeah, that's why I didn't suggest making this a warning. Users would 
blow past it just like they blow past SSL warnings now.

> In one sense, they are all safe. You won't lose any
> money by accepting a cookie, and your box can't get rooted. And cookies
> don't come with must-be-truthful purpose statements. "OK, I'll accept
> the one which says it's required to make the shopping cart one work, and
> reject the one that tracks me for advertising purposes."

The CookieSafe plugin uses domain granularity by default, which is 
good enough for me. As for "safety," those of us for whom privacy is a 
concern would disagree with your assertion. But we can leave that bit 
aside, neither of us will be changing our minds. :)

>> I know this was a long post, but I hope you found the information
>> valuable. Please let me know if I can be of any further assistance.
> 
> Thanks :-)

Whether we ultimately reach the same conclusions or not, it's obvious 
to me that you've been giving the discussion some thought, and for 
that I thank you as well.

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