On Jan 9, 2013 11:59 PM, Adam Barth w...@adambarth.com 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
On Mon, Jan 14, 2013 at 5:34 PM, Jonas Sicking jo...@sicking.cc wrote:
On Jan 9, 2013 11:59 PM, Adam Barth w...@adambarth.com 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
On Thu, Jan 10, 2013 at 10:29 PM, Adam Barth w...@adambarth.com 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
On 1/11/13 1:29 AM, Adam Barth wrote:
On Wed, Jan 9, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu 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?
On Wed, Jan 9, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu 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,
On Tue, Jan 8, 2013 at 5:56 AM, Boris Zbarsky bzbar...@mit.edu 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
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
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
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
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 12:23 PM, Boris Zbarsky bzbar...@mit.edu 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
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 ever
On Tue, Jan 8, 2013 at 7:46 AM, Boris Zbarsky bzbar...@mit.edu 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
On Wed, Jan 9, 2013 at 1:28 PM, Ian Hickson i...@hixie.ch 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
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 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
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 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
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
On Wed, Jan 9, 2013 at 2:18 PM, Boris Zbarsky bzbar...@mit.edu 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
On Wed, Jan 9, 2013 at 2:24 PM, Boris Zbarsky bzbar...@mit.edu 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
On Wed, 9 Jan 2013, Adam Barth wrote:
On Wed, Jan 9, 2013 at 1:28 PM, Ian Hickson i...@hixie.ch 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
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 requires that
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
appears to just returns
On Wed, 9 Jan 2013, Anne van Kesteren wrote:
On Tue, Jan 8, 2013 at 7:46 AM, Boris Zbarsky bzbar...@mit.edu 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
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
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
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 operations (like
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
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
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 Windows
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
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 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 not that
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 the applying,
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.
36 matches
Mail list logo
