Re: [whatwg] Window and WindowProxy
On Wed, 7 Aug 2013, Boris Zbarsky wrote: On 8/7/13 5:18 PM, Ian Hickson wrote: We could indeed move the indexed properties to WindowProxy, while leaving the security checks (which apply to non-indexed properties only) on Window. This would still address my concern, which is that if we move the security checks to WindowProxy, and then break the invariant whereby you can't actually get to a cross-origin Window directly If we break that invariant, fwiw, then I suspect we have much bigger problems. I would imagine most languages other than JavaScript would break that invariant. What other problems would it break? Because the current spec effectively calls for the global to be a proxy-like object (or some sort of object that's not describable in ES spec terms at all, of course, but the idea of ES proxies is to be able to describe anything remotely sane). No, the global object is the Window, at least per the spec today. Why is this not accurate? http://www.whatwg.org/specs/web-apps/current-work/#script's-global-object That's not actually compatible with ES because of how var needs to behave in global scope. Could you elaborate on this? So it seems to me that any implementor trying to implement this spec will go to their favorite ES implementation and discover that the spec cannot be implemented as written and must instead be mapped to some other conceptual model. After thinking about it for a bit, the only obvious way to avoid having proxy-like behavior on the Window is to put it all on WindowProxy, which _already_ has proxy-like behavior no matter what. I don't understand what mapping behaviour you think is conceptually needed on Window. At which point, I think we should spec it that way, for two reasons: 1) It reduces the burden on implementors trying to understand this part of the spec and map it to what ES will let them do. 2) It reduces the likelihood that some modification to ES or the Window/WindowProxy specs will in fact make things unimplementable altogether in the future. I agree that these are good goals. The difficulty with moving just the indexed properties are that length would now be on a different object than what it describes. I don't think that's a problem, honestly. length on a Window returns the number of child windows. An indexed access on a WindowProxy returns the corresponding child of its current Window. It seems fairly straightforward... Straightforward isn't the word I would use, but ok. Also, it would complicate the WindowProxy magic -- now, instead of it just being a proxy, it would be a proxy except for certain properties. Indeed. Of course WindowProxy is already not just a proxy: it doesn't transparently proxy enumeration or getOwnPropertyNames, for example. It should act _exactly_ like Window. As far as I can tell, that means it _should_ proxy proxy enumeration and getOwnPropertyNames, whatever those are. Why do you think this is not the case? That's just not very clearly specified... Again, I think we should just clearly define the behavior of WindowProxy using the ES MOP primitives. I have no idea what that means, but I'm certainly happy to do so if it makes sense. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] XML data islands related question
On Thu, 8 Aug 2013, Jukka K. Korpela wrote: 2013-08-08 0:08, Ian Hickson wrote: On Tue, 6 Aug 2013, Jukka K. Korpela wrote: 2013-08-06 17:45, Ian Hickson wrote: If such an application needs some bulk of text data, it can be included e.g. in script type=text/plain.../script but not in a separate plain text file (included into the application distribution, along with other files) referred to via script src=.../script. This is a frustrating restriction and makes it more difficult to maintain and customize application. If an external plain text file could be used, the data content could be separately managed (requiring knowledge only about the format used). I'm not sure what you mean by application distribution. Why can't a text/plain file by included the same way an image/png file is included? It can be included as a file, but it cannot be used. I can't read it. That is the point. I can use an img element referring to an image file, but I cannot refer to a simple plain text file (or an XML file) in an HTML document in a manner that lets me process its content in scripting. I can only include it via iframe or object, but that's different from accessing its content. I don't understand why XHR doesn't work for you. Because there is no server to talk to when you’re a truly local HTML5 application. XHR uses the same underlying logic as img src= and script src=. If you're able to conjur a file up for img src= or script src=, then I don't see why you wouldn't be able to conjur it up for XHR. Could you elaborate on exactly what you mean by truly local HTML5 application? I cannot see what setup you mean where one would work and not the other, per the specs today. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Window and WindowProxy
On 8/8/13 2:11 AM, Ian Hickson wrote: I would imagine most languages other than JavaScript would break that invariant. Why are we suddenly worrying about languages other than JavaScript? What other problems would it break? Let me think about this; it's been a while... Because the current spec effectively calls for the global to be a proxy-like object (or some sort of object that's not describable in ES spec terms at all, of course, but the idea of ES proxies is to be able to describe anything remotely sane). No, the global object is the Window, at least per the spec today. Why is this not accurate? The current spec calls for the Window to be a proxy-like object, because that's the only way to implement the spec's indexed getter behavior. That's not actually compatible with ES because of how var needs to behave in global scope. Could you elaborate on this? var needs to be able to define non-configurable properties. Proxies don't necessarily offer useful guarantees about being able to define such properties on them, and in particular the behavior for index/named getters in WebIDL precludes definition of non-configurable properties of the corresponding kind on the relevant object. So it seems to me that any implementor trying to implement this spec will go to their favorite ES implementation and discover that the spec cannot be implemented as written and must instead be mapped to some other conceptual model. After thinking about it for a bit, the only obvious way to avoid having proxy-like behavior on the Window is to put it all on WindowProxy, which _already_ has proxy-like behavior no matter what. I don't understand what mapping behaviour you think is conceptually needed on Window. I'm not sure what you mean. The mapping that needs to happen is how do I have a global that's not a magic proxy while being black-box compatible with the spec? I don't think that's a problem, honestly. length on a Window returns the number of child windows. An indexed access on a WindowProxy returns the corresponding child of its current Window. It seems fairly straightforward... Straightforward isn't the word I would use, but ok. It's a lot more straightforward than what we have now, in terms of interactions with ES... Indeed. Of course WindowProxy is already not just a proxy: it doesn't transparently proxy enumeration or getOwnPropertyNames, for example. It should act _exactly_ like Window. As far as I can tell, that means it _should_ proxy proxy enumeration and getOwnPropertyNames, whatever those are. Why do you think this is not the case? Because getOwnPropertyNames should return the own properties of the object, but doing that on a WindowProxy for a cross-origin window should not in fact return the Window's own properties. Or another similar issue: getting a property descriptor from a WindowProxy (for a same-origin window) should probably never claim to have a non-configurable property, because on navigation the property will in fact disappear and non-configurable properties are not allowed to do that in ES. See http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0386.html and the threads it references. But of course Window is required to be able to have non-configurable properties (see var). So WindowProxy can't just forward [[GetOwnProperty]] on to the Window. That link above also talks about how WindowProxy should probably reject attempts to define non-configurable properties on it altogether, which is an obvious non-starter for Window because var needs to work... That's just not very clearly specified... Again, I think we should just clearly define the behavior of WindowProxy using the ES MOP primitives. I have no idea what that means How objects behave in ES are defined in terms of various internal operations. The set of operations ... keeps changing. It used to be there were [[Get]], [[Set]], etc. Now, with property descriptors, there are lower-level primitives like [[GetOwnProperty]], [[DefineProperty]], [[Delete]]. For example, WebIDL defines the behavior of all its objects in terms of those three primitives. These low-level primitivies and how they interact define the meta-object protocol (MOP) for the abstract ES virtual machine. -Boris
Re: [whatwg] Window and WindowProxy
On 8/8/13 7:22 AM, Boris Zbarsky wrote: On 8/8/13 2:11 AM, Ian Hickson wrote: I would imagine most languages other than JavaScript would break that invariant. Why are we suddenly worrying about languages other than JavaScript? Let me try that with less snark. I believe that WindowProxy is solving an issue specific to the JavaScript bindings for the web platform: an issue caused by conflating the object representing the current page and the object representing a given navigation context. If I were creating bindings for the web platform in another language, or for that matter green-field designing JS bindings, I would simply expose those as two separate objects, with a get the current page getter on the navigation context and a get the navigation context getter on the object representing a page. So I'm not terribly worried about how other languages will deal with WindowProxy, because I don't really expect them to have a WindowProxy. And I'm not terribly worries about how they will deal with indexed access on a Window, because I don't expect them to do such a thing at all in their bindings... Just like I don't expect other languages to have a global scope polluter. -Boris
Re: [whatwg] XML data islands related question
On Thu, 08 Aug 2013 01:08:54 +0400, Ian Hickson i...@hixie.ch wrote: On Tue, 6 Aug 2013, Jukka K. Korpela wrote: 2013-08-06 17:45, Ian Hickson wrote: If such an application needs some bulk of text data, it can be included e.g. in script type=text/plain.../script but not in a separate plain text file (included into the application distribution, along with other files) referred to via script src=.../script. This is a frustrating restriction and makes it more difficult to maintain and customize application. If an external plain text file could be used, the data content could be separately managed (requiring knowledge only about the format used). I'm not sure what you mean by application distribution. Why can't a text/plain file by included the same way an image/png file is included? It can be included as a file, but it cannot be used. I can't read it. That is the point. I can use an img element referring to an image file, but I cannot refer to a simple plain text file (or an XML file) in an HTML document in a manner that lets me process its content in scripting. I can only include it via iframe or object, but that's different from accessing its content. I don't understand why XHR doesn't work for you. I can see why not. Imagine an app that wants to collect all my current email when it connects, but is then going to be offline for a day or two (or using the sort of terrible connection common in much of the world where you have something good for ten minutes, and then timeouts for an hour or two). It seems to me that you're trying to figure out how to make offline apps - sort of what appcache was meant to do (and famously did for a subset of use cases, but failed for many cases people thought it should work). I think what you are after is something like the apps that are described by a manifest (being worked on in W3C's webapps group), and runtime model describing security restrictions and what is trusted (in W3C's sysapps group) and general rethinking of how to do what we thought appcache would do (the above plus navcontrollers, and other ideas). chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] XML data islands related question
On Thu, Aug 8, 2013 at 1:38 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Thu, 08 Aug 2013 01:08:54 +0400, Ian Hickson i...@hixie.ch wrote: I don't understand why XHR doesn't work for you. I can see why not. Imagine an app that wants to collect all my current email when it connects, but is then going to be offline for a day or two (or using the sort of terrible connection common in much of the world where you have something good for ten minutes, and then timeouts for an hour or two). It seems to me that you're trying to figure out how to make offline apps - sort of what appcache was meant to do (and famously did for a subset of use cases, but failed for many cases people thought it should work). With https://github.com/slightlyoff/NavigationController/ which is the most likely answer to how we'll address offline you'd be able to intercept the request from XMLHttpRequest and things would be fine (you'd reply with something from the cache, database, or generate something on the fly). -- http://annevankesteren.nl/
Re: [whatwg] XML data islands related question
2013-08-08 9:13, Ian Hickson wrote: XHR uses the same underlying logic as img src= and script src=. If you're able to conjur a file up for img src= or script src=, then I don't see why you wouldn't be able to conjur it up for XHR. When a local HTML file is opened in a browser and it accesses local files, with simple relative URLs like foo.png or bar.js, img src= and script src= do not cause HTTP requests of any kind. Could you elaborate on exactly what you mean by truly local HTML5 application? At the simplest case, it is a set of files (HTML, CSS, JavaScript, image files), and launching the application means opening the HTML file in a browser, or in a sufficiently browser-like program. Conceptually, this would work even if the Internet didn’t exist. In practice, such applications are often distributed via web servers, and they may have URLs, but they can also be distributed on different media offline. (The issue is also relevant to applications that are not completely local and offline but may use HTTP connections for various purposes. For them, the point is that HTTP requests should not be done in vain, e.g. for a large static data file.) So the question is: if I can use images and scripts in separate files in that setup, accessed directly as local files by the browser (or alike), why can’t I do the same for plain text, CSV, or XML data? If there is a security risk, then surely it must be bigger for script that refers to a JavaScript file via src=... than for script that refers to a plain text file via src=... Yet the latter is disallowed. Whatever the reasons might be, I don’t think specifications should declare it as prohibited, though they can warn that implementations may pose such restrictions. Yucca
Re: [whatwg] XML data islands related question
On Thu, Aug 8, 2013 at 3:01 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-08-08 9:13, Ian Hickson wrote: XHR uses the same underlying logic as img src= and script src=. If you're able to conjur a file up for img src= or script src=, then I don't see why you wouldn't be able to conjur it up for XHR. When a local HTML file is opened in a browser and it accesses local files, with simple relative URLs like foo.png or bar.js, img src= and script src= do not cause HTTP requests of any kind. XMLHttpRequest works for file URLs as well. In practice browsers often have this pref-controlled and it's disabled by default for security reasons (or a somewhat more complicated story). It's not too different really. I would expect the same to apply to any similar kind of API as it is mostly about being able to access the data rather than anything else. -- http://annevankesteren.nl/
Re: [whatwg] HTML: A DOM attribute that returns the language of a node
2013-08-08 2:57, Ryosuke Niwa wrote: On Aug 2, 2013, at 6:10 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: [...] But regarding the effect of language markup on fonts, the effect is limited to situations where the font is not specified in a style sheet. This is a rather uncommon scenario these days; authors are more than eager to set fonts. Do you have actual statistics to support this point? No, it’s just an impression from looking at numerous pages and their coding as well as views presented in authors’ forums. As far as I checked, neither baidu.com nor yahoo.com.tw seems to explicitly specify a Chinese font. They both have font-family settings, slightly different, but basically the most common (sorry, no statistic on this either) setup that uses Arial (possibly with Helvetica as second option, which does not change much). So, granted, they don’t specify a Chinese font in the sense of including any specific fonts containing CJK characters in the font-family list. Baidu doesn’t set lang either, so they seem to be accepting, for any characters not covered by Arial, whatever happens to be in each browser’s list of fallback fonts, when no information about content language is available. Yahoo.com.tw sets lang=zh-tw, so they do care, but only to the extent that the fallback font should be one intended for Traditional Chinese. So the lang markup may affect fonts, but only under some conditions. And if you care about fonts, as an author, then an explicit list of font alternatives has better chances of creating the desired result. It is true that they might specify a font list where none of the fonts supports some characters that might be entered, and then a fallback font would be used. However, using “annotations” (presumably, lang attributes, along with extra span elements when needed) does not sound like a feasible approach to this. Whether it’s feasible or not, that’s what we have been doing due to the Han unification. If we could, we’ll undo the Han unification and use different glyphs for each character but we can’t do that at this point in time. If a page contains texts to be rendered using different forms (Traditional Chinese, Simplified Chinese, Japanese, Korean) for Han characters, you will need to control the rendering somehow. Using lang markup might be theoretically most adequate, but it’s indirect and less effective than just setting different fonts (via font-family lists that contain reasonably many alternatives). But even if lang attributes are used, I don’t think the issue has much relevance to the original question here. A DOM attribute that returns the language of a node would be useful for the purpose only if you intend to affect rendering via JavaScript. Yucca
Re: [whatwg] Splash screen proposal for web apps ?
On 01/08/13 19:17, Laurent Perez wrote: Our user agent is a HTTP proxy, currently we are feeding it HTML5 pages, then we are parsing custom data-* attributes and replacing them with UI components, for example data-carousel becomes a touch carousel, and so on. Instead of creating another data-splashscreen attribute, we always try standards first, so I'm evaluating the widgets spec, PhoneGap went the feature splashscreen way, RIM chose a rim:splash vendor namespace. On top of that there is also the manifest spec, implemented by Firefox OS. There have been a lot of discussions at Mozilla around this feature recently. The first released versions of Firefox OS have some kind of automatic splash screen mechanism that is under-optimised and not very accurate so our front end engineers asked for a declarative solution in the Web Manifest so they could tweak its behaviour. It seems to match what you are asking. The conclusions of our discussions are that a splash screen is not needed because the first paint of a page can be very quick if the page is designed for this. If all the scripts, stylesheets and content are loaded synchronously, your page will look slow and a splash screen might be required but the Web has many features that allow developers to be smart about time load. Even for applications that need to do some loading by design (let say a game that need to load assets), it is more efficient if the page itself handles the splash screen by loading a simple DOM + stylesheet that would show Loading. Please wait. rather than having the UA taking care of it. The UA will have a hard time to know when to stop loading the splash screen, when to stop it and would have many limitations around animated splash screen, internationalisation, etc. The sysapps WG is what I was looking for, thanks :) The Web Manifest lives in WebApps WG nowadays, you might want to bring that feature request if you still want it. Cheers, -- Mounir
Re: [whatwg] Window and WindowProxy
On Thu, 8 Aug 2013, Boris Zbarsky wrote: On 8/8/13 2:11 AM, Ian Hickson wrote: I would imagine most languages other than JavaScript would break that invariant. Why are we suddenly worrying about languages other than JavaScript? It's not sudden. The HTML spec has tried to be language agnostic since the beginning. WebIDL is similarly language-agnostic. The DOM specs, back when the W3C was maintaining them, were language agnostic. SVG was designed to be language agnostic. Attempts at adding new languages to the Web have been tried multiple times by multiple vendors (VB from Microsoft; Python, a while back, in the Mozilla world, and more recently asm.js, to some extent; Dart from Google, as well as some other related attempts like PNaCl; etc), with varying degrees of success. It would behoove us to not ignore all that, IMHO. While any new language naturally needs significant API work, we're still better being prepared than having the interaction of a new language with the Web API be completely undefined, leaving it entirely up to the whims of a new language group (especially since, historically, the people writing new languages intended for the Web are not the same people who are deeply embedded in core Web platform work). Because the current spec effectively calls for the global to be a proxy-like object (or some sort of object that's not describable in ES spec terms at all, of course, but the idea of ES proxies is to be able to describe anything remotely sane). No, the global object is the Window, at least per the spec today. Why is this not accurate? The current spec calls for the Window to be a proxy-like object, because that's the only way to implement the spec's indexed getter behavior. I don't understand what you mean. What's different about Window's indexed getter behaviour than the indexed getter behaviours of all the other interfaces in HTML that have indexed getters? That's not actually compatible with ES because of how var needs to behave in global scope. Could you elaborate on this? var needs to be able to define non-configurable properties. Proxies don't necessarily offer useful guarantees about being able to define such properties on them, and in particular the behavior for index/named getters in WebIDL precludes definition of non-configurable properties of the corresponding kind on the relevant object. I don't understand what this means, sorry. If WebIDL makes it hard for an object that has indexed and named getters to also be a [Global] object, then we should fix WebIDL, since 33% of the [Global] objects, and nearly 100% of the actual [Global] objects in the wild, have indexed and named getters. So it seems to me that any implementor trying to implement this spec will go to their favorite ES implementation and discover that the spec cannot be implemented as written and must instead be mapped to some other conceptual model. After thinking about it for a bit, the only obvious way to avoid having proxy-like behavior on the Window is to put it all on WindowProxy, which _already_ has proxy-like behavior no matter what. I don't understand what mapping behaviour you think is conceptually needed on Window. I'm not sure what you mean. The mapping that needs to happen is how do I have a global that's not a magic proxy while being black-box compatible with the spec? The Window object is just a regular object as far as I can tell. It has no magical proxiness. That's only WindowProxy, which isn't the global. Indeed. Of course WindowProxy is already not just a proxy: it doesn't transparently proxy enumeration or getOwnPropertyNames, for example. It should act _exactly_ like Window. As far as I can tell, that means it _should_ proxy proxy enumeration and getOwnPropertyNames, whatever those are. Why do you think this is not the case? Because getOwnPropertyNames should return the own properties of the object, but doing that on a WindowProxy for a cross-origin window should not in fact return the Window's own properties. Yes, it should. At least, IMHO. WindowProxy should be _completely indistinguishable_ from the Window it currently points to, except for the way it can be distinguished when what it points to changes. That's what this means: # all operations that would be performed on [a WindowProxy] must be # performed on the Window object of the browsing context's active document # instead It seems pretty unambiguous to me. Or another similar issue: getting a property descriptor from a WindowProxy (for a same-origin window) should probably never claim to have a non-configurable property, because on navigation the property will in fact disappear and non-configurable properties are not allowed to do that in ES. IMHO, yes, it should. It should be _exactly_ like the Window object. The fact that references to the WindowProxy
Re: [whatwg] Window and WindowProxy
On Thu, 8 Aug 2013, Boris Zbarsky wrote:
On 8/8/13 7:22 AM, Boris Zbarsky wrote:
On 8/8/13 2:11 AM, Ian Hickson wrote:
I would imagine most languages other than JavaScript would break
that invariant.
Why are we suddenly worrying about languages other than JavaScript?
Let me try that with less snark.
I believe that WindowProxy is solving an issue specific to the
JavaScript bindings for the web platform: an issue caused by conflating
the object representing the current page and the object representing
a given navigation context.
If I were creating bindings for the web platform in another language, or
for that matter green-field designing JS bindings, I would simply expose
those as two separate objects, with a get the current page getter on
the navigation context and a get the navigation context getter on the
object representing a page.
So I'm not terribly worried about how other languages will deal with
WindowProxy, because I don't really expect them to have a WindowProxy.
And I'm not terribly worries about how they will deal with indexed
access on a Window, because I don't expect them to do such a thing at
all in their bindings... Just like I don't expect other languages to
have a global scope polluter.
I'd go further -- I wouldn't expose WindowProxy to other languages at all,
personally. I would just make every attribute that returns a WindowProxy
return whatever the current Window is, or some such. Or alternatively,
have WindowProxy just defined as:
interface WindowProxy {
readonly attribute Window currentWindow;
};
...but that seems like it'd make the API unnecessarily ugly.
My point is that either way, if we do this, that means all the security
checks have to be on Window, not WindowProxy.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] XML data islands related question
On Thu, 8 Aug 2013, Jukka K. Korpela wrote: 2013-08-08 9:13, Ian Hickson wrote: XHR uses the same underlying logic as img src= and script src=. If you're able to conjur a file up for img src= or script src=, then I don't see why you wouldn't be able to conjur it up for XHR. When a local HTML file is opened in a browser and it accesses local files, with simple relative URLs like foo.png or bar.js, img src= and script src= do not cause HTTP requests of any kind. Nor would XMLHttpRequest. XHR has nothing to do with XML, or HTTP, or, really, any particular thing to do with requests. It's just a way to do a fetch (or, these days, a CORS fetch). Could you elaborate on exactly what you mean by truly local HTML5 application? At the simplest case, it is a set of files (HTML, CSS, JavaScript, image files), and launching the application means opening the HTML file in a browser, or in a sufficiently browser-like program. Conceptually, this would work even if the Internet didn’t exist. In practice, such applications are often distributed via web servers, and they may have URLs, but they can also be distributed on different media offline. Whatever they're served from, if they're loaded in a browser, they have a URL. It could be an http: URL or a file: URL, but it's still a URL. Either way, if script src= is able to load the file, then XHR should be able to load the file as well. If there were security preferences preventing the loading of files using XHR, they would also prevent the loading of that file using script src= for data (since the exact same security issues would be relevant). (The issue is also relevant to applications that are not completely local and offline but may use HTTP connections for various purposes. For them, the point is that HTTP requests should not be done in vain, e.g. for a large static data file.) XHR would give you far more control over this than script src=. So the question is: if I can use images and scripts in separate files in that setup, accessed directly as local files by the browser (or alike), why can’t I do the same for plain text, CSV, or XML data? You can. Use XHR. If there is a security risk, then surely it must be bigger for script that refers to a JavaScript file via src=... than for script that refers to a plain text file via src=... Actually no; running a script doesn't let you inspect the script's contents. Yet the latter is disallowed. If it is disallowed, it would be disallowed for script src= and XHR equally. Whatever the reasons might be, I don’t think specifications should declare it as prohibited, though they can warn that implementations may pose such restrictions. The specifications allow you to do this. XHR is the tool to do it. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Window and WindowProxy
On 8/8/13 2:50 PM, Ian Hickson wrote: I'd go further -- I wouldn't expose WindowProxy to other languages at all Yes, I thought that was more or less what I said. You still need an object to represent navigation contexts, of course. My point is that either way, if we do this, that means all the security checks have to be on Window, not WindowProxy. I think that depends on the language and how it represents objects, whether untrusted code in that language is even a concept, etc. For example, the C++ bindings for Window in browsers presumably do not perform security checks of any sort... The security checks in the spec right now are very much JS-as-it's-practiced-on-the-web specific. A different language, possibly with a different security model, would want different checks. -Boris
Re: [whatwg] Window and WindowProxy
On 8/8/13 2:48 PM, Ian Hickson wrote: The current spec calls for the Window to be a proxy-like object, because that's the only way to implement the spec's indexed getter behavior. I don't understand what you mean. What's different about Window's indexed getter behaviour than the indexed getter behaviours of all the other interfaces in HTML that have indexed getters? Absolutely nothing. All the other indexed getter behaviors in HTML require proxy-like behavior. But none of the rest of them are the global object, so they can just be proxies and do their weird proxy things (again, in ES6 terms), and it's all ok. var needs to be able to define non-configurable properties. Proxies don't necessarily offer useful guarantees about being able to define such properties on them, and in particular the behavior for index/named getters in WebIDL precludes definition of non-configurable properties of the corresponding kind on the relevant object. I don't understand what this means, sorry. Hmm. Which part is unclear? If WebIDL makes it hard for an object that has indexed and named getters to also be a [Global] object, then we should fix WebIDL, since 33% of the [Global] objects, and nearly 100% of the actual [Global] objects in the wild, have indexed and named getters. This is not a problem with WebIDL. This is a problem with the fact that indexed and named getters as implemented in modern browsers effectively violate ES language invariants that the global is not allowed to violate. Now the good thing is that we defined things in WebIDL so that this is ok: the named getters on the global are NOT on the global itself, but on the NamedPropertiesObject on its prototype chain (and the difference is readily observable; try var foo = 5; alert(foo); in a page that has iframe name=foo and note that you get 5, which you would not if the named getter were on the Window directly). And the indexed getter on Window, as I said, is black-box indistinguishable from living on the WindowProxy, because you can't use indices as barewords. So the upshot is that a UA can just put them there and not have conflicts with the ES spec. But, once again, if that's what UAs end up having to do anyway, we may as well spec it that way. I'm not sure what you mean. The mapping that needs to happen is how do I have a global that's not a magic proxy while being black-box compatible with the spec? The Window object is just a regular object as far as I can tell. It has no magical proxiness. The indexed getter behavior is magical proxiness as implemented in UAs and specced in WebIDL. Again, in ES6 terms. And we've tried to find other ways to define it; they all suck even more. That's only WindowProxy, which isn't the global. I think we might be using two different definitions of proxy. I am using proxy to indicate objects for which a normal, non-Proxy, user-created object in JS would not be able to emulate their behavior. Objects like that are why ES introduced Proxy objects, which are able to have a much wider range of behaviors than normal objects, because they can hook into various operations on a much lower level (specifically, they can more or less directly implement the MOP). Because getOwnPropertyNames should return the own properties of the object, but doing that on a WindowProxy for a cross-origin window should not in fact return the Window's own properties. Yes, it should. At least, IMHO. Er... That's a cross-site information leak. While some browsers apparently do in fact have this leak, the web does not require it, I don't think we should spec it, and Gecko certainly has no plans to add it. WindowProxy should be _completely indistinguishable_ from the Window it currently points to, except for the way it can be distinguished when what it points to changes. OK, so in this view there are multiple (one per origin, roughly) Window objects in JS all representing the same underlying browser object? I don't understand how this can work with document.domain, where things that used to not be same-origin suddenly become same-origin: in that situation two different origins become the same origin and the fact that they have different Window objects for the same current window ends up observable. I feel like I must be missing something about the model you're working with here. Or another similar issue: getting a property descriptor from a WindowProxy (for a same-origin window) should probably never claim to have a non-configurable property, because on navigation the property will in fact disappear and non-configurable properties are not allowed to do that in ES. IMHO, yes, it should. That's not allowed in ES. Do see the thread I linked to. See http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0386.html and the threads it references. But of course Window is required to be able to have non-configurable properties (see var). So WindowProxy can't
Re: [whatwg] Window and WindowProxy
On Thu, 8 Aug 2013, Boris Zbarsky wrote: (again, in ES6 terms) I think the problem is that I have no idea what these ES6 terms are or what they mean. Was all this a problem in previous revisions of JavaScript? Or is it some new problem caused by some new JavaScript feature? var needs to be able to define non-configurable properties. Proxies don't necessarily offer useful guarantees about being able to define such properties on them, and in particular the behavior for index/named getters in WebIDL precludes definition of non-configurable properties of the corresponding kind on the relevant object. I don't understand what this means, sorry. Hmm. Which part is unclear? I have basically no idea what any of it means. I understand all the individual words of that paragraph, but I've no idea what they mean when put next to each other in that order. :-) A property is just an entry in the bag that is a JS object, what does it mean for it to be or not be configurable? A proxy is something that passes incoming requests from one object to another object, and passes the responses back; what does it mean for a proxy to have a property? Etc. Because getOwnPropertyNames should return the own properties of the object, but doing that on a WindowProxy for a cross-origin window should not in fact return the Window's own properties. Yes, it should. At least, IMHO. Er... That's a cross-site information leak. How so? The names of the IDL attributes and methods on Window objects are the same on all Window objects (WindowModal notwithstanding), and the non-IDL properties aren't enumerable cross-origin. WindowProxy should be _completely indistinguishable_ from the Window it currently points to, except for the way it can be distinguished when what it points to changes. OK, so in this view there are multiple (one per origin, roughly) Window objects in JS all representing the same underlying browser object? For members that return objects (including function objects), each distinct effective script origin that is not the same as the Window object's Document's effective script origin must be provided with a separate set of objects. These objects must have the prototype chain appropriate for the script for which the objects are created (not those that would be appropriate for scripts whose script's global object is the Window object in question). I don't understand how this can work with document.domain, where things that used to not be same-origin suddenly become same-origin (same effective origin) in that situation two different origins become the same origin and the fact that they have different Window objects for the same current window ends up observable. Well, what the spec says now is that when the script changes effective origin, it also changes its prototypes and so forth, essentially. This isn't very explicit, though. I don't really have a strong opinion on what this should do (I'm all for dropping document.domain wherever we can). Or another similar issue: getting a property descriptor from a WindowProxy (for a same-origin window) should probably never claim to have a non-configurable property, because on navigation the property will in fact disappear and non-configurable properties are not allowed to do that in ES. IMHO, yes, it should. That's not allowed in ES. Do see the thread I linked to. We (the Web community) can change what's allowed and what isn't allowed. We do so all the time. Conceptually, it's just that the pointers to Window objects get redirected to point to a different Window object when the browsing context navigates. Let me try to make this clearer. If an object (in this case a WindowProxy, since that's what the script is working with) ever claims that it has a non-configurable property for some property name, ES requires that it _always_ do that from that point on. That's fine. The Window will keep having that property. The WindowProxy object's own properties can't be examined, because it just proxies (not in the ES6 meaning, whatever that is, but in the English meaning) everything to the underlying Window object. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Disabling document.domain setting on iframe@sandbox (especially with allow-same-origin)
On Fri, 2 Aug 2013, Boris Zbarsky wrote: On 8/2/13 10:35 PM, Ian Hickson wrote: Honestly, though, at the point where you're able to trick a similar-origin site into changing document.domain so you can attack it document.domain was not involved in any way in the cross-site issues I've pointed out to you recently. Sure. I was talking about the script-visible difference in the models, as opposed to the defense-in-depth aspects. My argument is that not having the defense in depth in the limited case of similar-origin frames is the cost of having defense-in-depth for all the other cases without any script-visible differences in the overall model. The question of whether this is a trade-off that's worth it or not is the question that decides what model the spec will follow -- right now, only Mozilla has indicated that this is a trade-off that is worth it, with all the other browsers instead following a process isolation model that, in its logical extension to origin isolation, only protects up to the similar-origin barrier (and in the meantime, doesn't protect at all). On Sat, 3 Aug 2013, David Bruant wrote: Indeed and that's the reason what I describe works I believe. Let's say we have pages from 2 domains a.example.org and b.example.org. One has an iframe to the other. iframe process isolation is not possible, because at any point, both could set their domains to example.org (or process isolation is possible, but the deoptimization would have a violent cost) a.example.org can sandbox the iframe to b.example.org and process isolation becomes possible again, because the parent and iframe are guaranteed to be of a different origin. However, this looses the origin of the iframe which breaks localstorage, etc. This can be solved with allow-same-origin, but process isolation is lost back because we're pretty much back in the previous case. What I'm suggesting is the following: poison the document.domain setter in sandboxed iframes regardless of whether there is allow-same-origin. This way, in the a.example.org/b.example.org case, the iframe can be process isolated (because guaranteed to be of a different origin). This also applies to example.org with a b.example.org iframe. The only case this doesn't allow to optimize is a.example.org with an iframe to example.org, where a.example.org might set document.domain to example.org. On Sat, 3 Aug 2013, Boris Zbarsky wrote: It doesn't matter, because _both_ have to set document.domain. As in, a.example.org setting .domain to example.org does not make it same-origin with example.org unless the latter also explicitly sets .domain to example.org. Which we would disallow in sandboxed iframes. On Sat, 3 Aug 2013, David Bruant wrote: oh ok. I guess I misunderstood the spec after all, but that supports the idea of poisonning the document.domain setter, yay! I'm certainly open to the idea of making document.domain not work in sandboxed iframes. Any objections? Who is ready to implement this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Window and WindowProxy
On 8/8/13 5:05 PM, Ian Hickson wrote: I think the problem is that I have no idea what these ES6 terms are or what they mean. OK. Which terms, exactly? Was all this a problem in previous revisions of JavaScript? Or is it some new problem caused by some new JavaScript feature? It's a problem, as far as it goes, caused by the ability to get property descriptors at all. In the old world there was no way to explicitly invoke [[DefineProperty]] or check whether something is configurable. So some things were not observable that are now observable, and the ES spec had to define what happens when you observe them. This is not an ES6 issue; ES5 has similar problems, but a bit less clarity (e.g. no Proxy objects in ES5, var needs to be able to define non-configurable properties. Proxies don't necessarily offer useful guarantees about being able to define such properties on them, and in particular the behavior for index/named getters in WebIDL precludes definition of non-configurable properties of the corresponding kind on the relevant object. I don't understand what this means, sorry. Hmm. Which part is unclear? I have basically no idea what any of it means. I understand all the individual words of that paragraph, but I've no idea what they mean when put next to each other in that order. :-) A property is just an entry in the bag that is a JS object, what does it mean for it to be or not be configurable? Ah, ok. So in ES5 there is a concept of a property descriptor. There is both an internal representation of property descriptors and a way to get JS objects that represent a property descriptor: Object.getOwnPropertyDescriptor. See ECMA-262 edition 5 section 8.10 for details on how property descriptors work, but fundamentally a property descriptor for an existing property describes how it's set up. A property descriptor can also be used to create new properties via Object.defineProperty. Every property descriptor has two booleans it stores: [[Enumerable]] and [[Configurable]]. [[Enumerable]] controls whether the property shows up in for..in enumeration. [[Configurable]] controls how the property descriptor for this property can change. In particular, if [[Configurable]] is false, then the values of [[Configurable]], [[Enumerable]], [[Get]], [[Set]], and [[Writable]] for this property cannot change in the future ([[Value]] can still change if this is a value property that is [[Writable]]). All property manipulation in ES5 and later is defined in terms of property descriptors. For example, the definition of [[Put]] (which is the thing that happens on foo.bar = something) in ES5 section 8.12.5 does gets the property descriptor and then looking at that descriptor and deciding what to do based on that ([[GetOwnProperty]] and [[GetProperty]] return property descriptors, somewhat non-obviously). A proxy is something that passes incoming requests from one object to another object A Proxy in ES6 is a particular kind of JS object that has pointers to two other objects: a target and a handler. The target is what requests get passed to, if desired. The handler is basically a mapping from MOP names to JS functions implementing the relevant MOP operation. So for example, an object with an indexed getter is defined in WebIDL by defining that it has special implementations for three MOP operations: [[GetOwnProperty]], [[DefineProperty]], and [[Delete]]. If you wanted to implement such an object in JS, there is no way to do this in ES5. In ES6, you would create a Proxy whose target is just a vanilla object for storing expandos and the proto link and whose handler does the steps defined by WebIDL for those three operations. Note that your description of a proxy above is certainly implementable as a Proxy, but a Proxy can also implement other things (again, like things with indexed or named getters as currently specced). See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-8.5 for the full-on spec bits. what does it mean for a proxy to have a property? If it returns something other than undefined from [[GetOwnProperty]]. Er... That's a cross-site information leak. How so? The names of the IDL attributes and methods on Window objects are the same on all Window objects (WindowModal notwithstanding), and the non-IDL properties aren't enumerable cross-origin. getOwnPropertyNames returns all own properties, not just enumerable ones. For members that return objects (including function objects), each distinct effective script origin that is not the same as the Window object's Document's effective script origin must be provided with a separate set of objects. These objects must have the prototype chain appropriate for the script for which the objects are created (not those that would be appropriate for scripts whose script's global object is the Window object in question). Mmm... I don't think this works very well for Window. (same
