Re: [whatwg] Styling details
On Sun, Jan 6, 2013 at 8:36 PM, Dimitri Glazkov dglaz...@chromium.org wrote: So I wouldn't call this exactly vaporware :) I cannot get it to work for select. But this is certainly interesting. It would require details to be defined in terms of shadow trees, or not? As otherwise the triangle in Chrome's implementation would not disappear so easily... -- http://annevankesteren.nl/
Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality
On 1/7/13 2:34 PM, Ian Hickson wrote: Ok. I've left the spec as is here. Please do let me know if this is the wrong thing to do after all Will do once I actually manage to get this stuff into a build people are using. For now, it runs afoul of script disabling for designMode and other such fun. -Boris
Re: [whatwg] Styling details
On Mon, Jan 7, 2013 at 2:25 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Jan 6, 2013 at 8:36 PM, Dimitri Glazkov dglaz...@chromium.org wrote: So I wouldn't call this exactly vaporware :) I cannot get it to work for select. Right. Here is WebKit's burn down list for all remaining elements to convert to be shadow tree-aware: https://bugs.webkit.org/showdependencytree.cgi?id=82313hide_resolved=1 But this is certainly interesting. It would require details to be defined in terms of shadow trees, or not? As otherwise the triangle in Chrome's implementation would not disappear so easily... While details is indeed implemented as a shadow tree in WebKit, it does not have to be. It does, however, need to be know how to interact with shadow trees. Specifically, the element has to pretend that its composition is defined in terms of insertion points: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#html-elements-and-their-shadow-trees :DG
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On Mon, 3 Dec 2012, Boris Zbarsky wrote: On 12/3/12 7:33 PM, Ian Hickson wrote: Note that onerror has a different type on HTMLElement and HTMLBodyElement. Yes, indeed. That's the biggest problem with forwarding to Window for the HTMLElement.prototype case for onerror here: the types are different. onscroll is a case where there's really no reason to use a different setter, agreed. So I've commented that out (and it's similar friends). That still leaves onerror though. Indeed. I would have no problem with just having HTMLElement.prototype.onerror's setter set an error handler on the body itself, like it would on any other HTML element, and likewise for the getter. Per our IRC discussion just now, I think I would propose that when a method/setter/getter from a prototype of interface A is called against an object that is of an interface B (or one of B's descendants), where B is a subclass of A, and B defines its own method/getter/setter with the same name, then it should throw. Hmm. That, as phrased, is pretty complicated to implement in a performant way, if the two methods/getters/setters have the same signatures... heycam, did we resolve this at the WebIDL level by any chance? Or is this still open? (If the latter, is there a bug# for it? Or is this an HTML problem I need to fix myself?) On Mon, 3 Dec 2012, Boris Zbarsky wrote: I have to ask: are there languages or runtime systems that have that sort of behavior on method calls (as opposed to in method implementations in special cases where the operation is nonsensical)? It seems weird to be requiring this behavior, in general. Most languages, if you invoke the method of a superclass on an object of a subclass that overrides that method in an incompatible way, will just let you crash the application. This isn't an option for us. In practice there are only a few of these cases, so implementations _could_ special-case them, rather than doing it at the binding level. If you have actual IDL in your pipeline, the compiler could flag which cases need this, and automatically generate tests to make sure they are done. It doesn't have to be a widespread performance impact. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Location object identity and navigation behavior
On Tue, 20 Nov 2012, Bobby Holley wrote: On Tue, Nov 20, 2012 at 9:46 AM, Ian Hickson i...@hixie.ch wrote: In thinking about this further last night, it struck me that while the proposed proxy mechanism was IMHO overly complex, there might be a simpler mechanism that still gets all the compatibility needs, and works for Mozilla, and isn't quite so crazy. I'm not a huge fan of this, but I'd be interested in what Adam thinks of it. Right now, as specced, each Document gets a Location object, but they all act the same: they all work on the active document and they all do security checks based on the active document, not the Location's Document. But what if, instead, we had one Location per Document, and it worked on that Document (not the active document), with the security policy being like Window, specific to its Document's effective origin, but instead of ever getting references to it, you only got references to a proxy that acted on the active document's Location? Wouldn't this effectively mean having a LocationProxy, just like WindowProxy? Yes. It differs from the original proposal in that there's multiple underlying objects and they're just proxied, not just one object that has its prototype and properties changed when the history is traversed. I'm certainly all for it, and think that it makes things much more sane, though I don't understand why this wouldn't propagate the magic that Adam doesn't want to propagate. I might be misunderstanding you though. Can you clarify? I agree that it does seem to be still more complicated than is apparently necessary, at least for implementations where determining the calling script's effective script origin is relatively easy. My understanding is that WebKit, old Gecko, and new IE do what the spec says currently, and old IE, Opera, and new Gecko do the proxying model. For authors, I don't really see the value of the proxying model. The current spec model is slightly simpler for authors, but only slightly, because you still can't access your own shims when the page is navigated to another origin. For implementors, I'm not really comfortable picking one side or the other here. I'm even less comfortable picking what's easy for Chrome over what's easy for Gecko. Browsers seem to be changing in both directions, and right now seem to be exactly equally split. So, I dunno. If it's a bust for authors, a tie for browsers, I guess the next level is spec writers, and, well, not changing anything is easier than changing something, so I guess that argues for not changing it? I've left the spec as-is for now, but I don't have a good argument one way or the other. Sorry for this unsatisfying answer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
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 before calling the core of the operation Why would this need to be on specific operations and not just be enforced on every operation? Is it that we want to avoid the overhead of origin checking if we know that calling the operation does not leak information? Or it it that only a limited set of objects is exposed cross origin anyway, so we only need to check those? * On attributes, both the getter and setter would throw if this is not of the right origin. * On interfaces, it would apply to everything (might be necessary for Window and Document) For the actual wording of the check, we could either have a security check that is performed at the right time in #es-operations etc. and which HTML defines to do the origin checking, or we can make Web IDL aware of origins itself, and then HTML would define what origin different objects come from.
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On 8/01/13 7:31 AM, Ian Hickson wrote: heycam, did we resolve this at the WebIDL level by any chance? Or is this still open? (If the latter, is there a bug# for it? Or is this an HTML problem I need to fix myself?) No, this didn't get resolved. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20225 is the open bug. I will respond there. On Mon, 3 Dec 2012, Boris Zbarsky wrote: I have to ask: are there languages or runtime systems that have that sort of behavior on method calls (as opposed to in method implementations in special cases where the operation is nonsensical)? It seems weird to be requiring this behavior, in general. Most languages, if you invoke the method of a superclass on an object of a subclass that overrides that method in an incompatible way, will just let you crash the application. This isn't an option for us. It might crash, but I'd say that's a bug in your class design that a superclass method cannot be called on a subclass.
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
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 in Boris case), an origin check would be performed before calling the core of the operation Why would this need to be on specific operations and not just be enforced on every operation? Most things don't have an origin. Origin checks are only done in some very specific places where you try to get an object's properties; what we're saying here is that for those properties, you also need to do the check when you run the code behind those properties (e.g. call a method), against the this. (Note: This is not what Gecko does. Some Mozilla people have been petitioning me to change the model in the spec to be more like Gecko's model.) Is it that we want to avoid the overhead of origin checking if we know that calling the operation does not leak information? Or it it that only a limited set of objects is exposed cross origin anyway, so we only need to check those? Both. For the actual wording of the check, we could either have a security check that is performed at the right time in #es-operations etc. and which HTML defines to do the origin checking, or we can make Web IDL aware of origins itself, and then HTML would define what origin different objects come from. In the case of Location, it's not about the origin of the object, it's about the origin of the active Document of the Window. See the Security sections in the HTML spec for examples of what we have now (there's one for Window, one for Document, and one for Location -- I think that's it). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Forms-related feedback
On Wed, 21 Nov 2012, Mounir Lamouri wrote: On 20/11/12 22:51, Ian Hickson wrote: On Tue, 20 Nov 2012, Mounir Lamouri wrote: At Mozilla, we think that the main use case for stepUp() and stepDown() is to create a UI with spin buttons: clicking on the up arrow would call stepUp() and clicking on the down arrow would call stepDown(). [...] Done, though I described it in a different way. (I hope it's equivalent.) I think there are two behaviour that you seem to have described differently: - in step 12, if you take the example page [1], setting the value to 21 and calling stepDown() should change the value to 20 and setting it to 19 and calling stepUp() should change it to 20. This how it is implemented in Opera and Firefox and this how the Chrome's UI behaves. As far as I understand the spec you wrote, those two examples would give respectively 10 and 30. [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918 - I believe that when the value is set to below min and n 0, we should not change the value. Same thing for value below max and n 0. This is the behaviour all UA currently have with stepUp() and stepDown() (though, the previous spec was requiring that) and this is Chrome's UI behaviour. I think that behaviour makes more sense UX-wise because going down or up and having the value going the opposite way is just weird and unexpected. Done. For this: input type='number' min='10' step='10' max='21' ...if the value is 22 and you step up (with the UI), Chrome sets it to 21. (Opera does nothing.) Per spec, stepUp() now would leave this unchanged (like Opera). (I tried to test Firefox but I couldn't get my build to show UI for type=number. Not sure if I'm on the wrong channel or something?) Also, note that per the new spec if stepUp() or stepDown() are called with an argument that isn't 1, it's ignored if the value isn't on a valid step. So in the example above, if value=22 and you call stepDown(5), it only goes down to 20, not 10. Is that ok? Also, if you call it as stepDown(-2), it goes down to 20, it's not left at 22, because the argument is ignored and the method itself is used to determine the direction if we're not on step. Is that ok? Similarly, if you're at 10, and you call stepUp(1), it goes to 20, but if you call stepUp(2), it stays at 10, because 30 is out of range (max 21). Is that ok? [1] The only difference between Chrome's spin buttons behaviour and our proposal is that when value is the empty string, it is setting value to 0 and continue to the next steps (unless the 0 is below the minimal allowed value and n 0, in that case value=min). It might be interesting to specify something better than do nothing if value=. I'm open to doing that too; what would you preference be? Maybe if value isn't valid, we could have it changed to the step base or |min + (max - min)/2| and exit the steps if stepDown() or stepUp() is called. (I think even if stepDown(hugeNumber) is called, we should still just set the value and do nothing else.) I would tend to prefer step base mostly because it would know set it to the default value if there is a default value. However, I think step base is quite a bad solution for some types. Maybe we could use the default value if there is such a concept for the type or the step base otherwise? It's probably simple enough for authors to check valueAsNumber is not NaN and then have them set it to the value they want as the default, if they're calling the stepUp/stepDown methods. I've left this as throwing if the value isn't a number. On Sun, 25 Nov 2012, Scott Gonz�lez wrote: For any non-parsable value (including no value), we start at 0, take the step, then confine to a valid step within min/max. I think that makes sense for the UI, but for the methods I'm less sure, given how easy it is to check for this case and do whatever behaviour makes the most sense for the control. On Thu, 22 Nov 2012, Markus Ernst wrote: Am 22.11.2012 01:51 schrieb Ian Hickson: On Sun, 14 Aug 2011, Timo Beermann wrote: It should be able to implemet checkboxes, where by only activating/deactivating this single checkbox you can active/deactivate multiple other checkboxes. That is possible with scripting today, but it should be possible without scripting, only with HTML/CSS. Because some users deactivate Scripting (for security or whatever other reason) and on other computers (school, university, work,...) you are not able to change the settings, even if you want to. E.g. I use NoScript and only allow scripting on very few trusted sites, that really need it. I haven't added this yet, but it is already logged as a possible future extension, so it's possible it may be added in the future. What would be helpful though is examples of sites that do this kind of thing, so that we can study how necessary it
Re: [whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed
On Mon, Dec 10, 2012 at 11:52 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 3, 2012, at 11:19 PM, Adam Barth w...@adambarth.com wrote: On Mon, Dec 3, 2012 at 9:57 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 3, 2012, at 2:11 PM, William Chan (陈智昌) willc...@chromium.org wrote: Unless I am misunderstanding, SPDY will not solve this problem. SPDY uses prioritized multiplexing of streams. It seems to me like SPDY could make this case work better: script async src=path/to/script-part1.js/script script async src=path/to/script-part2.js/script script async src=path/to/script-part3.js/script Specifically the individual script chunks could be ordered and prioritized such that all of script-part1.js transfers before any of script-part3.js. That's harder to do with HTTP because the scripts could be loading on wholly separate HTTP connections, while SPDY will use one connection to the server. That being said, I do not know if SPDY will actually achieve this. Presumably it makes sense for it to serialize within a given priority level, at least a priority level that's likely to correspond to resources that are only atomically consumable, like scripts. But I don't know if SPDY implementations really do that. It also has disadvantage (3): ---8--- (3) This approach requires the author who loads the script to use different syntax than normally used for loading script. For example, this prevents this technique from being applied to the JavaScript libraries that Google hosts (as described by https://developers.google.com/speed/libraries/). ---8--- Yes, but I presumed that multiple script tags is less deviation than the iframe approach. Perhaps that is not the case. Note that in the case of systematically named parts, a single inline script could document.write() the relevant sequence of external script tags, if verbosity is the concern. But it would indeed be different. Do you expect the multipart idea would work with no syntax change in the markup currently embedding the libraries? If so, how? Content negotiation? UA sniffing? Yes, using UA sniffing at first and eventually dropping support for old clients. Adam
Re: [whatwg] Script-related feedback
On Wed, Dec 19, 2012 at 2:27 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 3 Dec 2012, Adam Barth wrote: Currently, there are a number of ways to load a script from the network and execute it, but none of them will actually load and execute the script as fast as physically possible. Consider the following markup: script async src=path/to/script.js/script In this case, the user agent will wait until it receives the last byte of script.js from the network before executing the first byte of script.js. It had better, since JavaScript requires that syntax errors in the lasy byte prevent execution of the first byte. The main ingredient that we're missing is a way for the author to signal to the user agent which chunks of scripts are safe to execute in parallel with loading subsequent chunks from the network. Fortunately, the web platform already has a mechanism for breaking a single HTTP response body into chunks that are processed sequentially: multipart/mixed. For example, if an HTTP server provides a multipart/mixed response to a request for an image, the img element will display each part of the response in sequence, animating the image. Similarly, if an HTTP server provides a multipart/mixed response to a request for an HTML document, the user agent will display each part of the response sequentially. One way to address this use case is to add multipart/mixed support to the script element. Upon receiving a multipart/mixed response to a request for a script, the script element must execute each part of the response as they become available. This behavior appears to be consistent with the definition of multipart/mixed http://tools.ietf.org/html/rfc2046#section-5.1.3. To load and execute a script as quickly as possible, the author would use the following markup: script async src=path/to/script.js/script The HTTP server would then break script.js into chunks that are safe to execute sequentially and provide each chunk as a separate MIME part in a multipart/mixed response. This seems like an overly complicated way of solving this problem. Why not just introduce a keyword or pragma to JavaScript that tells the user agent to act as if the end of the Program production had been reached, and that it should treat the remainder of the file as another Program? This could even be done in a backwards-compatible fashion by having the syntax to do this be something that down-level clients ignore, e.g.: /*@BREAK*/ ...or some such. That approach is an in-band signal, which means it's vulnerable to injection attacks. For example, consider a server that produces a JavaScript file of the following form: [...] var userData = ?php echo santize($userData) ?; [...] Currently, the rules for sanitizing using input are relatively straightforward (essentially, you just need to worry about a few special characters). However, if we implemented an in-band signaling we might well break these sanitation algorithms. To make this secure, we'd probably want some sort of randomized delimiter (perhaps declared via a pragma at the top of the file), but then we would have just re-invented multipart/mixed. Adam
Re: [whatwg] Location object identity and navigation behavior
On Mon, Jan 7, 2013 at 12:26 PM, Ian Hickson i...@hixie.ch wrote: My understanding is that WebKit, old Gecko, and new IE do what the spec says currently, and old IE, Opera, and new Gecko do the proxying model. Given the concerns in this thread, I never landed such a change to Gecko. New Gecko == Old Gecko here. For authors, I don't really see the value of the proxying model. The current spec model is slightly simpler for authors, but only slightly, because you still can't access your own shims when the page is navigated to another origin. I still think it's less confusing for the casual author (since, like window, if the object describes the picture frame, there would appear to be one object per picture frame), though for spec-reading authors the extra LocationProxy stuff might be more confusing. For implementors, I'm not really comfortable picking one side or the other here. I'm even less comfortable picking what's easy for Chrome over what's easy for Gecko. Browsers seem to be changing in both directions, and right now seem to be exactly equally split. So, I dunno. If it's a bust for authors, a tie for browsers, I guess the next level is spec writers, and, well, not changing anything is easier than changing something, so I guess that argues for not changing it? I've left the spec as-is for now, but I don't have a good argument one way or the other. Sorry for this unsatisfying answer. No worries - I appreciate the thoroughness of consideration you've given here. And anyways, I managed to get rid of most of the nastiest stuff in Gecko's Location implementation, in exchange for explicit security checks in each C++ method implementation. Aside from concerns about stack introspection, the main downside of this approach is that it's a blacklist, rather than a whitelist (like our other security code), so we'll have to be extra careful when implementing anything new on Location. Please keep that in mind when updating the spec. ;-) Cheers, bholley
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
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 cross origin anyway The set of objects exposed is not particularly limited once document.domain gets involved. Note that there is longstanding disagreemed on which cases of direct property access should perform same-origin checks. Again, Gecko I believe does it for all but a whitelist of properties like Window.top and such. For the actual wording of the check, we could either have a security check that is performed at the right time in #es-operations etc. and which HTML defines to do the origin checking, or we can make Web IDL aware of origins itself, and then HTML would define what origin different objects come from. For what it's worth, in Gecko the is same origin determination is one and the same as implements an interface determination: a cross-origin object simply claims to not implement any interfaces from the caller's point of view. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
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 to get an object's properties; what we're saying here is that for those properties, you also need to do the check when you run the code behind those properties (e.g. call a method), against the this. I'm not quite sure we're talking about the same thing here. Can you give an example of what you're thinking? What _I'm_ thinking is that there needs to be a security check when someone does Document.prototype.getElementsByTagName.call(subframe.contentDocument). This is not the same security check as the one performed by subframe.contentDocument.getElementsByTagName (note lack of call; it never gets that far in the cross-origin case). This is independent of whether we're doing security checks on all property access or on some of them. Is it that we want to avoid the overhead of origin checking if we know that calling the operation does not leak information? Or it it that only a limited set of objects is exposed cross origin anyway, so we only need to check those? Both. Implementing different security models on the IDL level is a footgun of enormous size. We should simply have IDL methods throw if called with not-same-origin this or arguments, except for a whitelist. In my opinion. Anything else is fragile and leads to security whack-a-mole. Not that we can have the argument about which interfaces are subject to this security check if you want to only limit it to some objects; or example you could argue that this is only needed on Window, EventTarget, Document, Node, and a few others. That's a separate argument from whether the security checks for those interfaces should be opt-in or opt-out. -Boris
Re: [whatwg] Script-related feedback
On Mon, 7 Jan 2013, Adam Barth wrote: Why not just introduce a keyword or pragma to JavaScript that tells the user agent to act as if the end of the Program production had been reached, and that it should treat the remainder of the file as another Program? This could even be done in a backwards-compatible fashion by having the syntax to do this be something that down-level clients ignore, e.g.: /*@BREAK*/ ...or some such. That approach is an in-band signal, which means it's vulnerable to injection attacks. If you can inject this, you can inject arbitrary code, so I don't see how this would be a problem. For example, consider a server that produces a JavaScript file of the following form: [...] var userData = ?php echo santize($userData) ?; [...] Currently, the rules for sanitizing using input are relatively straightforward (essentially, you just need to worry about a few special characters). Those simple rules would prevent anyone from inserting a pragma-like comment, too, so that's fine. However, if we implemented an in-band signaling we might well break these sanitation algorithms. How? I'm not suggesting changing any JS syntax, just making existing JS syntax be used as a signal. If making a comment do this is too dodgy, make it something like this: breakParsing(); ...and for down-level support, define an explicit breakParsing function that does nothing. If someone can insert a function call into JS, you've definitely lost already. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Location object identity and navigation behavior
On Mon, 7 Jan 2013, Bobby Holley wrote: Aside from concerns about stack introspection, the main downside of this approach is that it's a blacklist, rather than a whitelist (like our other security code), so we'll have to be extra careful when implementing anything new on Location. Please keep that in mind when updating the spec. ;-) Can you elaborate on what is a blacklist? The way it ended up in the spec is that everything on Location is blocked if it's a cross-origin access, except for the 'href' setter and 'replace'. This is an area that I've already screwed up the security model for twice, though, so I would have no trouble believing I screwed it up again... http://whatwg.org/html#security-3 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Script-related feedback
On Mon, Jan 7, 2013 at 7:20 PM, Adam Barth w...@adambarth.com wrote: This could even be done in a backwards-compatible fashion by having the syntax to do this be something that down-level clients ignore, e.g.: /*@BREAK*/ ...or some such. That approach is an in-band signal, which means it's vulnerable to injection attacks. For example, consider a server that produces a JavaScript file of the following form: [...] var userData = ?php echo santize($userData) ?; [...] Currently, the rules for sanitizing using input are relatively straightforward (essentially, you just need to worry about a few special characters). However, if we implemented an in-band signaling we might well break these sanitation algorithms. To make this secure, we'd probably want some sort of randomized delimiter (perhaps declared via a pragma at the top of the file), but then we would have just re-invented multipart/mixed. The suggestion was the comment /*@BREAK*/, which the string literal /*@BREAK*/ wouldn't match, being a string token, not a comment, right? -- Glenn Maynard
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
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 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 any) Document. Origin checks are only done in some very specific places where you try to get an object's properties; what we're saying here is that for those properties, you also need to do the check when you run the code behind those properties (e.g. call a method), against the this. I'm not quite sure we're talking about the same thing here. Can you give an example of what you're thinking? Suppose you try to get the property from a Document whose origin doesn't match your script's origin. Right now, this throws a SecurityError, because of: # User agents must throw a SecurityError exception whenever any properties # of a Document object are accessed by scripts whose effective script # origin is not the same as the Document's effective script origin. -- http://www.whatwg.org/specs/web-apps/current-work/#security-document The check we need to add is for when you actually invoke the properties, in case you got the property from another Document and then apply it to this one. 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. What _I'm_ thinking is that there needs to be a security check when someone does Document.prototype.getElementsByTagName.call(subframe.contentDocument). This is not the same security check as the one performed by subframe.contentDocument.getElementsByTagName (note lack of call; it never gets that far in the cross-origin case). This is independent of whether we're doing security checks on all property access or on some of them. Right. Specifically, the new security check (for compat we still need the old one too, though I guess in many cases it's now redundant) needs to be in getElementsByTagName()'s definition or in call()'s definition. (If the latter, we also need to put it in a number of other places, like the stuff that interacts with getters/setters.) So e.g. we could put it in call() and define it as checking whether you can obtain the property on the target object before actually executing any code. I don't want us to literally put the checks (in the spec) in each method / property of the four objects with these checks (Document, Window, Location, Storage), since that's a _lot_ of places to put these checks. We could put them in prose in the same places that have the access checks now. Or we could put them elsewhere. Where the current checks are makes the most sense to me, but I'm not sure exactly how to phrase them. Implementing different security models on the IDL level is a footgun of enormous size. We should simply have IDL methods throw if called with not-same-origin this or arguments, except for a whitelist. Except for having to define the origin of things for this purpose, yes, that's what I'm essentially saying. Not that we can have the argument about which interfaces are subject to this security check if you want to only limit it to some objects; or example you could argue that this is only needed on Window, EventTarget, Document, Node, and a few others. That's a separate argument from whether the security checks for those interfaces should be opt-in or opt-out. I don't see why EventTarget would be subject to this (it's implemented by things that need checking, but presumably everything that's implemented in that way should just be handled by that host interface the same way as everything on that host interface that isn't white listed). The only interfaces that are of interest here (that need them and their inherited and implemented interfaces checked) are Document, Window, Location, and Storage. At least, in the HTML spec, as far as I can tell. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
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 any) Document. Yes, I know what the spec says. What I'm saying is that the spec is not doing anyone any favors by using origin to mean different things for different objects. In particular, for images/audio/video the origin in the spec is the origin that's relevant for the _data_, not necessarily for the element itself. Suppose you try to get the property from a Document whose origin doesn't match your script's origin. Right now, this throws a SecurityError Right. We all agree on this part; there is no problem here. The check we need to add is for when you actually invoke the properties, in case you got the property from another Document and then apply it to this one. Yes. 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. That's an option, yes. As I said, Gecko throws TypeError like it would for a non-document. That happens to require less code, and I'm not sure people really care about the exact exception here (though I know bholley disagrees with me on this). Right. Specifically, the new security check (for compat we still need the old one too, though I guess in many cases it's now redundant) It's not redundant, because nothing says that subframeDoc.getElementsByTagName is actually the WebIDL-defined method; it could be something the script in the subframe set up. So you have to block access to it no matter what. needs to be in getElementsByTagName()'s definition or in call()'s definition. (If the latter, we also need to put it in a number of other places, like the stuff that interacts with getters/setters.) I would vastly prefer that this check be in the definition of the [[Call]], because then it can be done on the binding level, when you're checking the this object anyway. So e.g. we could put it in call() and define it as checking whether you can obtain the property on the target object before actually executing any code. Is that actually needed? There are properties you can obtain on objects cross-origin (like window.top) that I see no need to allow via this backdoor since no content depends on it now. So I would prefer simply checking whether the origin of the caller matches the origin of this. I don't want us to literally put the checks (in the spec) in each method / property of the four objects with these checks (Document, Window, Location, Storage), since that's a _lot_ of places to put these checks. We could put them in prose in the same places that have the access checks now. Or we could put them elsewhere. Where the current checks are makes the most sense to me, but I'm not sure exactly how to phrase them. Or you could spec what Gecko does, which is that any WebIDL call gets such a check, and then it's just defined in WebIDL. ;) Of course that does mean defining an origin for every object (as opposed to data associated with the object). Except for having to define the origin of things for this purpose, yes, that's what I'm essentially saying. OK. So here's the thing. Given any script-exposed object, it already has to be associated with a specific global. WebIDL makes this a requirement, since you have to find the right prototype object for it. At that point, you have a Window to work with, and a Window has an associated Document, and that has an origin. For object-access checks (again, as opposed to data-access checks), this is the right origin to use. I don't see why EventTarget would be subject to this (it's implemented by things that need checking, but presumably everything that's implemented in that way should just be handled by that host interface the same way as everything on that host interface that isn't white listed). EventTarget isn't implemented. It's inherited from. The only interfaces that are of interest here (that need them and their inherited and implemented interfaces checked) are Document, Window, Location, and Storage. At least, in the HTML spec, as far as I can tell. var myGetter = Object.getOwnPropertyDescriptor(Node.prototype, firstChild).get; var node = myGetter.call(crossOriginDoc); This should throw; we agree on that, right? So I'm not sure what we're disagreeing about here. Perhaps you're thinking of this as throwing because of something crossOriginDoc does, while I'm thinking of it as throwing because of something myGetter does? Again, right now this is implemented in Gecko as part of myGetter's [[Call]], so that's the way I'm thinking of it. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
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. 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 would expect out of people creating APIs, which is why I would really prefer we define this on a low level where people can't screw up by forgetting it.) -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
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 of the most obvious related (or in some cases any) Document. Yes, I know what the spec says. What I'm saying is that the spec is not doing anyone any favors by using origin to mean different things for different objects. I don't think it means different things, but I guess that's semantics. In particular, for images/audio/video the origin in the spec is the origin that's relevant for the _data_, not necessarily for the element itself. In the spec's security model, origins are never relevant for elements except when we're looking at the element's data. Right. Specifically, the new security check (for compat we still need the old one too, though I guess in many cases it's now redundant) It's not redundant, because nothing says that subframeDoc.getElementsByTagName is actually the WebIDL-defined method; it could be something the script in the subframe set up. So you have to block access to it no matter what. Agreed; by being redundant in many cases I didn't mean that we could do away with it, just that in many cases you effectively have to do the check twice (since in most cases the property isn't overridden). needs to be in getElementsByTagName()'s definition or in call()'s definition. (If the latter, we also need to put it in a number of other places, like the stuff that interacts with getters/setters.) I would vastly prefer that this check be in the definition of the [[Call]], because then it can be done on the binding level, when you're checking the this object anyway. Doing it in [[Call]] and the various equivalents for IDL attributes would be fine by me. So e.g. we could put it in call() and define it as checking whether you can obtain the property on the target object before actually executing any code. Is that actually needed? There are properties you can obtain on objects cross-origin (like window.top) that I see no need to allow via this backdoor since no content depends on it now. So I would prefer simply checking whether the origin of the caller matches the origin of this. Well right now this doesn't necessarily have an origin. Also, consider Location. If you have a Location object and then navigate its browsing context and then call something on it, you need to check that the calling script doesn't match the origin of the new active document, not the origin of the Location object's Window's Document. I don't want us to literally put the checks (in the spec) in each method / property of the four objects with these checks (Document, Window, Location, Storage), since that's a _lot_ of places to put these checks. We could put them in prose in the same places that have the access checks now. Or we could put them elsewhere. Where the current checks are makes the most sense to me, but I'm not sure exactly how to phrase them. Or you could spec what Gecko does, which is that any WebIDL call gets such a check, and then it's just defined in WebIDL. ;) Doing a check on _every_ call seems rather expensive for implementations that don't use Gecko's security model compared to only doing a check on those interfaces that matter. Given any script-exposed object, it already has to be associated with a specific global. WebIDL makes this a requirement, since you have to find the right prototype object for it. A Location object has multiple prototypes (one for each origin that accesses it). At that point, you have a Window to work with, and a Window has an associated Document, and that has an origin. For object-access checks (again, as opposed to data-access checks), this is the right origin to use. For Storage, the access check has to be the actual origin of the Document, not the effective script origin as it does for Window and Document. I don't see why EventTarget would be subject to this (it's implemented by things that need checking, but presumably everything that's implemented in that way should just be handled by that host interface the same way as everything on that host interface that isn't white listed). EventTarget isn't implemented. It's inherited from. You're right, my bad. The only interfaces that are of interest here (that need them and their inherited and implemented interfaces checked) are Document, Window, Location, and Storage. At least, in the HTML spec, as far as I can tell. var myGetter = Object.getOwnPropertyDescriptor(Node.prototype, firstChild).get; var node = myGetter.call(crossOriginDoc); This should throw; we agree on that, right? Assuming the script's effective
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
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, throw SecurityError. 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 would expect out of people creating APIs, which is why I would really prefer we define this on a low level where people can't screw up by forgetting it.) 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. (For example, one could imagine a PortCollection analogue for Window.postMessage() where you push the destination Window objects into an opaque object and then have the browser iterate over them.) I would be fine with an annotation on Document and Window that says that you can't pass them in as arguments when they're cross-origin except if the method's argument has itself been annotated with a I know what I'm doing marker. (Dunno how this would work with Location and Storage.) But if there's only one API that takes any of these four object types currently (I couldn't find any that took Document or Window in the HTML spec in a cursory look) then maybe it's not worth the bother. Wack a mole isn't _so_ bad if it's one mole a decade. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Location object identity and navigation behavior
On Mon, Jan 7, 2013 at 8:05 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Jan 2013, Bobby Holley wrote: Aside from concerns about stack introspection, the main downside of this approach is that it's a blacklist, rather than a whitelist (like our other security code), so we'll have to be extra careful when implementing anything new on Location. Please keep that in mind when updating the spec. ;-) Can you elaborate on what is a blacklist? In the sense that we have to implement it as explicit per-method checks in C++. Our regular security model is an object-capability system enforced with wrappers across scope boundaries (using a whitelist), which, as previously discussed, doesn't jive with the current spec for Location. So if something new is ever added to nsLocation, we're going to need to remember to add a security check. bholley
