- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 9 Nov 2012 14:05:04 -0800
- 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 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
Received on Friday, 9 November 2012 23:04:17 UTC