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

On Thu, May 24, 2012 at 2:49 PM, Boris Zbarsky <bzbarsky@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

Received on Saturday, 26 May 2012 00:37:02 UTC