[DNSOP] Public Suffix List
Dear HTTP and DNS Operations WGs, The following email message will shortly be sent to the technical contact for all TLDs. Yngve Pettersen at Opera suggested that I also let you both know about it. The technology in question, including a version of the list, is about to ship in Firefox 3, but we'd like to verify and improve the quality of the underlying data. Please let me know if you see any way I can improve the email, the explanatory website, or the submission process. Gerv Dear Technical Contact, The Mozilla Project (http://www.mozilla.org/), responsible for the Firefox web browser, requests your help. We are maintaining a list of all "Public Suffixes". A Public Suffix is a domain label under which internet users can directly register domains. Examples of Public Suffixes are ".net", ".org.uk" and ".pvt.k12.ca.us". In other words, the list is an encoding of the "structure" of each top-level domain, so a TLD may contain many Public Suffixes. This information is used by web browsers for several purposes - for example, to make sure they have secure cookie-setting policies. For more details, see http://publicsuffix.org/learn/. We would like your help to make sure, now and in the future, that the entries for your TLD(s) are correct. It is in your interest as a registry to make sure that this is so. Any errors may either cause your customers (domain owners in your TLD) to not be able to set cookies when they should, or cause cookie information to be leaked between two domains without a trust relationship. Neither of these things is desirable. Therefore, we are writing to ask your technical team to view the current list and, if it is incorrect, to submit updated data. A description of the format of the list, and details for sending updates is at: http://publicsuffix.org/submit/ We also ask you to send updated information whenever you change your registration policies in a way which affects the list. Thanking you in advance, Gervase Markham ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Jeroen Massar wrote: > [Why not go DNSSEC first instead of solving a problem which is not a > real problem? See below... ] I'm not sure that DNSSEC solves the problem we are trying to solve, but would be happy to be enlightened. > You are *hard-coding* such a list into a 'product'? You do realize that > a lot of people simply don't update their software I hope. Unfortunately > for the OS's that need updating the most those people don't tend to update. Fortunately, Firefox has an extremely good and fast update and uptake rate. This is partly because we don't give users a choice about taking non-major-version updates. > You might want to consider using at least an RBL-style way for this. > Though, you will of course hit off on all the privacy folks when you are > doing another DNS query for www.spooks.gov.rbl.mozilla.org every hit and > collecting all that information. Indeed. This is why this type of scheme is not a runner. Yngve Pettersen of Opera has suggested something like this in his internet draft; however, my view is that getting comprehensive buy-in would take quite a lot more time and effort than this method. http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-03.txt > How can non-TLD's get into this list!? Just by asking; I already got an email from CentralNIC. > If you are going to push this 'technology', you might want to consider > doing an SPF-alike test, thus getting that information from the provider > of the label, or better: fix the cookie standards. Yngve has several suggestions about how this may be fixed longer-term: http://my.opera.com/yngve/blog/2008/02/25/refreshed-internet-drafts-0208 However, this is what we have that works here and now. > And another much better step which I think the rest of this group (as of > course this message is just and only my personal opinion and not that of > the group in anyway... that is how the IETF works afterall ;) would > actually also like is the use of DNSSEC. Which actually tells you that > the domain you are looking at is really the domain you are requesting > records from. That's a different problem, though. Even if DNSSEC was deployed, it wouldn't teach browsers about the structure of the DNS. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Patrik Fältström wrote: > The problem with any such mechanisms is that the barrier of entry for > new players (that does not match the currently used list -- including > non-upgraded software) is increased. More than what people think. This isn't so. For TLDs not in the list, the usual rules (about e.g. cookie setting) would be applied. In other words, the situation is no different to what it is now. This information is additive. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Wes Hardaker wrote: > 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. That doesn't solve the privacy problem. If www.flirble.co.zz and www.widget.co.zz wished to conspire to track users across the two sites, they would simply both say that they are happy to accept co.zz cookies. I am not particularly interested in a long discussion about whether we need this data. Please be assured that we need it. I am, on the other hand, open to suggestions about better ways to obtain it. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Patrik Fältström wrote: > What about new structures in a TLD that is in the list? If the structure is additive, then again there is no problem. If it is reductive, then there are potential problems depending on how the customers of the newly-available domains set things up. Let us say, for example, that the .zz domain has five sub-levels, which are the only places you can register: com.zz org.zz net.zz ltd.zz plc.zz So this is what the list will say. Now, say the .zz domain changes their policies to permit direct registration under the root. If someone purchases "foo.zz", they will not be able to set a cookie for "foo.zz" until the list is updated. They will, however, be able to set one for "www.foo.zz". So what is inhibited is the sharing of cookies across different sites in the same domain, not the setting of cookies entirely. I agree that this is not ideal. But I believe what we are doing now is the least worst option, and that good publicity for the scheme among the TLD owners will mean that if they are considering such a move, they will let us know. I hope that publicsuffix.org (or somewhere more official) will become the single source for this data. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
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 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Andrew Sullivan wrote: > Because what you are proposing to do adds special meaning to certain > labels (and their relative position) and not to others, in exactly the > way that previously people had special interpretations of certain > labels and their positions in the set of labels. Right. But they did things like throw error messages saying "That's an invalid domain name because it has too many characters in the extension. Please enter a valid one." We aren't planning anything like that. > What you're really > trying to do here is extract meaning from the domain name, but you > can't do that reliably. Previous efforts in that direction have > failed in unexpected ways; and given that you seem to have multiple > ways you want to use this feature, I don't see any reason to believe > you won't have surprising failures too. I think your statements of doom need to be more specific. > The plan is both too narrow and too wide. First, it will almost > certainly fail to capture 100% of the cases you currently don't want > to succeed. That's true. It's an improvement to privacy and UI, not a magic bullet. > Second, it will (as we've been arguing in this thread) > not work for new TLDs and other cases. It will work perfectly for any new TLD which allows registration directly below the root. Of the seven new gTLDs introduced in 2001/2, this is true (as far as I can see) of .biz, .info, .name and .coop. So those four would have worked fine if this system had been in place and there had been no update. .museum and .name have sub-structure, but we haven't found a definitive list. If .pro were not present in the list, then people within the professional subdomains such as bar.pro could conspire to share cookies. The end-user effect of this is a minor loss of privacy, but none of function. > Your counterargument is that > the behaviour will then fall back to the current arrangement. This > means that different domains behave in different ways, and the user > can't rely on any behaviour consistently. But if consistent behaviour was the goal, then we _would_ allow privacy-busting cookies for .co.uk and .com.au, because those domains are "just the same" as foo.com, and we want "consistency". Who is "the user" in your statement? >> 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. > > It seems to me that what you want is metadata about certain domains. > Therefore, what you need is a mechanism for publishing metadata, not a > magical list of domains about which you'll have hard-coded > information. As I have mentioned earlier in the thread, Yngve is proposing a scheme were every TLD operator publishes this information using a web service, and clients can look it up (and cache it). I personally think the chances of that happening are very slim. But if I am proved wrong, we can happily switch over to using it. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
David Conrad wrote: >> however, my view is that getting comprehensive buy-in >> would take quite a lot more time and effort than this method. > > is the common excuse that results in lots of broken crap on the > Internet. It is sad to see the same mistake repeated again and again. Prove me wrong, then. You can send a message to the Technical Contacts of all 284 domains (I can supply you with a list) saying "Please set up a resilient, highly-available web service to provide current data on your registration structure." See what sort of reaction you get. >>> How can non-TLD's get into this list!? >> Just by asking; I already got an email from CentralNIC. > > If there is no vetting, doesn't this defeat the purpose? Who says there's no vetting? How does adding e.g. CentralNIC defeat the purpose? In some ways, it is the purpose; CentralNIC customers will no longer be able to conspire to damage users privacy, and if users accidentally mis-set cookies, other CentralNIC customers can't steal them. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Jamie Lokier wrote: > Wouldn't it be more appropriate for MyBank to _itself_ say the history > for these sites should be grouped? E.g. in an HTTP response header, > or DNS record for mybank.co.uk? The total amount of effort required for this solution is mind-boggling. > Also, wouldn't DNS generally be the appropriate mechanism to say what > grouping relationships there are under $DOMAIN? After all, the > administrative control for the grouping info which you are maintaining > for *.$DOMAIN, and DNS for *.$DOMAIN, are the same. It would be an appropriate mechanism; when it does contain this information, let me know. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
David Conrad wrote: > I suspect I might have a better list than you (:-) hint: I work at ICANN). Well, OK :-) > My reading of Yngve's draft (in particular, section 5.1) led me to > believe that all TLDs would not need to run such a service, rather that > such a service be available in a "well known" place (I think the right > approach would be for IANA to maintain pointers to well known places, > but that's an implementation detail). I'm happy to admit that Yngve's solution, if it ever got up and running, would be a good one. (Although it's worth noting that such a service would need to deal with a non-negligible amount of traffic.) But it doesn't exist. > I'm curious: have you consulted with the various TLD-related > organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD, etc.) on > how to solve this problem? No. What do you think they'd say that hasn't been said in this thread already? We've had this basic problem in the domain of cookies for years. I don't expect another solution to pop out of the woodwork now. But I'm open to being surprised :-) Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Jamie Lokier wrote: > Gervase Markham wrote: >>> Wouldn't it be more appropriate for MyBank to _itself_ say the history >>> for these sites should be grouped? E.g. in an HTTP response header, >>> or DNS record for mybank.co.uk? >> The total amount of effort required for this solution is mind-boggling. > > How is it more work for them to publish over DNS or HTTP, than to send > you the information to publish, with the associated time lag etc? Your solution requires every site to set HTTP response headers, or every ISP to contact their customers to get the correct values for the DNS records. My solution involves communicating with a far smaller group. > You've asked for the same thing: for administrators of certain domains > to provide you with information about independent or related users of > those subdomains. But the two plans are talking about two different sets of admins, one vastly larger than the other. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
David Conrad wrote: > You're talking about essentially creating a registry of their registry > policies and distributing it statically via your product. I would > imagine they might be interested and might even have some useful input > to provide. We're about to ask them for their input. > Just to be clear, my understanding of the situation is that you are > proposing to ask that every TLD who has a zone in which the public can > register to notify you of that fact so that you can distribute and use a > list of these registries within your product, relying on Mozilla's > update/upgrade functionality to update and maintain this list. Explicit > in this proposal is that the registries notify you every time they add a > new 'public registry' or change the status of an existing 'public > registry'. Failure to update a registry could have negative impact on > customers of the TLD due to, for example, being unable to set cookies. > Is this an accurate summary? 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? - "No, sorry, you can't do any of the things for which you might want this data" - "It's fine to want this data, but you should get it via this alternative method:..." > P.S. If you do send your message to the technical contacts for all the > TLDs, expect quite a few bounces. OK - thanks. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Stephane Bortzmeyer wrote: > * Difficulty of managing this list (and even worse if every browser > vendor ask the TLD managers for a slightly different info) We are making our data available for everyone to use, so we are trying hard to make sure this doesn't happen. > * Administrative boundaries at lower levels (if we delegate under > ".fr", it says nothing about x.example.fr and y.example.fr: are they > in the same administrative domain?) This problem exists today, so there is no difference between Firefox 2 and 3 on this question. > * Mozilla's methods of arm-twisting We aren't twisting anyone's arm. We are making a request for help. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
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. > 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. > 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. > 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. (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. > 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. > 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 . > 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. I wouldn't be the person to make the final decision, but I strongly suspect that UI to turn this off wouldn't make it into the product. > 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. 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." > 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 :-) Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Jamie Lokier wrote: > The information would be published in the ISP's TLD-alike domain, not > the customer's subdomains. E.g. 'co.uk', not 'mybank.co.uk', assuming > the information is "each domain $WORD.co.uk is independent". > > The values are the same information that you are gathering. The > ISP/NIC (Nominet UK for .co.uk) does not need to contact their > customers for this: it's a .co.uk policy. OK. Then we are basically back to Yngve's suggestion. But this does require universal take-up for universal support - and that, as someone else has pointed out, makes it (in my opinion) doomed. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Kim Davies wrote: > This thread sounds remarkably like deja vu. Indeed, the TLD community was > rather upset a few years ago by Mozilla taking unilateral action to > introduce a hard-coded white-list of acceptable IDN TLDs without prior > consultation. That's unfortunate; but I must say this upset was not communicated to me. That policy of ours should have no effect whatsoever on TLDs with a responsible attitude to homographs. Our registration requirements are not onerous. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Paul Hoffman wrote: > One possible method is to start Firefox 3.0 with an empty registry, and > fetch a registry update from Mozilla each time a user does either a > manual or automatic "check for updates" on Firefox. That's an interesting idea. We didn't make the data remotely-updatable on its own for Firefox 3, but we may be able to do so for the next release. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=438304 . Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Florian Weimer wrote: > * Jamie Lokier: >> (By the way, although we're talking about administrative divides in >> the DNS tree, a little thought might be given to administrative >> divides in URL trees. There are a fair number of sites containing >> http://domain.com/user1/* and http://domain.com/user2/*, where those >> prefixes indicates separately administered URL spaces. Do similar >> cookie issues apply? > > Yes. I think Ebay suffers from these issues. Indeed. This is one of the reasons that livejournal switched from www.livejournal.com/name to name.livejournal.com. It prevented rogue code on user sites stealing the cookies of other users. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Jelte Jansen wrote: > won't they run into the very same problem if only tld's (and their > sld's) are marked as don't-set-cookies-here? Or is livejournal.com also > supposed to get on the list of public suffixes? No. They can set cookies for www.livejournal.com or admin.livejournal.com (as opposed to livejournal.com), and these will not be shared with name.livejournal.com. This is somewhat of a red herring; the problem they had is one they could fix using existing technology. It's not what the public suffix list addresses. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Doug Barton wrote:
> Gervase Markham wrote:
>> 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 don't think so. Both are statements of truth.
If I had had time, I would have got this update mechanism sorted out
months ago. The fact that I didn't have time is not me saying that "I
don't want other people to have input into this process".
It's true that people saying "Please don't do anything like that" are
unlikely to be heeded. But that was just as true months ago as it is now.
> "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."
Yep. In six to eight weeks, usually.
> The fact that your list seems to be missing some of the recent updates
> to the IANA list does not fill me with hope.
I've added to my ToDo list an item to check that list against ours.
Although again I stress that just adding ".zz" to the list is the same
as having no entries, because it's just an explicit encoding of the
default behaviour.
> 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.
I didn't say anything about significance. It was merely a factual
statement about the number of websites. I don't have the ability to
determine how many sites there are in .je (I'm sure many people reading
this list do) but I'd wager it's four orders of magnitude less than the
number in .com, and at least two less than in .co.uk. And so ad-serving
companies are unlikely to be optimising their tracking systems to track
visitors across different sites in .com.je (even if that exists; I don't
know that it does). Perhaps I should continue to use ".xx" or ".zz" as
an example?
> 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).
I very much doubt that established businesses will change their domain
name just so they can track users more accurately. ("Welcome to
cnn.xx!") I think you overestimate the impact of this change.
>> 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
Done; thank you.
> 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?
To be entirely honest, I was under the impression that this was still
the case. I am looking into the question.
> Heh, if that's your criteria, then the options you have already would
> be significantly reduced. :)
There's always more work to do :-)
Gerv
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Henrik Nordstrom wrote: > I seriously question this "will break" part. Sure, they will get > annoyed, but in nearly all possible solutions layering ontop of the > existing cookie system there will be easy ways for the owners of such > sites to make them behave well, and a transition period giving them > inciative and reasonable warning period to do so. 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. 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. Long history and experience has shown us that we can't just break people's websites like that. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Paul Hoffman wrote: > For your IDN display technology, Mozilla decides which TLDs have a > "responsible attitude". Mozilla enforces these rules as a "powerful > incentive" for TLDs to do as Mozilla wishes. As are Microsoft's rules - which, sadly, are both different and IMO much more likely to retard the growth of IDN. But that's another discussion. > In doing so, Mozilla > degrades the user experience of TLDs that don't go along with the > Mozilla rules, such as .com/.net and ccTLDs throughout the world. The > Mozilla "public suffix list" may prove to be similar. The difference is that the public suffix list is an (attempt at an) expression of fact, not policy. If you are concerned that we will withhold changes or issue known-incorrect lists in order to conduct some sort of vendetta against a particular TLD, all I can say is "why on earth would we do that?" Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Dean Anderson wrote: >> That's unfortunate; but I must say this upset was not communicated to me. > > Probably that's because you are using SORBS to filter your email. SORBS > has an unusually high number of false positives, and for example, > falsely claims that that 130.105/16 and 198.3.136/21 are hijacked. You > can find more information about SORBS on http://www.iadl.org/ No-one can have control over and knowledge of everything their ISP does with relation to the services they provide. I confess I've only ever vaguely heard the name SORBS, and had no idea that my provider was using it. But I don't believe that using it makes me uncontactable. My phone number and address are on my personal web page. I can hardly imagine some TLD administrator saying "I'm so irritated about Firefox's TLD IDN whitelist. I'm going to send Gerv a nasty email. Hang on, my email's been rejected. Oh well, I guess I'll just have to live with it." >> That policy of ours should have no effect whatsoever on TLDs with a >> responsible attitude to homographs. Our registration requirements are >> not onerous. > > ??? This statement doesn't seem very credible. What authority do you > have to decide what a 'responsible attitude to homegraphs' would be? What's your answer to that question? (Hint: the answer "no-one" is equivalent to the answer "the registries", which has been shown not to work. See http://www.shmoo.com/idn/ .) > Mozilla.org doesn't represent the internet industry nor any government > or governing organization. No, we represent our users, and we make all sorts of security decisions for them on a regular basis. One of the reasons Firefox is popular is precisely because it doesn't wimp out of security decisions with user-irritating popup questions they have no information to answer. But, as someone else has said, if people don't like the decisions we make, they can either become part of "we" and seek to change them, or they can change or build their copy, or can distribute an alternative browser. > Why should TLD's think they need to register > with Mozilla.org? They don't have to. Why should TLDs think they have an automatic right to have Firefox display domains they have issued which allow our users to be fooled or defrauded? Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Florian Weimer wrote: > Have a look at this file: > > /usr/share/apps/khtml/domain_info Indeed. It looks like they do the same thing as us, but in a far more approximate and erroneous fashion. Persuading them to use the public suffix list would be an improvement. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Wes Hardaker wrote: > * We, mozilla, obviously can't do this ourselves On the contrary. We have done it for ourselves. > so you must do it for > us or else negative things will happen (and you'll be at fault, not > us, mozilla). Please continue to do this work for us till the end of > time. Oh, and we need it immediately. We don't need it immediately. The first Firefox 3 security release will probably be in six to eight weeks. > * We, mozilla, won't work on any other solution because we don't think > it'll work or it'll take too much effort and we refuse to help out in > those ventures even if they might be better. Please stop talking > about alternatives as we don't want your opinions on them. It's not true that we won't work on any other solution. This is what we have now, and there have been no alternative proposals which (to my mind) look like producing anything workable in the short term. Half this list seems to think that getting all the TLDs to agree on or do anything is an enterprise doomed to failure, and the other half seem to think that we should be waiting for all the TLD operators to agree to set up their own repositories of the data. There is a contradiction there. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Wes Hardaker wrote: > * We, mozilla, obviously can't do this ourselves On the contrary. We have done it for ourselves. > so you must do it for > us or else negative things will happen (and you'll be at fault, not > us, mozilla). Please continue to do this work for us till the end of > time. Oh, and we need it immediately. We don't need it immediately. The first Firefox 3 security release will probably be in six to eight weeks. > * We, mozilla, won't work on any other solution because we don't think > it'll work or it'll take too much effort and we refuse to help out in > those ventures even if they might be better. Please stop talking > about alternatives as we don't want your opinions on them. It's not true that we won't work on any other solution. This is what we have now, and there have been no alternative proposals which (to my mind) look like producing anything workable in the short term. Half this list seems to think that getting all the TLDs to agree on or do anything is an enterprise doomed to failure, and the other half seem to think that we should be waiting for all the TLD operators to agree to set up their own repositories of the data. There is a contradiction there. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Jamie Lokier wrote: > Oh? How is this reconciled with earlier comments that > login.mybank.co.uk and accounts.mybank.co.uk are grouped together - or > is the Public Suffix List only for history grouping in browsers, not > for cookie sharing? I'm not sure that either dnsop or ietf-http-wg are interested in a discussion about the inner workings of cookies and Firefox's use of the list. But briefly: login.mybank.co.uk and accounts.mybank.co.uk can be grouped together because we group by "public suffix + 1" - in this case, mybank.co.uk, with the public suffix being .co.uk and so +1 being mybank.co.uk. (Without the list, all .co.uk sites would be grouped together.) Cookies are set for a particular domain or domain suffix, and are sent to all sites with that domain suffix. So (under the current code) www.mybank.co.uk can set cookies for either www.mybank.co.uk (shared with foo.www.mybank.co.uk but not login.mybank.co.uk), mybank.co.uk (shared with login.mybank.co.uk but not adserver.co.uk) or co.uk (shared with adserver.co.uk but not with myorg.org.uk). It is this latter use we want to prevent. We can do so by stopping cookies being set for any domain which is a public suffix. (Again, I comment that cookies are not the only way we are using this information.) Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Jeroen Massar wrote: > If adserver.co.uk (as they are 'evil') sets a cookie for co.uk then > indeed that cookie gets sent to mybank.co.uk too. What harm does/can > this do? (Except that they might set a cookie identical of type to the > bank one and maybe auto-login to their bank account!?) Say adserver.co.uk has contracts with mybank.co.uk, mygrocer.co.uk, mypetstore.co.uk to supply them with ads. adserver.co.uk can set the ad-tracking cookie for .co.uk and build up a cross-site profile of a particular user, perhaps augmented by information passed to them by one or more of the sites concerned. This is a privacy issue. Therefore, they should not be permitted to set such cookies. The only way to do that, while continuing to allow foo.com to set cookies, is for the browser to know the difference between co.uk and foo.com. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Joe Baptista wrote: > I asked you a question earlier in this conversation but have yet to get > a response. So I will ask it again. You asked me by private mail, and I replied in private at 10/06/08 10:47 my time. > What happens if a TLD is not on the Public Suffix list? The same thing as now. It's treated as if (again, using cookies as an example) cookies can be set all the way down to, but not including, ".xx". Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
Edward Lewis wrote: > Is the issue that a cookie needs to state for what domains it is > valid? No. > Are you trying to relate domain names to a registrant? No. I must confess it is somewhat frustrating when, having put up a website explaining what this is all about, and having had a long discussion on this list, people continually misunderstand the point while having shown no evidence of attempting to read the existing explanations. I even got one (private) mail basically saying "I can't be bothered to read all that. Tell me, what are you trying to do?" http://publicsuffix/learn/ has more info (and I've just checked in another update, which should be visible in the next day or so. There's a human in the update loop). Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
[EMAIL PROTECTED] wrote: > that URL does not resolve in the way you might > expect. Sorry :-) Cut and pasted from my browser without checking. That's my local testing copy, of course. http://www.publicsuffix.org/learn/ Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
Joe Baptista wrote: > Listening would you mind explaining something here. Do we work for > you? I'm pretty sure your being paid to promote your public suffix idea > but we are not. There are many here who are too busy to spend time > reading your stuff, let alone go back to the web site for updates. That's fine. But please don't ask me questions about it then. - "I don't have time to understand this." - Fine. - "I do have time to understand this. Here is an intelligent question." - Fine. - "I don't have time to understand this so I'm going to ask uninformed questions." - Not fine. Not just here, but in any walk of life where people respect other people's time. > Now Gerv focus. You have come here for a reason and that is to promote > a protocol. No. I came here because Yngve suggested that the membership of this list would appreciate a heads-up. > Gerv focus. Kindly remember your position in his affair. You are here > on behalf Mozilla to sell an idea and we are the people who have to be > sold. No. I don't need to sell you the idea. The idea doesn't stand or fall on the opinion of this mailing list. > Incidentally - have you answered by question yet - or put it on the web > site? What happens to your web browsers behavior if I try to surf a TLD > not on the list? I've answered it once to you privately and once to the list. Third time: "the same thing as now". Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
Joe Baptista wrote: > Listening would you mind explaining something here. Do we work for > you? I'm pretty sure your being paid to promote your public suffix idea > but we are not. There are many here who are too busy to spend time > reading your stuff, let alone go back to the web site for updates. That's fine. But please don't ask me questions about it then. - "I don't have time to understand this." - Fine. - "I do have time to understand this. Here is an intelligent question." - Fine. - "I don't have time to understand this so I'm going to ask uninformed questions." - Not fine. Not just here, but in any walk of life where people respect other people's time. > Now Gerv focus. You have come here for a reason and that is to promote > a protocol. No. I came here because Yngve suggested that the membership of this list would appreciate a heads-up. > Gerv focus. Kindly remember your position in his affair. You are here > on behalf Mozilla to sell an idea and we are the people who have to be > sold. No. I don't need to sell you the idea. The idea doesn't stand or fall on the opinion of this mailing list. > Incidentally - have you answered by question yet - or put it on the web > site? What happens to your web browsers behavior if I try to surf a TLD > not on the list? I've answered it once to you privately and once to the list. Third time: "the same thing as now". Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
Antoin Verschuren wrote: >> No. I don't need to sell you the idea. The idea doesn't stand or >> fall on the opinion of this mailing list. > > Did you really say this ? Did I read this correctly ? > > No, can't be. I don't think Mozilla wants to insult all the IETF > experts that have voluntarily helped them make a living in the first > place... Why is the above an insult? It's just a statement of fact. I didn't come here to say "I have this idea. If you guys like it, we'll do it. If you don't like it, we won't." I apologise if some people thought that this is what I was saying. As I said, I came here because Yngve suggested that you would appreciate being told about this scheme. I've had some useful feedback, and food for thought. And I'm grateful to those people who gave it to me. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Ted Lemon wrote: > On Jun 11, 2008, at 6:26 AM, Gervase Markham wrote: >> It's not true that we won't work on any other solution. This is what we >> have now, and there have been no alternative proposals which (to my >> mind) look like producing anything workable in the short term. > > Putting the list in the DNS instead of in the browser isn't workable? Perhaps, but not in the short term. > Serious question. I think several proposals have been advanced here > that /could/ work. Mine has the virtue of being completely under your > control. It does. I admit I hadn't thought of something like that, and would be interested to see what Yngve makes of it. He's done the most work on protocols for transmitting this information; see: http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-03.txt Is there a particular reason that DNS is a better mechanism than HTTP, in your view? Or is that an implementation detail? > I haven't heard you responding that either of these solutions wouldn't > work, so I'm assuming they would, but perhaps I'm wrong. It also may > be the case that for reasons of practicality you need to start with a > list embedded in the browser; as long as you have a plan to make the > transition to a list that's maintained more dynamically, and as long as > you actually execute that plan, it seems to me that this is harmless. The second question is one of resources and client complexity. I am meeting resistance to the idea of having the existing list regularly dynamically downloaded, which would be the simplest method of providing more frequent updates than the six-to-eight week Firefox security releases. An assemble-and-cache-the-data-from-DNS scheme would be an order of magnitude more complex. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] IE's domain highlighting algorithm
IE 8 has a mechanism for highlighting the "owning domain" of the current
website in the address bar.[0] As they are not using the Public Suffix
List, I asked if they would explain their algorithm for deciding what to
highlight.
A Microsoft engineer was kind enough to explain the algorithm to me, and
I have reimplemented it in Perl for my own understanding. I thought it
might also be of interest to DNSOP. Please find it attached. Note that
this is the algorithm for determining the "domain" property of the IURI
object; its (close) relationship to what is highlighted is explained in
comments in the script.
DNSOP might find it instructive to compare their approach with that of
KDE[1] and of Mozilla.
Gerv
[0]
http://blogs.msdn.com/ie/archive/2008/03/11/address-bar-improvements-in-internet-explorer-8-beta-1.aspx
[1] http://www.ietf.org/mail-archive/web/dnsop/current/msg06185.html
#!/usr/bin/perl -w
# Implementation of the IE algorithm for determining the IURI 'domain'
# property from a FQDN. This property is important in determining the
# behaviour of IE 8's address bar highlighting.
#
# Written by Gervase Markham <[EMAIL PROTECTED]>
# 2008-08-25
# Any copyright possessed by me is dedicated to the Public Domain.
# http://creativecommons.org/licenses/publicdomain/
# This statement has no effect on any rights Microsoft may or may not have.
#
# This implementation is based on an explanation from Eric Lawrence of
# Microsoft (see numbered comments). Many thanks to him. No Microsoft code
# was viewed or copied to create this implementation.
#
# IURI's "domain" property
# (http://msdn.microsoft.com/en-us/library/ms775016(VS.85).aspx) is made up of
# "PublicSuffix + 1". If there is no Public Suffix (e.g. http://foo/) then the
# domain property is null. [This script determines the value of this property.]
#
# IURI's "host" property
# (http://msdn.microsoft.com/en-us/library/ms775019(VS.85).aspx) returns the
# FQDN.
#
# IE's address bar highlighting will highlight either the IURI domain or, if
# the (IURI domain==null) AND the hostname is plain (no dots), then it will
# highlight the plain hostname. If the domain is null and the hostname is
# dotted, then nothing is highlighted (considered an error condition).
#
# Microsoft does not guarantee that any of this will always continue to work #
this way.
my $fqdn = $ARGV[0] || die "No FQDN given.\n";
print getDomain($fqdn) . "\n";
exit(0);
sub getDomain {
# 1> If the final label is empty, drop it for the purposes of this algorithm
# Otherwise "www.ericlawrence.com." would have four labels "www",
# "ericlawrence", "com", "". Instead, we drop the final label.
# GRM NOTE: split() automatically does this.
my @labels = split('\.', $_[0]);
my $labelCount = getNoOfLabelsInDomain(@labels);
# 2> Name the labels Ln,...,L3,L2,L1; decreasing from start (Leftmost=Ln) to
# finish (Rightmost=L1).
# If at any point in this algorithm the result demands >n labels, getDomain
# returns "".
if (@labels < $labelCount) {
print STDERR "Rule 2: algorithm requires more labels than present.\n";
return "";
}
else {
return join(".", @labels[-$labelCount..-1]);
}
}
sub getNoOfLabelsInDomain {
my @labels = @_;
# 3> Check n > 1. If not, there's no domain, just a plain hostname. Return
# ""; exit.
# Dotless FQDNs consist of a host only, there is no domain.
if (@labels < 2) {
print STDERR "Rule 3: only one label.\n";
return 0;
}
# 4> Check L1 == "tv". If so, getDomain returns L2.L1; exit.
# "tv" is a special-case "completely flat" ccTLD for historical reasons.
if ($labels[-1] eq "tv") {
print STDERR "Rule 4: .tv is special.\n";
return 2;
}
# 5> Check Len(L1) > 2. If so, getDomain returns L2.L1; exit.
# Len(L1)>2 suggests L1 is a gTLD rather than a ccTLD.
# If Len(L1)<=2 we assume L1 is a part of a ccTLD.
if (length($labels[-1]) > 2) {
print STDERR "Rule 5: length of L1 > 2 therefore gTLD.\n";
return 2;
}
# 6> Check if L2 in gTLD list "com,edu,net,org,gov,mil,int". If so,
# getDomain returns L3.L2.L1; exit.
# gTLDs, when they appear immediately left of a ccTLD (modulo exception in
# step 4), are considered a part of the TLD.
if ($labels[-2] =~ /^(com|edu|net|org|gov|mil|int)$/) {
print STDERR "Rule 6: L2 is in gTLD list therefore return 3 parts.\n";
return 3;
}
# 7> If L1 is in the list "GR,PL" AND L2 is NOT in the gTLD list, getDomain
# returns L2.L1; exit.
# GR and PL are considered "flat" ccTLDs EXCEPT when a gTLD appears in L2.
# getDomain("a.pl") ret
Re: [DNSOP] IE's domain highlighting algorithm
David Conrad wrote: > What is this code trying to do? The code you quoted returns the number of domain labels, counting from the right hand end, which are used to make up the "domain" property (e.g. 2). The code works this way because those are the terms in which the algorithm was described to me. Have you tried running it on some example FQDNs, like www.google.com or foo.bar.se? That should give an idea of what it does overall. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
