Re: [whatwg] proposal for a location.domain property
On Nov 29, 2012, at 4:31 AM, Anne van Kesteren wrote: > On Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak 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 Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak 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 May 25, 2012, at 4:27 AM, João Eiras wrote: > On Thu, 24 May 2012 23:02:00 +0200, 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, 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
Re: [whatwg] proposal for a location.domain property
On Thu, May 24, 2012 at 2:49 PM, Boris Zbarsky 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 Thu, 24 May 2012 23:02:00 +0200, 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, 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 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
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 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
> 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
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
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
