Re: [whatwg] proposal for a location.domain property
On Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak m...@apple.com wrote: I don't think location.domain would be the same as location.tld, to the extent I understand the intent of them. For the URL http://www.apple.com/;, apple.com would be the domain, and com would be the TLD. Yes, but for the URL http://www.google.co.uk/; you would need to have publicsuffix.org information in order to determine that the effective domain is google.co.uk and not co.uk. I'm not going to add this because cookies and document.domain are not good use cases for this. Cookies should eventually move to an origin-based security model (probably via some kind of opt-in) and document.domain should simply be avoided. (Ian asked me to reply to this thread https://www.w3.org/Bugs/Public/show_bug.cgi?id=20011 as the URL Standard now deals with these attributes.) -- http://annevankesteren.nl/
Re: [whatwg] proposal for a location.domain property
On Nov 29, 2012, at 4:31 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak m...@apple.com wrote: I don't think location.domain would be the same as location.tld, to the extent I understand the intent of them. For the URL http://www.apple.com/;, apple.com would be the domain, and com would be the TLD. Yes, but for the URL http://www.google.co.uk/; you would need to have publicsuffix.org information in order to determine that the effective domain is google.co.uk and not co.uk. I'm not going to add this because cookies and document.domain are not good use cases for this. Cookies should eventually move to an origin-based security model (probably via some kind of opt-in) and document.domain should simply be avoided. (Ian asked me to reply to this thread https://www.w3.org/Bugs/Public/show_bug.cgi?id=20011 as the URL Standard now deals with these attributes.) To be clear, I don't support adding either location.domain or location.tld. It was messages earlier in the thread that asked for it. My remark above was just a pedantic correction. - Maciej
Re: [whatwg] proposal for a location.domain property
On Thu, 24 May 2012 23:02:00 +0200, Maciej Stachowiak m...@apple.com wrote: I agree. Even though there are still legacy features like cookies and document.domain that use domain-based security, most of the Web platform uses origin-based security, and that has proved to be a sounder model. While I acknowledge the use cases for exposing location.domain, it's also likely to become an attractive nuisance that pulls developers in the wrong direction. Although I understand this opinion and agree with it, the domain based security checks are used for cross frame interaction, cookies, security certificates, etc, therefore it has to be specified and documented. I don't think adding a location.tld property or location.topDomain would pull developers away from anything. It would just make the legacy domain based security checks a bit more easy to handle and understand. It's the specifications and APIs that tell which security model to use, not the developer.
Re: [whatwg] proposal for a location.domain property
On Thu, May 24, 2012 at 2:49 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/24/12 5:02 PM, Maciej Stachowiak wrote: I agree. Even though there are still legacy features like cookies and document.domain that use domain-based security, most of the Web platform uses origin-based security For security, yes. But for, say, resource limits, one wants to use domain-based limits because otherwise limits are easily worked around using subdomains. At least that's the way we try to do it in Gecko. Looking at our (Mozilla's) internal uses of getBaseDomain(), it's used for: * cookies * various site identity UI bits (e.g. highlighting the TLD+1 in the URL bar, the thing to show as the site identifier in various prompts, and so forth) * something about deciding whether to send CSP error reports ^^^ We removed this from the CSP spec for precisely this reason. This code in Gecko is out-of-date and should be removed. * third-party determination (mostly cookies again, I suspect) * document.domain setting * Clearing per-site plugin data (see cookies) * localStorage quota enforcement * Something with caps on number of concurrent DOM workers * The URL bar autosuggest implementation Of this list, only cookie and document.domain are directly observable to the web. For example, the URL bar autosuggest obviously isn't observable in the platform. The cap on the number of web workers also isn't really reliably observable because there are any number of reasons why a browser might refuse to create another web worker. Exposing this information in location.domain would make the eTLD list much more directly observable, which is the wrong direction for the web. Adam I agree that it's not entirely clear how much of this is relevant to the web at large. Web apps that need this functionality (e.g. the browser in B2G) _can_ always import the eTLD list, if forced to -Boris
Re: [whatwg] proposal for a location.domain property
On May 25, 2012, at 4:27 AM, João Eiras jo...@opera.com wrote: On Thu, 24 May 2012 23:02:00 +0200, Maciej Stachowiak m...@apple.com wrote: I agree. Even though there are still legacy features like cookies and document.domain that use domain-based security, most of the Web platform uses origin-based security, and that has proved to be a sounder model. While I acknowledge the use cases for exposing location.domain, it's also likely to become an attractive nuisance that pulls developers in the wrong direction. Although I understand this opinion and agree with it, the domain based security checks are used for cross frame interaction, cookies, security certificates, etc, therefore it has to be specified and documented. When you say cross frame interaction, do you mean just the relatively rare case of document.domain being explicitly set? I agree with you that we must document the right rules for what domains are valid, but I do not think that this requires exposing location.domain explicitly. I don't think adding a location.tld property or location.topDomain would pull developers away from anything. It would just make the legacy domain based security checks a bit more easy to handle and understand. It's the specifications and APIs that tell which security model to use, not the developer. I don't think location.domain would be the same as location.tld, to the extent I understand the intent of them. For the URL http://www.apple.com/;, apple.com would be the domain, and com would be the TLD. Regards, Maciej
[whatwg] proposal for a location.domain property
Many browser engines use lists of top-level domains to be able to
determine what a server's base domain is. For some use cases it would be
interesting to have this information available to scripts. I list some use
cases I can think of below:
1) Determining in a simple and fool-proof manner that a page is from a
given domain. For example, if a script that might run on *.example.com,
*.example.co.uk etc can do
if(location.domain.indexOf('example.'==0) to check whether it runs on an
*.example.* site (and not get a false positive match on
example.exmple.com).
2) Checking what the shortest possible string for document.domain is.
3) Set cookies for all servers in a domain easily from JS without specific
string operations on the hostname
Thoughts?
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: [whatwg] proposal for a location.domain property
IMHO, we should be moving away from using the public suffix list in
the platform rather than adding more APIs that interact with it.
Adam
On Thu, May 24, 2012 at 8:35 AM, Hallvord R. M. Steen
hallv...@opera.com wrote:
Many browser engines use lists of top-level domains to be able to determine
what a server's base domain is. For some use cases it would be interesting
to have this information available to scripts. I list some use cases I can
think of below:
1) Determining in a simple and fool-proof manner that a page is from a given
domain. For example, if a script that might run on *.example.com,
*.example.co.uk etc can do
if(location.domain.indexOf('example.'==0) to check whether it runs on an
*.example.* site (and not get a false positive match on example.exmple.com).
2) Checking what the shortest possible string for document.domain is.
3) Set cookies for all servers in a domain easily from JS without specific
string operations on the hostname
Thoughts?
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: [whatwg] proposal for a location.domain property
I agree. Even though there are still legacy features like cookies and
document.domain that use domain-based security, most of the Web platform uses
origin-based security, and that has proved to be a sounder model. While I
acknowledge the use cases for exposing location.domain, it's also likely to
become an attractive nuisance that pulls developers in the wrong direction.
- Maciej
On May 24, 2012, at 10:56 AM, Adam Barth w...@adambarth.com wrote:
IMHO, we should be moving away from using the public suffix list in
the platform rather than adding more APIs that interact with it.
Adam
On Thu, May 24, 2012 at 8:35 AM, Hallvord R. M. Steen
hallv...@opera.com wrote:
Many browser engines use lists of top-level domains to be able to determine
what a server's base domain is. For some use cases it would be interesting
to have this information available to scripts. I list some use cases I can
think of below:
1) Determining in a simple and fool-proof manner that a page is from a given
domain. For example, if a script that might run on *.example.com,
*.example.co.uk etc can do
if(location.domain.indexOf('example.'==0) to check whether it runs on an
*.example.* site (and not get a false positive match on example.exmple.com).
2) Checking what the shortest possible string for document.domain is.
3) Set cookies for all servers in a domain easily from JS without specific
string operations on the hostname
Thoughts?
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: [whatwg] proposal for a location.domain property
On 5/24/12 5:02 PM, Maciej Stachowiak wrote: I agree. Even though there are still legacy features like cookies and document.domain that use domain-based security, most of the Web platform uses origin-based security For security, yes. But for, say, resource limits, one wants to use domain-based limits because otherwise limits are easily worked around using subdomains. At least that's the way we try to do it in Gecko. Looking at our (Mozilla's) internal uses of getBaseDomain(), it's used for: * cookies * various site identity UI bits (e.g. highlighting the TLD+1 in the URL bar, the thing to show as the site identifier in various prompts, and so forth) * something about deciding whether to send CSP error reports * third-party determination (mostly cookies again, I suspect) * document.domain setting * Clearing per-site plugin data (see cookies) * localStorage quota enforcement * Something with caps on number of concurrent DOM workers * The URL bar autosuggest implementation I agree that it's not entirely clear how much of this is relevant to the web at large. Web apps that need this functionality (e.g. the browser in B2G) _can_ always import the eTLD list, if forced to -Boris
