Re: [whatwg] Web forms 2, input type suggestions
Martin Atkins wrote: Lachlan Hunt wrote: http://www.haymespaint.com.au/haymes/colourcentre/ http://www.ficml.org/jemimap/style/color/wheel.html http://wellstyled.com/tools/colorscheme2/ These are some rather contrived examples. How can you possibly call them contrived, when they are real world examples of colour selection applications? The first is asking users to select real-world (i.e. paint) colours, while this proposal was for screen colours in RGB format. (At least, that was my understanding based on the reference to six-digit hex encoding.) I think it indicates a limitation with the proposed solution, and a perfect example of why we need to start with *problems* and *use cases* instead of solutions. We need to devise a solution that fits the use cases, not reject use cases that don't fit the solution. -- Lachlan Hunt http://lachy.id.au/
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