On Mon, Jan 7, 2013 at 11:17 PM, Bobby Holley wrote:
> On Mon, Jan 7, 2013 at 8:05 PM, Ian Hickson wrote:
>> On Mon, 7 Jan 2013, Bobby Holley wrote:
>> >
>> > Aside from concerns about stack introspection, the main downside of this
>> > approach is that it's a blacklist, rather than a whitelist (
On Mon, Jan 7, 2013 at 8:05 PM, Ian Hickson wrote:
> On Mon, 7 Jan 2013, Bobby Holley wrote:
> >
> > Aside from concerns about stack introspection, the main downside of this
> > approach is that it's a blacklist, rather than a whitelist (like our
> > other security code), so we'll have to be extr
On Mon, 7 Jan 2013, Bobby Holley wrote:
>
> Aside from concerns about stack introspection, the main downside of this
> approach is that it's a blacklist, rather than a whitelist (like our
> other security code), so we'll have to be extra careful when
> implementing anything new on Location. Ple
On Mon, Jan 7, 2013 at 12:26 PM, Ian Hickson wrote:
> My understanding is that WebKit, old Gecko, and new IE do what the spec
> says currently, and old IE, Opera, and new Gecko do the proxying model.
>
Given the concerns in this thread, I never landed such a change to Gecko.
New Gecko == Old Gec
On Tue, 20 Nov 2012, Bobby Holley wrote:
> On Tue, Nov 20, 2012 at 9:46 AM, Ian Hickson wrote:
> >
> > In thinking about this further last night, it struck me that while the
> > proposed proxy mechanism was IMHO overly complex, there might be a
> > simpler mechanism that still gets all the compa
On 11/20/12 12:46 PM, Ian Hickson wrote:
Given the way JavaScript works, I just don't see a sane way to make a
non-symmetric model work.
How does "JavaScript work" in your mind? We have a good amount of
experience making a non-symmetric model work in Gecko, for what it's worth.
Any time yo
On Tue, Nov 20, 2012 at 9:46 AM, Ian Hickson wrote:
> Given the way JavaScript works, I just don't see a sane way to make a
> non-symmetric model work. JS just allows too much introspection. Any time
> you pass a string from one to the other, you're also passing a way for the
> callee to call bac
On Tue, 20 Nov 2012, Boris Zbarsky wrote:
> On 11/20/12 2:38 AM, Ian Hickson wrote:
> > IMHO there's no point us trying to keep things locked down when you
> > set document.domain.
>
> I believe sites actually rely on a certain amount of lockdown in
> situations like this... Adam can fill you i
On 11/20/12 2:38 AM, Ian Hickson wrote:
IMHO there's no point us trying to keep things locked down when you set
document.domain.
I believe sites actually rely on a certain amount of lockdown in
situations like this... Adam can fill you in, I'm sure.
But in general, as people work more and m
On Tue, 20 Nov 2012, Boris Zbarsky wrote:
>
> All you need for script A to be able to call script B as the spec us
> currently written is that sometime in the past the effective script
> origin of A matched the effective script origin of some script C and
> that at some point in the past (possi
On 11/20/12 1:23 AM, Ian Hickson wrote:
Could you elaborate in the bug? I've no idea what you think is wrong.
Done, but what's wrong is that the security checks described in the spec
check the origin of the wrong document.
You can maintain a stack of entry scripts. You can't use a global,
On Mon, 19 Nov 2012, Boris Zbarsky wrote:
> On 11/19/12 8:38 PM, Ian Hickson wrote:
> > For now I've tightened up the spec so it should be implementable,
> > secure, and Web-compatible
>
> I don't believe it's secure as currently written, actually. Filed
> https://www.w3.org/Bugs/Public/show_bu
On 11/19/12 8:38 PM, Ian Hickson wrote:
For now I've tightened up the spec so it should be implementable, secure,
and Web-compatible
I don't believe it's secure as currently written, actually. Filed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20012
I'm also curious as to why figuring ou
On Thu, 8 Nov 2012, Bobby Holley wrote:
>
> The current spec for the Location object doesn't match reality. At the
> moment, the spec says that Location is a per-Window object that
> describes the associated Document. However, in our testing, it appears
> that none of the user-agents (Gecko, Web
On 11/9/12 2:05 PM, Adam Barth wrote:
The approach we use in WebKit is quite simple---we just perform an
access check before doing any sensitive operations.
The issue in Gecko, as I understand, is that security checks from C++
code require introspecting running JS to figure out what the righ
On Fri, Nov 9, 2012 at 12:26 PM, Bobby Holley wrote:
> On Fri, Nov 9, 2012 at 12:17 PM, Adam Barth 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
On Fri, Nov 9, 2012 at 12:17 PM, Adam Barth 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://l
On Fri, Nov 9, 2012 at 11:33 AM, Adam Barth wrote:
> > That was my opinion for a while, too, but I eventually decided it was
> > necessary in Gecko.
>
> Can you explain why you think it is necessary? In WebKit, the
> WindowProxy is the only object that has this magic.
>
As noted, the Location o
On Fri, Nov 9, 2012 at 9:43 AM, Bobby Holley wrote:
> On Fri, Nov 9, 2012 at 9:30 AM, Adam Barth wrote:
>> On Thu, Nov 8, 2012 at 10:21 PM, Boris Zbarsky wrote:
>> > You presumably have a solution for this situation for the WindowProxy
>> > case,
>> > right? Certainly Gecko does, and we would b
On Fri, Nov 9, 2012 at 12:06 PM, Bobby Holley wrote:
> On Fri, Nov 9, 2012 at 11:33 AM, Adam Barth wrote:
>> > That was my opinion for a while, too, but I eventually decided it was
>> > necessary in Gecko.
>>
>> Can you explain why you think it is necessary? In WebKit, the
>> WindowProxy is the
On Fri, Nov 9, 2012 at 9:30 AM, Adam Barth wrote:
> On Thu, Nov 8, 2012 at 10:21 PM, Boris Zbarsky wrote:
> > You presumably have a solution for this situation for the WindowProxy
> case,
> > right? Certainly Gecko does, and we would be using the same solution for
> > Location if we tie the lif
On Thu, Nov 8, 2012 at 10:21 PM, Boris Zbarsky wrote:
> On 11/8/12 6:09 PM, Adam Barth wrote:
>> I don't think I quite understand what you mean, but the way this works
>> in WebKit is that each Window object has its own Location object.
>
> That's not how it works in Presto and Trident, as far as
On 11/08/2012 07:19 PM, Bobby Holley wrote:
The current spec for the Location object doesn't match reality. At the
moment, the spec says that Location is a per-Window object that describes
the associated Document. However, in our testing, it appears that none of
the user-agents (Gecko, WebKit, Tr
On 11/8/12 6:09 PM, Adam Barth wrote:
I don't think I quite understand what you mean, but the way this works
in WebKit is that each Window object has its own Location object.
That's not how it works in Presto and Trident, as far as we can tell
based on testing with "==". In those, each Window
On Thu, Nov 8, 2012 at 10:19 AM, Bobby Holley wrote:
> The current spec for the Location object doesn't match reality. At the
> moment, the spec says that Location is a per-Window object that describes
> the associated Document. However, in our testing, it appears that none of
> the user-agents (G
The current spec for the Location object doesn't match reality. At the
moment, the spec says that Location is a per-Window object that describes
the associated Document. However, in our testing, it appears that none of
the user-agents (Gecko, WebKit, Trident, Presto) do this [1]. Instead, all
imple
26 matches
Mail list logo
