[whatwg] Location object identity and navigation behavior

[Adam Barth]

On Fri, Nov 9, 2012 at 12:26 PM, Bobby Holley <bobbyholley at gmail.com> wrote:
> On Fri, Nov 9, 2012 at 12:17 PM, Adam Barth <w3c at adambarth.com> wrote:
>> I don't think the average web developer will hit this case because it
>> depends on interacting with the Location object in an inactive
>> document.
>
> Agreed.
>
>> Maybe I didn't receive your email.
>
> Here's a link to it in the archives:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037850.html

Thanks for the link.  Somehow the message got routed to spam.

It's possible we could implement that in WebKit, but the
implementation would be very delicate.  We currently implement similar
security checks for Location because Location is visible across
origins.  The main difficulty would be implementing the
WindowProxy-like re-writing of existing references.  I understand that
implementing that behavior in Gecko is much easier than in WebKit
because Gecko makes extensive use of JavaScript wrapper objects.  We
have avoided introducing similar wrapper objects in WebKit because
they're quite subtle and can lead to security vulnerabilities if used
incorrectly.

I don't fully understand why the current behavior is fragile in Gecko.
 The approach we use in WebKit is quite simple---we just perform an
access check before doing any sensitive operations.  This access check
is required in any case because the underlying Location object is
visible across origins.  I guess the issue must be that Gecko performs
the access check based on some property of the JavaScript object.  In
WebKit, we simply perform the access check based on the operation
we're actually about to perform, irrespective of what API was used to
trigger the action.

Adam