Re: [Whatwg] [whatwg] More on postMessage (OT)
Dnia piątek, 20 lipca 2007 04:49, Maciej Stachowiak napisał: I don't think AppleScript is very useful to understanding API design in languages with more conventional syntax. For example, document.write(foobar) is not very well expressed as 'tell document to write foobar', it would be more accurate to say 'write foobar to document'. It is consistent with the original tell paragraph 5 to set word 3 to foobar. I am accustomed to this syntax and I can see nothing weird about it right now. AppleScript rulez :-) Chris
Re: [whatwg] More on postMessage
- Original Message - From: Jeff Walden [EMAIL PROTECTED] To: Gorm Haug Eriksen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, July 16, 2007 9:17 PM Subject: Re: [whatwg] More on postMessage I'll agree that calling postMessage on the other window feels like a better and more intuitive API for users, but if implementers have to make such invasive and potentially-unsafe changes to do it, I think it's the wrong way to do it. How come? otherWindow.postMessage(M) translates to AppleScript tell otherWindow to post message M. It is not what you want to do here. You can either tell thisWindow to post message M to otherWindow-which is good because thisWindow can intercept the message and handle the fact that you are trying to post according to an event handler that may be attached-or tell otherWindow to receive message M from thisWindow which is wrong because thisWindow is unaware that you pretend it is posting a message. If you follow this path nevertheless, you should call it receiveMessage, not postMessage. Best regards Chris
Re: [whatwg] More on postMessage
On Jul 19, 2007, at 5:53 AM, Krištof Želechovski wrote: I'll agree that calling postMessage on the other window feels like a better and more intuitive API for users, but if implementers have to make such invasive and potentially-unsafe changes to do it, I think it's the wrong way to do it. How come? otherWindow.postMessage(M) translates to AppleScript tell otherWindow to post message M. It is not what you want to do here. You can either tell thisWindow to post message M to otherWindow-which is good because thisWindow can intercept the message and handle the fact that you are trying to post according to an event handler that may be attached-or tell otherWindow to receive message M from thisWindow which is wrong because thisWindow is unaware that you pretend it is posting a message. If you follow this path nevertheless, you should call it receiveMessage, not postMessage. I don't think AppleScript is very useful to understanding API design in languages with more conventional syntax. For example, document.write(foobar) is not very well expressed as 'tell document to write foobar', it would be more accurate to say 'write foobar to document'. Regards, Maciej
Re: [whatwg] More on postMessage
On Sun, 15 Jul 2007 02:15:45 +0200, Jeff Walden [EMAIL PROTECTED] wrote: First, I think placing |otherWindow| as the first argument and |message| as the second is more aesthetically pleasing than the other way around, tweaking the suggestion I made last time. I don't have a strong reason for this beyond its being analogous to the traditional security model in the literature (which seems good enough to me in the absence of strong reasons going the other way): yourWindow . postMessage ( otherWindow , message ) ; actor doesverbto object Jeff, I agree that postMessage should have been on the window and not on the document, but why would you like to have the method on yourWindow instead of the otherWindow you post the message to? Are there any concrete benefits/use-cases for this? -- Cheers, - Gorm
Re: [whatwg] More on postMessage
Gorm Haug Eriksen wrote:
I agree that postMessage should have been on the window and not on the
document, but why would you like to have the method on yourWindow
instead of the otherWindow you post the message to?
The benefit is that you don't have to punch holes through your existing
security infrastructure to do it. If you're in your code, you can have a
reference to an |otherWindow| that's not same-origin as you, but you can't do
any of the following (and probably more) with it:
var secretProperty = otherWindow.secretProperty; // stolen!
for (var i in otherWindow)
{
// if you get here, you know some of otherWindow's
// properties -- information leak
}
otherWindow.trustedProperty = subverted; // oops!
delete otherWindow.importantInfo; // DOS
For you to need to use postMessage on otherWindow, you need to be able to do
many of these things -- but the entire browser security model is based on not
allowing you to do this if the window you've called it on isn't same-origin
with you. You have to punch a hole in this security to allow getting, calling,
or enumerating postMessage, but only if the object off which the property is
gotten is a Window. You also have to make the property appear
ReadOnly/DontDelete externally, so you can't screw with windows that try to
call postMessage on you. Also, how does this restriction work with other
windows which are same-origin? Do they see only the original postMessage
binding, or do they see any modifications that window makes to it? What if a
different window, same-origin, makes that modification? What if windows
pre-HTML5 wanted to communicate via a postMessage binding? This gets
complicated pretty quickly, and to do it all you have to punch a hole through
security, and wi
th the fragility of that hole (only on Window, only if postMessage, only with
the original binding or only if it hasn't been overridden -- and I'm not at all sure
that's enough) and the specific criteria for that hole to exist, it's going to be easy to
accidentally allow more than you wanted to allow.
In contrast, passing a different-origin value into a function is already
allowed, and you don't need to do anything special to make it possible. The
only security modification to allow the cross-origin-ness is to make
postMessage ignore origins. This is *vastly* simpler, easier to implement, and
hence safer and more secure.
I'll agree that calling postMessage on the other window feels like a better and
more intuitive API for users, but if implementers have to make such invasive
and potentially-unsafe changes to do it, I think it's the wrong way to do it.
Jeff
Re: [whatwg] More on postMessage
On 7/16/07, Jeff Walden [EMAIL PROTECTED] wrote: I'll agree that calling postMessage on the other window feels like a better and more intuitive API for users, but if implementers have to make such invasive and potentially-unsafe changes to do it, I think it's the wrong way to do it. FWIW, I completely agree with this argument. And if we were to implement PostMessage in Gears for IE, Jeff's proposal would probably make it easier to do. - a
Re: [whatwg] More on postMessage
FWIW, I just talked with our javascript security guys and they very much
agree with Jeff. Browsers have to deal with accessing properties on
other windows already, such as otherWindow.open(...). However this is
very hard to implement safely and we have found numerous security
problems with this stuff over the years, some exploitable, some not. So
the fewer properties like this we have the better.
So this is purely an implementation issue. There may be other reasons
too, but implementation wise it's much simpler, and author wise the
difference in syntax is simply:
otherWindow.sendMessage(hi);
vs.
sendMessage(otherWindow, hi);
which really doesn't matter much I would think.
/ Jonas
Jeff Walden wrote:
Gorm Haug Eriksen wrote:
I agree that postMessage should have been on the window and not on the
document, but why would you like to have the method on yourWindow
instead of the otherWindow you post the message to?
The benefit is that you don't have to punch holes through your existing
security infrastructure to do it. If you're in your code, you can have
a reference to an |otherWindow| that's not same-origin as you, but you
can't do any of the following (and probably more) with it:
var secretProperty = otherWindow.secretProperty; // stolen!
for (var i in otherWindow)
{
// if you get here, you know some of otherWindow's
// properties -- information leak
}
otherWindow.trustedProperty = subverted; // oops!
delete otherWindow.importantInfo; // DOS
For you to need to use postMessage on otherWindow, you need to be able
to do many of these things -- but the entire browser security model is
based on not allowing you to do this if the window you've called it on
isn't same-origin with you. You have to punch a hole in this security
to allow getting, calling, or enumerating postMessage, but only if the
object off which the property is gotten is a Window. You also have to
make the property appear ReadOnly/DontDelete externally, so you can't
screw with windows that try to call postMessage on you. Also, how does
this restriction work with other windows which are same-origin? Do they
see only the original postMessage binding, or do they see any
modifications that window makes to it? What if a different window,
same-origin, makes that modification? What if windows pre-HTML5 wanted
to communicate via a postMessage binding? This gets complicated pretty
quickly, and to do it all you have to punch a hole through security, and wi
th the fragility of that hole (only on Window, only if postMessage,
only with the original binding or only if it hasn't been overridden --
and I'm not at all sure that's enough) and the specific criteria for
that hole to exist, it's going to be easy to accidentally allow more
than you wanted to allow.
In contrast, passing a different-origin value into a function is already
allowed, and you don't need to do anything special to make it possible.
The only security modification to allow the cross-origin-ness is to make
postMessage ignore origins. This is *vastly* simpler, easier to
implement, and hence safer and more secure.
I'll agree that calling postMessage on the other window feels like a
better and more intuitive API for users, but if implementers have to
make such invasive and potentially-unsafe changes to do it, I think it's
the wrong way to do it.
Jeff
Re: [whatwg] More on postMessage
Hi Jeff,
On Jul 16, 2007, at 12:17 PM, Jeff Walden wrote:
Gorm Haug Eriksen wrote:
I agree that postMessage should have been on the window and not on
the document, but why would you like to have the method on
yourWindow instead of the otherWindow you post the message to?
The benefit is that you don't have to punch holes through your
existing security infrastructure to do it. If you're in your code,
you can have a reference to an |otherWindow| that's not same-origin
as you, but you can't do any of the following (and probably more)
with it:
var secretProperty = otherWindow.secretProperty; // stolen!
for (var i in otherWindow)
{
// if you get here, you know some of otherWindow's
// properties -- information leak
}
otherWindow.trustedProperty = subverted; // oops!
delete otherWindow.importantInfo; // DOS
For you to need to use postMessage on otherWindow, you need to be
able to do many of these things -- but the entire browser security
model is based on not allowing you to do this if the window you've
called it on isn't same-origin with you. You have to punch a hole
in this security to allow getting, calling, or enumerating
postMessage, but only if the object off which the property is gotten
is a Window.
There's already a handful of Window properties and methods where
access bypasses the normal cross-domain security checks, such as the
close() method and the closed property. So this isn't a new concept.
In WebKit at least we handle these domain security exceptions in a
unified way, and adding one more method that works the same way would
not be a big deal.
You also have to make the property appear ReadOnly/DontDelete
externally, so you can't screw with windows that try to call
postMessage on you. Also, how does this restriction work with other
windows which are same-origin? Do they see only the original
postMessage binding, or do they see any modifications that window
makes to it? What if a different window, same-origin, makes that
modification? What if windows pre-HTML5 wanted to communicate via a
postMessage binding? This gets complicated pretty quickly, and to
do it all you have to punch a hole through security, and with the
fragility of that hole (only on Window, only if postMessage, only
with the original binding or only if it hasn't been overridden --
and I'm not at all sure that's enough) and the specific criteria for
that hole to exist, it's going to be easy to accidentally allow more
than you wanted to allow.
I don't think that's the case, given that browsers must already
implement the other exceptions.
In contrast, passing a different-origin value into a function is
already allowed, and you don't need to do anything special to make
it possible. The only security modification to allow the cross-
origin-ness is to make postMessage ignore origins. This is *vastly*
simpler, easier to implement, and hence safer and more secure.
I'll agree that calling postMessage on the other window feels like a
better and more intuitive API for users, but if implementers have to
make such invasive and potentially-unsafe changes to do it, I think
it's the wrong way to do it.
I would say go with the simpler API, since I don't think either way
creates extra implementation difficulties.
Regards,
Maciej
[whatwg] More on postMessage
In my previous email regarding HTML5's postMessage (section 6.4, cross-domain communication), I suggested changing the API to |yourWindow.postMessage(message, otherWindow)|. I have a few more questions/suggestions after playing around with an implementation of this in Mozilla (bug postMessage for anyone who cares); I somewhat hope to get this in 1.9. First, I think placing |otherWindow| as the first argument and |message| as the second is more aesthetically pleasing than the other way around, tweaking the suggestion I made last time. I don't have a strong reason for this beyond its being analogous to the traditional security model in the literature (which seems good enough to me in the absence of strong reasons going the other way): yourWindow . postMessage ( otherWindow , message ) ; actor doesverbto object Second, in the interests of explicitness, we should be clear about the exact values of event.domain and event.uri. Two concerns: how does setting document.domain interact with the computed value for event.domain, and what are the contents of event.domain in the presence of default and non-default ports? I think the answers to these two concerns must be as follows. Setting document.domain must have no effect on the value of event.domain, in the interests of web hosts who host content on subdomains of their main domain, e.g. myhomepage.webhost.com and webhost.com (else it would allow spoofing in pages which listened for cross-domain messages but didn't check the uri). The contents of event.domain must include the port number iff it is not the default port number for the protocol (80 for http, 443 for https) and must omit it otherwise. Third, with the modified API, the following is possible: // kidFrame is same-origin wrt window window.frames.kidFrame.postMessage(otherWindow, message); With the current design, this would basically allow a window to send an event which looks as though it has been created by another (same-origin, or joined-principals via document.domain) window, with a different event.uri. Since the two windows are same-session this probably isn't a real concern, but I think it's worth mentioning that the change makes it possible to send a message from a window different from the one currently executing the script. Fourth, and probably most importantly, is the event dispatched by postMessage dispatched synchronously (event fired and processed before postMessage returns) or asynchronously? I interpret the current wording to mean synchronously, in accordance with the DOM 3 Events section on reentrance, but I'd like to be clear that's the intended interpretation. Jeff
