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

Re: [whatwg] Location object identity and navigation behavior

From: Adam Barth <w3c@adambarth.com>
Date: Fri, 9 Nov 2012 14:05:04 -0800
Message-ID: <CAJE5ia8ec1=XsS_x-KF17A2O5j0pwYdE3y-fDpYrZrR5fvfReg@mail.gmail.com>
To: Bobby Holley <bobbyholley@gmail.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Matt Wobensmith <mwobensmith@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, Johnny Stenback <jst@mozilla.com>
On Fri, Nov 9, 2012 at 12:26 PM, Bobby Holley <bobbyholley@gmail.com> wrote:
> On Fri, Nov 9, 2012 at 12:17 PM, Adam Barth <w3c@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

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.

Received on Friday, 9 November 2012 23:04:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:17 UTC