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 <w3c@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
> <hallvord@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

Received on Thursday, 24 May 2012 21:02:35 UTC