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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gervase Markham wrote: Florian Weimer wrote: * Jamie Lokier: 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. 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? And will they care? (well, livejournal might, but i could imagine some others not to care enough to get themselves on it) Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIT4+T4nZCKsdOncURAqZkAKCOxkwMs6By3zxef2AhKU7nP9+0qgCbBJZd sEApH+yga8r+DXQVN76qpMQ= =SP/N -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Wed, Jun 11, 2008 at 10:15:19AM +0100, Gervase Markham [EMAIL PROTECTED] wrote a message of 53 lines which said: 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? Interesting. It reminds me of the RIR which assign IP addresses prefixes without being able to guarantee they will be routed. I always assumed that the poor domain name registrant had only to fight with the rules of the registrar/registry/ICANN/governement to get his domain registered and used everywhere in the world. Now, I see that besides registration rules (sometimes painful, see http://www.afnic.fr/obtenir/chartes_en), registrants also have to go through the filter of browser authors. ___ 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
On Tue, Jun 10, 2008 at 11:31:00PM +0200, Stephane Bortzmeyer [EMAIL PROTECTED] wrote a message of 16 lines which said: I assume it is a list of TLD which register at the third level. If so, it is questionable (.af, .dz, .fr register at the second and the third level and I do not know how Konqueror handles it). Reported http://bugs.kde.org/show_bug.cgi?id=163774. Let's see if Konqueror people react in the Mozilla way (We decided and your opinion does not matter) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On ons, 2008-06-11 at 10:10 +0100, Gervase Markham wrote: 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. If you do this wronly yes. 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. No. Neither users or sites are completely static in nature. Long history and experience has shown us that we can't just break people's websites like that. Sites do break in upgrades. Problems arise if you break too many of them and neither the site operators of users have an easy way around, or when they do not understand why things broke. Fortunately the area we are discussing is fundamentally broken by design, and sites do break today differently in different browsers. If you want something positive to come out of discussions like this you have to have a little more open mind in looking where to find solutions. There is at least 10 different solutions to the cookie domain problem, of varying complexity and feasibility. Your proposed list is one, and not a competely bad one, but very incomplete and too static to be feasible as the solution to this problem. But it's a reasonable interim step to patch things up while discussing how the actual problem should be addressed. In short the cookie problem is threefold: a) Receivers of a cookie have no way of knowing who issued that cookie. b) Receivers of cookies have no means of indicating who is allowed to set cookies for them. c) Issuers of cookies often want to issue a cookie to multiple domains all of which is under their administrative control, but often have to figth the very blunt domain based filters. As result we have many designs using URL based transfer of the cookie details when moving from one site to another when better operation would be seen if the cookie could be managed as a single cookie valid for multiple sites. These URL based cookie tunnels is often installed as a way around broken browser cookie policies, and I would suspect they often create gaping security issues from lacking awareness of why these policies even exists. Regards Henrik signature.asc Description: This is a digitally signed message part ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Tue, Jun 10, 2008 at 09:22:27PM +0200, Florian Weimer [EMAIL PROTECTED] wrote a message of 10 lines which said: In other words, Internet Explorer has got it's own list (and the operating system, too, for use in DNS devolution). According to this blog post, IE does it the other direction (SLD are the rule and registration under the TLD the exception): http://crisp.tweakblogs.net/blog/ie-and-2-letter-domain-names.html ___ 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
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!?) sigh 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
Gervase Markham wrote: 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!?) sigh 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. Thus you are going to break the contract that mybank.co.uk has with adserver.co.uk? wow, now you are really getting into something... That privacy issue is not a privacy issue, that is an issue with the bank in question which is compromising the privacy of its users. Solve the problem at the bank. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
While this thread isn't necessarily off-topic for ietf-http-wg list, it's more relevant IMO to dnsop, and cross-posted high-volume discussions tend to be distracting. So, please try to move discussion onto the dnsop list (I've set Reply- To accordingly). Thanks, -- Mark Nottingham http://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
At 23:10 +1000 6/11/08, Mark Nottingham wrote: While this thread isn't necessarily off-topic for ietf-http-wg list, it's more relevant IMO to dnsop, and cross-posted high-volume discussions tend to be distracting. So, please try to move discussion onto the dnsop list (I've set Reply- To accordingly). Odd to see this, I was about to say what does this have to do with DNS operations? and suggest that it move back to the HTTP group. Cookies aren't part of the DNS protocol. Is the issue that a cookie needs to state for what domains it is valid? Are you trying to relate domain names to a registrant? That's not a DNS issue, that's a WhoIs/IRIS issue, if you want to pin that into a protocol. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase Markham 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? under the current code ... www.mybank.co.uk can set cookies for ... 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. I'm not seeing how this is different from mybank.livejournal.com setting cookies on livejournal.com which can be read by adserver.livejournal.com. livejournal.com needs to be on your Public Suffix List to prevent that - if the content from subdomains can set their own cookies. Maybe not on Livejournal, but there are sites where it's possible. Even in mybank.co.uk, it's typical that login.mybank.co.uk and thirdpartyinformation.mybank.co.uk will be somewhat independent. The latter should not be setting arbitrary cookies affecting the former, imho - security, rather than privacy. Regarding the break the contract with adserver argument, there are plenty of ways for mybank.co.uk to pass tracking info to adserver.co.uk by contract. Banning cross-domain cookies in this case just forces them to use another method. (Again, I comment that cookies are not the only way we are using this information.) I don't think anybody minds how you use the information to present History dialogs and such. Just whether it breaks applications that come to depend on the structure of the list, and whether it adds another barrier for site publishers who serve public content in a way which resembles NICs. -- Jamie ___ 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
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 ___ that URL does not resolve in the way you might expect. --bill ___ 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
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? Serious question. I think several proposals have been advanced here that /could/ work. Mine has the virtue of being completely under your control. The other one, where subdomains are called out in the zones of the domains that contain them, is not under your control, and wouldn't be a good interim solution, but sounds like a good long-term solution because it puts correctness in the hands of the people who suffer or benefit from it. So what I would personally like to see here is a staged transition. In the first stage, mozilla.org would set up a TLD list in its own DNS space, or in some new subdomain they register with good anycast replication so that no individual server has to bear the entire load. This list would be maintained by mozilla.org, using information from registries and domain owners, and also using your current ad-hoc system. But you'd also implement the system that was proposed here where the registries themselves can publish this information in their own domains. And over time, the hope would be that the number of TLDs you'd have to maintain in your list would slowly dwindle, to the point where it would become more of a quirks list than a registry of its own. This could work because the incentives are in the right direction - sites that have problems with your ad-hoc registry can either contact you or fix their own DNS, and fixing their own DNS may well be easier. 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. BTW, thanks for your reasoned responses to all these questions and accusations being thrown at you. You seem to have really elicited a lot of energetic response with your initial request, and I hope that something good will come of it. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
On Jun 11, 2008, at 11:06 AM, 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. Joe, the problem description on the web site contains five paragraphs, two of which are a single sentence. ___ 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
Gervase Markham wrote: The difference is that the public suffix list is an (attempt at an) expression of fact, not policy. I think is where you are encountering resistance, even though you may not realize it. What you are doing is *publishing* something, which alleges to be a factual list. Who is on it, who is not on it, and who uses it and how, matter a great deal. If the list is 100% complete and 100% accurate and 100% timely, there are no problems. Any deviation from that situation, regardless of how much and in what manner the deviation occurs, puts the publisher of alleged facts at risk. And relying on authoritative sources to push data to you, is a reverse onus that hundreds of years of case law quite likely present a formidable obstacle, if it becomes necessary to defend your choice. Here's a concrete analogy that may be suitable for demonstrating the issue. Imagine a magazine dedicated to Tires. It publishes an article on Tire Safety. It contains a list of Tires (manufacturer/model) safe to use at 180 km/h. Is the list accurate? Timely? Complete? If a reader bases a safety decision (buys tires, drives 180 km/h) that goes badly, then what? What about recalls? Also: Publishing a list may be even *riskier* than publishing a single, but erroneous, fact. E.g. what about manufacturers not listed? They have been implicitly or even explicitly defamed, even if you include a footnote to the effect that this list is not complete. 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? No malice is needed on your part, for publishing a list to cause problems, esp. for you and the publisher (Mozilla). I think you might not have considered that, yet. Conclusion: Regardless of the benign intent of the list, publishing it means needing to keep it timely, accurate, and complete, and that is why the notion of updates based on volunteered data from registries, updated only when software updates are performed, is a particularly bad idea. I happen to think that the idea of maintaining such a list is probably not a bad idea itself. It is the means by which the list is built, and distributed, that are of great concern. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
On Wed, Jun 11, 2008 at 12:26 PM, Gervase Markham [EMAIL PROTECTED] wrote: 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. We must be having email issues. Because I have neither received a private email from you that I can find. Will check my spam folder in case it ended up there. And I have not seen a response to my question on the list. Its been pretty busy here since you dropped this little bomb that has gotten us so excited. So please help me out here, I didn't get that answer. So what is the answer to the question ??? What happens to your web browsers behavior if I try to surf a TLD not on the list? Thanks in advance for your answer. Joe Baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase, On Jun 11, 2008, at 4: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. I guess it depends on what you mean by 'workable'. 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. While I might agree that it is unlikely you'll get all the TLDs to agree on or do anything (they are a wildly varying bunch in pretty much every axis) I don't remember anyone suggesting you wait on the TLD operators to set up their own repositories. What I do remember folks saying is that hardcoding a list in other contexts has caused lots of trouble in the past and that it is probably a mistake for you to do it in your product. Some folks have even suggested alternatives (although I gather you do not consider them 'workable'). If I understand correctly, if there is no data (regardless of the solution), you get no change in behavior. As such, doing a probe for policy data when it is needed would seem to be workable. If there is no data available (for whatever reason), you get no change in behavior. If there is data, you get the most up to date available. Whether or not you start with a static list that is then over-ridden by the response from the probe is an implementation choice that can be argued. FWIW. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
* Gervase Markham: 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. I'd love to see an official statement from the Mozilla Foundation that cross-domain ad correlation is evil, and should be stopped by technology. Certainly this is not what you're trying to say here. I guess the real issue is that by setting a cookie for co.uk, it's possible to exploit session fixation vulnerabilities in web sites under co.uk. Unfortunately, the Public Suffix List web site is a bit unclear in this regard. It does not list a single protocol spec which requires this sort of data. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Jun 11, 2008, at 3:16 PM, Florian Weimer wrote: I guess the real issue is that by setting a cookie for co.uk, it's possible to exploit session fixation vulnerabilities in web sites under co.uk. Unfortunately, the Public Suffix List web site is a bit unclear in this regard. It does not list a single protocol spec which requires this sort of data. It's kind of assumed that you would be aware of these issues, I guess. Lots of web sites use cookies to associate a session with a particular user. With cross-site cookie theft, a malicious web site can gain access to your session cookie even if it was protected by https encryption when you were talking to the legitimate site. Of course there are ways to mitigate this risk, but the only knob the mozilla guys have to turn is preventing the cookie from being leaked in the first place. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
* Ted Lemon: It's kind of assumed that you would be aware of these issues, I guess. But hardly anybody seems to be. Lots of web sites use cookies to associate a session with a particular user. With cross-site cookie theft, a malicious web site can gain access to your session cookie even if it was protected by https encryption when you were talking to the legitimate site. Yes, but that's why cookies are associated with the host name of the incoming request. The cookie set operation controls which domains can read the cookie. No special data is required for that. What's happening here is that a restriction is placed on the largest possible subtree for which you can set a cookie. Failure to do this does not grant read access to arbitrary cookies in itself. But as I wrote, it might expose session fixation problems. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Jun 11, 2008, at 3:30 PM, Florian Weimer wrote: Failure to do this does not grant read access to arbitrary cookies in itself. But as I wrote, it might expose session fixation problems. Right, the point is that the mozilla guys can't force web site implementors to do the right thing, but they still get dinged for a security flaw if the web site implementors do the wrong thing. The only knob they can turn is this one. So it makes a great deal of sense for them to try to turn it. Also, you discounted the privacy issue in your previous message, but the point is that in some countries privacy is actually a legal requirement, one which the Mozilla folks, I think rightly, feel some obligation to honor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Hi Gervase, At 02:15 11-06-2008, Gervase Markham wrote: 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? Does that mean that the new Firefox will never display domains that allow its users to be fooled or defrauded? :-) At 04:25 11-06-2008, 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. If you push aside all the negative views, you won't see any alternative proposals. 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 That's because there are some people on this list who have attempted that before. 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. Maybe those people are not looking for a short-term fix. By the way, the question of suffix lists has been discussed in other Internet areas before. It's not restricted to cookies only. The fact that nobody pointed you to a RFC suggests that there hasn't been an acceptable solution yet. Quoting RFC 4085: Products that rely on such embedded IP addresses initially may appear to be convenient to the product's designer and to its operator or user, but this dubious benefit comes at the expense of others in the Internet community. Replace IP addresses with publish suffix and you'll see why your proposal generated so much controversy on this mailing list. Regards, -sm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Wed, 11 Jun 2008, Gervase Markham wrote: 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. Actaully, I looked into the 'Our ISP blocked our mail without our knowledge' claim. [I'm always interested in the cases where this is true]. In fact, Mozilla's email is handled by mailservers on 63.245.208/20, which is a /20 assigned to Mozilla.org. It struck me as quite odd that quite strange that Mozilla.org has 4096 IP addresses, and that it got this assignment in 2006, under what should have been very strict usage and allocation rules...I wonder how Mozilla.org justifies 4k public IP addresses---Question for a different forum. Anyway, using SORBS isn't a decision you can blame on your ISP. Its Mozilla.org's mailserver, not an outsourced ISP mailserver. Mozilla.org has control over its email filtering, and it seems likely a Mozilla.org admin configured SORBS. It was not their ISP. This affects at least my view of your credibility. 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. Well, somehow they managed to convey their upset'ness to ICANN, but not convey that to Mozilla. I don't know exactly why that was. But people often don't try very hard to overcome communication problems to tell someone that they are unreasonably off in the weeds. A SORBS bounce would tend to confirm the effort is pointless. 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/ .) I don't see that the answer is no-one, nor that the registries has been shown not to work, as you claim. However, if you think there is a problem and you have a solution that should be imposed on the TLDs, you should take the matter up with ICANN. Your unilateral exercise is certainly no solution. 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. Hmm. Worrisome, given the apparent lack of serious thought put into some of those security decisions, and the lack of credible, serious thought put into even anti-spam choices, and the blaming of things on your ISP. 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. I also use firefox, but certainly not for those reasons. I use it because it came with Linux, and it displays HTML pretty reasonably. I didn't know it might have other dubious agendas hard-coded. 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. Actually, I said that. Perhaps others did, too. 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? You have no justification to form that conclusion. The TLDs aren't defrauding anyone; The TLDs aren't aiding in the fraud of anyone. And your scheme isn't even shown to stop fraudulent websites. So Mozilla.org seems to have little to no justification whatsoever for its extremely unilateral actions. The people who register their domains with any certified TLD do have an automatic right to have Firefox display their websites. You have no right to assert they are fraudulent when they aren't and you have no evidence they are. I don't get a good feeling about Mozilla.org, anymore. The unrealistic, unilateral attitude reminds me of other kinds of similar extremism, that was also found to be unsubstantiated, and a
