Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Sun, 15 Mar 2009 22:09:16 +0100, Hans Schmucker hansschmuc...@gmail.com wrote: Sorry, I didn't mean to make it sound like an attack, I really just meant to say that this (for me) belongs more into HTML5, which deals primarily with the user agent, than into the CORS spec, which more or less focuses on the server side and the communication between server and client. I don't think anyone is disagreeing with that. So, where would you put it? The problem for me is that there's no logical grouping of elements that load offsite resources (like img, script, link, video, ...) where one could add the necessary attributes. All off them descend directly from HTMLElement. So there would be two routes: Either making all elements that load offsite data descend from a common HTMLRemotelyFedElement interface (which seems like the right way to do things, but it's also IMHO completely unrealistic as it would either require reworking the DOM top to bottom or including ugly hacks) or adding the necessary attributes to HTMLElement itself... which seems like asking for trouble. Why does the DOM need to get involved here? Then there's the (IMHO) despicable way of just writing a random chapter about it and referencing that chapter in the spec wherever appropriate. Feels very, very wrong, but I don't think we have much choice here. I don't see how this is wrong. Since the exact semantics of a cross-origin request vary per API anyway grouping the common things somewhere makes sense to me. (E.g. EventSource would completely fail in case the resource sharing check fails where as an image would still be displayed.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
So, where would you put it? The problem for me is that there's no logical grouping of elements that load offsite resources (like img, script, link, video, ...) where one could add the necessary attributes. All off them descend directly from HTMLElement. So there would be two routes: Either making all elements that load offsite data descend from a common HTMLRemotelyFedElement interface (which seems like the right way to do things, but it's also IMHO completely unrealistic as it would either require reworking the DOM top to bottom or including ugly hacks) or adding the necessary attributes to HTMLElement itself... which seems like asking for trouble. Why does the DOM need to get involved here? Well it should be involved, although I don't think we can actually do it. I think the CORS header response should be stored and be available the same way across all DOM elements that can load data. If that would be provided by a special interface from which all elements that load data descend, it would not only make the whole thing cleaner in the spec, but also in the implementations. Instead of an UA supporting first XHR, then image, then video, then XY, the status of the implementation would be identical in all parts of the UA. Basically, it would force implementations to create the CORS dom support with a common codebase for all elements that use it, instead of having duplicate code which might behave differently. Then there's the (IMHO) despicable way of just writing a random chapter about it and referencing that chapter in the spec wherever appropriate. Feels very, very wrong, but I don't think we have much choice here. I don't see how this is wrong. Since the exact semantics of a cross-origin request vary per API anyway grouping the common things somewhere makes sense to me. (E.g. EventSource would completely fail in case the resource sharing check fails where as an image would still be displayed.) Reading this again the next morning I really should have worded that differently. Sorry about that. But I'm really afraid JS developers, in addition to catching different behaviours in different UAs would also have to deal with different behaviour inside the same UA. Yes, the actual use would be different across different cases, but at least the raw data would be readable the same way and the parts that implement the different uses would have a standardized to where to get their data from.
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Mon, 16 Mar 2009 14:07:38 +0100, Hans Schmucker hansschmuc...@gmail.com wrote: Why does the DOM need to get involved here? Well it should be involved, although I don't think we can actually do it. I think the CORS header response should be stored and be available the same way across all DOM elements that can load data. If that would be provided by a special interface from which all elements that load data descend, it would not only make the whole thing cleaner in the spec, but also in the implementations. If the specifics are not exposed to authors the DOM does not need to get involved. Instead of an UA supporting first XHR, then image, then video, then XY, the status of the implementation would be identical in all parts of the UA. Basically, it would force implementations to create the CORS dom support with a common codebase for all elements that use it, instead of having duplicate code which might behave differently. I don't think we should be in the business of enforcing how implementations implement things. We can certainly encourage things by re-using algorithms, indicating things are identical, etc., but if there is no author-observable difference we cannot test it. Then there's the (IMHO) despicable way of just writing a random chapter about it and referencing that chapter in the spec wherever appropriate. Feels very, very wrong, but I don't think we have much choice here. I don't see how this is wrong. Since the exact semantics of a cross-origin request vary per API anyway grouping the common things somewhere makes sense to me. (E.g. EventSource would completely fail in case the resource sharing check fails where as an image would still be displayed.) Reading this again the next morning I really should have worded that differently. Sorry about that. But I'm really afraid JS developers, in addition to catching different behaviours in different UAs would also have to deal with different behaviour inside the same UA. Yes, the actual use would be different across different cases, but at least the raw data would be readable the same way and the parts that implement the different uses would have a standardized to where to get their data from. Consistency is enforced by tests and proper specifications. Currently HTML5 has not integrated support for CORS (yet) so it seems a bit early to complain :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Mon, Mar 16, 2009 at 2:43 PM, Anne van Kesteren ann...@opera.com wrote: On Mon, 16 Mar 2009 14:07:38 +0100, Hans Schmucker hansschmuc...@gmail.com wrote: Why does the DOM need to get involved here? Well it should be involved, although I don't think we can actually do it. I think the CORS header response should be stored and be available the same way across all DOM elements that can load data. If that would be provided by a special interface from which all elements that load data descend, it would not only make the whole thing cleaner in the spec, but also in the implementations. If the specifics are not exposed to authors the DOM does not need to get involved. Correct. I'm not a browser maker, so my perspective is probably a bit different than yours. I just write JS. The problem for me is that if such data is not available, I would be forced to basically do a lot of try/catch or other form of error catching just to find out what exactly I can do when I could just look it up in the elements attributes. Instead of an UA supporting first XHR, then image, then video, then XY, the status of the implementation would be identical in all parts of the UA. Basically, it would force implementations to create the CORS dom support with a common codebase for all elements that use it, instead of having duplicate code which might behave differently. I don't think we should be in the business of enforcing how implementations implement things. We can certainly encourage things by re-using algorithms, indicating things are identical, etc., but if there is no author-observable difference we cannot test it. Well, a bit. We do that all the time when we specify inheritance. At least we encourage it and plant the idea that this really should be in a common spot. Then there's the (IMHO) despicable way of just writing a random chapter about it and referencing that chapter in the spec wherever appropriate. Feels very, very wrong, but I don't think we have much choice here. I don't see how this is wrong. Since the exact semantics of a cross-origin request vary per API anyway grouping the common things somewhere makes sense to me. (E.g. EventSource would completely fail in case the resource sharing check fails where as an image would still be displayed.) Reading this again the next morning I really should have worded that differently. Sorry about that. But I'm really afraid JS developers, in addition to catching different behaviours in different UAs would also have to deal with different behaviour inside the same UA. Yes, the actual use would be different across different cases, but at least the raw data would be readable the same way and the parts that implement the different uses would have a standardized to where to get their data from. Consistency is enforced by tests and proper specifications. Currently HTML5 has not integrated support for CORS (yet) so it seems a bit early to complain :-) Better now than when the damage is done, right?
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Sat, Mar 14, 2009 at 3:11 PM, Anne van Kesteren ann...@opera.com wrote: On Fri, 13 Mar 2009 23:53:36 -, Hans Schmucker hansschmuc...@gmail.com wrote: Question is: what would be the best way to fix it? Of course the spec could be changed for video and image, but wouldn't it be simpler to update the defintion of origins to include patterns that can represent allow rules? Aside: You might want to take a look at a later version of the specification (the one that is being implemented): http://dev.w3.org/2006/waf/access-control/ Thank you Anne, but I think this has to be dealt with primarily inside the HTML5 spec. The Access Control spec is already pretty clear on how things are supposed to work on the server and from the server to the client and it's probably mostly enough to say that Image and Video elements in addition to cross-origin linking also allow for cross-origin use as described in Cross-Origin Resource Sharing. Me and Chris actually assumed it would work that way until we tried it. The main question for me (aside from the question if image/video/canvas elements should retain all necessary information to check for valid origins that are allowed access again or just be marked standard/public) is where to put it in the spec. It's an issue that applies to pretty much anything that allows access to the raw data (which is just canvas now, but nobody knows what the future will bring) and to make matters worse its nature not only requires changes to canvas itself, but also to the elements that are drawable, like img or video. So to me it would make the most sense to put this as far away as possible from Canvas and make it more into a generic item how DOM elements are supposed to hold data about cross origin headers. Then the canvas description would need virtually no changed beyond obeys cross-origin rules for pixel access.
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Sun, 15 Mar 2009 20:45:17 +0100, Hans Schmucker hansschmuc...@gmail.com wrote: Thank you Anne, but I think this has to be dealt with primarily inside the HTML5 spec. Yes, hence me using the word aside... Anyway, ... The Access Control spec is already pretty clear on how things are supposed to work on the server and from the server to the client and it's probably mostly enough to say that Image and Video elements in addition to cross-origin linking also allow for cross-origin use as described in Cross-Origin Resource Sharing. No, currently you actually have to state which algorithm you use in CORS and how. Otherwise CORS does not apply (at least not from a specification standpoint). Me and Chris actually assumed it would work that way until we tried it. The main question for me (aside from the question if image/video/canvas elements should retain all necessary information to check for valid origins that are allowed access again or just be marked standard/public) is where to put it in the spec. It's an issue that applies to pretty much anything that allows access to the raw data (which is just canvas now, but nobody knows what the future will bring) and to make matters worse its nature not only requires changes to canvas itself, but also to the elements that are drawable, like img or video. So to me it would make the most sense to put this as far away as possible from Canvas and make it more into a generic item how DOM elements are supposed to hold data about cross origin headers. Then the canvas description would need virtually no changed beyond obeys cross-origin rules for pixel access. That does sound nice yes. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
Thank you Anne, but I think this has to be dealt with primarily inside the HTML5 spec. Yes, hence me using the word aside... Sorry, I didn't mean to make it sound like an attack, I really just meant to say that this (for me) belongs more into HTML5, which deals primarily with the user agent, than into the CORS spec, which more or less focuses on the server side and the communication between server and client. No, currently you actually have to state which algorithm you use in CORS and how. Otherwise CORS does not apply (at least not from a specification standpoint). Yes, we pretty much assumed that HTML5 had already adapted to CORS. It was an assumption, but it's an assumption many people are bound to make as other HTML5 features depend on CORS. It's an issue that applies to pretty much anything that allows access to the raw data (which is just canvas now, but nobody knows what the future will bring) and to make matters worse its nature not only requires changes to canvas itself, but also to the elements that are drawable, like img or video. So to me it would make the most sense to put this as far away as possible from Canvas and make it more into a generic item how DOM elements are supposed to hold data about cross origin headers. Then the canvas description would need virtually no changed beyond obeys cross-origin rules for pixel access. That does sound nice yes. So, where would you put it? The problem for me is that there's no logical grouping of elements that load offsite resources (like img, script, link, video, ...) where one could add the necessary attributes. All off them descend directly from HTMLElement. So there would be two routes: Either making all elements that load offsite data descend from a common HTMLRemotelyFedElement interface (which seems like the right way to do things, but it's also IMHO completely unrealistic as it would either require reworking the DOM top to bottom or including ugly hacks) or adding the necessary attributes to HTMLElement itself... which seems like asking for trouble. Then there's the (IMHO) despicable way of just writing a random chapter about it and referencing that chapter in the spec wherever appropriate. Feels very, very wrong, but I don't think we have much choice here.
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Sat, Mar 14, 2009 at 12:53 PM, Hans Schmucker hansschmuc...@gmail.comwrote: Question is: what would be the best way to fix it? Of course the spec could be changed for video and image, but wouldn't it be simpler to update the defintion of origins to include patterns that can represent allow rules? I don't think changing the definition of origins is the right way to go. It seems better to define a category of public resources, specify that a resource served with Access-Control-Allow-Origin: * is public, and have canvas. treat public resources specially. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
Doesn't that kind of defeat the purpose of access control to have fine grained control over who is allowed access? Public resources are a quick fix for most scenarios that I can imagine, but I think using patterns would appear more consistent and logical to most users. It may not be terribly useful, but it would avoid a few embarassing moments for people who use access control. On 3/14/09, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Mar 14, 2009 at 12:53 PM, Hans Schmucker hansschmuc...@gmail.comwrote: Question is: what would be the best way to fix it? Of course the spec could be changed for video and image, but wouldn't it be simpler to update the defintion of origins to include patterns that can represent allow rules? I don't think changing the definition of origins is the right way to go. It seems better to define a category of public resources, specify that a resource served with Access-Control-Allow-Origin: * is public, and have canvas. treat public resources specially. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Fri, 13 Mar 2009 23:53:36 -, Hans Schmucker hansschmuc...@gmail.com wrote: Question is: what would be the best way to fix it? Of course the spec could be changed for video and image, but wouldn't it be simpler to update the defintion of origins to include patterns that can represent allow rules? Aside: You might want to take a look at a later version of the specification (the one that is being implemented): http://dev.w3.org/2006/waf/access-control/ -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
I think this is an excellent point. I've been playing with the Chroma-Key replacement trick demonstrated in FireFox 3.1b3: https://developer.mozilla.org/samples/video/chroma-key/index.xhtml https://developer.mozilla.org/En/Manipulating_video_using_canvas For my own experiments, I grabbed a green-screen video from Youtube and converted it to OGG. If the access control were in place for Canvas, I could have done direct compositing on an embedded video from TinyVid. Which would open up some interesting possibilities for video mashups on the web. Thanks, Jerason On Fri, Mar 13, 2009 at 11:24 AM, Hans Schmucker hansschmuc...@gmail.comwrote: This problem recently became apparent while trying to process a public video on tinyvid.tv: In article 4.8.11.3 Security with canvas elements, the origin-clean flag is only set depending on an element's origin. However there are many scenarios where an image/video may actually be public and actively allowing processing on other domains (as indicated by Access-Control-Allow-Origin). Is this an oversight or is there a specific reason why Access Control for Cross-Site Requests should not work for Canvas?
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
On Fri, Mar 13, 2009 at 9:24 AM, Hans Schmucker hansschmuc...@gmail.com wrote: This problem recently became apparent while trying to process a public video on tinyvid.tv: In article 4.8.11.3 Security with canvas elements, the origin-clean flag is only set depending on an element's origin. However there are many scenarios where an image/video may actually be public and actively allowing processing on other domains (as indicated by Access-Control-Allow-Origin). Is this an oversight or is there a specific reason why Access Control for Cross-Site Requests should not work for Canvas? I think it's because the majority of the canvas spec was developed before the Access Control spec existed. Or at least before it had the ability to work on images (originally it only worked on XML data). / Jonas
Re: [whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests
Question is: what would be the best way to fix it? Of course the spec could be changed for video and image, but wouldn't it be simpler to update the defintion of origins to include patterns that can represent allow rules?
