W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

Re: [whatwg] proposal for a location.domain property

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 25 May 2012 18:58:36 -0700
Message-id: <ACB2DD95-08FF-41A5-AFD7-B5DA85F1C213@apple.com>
To: Joćo Eiras <joaoe@opera.com>
Cc: whatwg@lists.whatwg.org

On May 25, 2012, at 4:27 AM, Joćo Eiras <joaoe@opera.com> wrote:

> On Thu, 24 May 2012 23:02:00 +0200, Maciej Stachowiak <mjs@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.

Received on Saturday, 26 May 2012 01:59:06 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:42 UTC