On Mon, Jan 14, 2013 at 5:34 PM, Jonas Sicking wrote:
> On Jan 9, 2013 11:59 PM, "Adam Barth" wrote:
>> To gather this information, I grepped the WebKit IDL files for
>> "CheckSecurity". Here's what I learned:
> [snip]
>
> I see no mention of document.domain handling in your description.
Yeah,
On Jan 9, 2013 11:59 PM, "Adam Barth" wrote:
> To gather this information, I grepped the WebKit IDL files for
> "CheckSecurity". Here's what I learned:
[snip]
I see no mention of document.domain handling in your description.
How do you handle the case when script from one Window grabs a Node f
On 1/11/13 1:29 AM, Adam Barth wrote:
On Wed, Jan 9, 2013 at 8:21 PM, Boris Zbarsky wrote:
Yes, agreed. For what it's worth, I believe Gecko recently made history not
accessible cross-origin anymore
Do you have a link to the bug where that change was made?
https://bugzilla.mozilla.org/show
On Thu, Jan 10, 2013 at 10:29 PM, Adam Barth wrote:
>> Yes, agreed. For what it's worth, I believe Gecko recently made history not
>> accessible cross-origin anymore, so with any luck you'll be able to make
>> this change too if desired...
>
> Do you have a link to the bug where that change was m
On Wed, Jan 9, 2013 at 8:21 PM, Boris Zbarsky wrote:
> Adam, thank you for taking the time to put this together. I really
> appreciate it. There are lots of things here where we can converge behavior
> no matter what happens with other pieces of the platform.
>
> On 1/9/13 5:58 PM, Adam Barth wr
Adam, thank you for taking the time to put this together. I really
appreciate it. There are lots of things here where we can converge
behavior no matter what happens with other pieces of the platform.
On 1/9/13 5:58 PM, Adam Barth wrote:
Generally speaking, I'd recommend exposing as few thin
On Wed, 9 Jan 2013, Anne van Kesteren wrote:
> On Tue, Jan 8, 2013 at 7:46 AM, Boris Zbarsky wrote:
> > Actually, that's not enough. You have to security-check arguments
> > too. Otherwise this:
> >
> > document.createTreeWalker(crossFrameDoc, etc);
> >
> > would be bad. (Note that right now
On Wed, 9 Jan 2013, James Graham wrote:
> On Wed, 9 Jan 2013, Boris Zbarsky wrote:
> > On 1/9/13 4:12 PM, Adam Barth wrote:
> > > >window.addEventListener.call(otherWindow, "click", function()
> > > > {});
> > >
> > > This example does not appear to throw an exception in Chrome. It
> > > ap
On Wed, 9 Jan 2013, Boris Zbarsky wrote:
> On 1/9/13 4:33 PM, Adam Barth wrote:
> > For what it's worth, that doesn't appear to be necessary for web
> > compatibility. Any time WebKit would return a Document to a script in
> > another origin, WebKit returns null instead.
>
> The HTML spec requi
On Wed, 9 Jan 2013, Adam Barth wrote:
> On Wed, Jan 9, 2013 at 1:28 PM, Ian Hickson wrote:
> > On Wed, 9 Jan 2013, Adam Barth wrote:
> >> The Document interface (which is what we started this thread
> >> discussing) is never visible across origins and so does not have any
> >> of these complexit
On Wed, Jan 9, 2013 at 2:24 PM, Boris Zbarsky wrote:
> On 1/9/13 5:19 PM, Adam Barth wrote:
>> Those checks are neither required for compatibility nor security. The
>> spec might say to perform the checks, but they aren't needed to build
>> a secure, compatible browser.
>
> OK. So what checks do
On Wed, Jan 9, 2013 at 2:18 PM, Boris Zbarsky wrote:
> On 1/9/13 4:33 PM, Adam Barth wrote:
>> For what it's worth, that doesn't appear to be necessary for web
>> compatibility. Any time WebKit would return a Document to a script in
>> another origin, WebKit returns null instead.
>
> The HTML spe
On Wed, 9 Jan 2013, Boris Zbarsky wrote:
On 1/9/13 4:12 PM, Adam Barth wrote:
window.addEventListener.call(otherWindow, "click", function() {});
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a secu
On 1/9/13 5:19 PM, Adam Barth wrote:
Those checks are neither required for compatibility nor security. The
spec might say to perform the checks, but they aren't needed to build
a secure, compatible browser.
OK. So what checks do you believe are required, then? Just effective
script origin c
On 1/9/13 4:28 PM, Anne van Kesteren wrote:
You didn't file a bug on this I think.
Yes, because the DOM spec is not the right place to address it, imo.
-Boris
On 1/9/13 4:33 PM, Adam Barth wrote:
For what it's worth, that doesn't appear to be necessary for web
compatibility. Any time WebKit would return a Document to a script in
another origin, WebKit returns null instead.
The HTML spec requires that property access on documents use effective
scrip
On 1/9/13 4:12 PM, Adam Barth wrote:
window.addEventListener.call(otherWindow, "click", function() {});
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a security error to the debug console).
Hmm. I
On Wed, Jan 9, 2013 at 1:28 PM, Ian Hickson wrote:
> On Wed, 9 Jan 2013, Adam Barth wrote:
>> The Document interface (which is what we started this thread discussing)
>> is never visible across origins and so does not have any of these
>> complexities.
>
> Actually Document objects can be visible
On Tue, Jan 8, 2013 at 7:46 AM, Boris Zbarsky wrote:
> Actually, that's not enough. You have to security-check arguments too.
> Otherwise this:
>
> document.createTreeWalker(crossFrameDoc, etc);
>
> would be bad. (Note that right now the DOM spec fails to handle this, which
> is about what I w
On Wed, 9 Jan 2013, Adam Barth wrote:
>
> The Document interface (which is what we started this thread discussing)
> is never visible across origins and so does not have any of these
> complexities.
Actually Document objects can be visible across origins per spec, but none
of their properties e
On Wed, Jan 9, 2013 at 12:23 PM, Boris Zbarsky wrote:
> On 1/9/13 3:12 PM, Adam Barth wrote:
>> As I've stated several times on this thread (any many times over the
>> years), my opinion is that we should not expose an asymmetric access
>> relation to the web platform.
>
> OK, let's agree to disag
On 1/9/13 3:12 PM, Adam Barth wrote:
As I've stated several times on this thread (any many times over the
years), my opinion is that we should not expose an asymmetric access
relation to the web platform.
OK, let's agree to disagree on this one for now.
Do we at least agree that this code:
On Wed, Jan 9, 2013 at 11:59 AM, Boris Zbarsky wrote:
> On 1/9/13 2:30 PM, Adam Barth wrote:
>> As a consequence, I would recommend that you do not use asymmetric
>> access relations in features that you would like other browser vendors
>> to implement in the future.
>
> Browsers have asymmetric a
On 1/9/13 2:30 PM, Adam Barth wrote:
As a consequence, I would recommend that you do not use asymmetric
access relations in features that you would like other browser vendors
to implement in the future.
Browsers have asymmetric access relations all the time; they just have
some of the code in
It seems like your arguments all originate from wanting to support an
asymmetric access relation. Supporting an asymmetric access relation
is a bad idea, and we shouldn't do it.
I understand that Mozilla already has technology for implementing an
asymmetric access relation and that you're using i
On 1/9/13 3:11 AM, Adam Barth wrote:
I'm not convinced of that. I understand that Gecko need to deal with
these complications because of a number of Mozilla-proprietary APIs,
Actually, what I'm talking about here has nothing to do with APIs but
everything to do with wanting to write web appli
On Tue, Jan 8, 2013 at 5:56 AM, Boris Zbarsky wrote:
> On 1/8/13 8:14 AM, Boris Zbarsky wrote:
>> On 1/8/13 2:09 AM, Ian Hickson wrote:
>>> In the spec's security model, origins are never relevant for elements
>>> except when we're looking at the element's data.
>>
>> Yes. I think the spec's secu
On 1/8/13 8:14 AM, Boris Zbarsky wrote:
On 1/8/13 2:09 AM, Ian Hickson wrote:
In the spec's security model, origins are never relevant for elements
except when we're looking at the element's data.
Yes. I think the spec's security model is not viable long-term, for
what it's worth, and think w
On 1/8/13 2:16 AM, Ian Hickson wrote:
I don't know about Document, but I can definitely think of APIs where it
makes sense to be passing Window objects from other origins.
Yeah, I can see exceptions for Window, possibly.
But if there's only one API that takes any of these four object types
cu
On 1/8/13 2:09 AM, Ian Hickson wrote:
In the spec's security model, origins are never relevant for elements
except when we're looking at the element's data.
Yes. I think the spec's security model is not viable long-term, for
what it's worth, and think we should be designing a security model t
On Tue, 8 Jan 2013, Boris Zbarsky wrote:
> On 1/8/13 1:42 AM, Boris Zbarsky wrote:
> >On 1/7/13 11:28 PM, Ian Hickson wrote:
> > > The check is the same -- if the Document that is the "this" to which
> > > the property is being applied doesn't match the origin of the script
> > > that is doing th
On Tue, 8 Jan 2013, Boris Zbarsky wrote:
> On 1/7/13 11:28 PM, Ian Hickson wrote:
> > Per spec, even Windows actually don't have an origin. Things that have
> > origins are URLs, Documents, images, audio and video elements, fonts,
> > and scripts. Many of those things can have origins that are no
On 1/8/13 1:42 AM, Boris Zbarsky wrote:
>On 1/7/13 11:28 PM, Ian Hickson wrote:
The check is the same -- if the Document that is the "this" to
which the property is being applied doesn't match the origin of the
script
that is doing the applying, throw SecurityError.
Actually, that's not enough.
On 1/7/13 11:28 PM, Ian Hickson wrote:
Per spec, even Windows actually don't have an origin. Things that have
origins are URLs, Documents, images, audio and video elements, fonts, and
scripts. Many of those things can have origins that are not that of the
most obvious related (or in some cases an
On Mon, 7 Jan 2013, Boris Zbarsky wrote:
> On 1/7/13 6:41 PM, Ian Hickson wrote:
> > Most things don't have an origin.
>
> Pretty much everything has an origin in practice: it's associated with
> some Window, hence can be treated as having the same origin as that
> Window.
Per spec, even Window
On 1/7/13 6:41 PM, Ian Hickson wrote:
Most things don't have an origin.
Pretty much everything has an origin in practice: it's associated with
some Window, hence can be treated as having the same origin as that Window.
Origin checks are only done in some very
specific places where you try t
On 1/7/13 6:20 PM, Cameron McCormack wrote:
Why would this need to be on specific operations and not just be
enforced on every operation?
I believe Gecko currently enforces this sort of thing on every
operation, for what it's worth.
Or it it that only a limited set of objects is exposed
cro
On Tue, 8 Jan 2013, Cameron McCormack wrote:
> On 16/12/12 9:34 PM, David Bruant wrote:
> > WebIDL needs to embed in some way the notion of origin to enable
> > throwing for security reasons in the right places.
> >
> > One idea would be to add an [OriginAware] extended attribute:
> > * On operat
On 16/12/12 9:34 PM, David Bruant wrote:
WebIDL needs to embed in some way the notion of origin to enable
throwing for security reasons in the right places.
One idea would be to add an [OriginAware] extended attribute:
* On operations (like in Boris case), an origin check would be performed
befo
On 12/15/12 8:33 PM, Jonas Sicking wrote:
An "easy" solution would be to just return null for .contentDocument
in the case of cross-origin iframes.
Even if that were web-compatible (which is not obvious), that doesn't
solve the problem of doing the same sort of thing with .contentWindow.
-Bo
40 matches
Mail list logo