Re: Custom Elements: is=
On Mon, Jun 8, 2015 at 11:48 PM, Justin Fagnani justinfagn...@google.com wrote: And I'm still concerned that removing is= would severely harm the cases where you need access to special parsing behavior like template and style. With synchronous constructors you could imagine setting the parsing policy in the constructor (as `this[Element.parsingPolicy] = x` or some such). I wouldn't want to do that for v1, but it opens up that possibility of making the HTML parser hackable. -- https://annevankesteren.nl/
Re: Custom Elements: is=
On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote: - v1 sets the stage for people to develop habits and expectations about how custom elements work. New features tend to be slowly adopted, by both browser vendors and (partly as a consequence) developers, so even if we do come up with something for v2, it will be even longer before it becomes mainstream (and as I mentioned earlier we will still be stuck with code written to v1 for much longer again). I don't see how it will be longer. is= is not getting acceptance as-is. So all this would result in is not getting custom elements across browsers until v2 is done. I sort of assumes that the reason for this discussion is to get everyone on the same page regarding type extension and hope to arrive at better acceptance. Arguing that something isn't getting acceptance when the purpose of discussion is attempting to gain the said acceptance seems a bit circular. Other than that, please do continue this conversation! :) :DG
Re: Custom Elements: is=
On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall aboxh...@google.com wrote: - In the time between v1 and v2 (however long that ends up being) we are left without any way to solve this problem, assuming we don't come up with something else for v1. If developers start using custom elements where they would previously have used a native element, this could well result in a regression in accessibility for the web as a whole for this period, and we will be stuck with the legacy of code written during this period for much longer as well. I don't see how it is a regression compared to the current situation. - I realise that to some extent developers already aren't using native elements, in part because of the styling issues we've discussed which also affect is=. My concern here is that custom elements will further legitimise this habit, which we've been making some recent progress in changing - we stand to backslide on that effort. Having is= would allow us to roll it into the use native elements where possible message rather than diluting it with unless you're using a custom element in which case here's a checklist which you're not going to look at of everything it should do until we come up with an alternative. Most examples of custom elements to date are not actually with is=, simply because custom tag names are much more appealing. The ergonomics don't back up the message. - v1 sets the stage for people to develop habits and expectations about how custom elements work. New features tend to be slowly adopted, by both browser vendors and (partly as a consequence) developers, so even if we do come up with something for v2, it will be even longer before it becomes mainstream (and as I mentioned earlier we will still be stuck with code written to v1 for much longer again). I don't see how it will be longer. is= is not getting acceptance as-is. So all this would result in is not getting custom elements across browsers until v2 is done. Here's where we differ, because: - I don't think it's a wart. I've given this a great deal of thought and I keep ending up back at the current syntax when I try to think of reasonable alternatives, even assuming we could magically fix all the implementation issues with any alternative proposal. I think if we figured out how the behavior of current elements is composed and how to address the styling problem we'd be much closer to an agreement. And I think everyone agrees those need to be solved, so I'm a bit lost as to why we don't focus on those. - I don't think shipping in one browser is nothing. People (both framework authors and web page authors) are already writing code using is=. Well, I disagree. E.g. Microsoft had a ton of features shipping in Internet Explorer 5.0 that were used and never ended up as-is (or at all) in other browsers. In the long run it's pretty close to nothing. -- https://annevankesteren.nl/
Re: Custom Elements: is=
On Jun 9, 2015 8:45 AM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote: - v1 sets the stage for people to develop habits and expectations about how custom elements work. New features tend to be slowly adopted, by both browser vendors and (partly as a consequence) developers, so even if we do come up with something for v2, it will be even longer before it becomes mainstream (and as I mentioned earlier we will still be stuck with code written to v1 for much longer again). I don't see how it will be longer. is= is not getting acceptance as-is. So all this would result in is not getting custom elements across browsers until v2 is done. I sort of assumes that the reason for this discussion is to get everyone on the same page regarding type extension and hope to arrive at better acceptance. Arguing that something isn't getting acceptance when the purpose of discussion is attempting to gain the said acceptance seems a bit circular. Other than that, please do continue this conversation! :) I'll also note that a large fraction of Polymer elements and Polymer using pages, thus a large fraction of existing custom elements and use, uses is=, via template is=dom-repeat / dom-if / dom-bind and style is=custom-style. So as far as current custom elements are concerned, is= is accepted. :DG
Re: Custom Elements: is=
On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall aboxh...@google.com wrote: - In the time between v1 and v2 (however long that ends up being) we are left without any way to solve this problem, assuming we don't come up with something else for v1. If developers start using custom elements where they would previously have used a native element, this could well result in a regression in accessibility for the web as a whole for this period, and we will be stuck with the legacy of code written during this period for much longer as well. I don't see how it is a regression compared to the current situation. Exactly: this describes the current situation, which I think is unsatisfactory. - I realise that to some extent developers already aren't using native elements, in part because of the styling issues we've discussed which also affect is=. My concern here is that custom elements will further legitimise this habit, which we've been making some recent progress in changing - we stand to backslide on that effort. Having is= would allow us to roll it into the use native elements where possible message rather than diluting it with unless you're using a custom element in which case here's a checklist which you're not going to look at of everything it should do until we come up with an alternative. Most examples of custom elements to date are not actually with is=, simply because custom tag names are much more appealing. The ergonomics don't back up the message. Polymer have a whole suite of elements which use is=: https://elements.polymer-project.org/browse?package=gold-elements When you refer to ergonomics, are you talking purely about the syntax? Or about the set of issues involved in using native elements compared to (lower case c) custom elements: essentially, whether or not you're ceding some control over styling and behaviour to the browser? - v1 sets the stage for people to develop habits and expectations about how custom elements work. New features tend to be slowly adopted, by both browser vendors and (partly as a consequence) developers, so even if we do come up with something for v2, it will be even longer before it becomes mainstream (and as I mentioned earlier we will still be stuck with code written to v1 for much longer again). I don't see how it will be longer. is= is not getting acceptance as-is. So all this would result in is not getting custom elements across browsers until v2 is done. I think Dimitri responded to this better than I could. Here's where we differ, because: - I don't think it's a wart. I've given this a great deal of thought and I keep ending up back at the current syntax when I try to think of reasonable alternatives, even assuming we could magically fix all the implementation issues with any alternative proposal. I think if we figured out how the behavior of current elements is composed and how to address the styling problem we'd be much closer to an agreement. And I think everyone agrees those need to be solved, so I'm a bit lost as to why we don't focus on those. I agree that those problems need to be solved (in particular, the styling issue also comes into play when using is=), but I think that these are multiple pieces of the same puzzle. The primitives are critical for creating novel types of elements, which won't be able to benefit from type extensions in any case. Styling is critical for getting people to use native elements with or without type extensions. Allowing developers to extend native types means that *users* benefit from not relying on custom element developers who just want to create a button with some fancy rendering (beyond what can be achieved using CSS alone), or custom behaviour, remembering to re-implement all of the accessibility affordances which are built in to an HTML button. It also means that *developers* benefit from not having to do the extra legwork for accessibility. We see time after time after time that accessibility is fighting an uphill battle because it isn't on developers' radars as a priority for v1. This causes constant regressions in functionality for people who rely on assistive technology. The promise of the HTML platform is that it should be accessible if we use the native elements as they were designed to be used. Part of my day job is helping make sure that the browser I work on upholds its part of that bargain. You could argue that what we need is a way to wrap *all* of the accessibility affordances of a button into a mix-in object; I really don't see a much more efficient way to do that than extending a button element, either in terms of creating the spec or in terms of using the object. - I don't think shipping in one browser is nothing. People (both framework authors and web page authors) are already writing code using is=. Well, I disagree. E.g. Microsoft
Clipboard API: remove dangerous formats from mandatory data types
Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg - image/gif If these types are supported, malicious web content can trivially write a malformed GIF/JPG/PNG to the clipboard and trigger code execution when pasting in a program with a vulnerable image decoder. This provides a trivial way to bypass the sandbox that web content is usually in. Given this, I'd like to propose that we remove the above formats from the list of mandatory data types, and avoid adding support for any more complex formats. Daniel [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
Re: Clipboard API: remove dangerous formats from mandatory data types
On 06/09/2015 09:39 PM, Daniel Cheng wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg - image/gif If these types are supported, malicious web content can trivially write a malformed GIF/JPG/PNG to the clipboard and trigger code execution when pasting in a program with a vulnerable image decoder. This provides a trivial way to bypass the sandbox that web content is usually in. Given this, I'd like to propose that we remove the above formats from the list of mandatory data types, and avoid adding support for any more complex formats. Daniel [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1 Why would text/html, application/xhtml+xml, image/svg+xml, application/xml, text/xml, application/javascript be any safer if the program which the data is pasted to has vulnerable html/xml/js parsing? -Olli
Re: Clipboard API: remove dangerous formats from mandatory data types
On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht p...@hoplahup.net wrote: Daniel, this does not make sense to me. All these image parsers exploits can be triggered by an img tag, or? Similarly for XML using an XHR or some particular XML formats (RSS, SVG, XHTML, ...) in markup. Sure. That's why Chrome only decodes images in sandboxed processes like the renderer. There's absolutely no difference in the mistrust we should have between content brought by an HTML page and content brought by a JavaScript, or? Hence we should just not accept the reason of knowing of broken parsers to be a reason to change the standards! The difference is that copy image to clipboard never writes a GIF/JPG/PNG to the clipboard. The trusted browser process grabs the raw decoded bitmap from the renderer, validates the size information and some other stuff, and then writes it to the clipboard as a bitmap of the appropriate format. On the other hand, supporting this from JS means the untrusted renderer would get to control and place arbitrary GIF/JPG/PNG into the clipboard. It's not really feasible to do any corresponding validation that the data isn't bad. If, as a president, you need to decide to change the roads because a particular car was built massively and needs a particularirty of your roads, you would also find it nonsense, or? You're making me feel like France which did this for a particular type of trains which required to change all platforms because their ordered trains were already built too wide It's unfortunate, but I doubt any native apps attempt to securely decode images. Previously, it didn't matter, since the clipboard content came from other native apps, and if you can't trust other native apps, you're kind of hosed anyway. However, going from web content - native crosses a security boundary, which means these sort of issues need to be taken into consideration. Paul On 9/06/15 21:15, Daniel Cheng wrote: I'm not against considering more formats to be dangerous. =) In particular: JS: I'm not support what context we'd ever want to support this, since we go out of our way to try prevent XSS in HTML pastes. XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE bugs on a semi-regular basis. Daniel On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay o...@pettay.fi wrote: On 06/09/2015 09:39 PM, Daniel Cheng wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg - image/gif If these types are supported, malicious web content can trivially write a malformed GIF/JPG/PNG to the clipboard and trigger code execution when pasting in a program with a vulnerable image decoder. This provides a trivial way to bypass the sandbox that web content is usually in. Given this, I'd like to propose that we remove the above formats from the list of mandatory data types, and avoid adding support for any more complex formats. Daniel [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1 Why would text/html, application/xhtml+xml, image/svg+xml, application/xml, text/xml, application/javascript be any safer if the program which the data is pasted to has vulnerable html/xml/js parsing? -Olli
Re: Clipboard API: remove dangerous formats from mandatory data types
Why we would exclude any data formats that the browsers currently already support copying today? Definitely not a fan of that idea offhand. Is it not possible for a malicious image to be displayed (or display as broken) in Chrome and allow a user to choose Copy Image from that element's context menu? If not, how is that protection/prevention achieved today? Could the same process to applied to outgoing copy/cut operations and incoming paste operations? Sincerely, James M. Greene On Jun 9, 2015 2:19 PM, Daniel Cheng dch...@google.com wrote: I'm not against considering more formats to be dangerous. =) In particular: JS: I'm not support what context we'd ever want to support this, since we go out of our way to try prevent XSS in HTML pastes. XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE bugs on a semi-regular basis. Daniel On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay o...@pettay.fi wrote: On 06/09/2015 09:39 PM, Daniel Cheng wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg - image/gif If these types are supported, malicious web content can trivially write a malformed GIF/JPG/PNG to the clipboard and trigger code execution when pasting in a program with a vulnerable image decoder. This provides a trivial way to bypass the sandbox that web content is usually in. Given this, I'd like to propose that we remove the above formats from the list of mandatory data types, and avoid adding support for any more complex formats. Daniel [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1 Why would text/html, application/xhtml+xml, image/svg+xml, application/xml, text/xml, application/javascript be any safer if the program which the data is pasted to has vulnerable html/xml/js parsing? -Olli
Re: Clipboard API: remove dangerous formats from mandatory data types
Daniel, this does not make sense to me. All these image parsers exploits can be triggered by an img tag, or? Similarly for XML using an XHR or some particular XML formats (RSS, SVG, XHTML, ...) in markup. There's absolutely no difference in the mistrust we should have between content brought by an HTML page and content brought by a JavaScript, or? Hence we should just not accept the reason of knowing of broken parsers to be a reason to change the standards! If, as a president, you need to decide to change the roads because a particular car was built massively and needs a particularirty of your roads, you would also find it nonsense, or? You're making me feel like France which did this for a particular type of trains which required to change all platforms because their ordered trains were already built too wide Paul On 9/06/15 21:15, Daniel Cheng wrote: I'm not against considering more formats to be dangerous. =) In particular: JS: I'm not support what context we'd ever want to support this, since we go out of our way to try prevent XSS in HTML pastes. XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE bugs on a semi-regular basis. Daniel On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay o...@pettay.fi mailto:o...@pettay.fi wrote: On 06/09/2015 09:39 PM, Daniel Cheng wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg - image/gif If these types are supported, malicious web content can trivially write a malformed GIF/JPG/PNG to the clipboard and trigger code execution when pasting in a program with a vulnerable image decoder. This provides a trivial way to bypass the sandbox that web content is usually in. Given this, I'd like to propose that we remove the above formats from the list of mandatory data types, and avoid adding support for any more complex formats. Daniel [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1 Why would text/html, application/xhtml+xml, image/svg+xml, application/xml, text/xml, application/javascript be any safer if the program which the data is pasted to has vulnerable html/xml/js parsing? -Olli signature.asc Description: OpenPGP digital signature
Re: Clipboard API: remove dangerous formats from mandatory data types
On Tue, Jun 9, 2015 at 1:17 PM James M. Greene james.m.gre...@gmail.com wrote: Why we would exclude any data formats that the browsers currently already support copying today? Definitely not a fan of that idea offhand. Is it not possible for a malicious image to be displayed (or display as broken) in Chrome and allow a user to choose Copy Image from that element's context menu? See my earlier reply. If not, how is that protection/prevention achieved today? Could the same process to applied to outgoing copy/cut operations and incoming paste operations? Sincerely, James M. Greene Incoming paste isn't the problem, it's just outgoing copy/cut. Can an implementation really claim to support GIF/JPG/PNG if it has to decode it to a bitmap and then (potentially lossily) convert it back? Image encoding is not free either; Chrome has a very poor implementation today to expose image/png, and you'll find if you try to paste a very large bitmap (several dozen megapixels), the renderer will stop responding for a period of time. Daniel On Jun 9, 2015 2:19 PM, Daniel Cheng dch...@google.com wrote: I'm not against considering more formats to be dangerous. =) In particular: JS: I'm not support what context we'd ever want to support this, since we go out of our way to try prevent XSS in HTML pastes. XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE bugs on a semi-regular basis. Daniel On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay o...@pettay.fi wrote: On 06/09/2015 09:39 PM, Daniel Cheng wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg - image/gif If these types are supported, malicious web content can trivially write a malformed GIF/JPG/PNG to the clipboard and trigger code execution when pasting in a program with a vulnerable image decoder. This provides a trivial way to bypass the sandbox that web content is usually in. Given this, I'd like to propose that we remove the above formats from the list of mandatory data types, and avoid adding support for any more complex formats. Daniel [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1 Why would text/html, application/xhtml+xml, image/svg+xml, application/xml, text/xml, application/javascript be any safer if the program which the data is pasted to has vulnerable html/xml/js parsing? -Olli
Re: Clipboard API: remove dangerous formats from mandatory data types
On Tue, Jun 9, 2015 at 1:25 PM Paul Libbrecht p...@hoplahup.net wrote: Daniel, I understand now that the mistrust is about parsers that are even further and I understand it's an added risk. So the solution is to require that browsers that make known media-types in the clipboard actually parse it for its value? That sounds doable (and probably even useful: e.g. put other picture flavours in case of a pictures). Paul I don't think I understand what this means. Daniel On 9/06/15 22:20, Daniel Cheng wrote: On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht p...@hoplahup.net wrote: Daniel, this does not make sense to me. All these image parsers exploits can be triggered by an img tag, or? Similarly for XML using an XHR or some particular XML formats (RSS, SVG, XHTML, ...) in markup. Sure. That's why Chrome only decodes images in sandboxed processes like the renderer. There's absolutely no difference in the mistrust we should have between content brought by an HTML page and content brought by a JavaScript, or? Hence we should just not accept the reason of knowing of broken parsers to be a reason to change the standards! The difference is that copy image to clipboard never writes a GIF/JPG/PNG to the clipboard. The trusted browser process grabs the raw decoded bitmap from the renderer, validates the size information and some other stuff, and then writes it to the clipboard as a bitmap of the appropriate format. On the other hand, supporting this from JS means the untrusted renderer would get to control and place arbitrary GIF/JPG/PNG into the clipboard. It's not really feasible to do any corresponding validation that the data isn't bad. If, as a president, you need to decide to change the roads because a particular car was built massively and needs a particularirty of your roads, you would also find it nonsense, or? You're making me feel like France which did this for a particular type of trains which required to change all platforms because their ordered trains were already built too wide It's unfortunate, but I doubt any native apps attempt to securely decode images. Previously, it didn't matter, since the clipboard content came from other native apps, and if you can't trust other native apps, you're kind of hosed anyway. However, going from web content - native crosses a security boundary, which means these sort of issues need to be taken into consideration. Paul On 9/06/15 21:15, Daniel Cheng wrote: I'm not against considering more formats to be dangerous. =) In particular: JS: I'm not support what context we'd ever want to support this, since we go out of our way to try prevent XSS in HTML pastes. XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE bugs on a semi-regular basis. Daniel On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay o...@pettay.fi wrote: On 06/09/2015 09:39 PM, Daniel Cheng wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg - image/gif If these types are supported, malicious web content can trivially write a malformed GIF/JPG/PNG to the clipboard and trigger code execution when pasting in a program with a vulnerable image decoder. This provides a trivial way to bypass the sandbox that web content is usually in. Given this, I'd like to propose that we remove the above formats from the list of mandatory data types, and avoid adding support for any more complex formats. Daniel [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1 Why would text/html, application/xhtml+xml, image/svg+xml, application/xml, text/xml, application/javascript be any safer if the program which the data is pasted to has vulnerable html/xml/js parsing? -Olli
Re: Clipboard API: remove dangerous formats from mandatory data types
On 9/06/15 23:08, Daniel Cheng wrote: So the solution is to require that browsers that make known media-types in the clipboard actually parse it for its value? That sounds doable (and probably even useful: e.g. put other picture flavours in case of a pictures). I don't think I understand what this means. Since the browser is what would act on behalf of JS when putting a given data into the clipboard, it could check that this data is well formed and maybe matches the patterns of known exploits. paul signature.asc Description: OpenPGP digital signature
Re: Clipboard API: remove dangerous formats from mandatory data types
I'm not against considering more formats to be dangerous. =) In particular: JS: I'm not support what context we'd ever want to support this, since we go out of our way to try prevent XSS in HTML pastes. XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE bugs on a semi-regular basis. Daniel On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay o...@pettay.fi wrote: On 06/09/2015 09:39 PM, Daniel Cheng wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg - image/gif If these types are supported, malicious web content can trivially write a malformed GIF/JPG/PNG to the clipboard and trigger code execution when pasting in a program with a vulnerable image decoder. This provides a trivial way to bypass the sandbox that web content is usually in. Given this, I'd like to propose that we remove the above formats from the list of mandatory data types, and avoid adding support for any more complex formats. Daniel [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1 Why would text/html, application/xhtml+xml, image/svg+xml, application/xml, text/xml, application/javascript be any safer if the program which the data is pasted to has vulnerable html/xml/js parsing? -Olli
Re: Clipboard API: remove dangerous formats from mandatory data types
Daniel, I understand now that the mistrust is about parsers that are even further and I understand it's an added risk. So the solution is to require that browsers that make known media-types in the clipboard actually parse it for its value? That sounds doable (and probably even useful: e.g. put other picture flavours in case of a pictures). Paul On 9/06/15 22:20, Daniel Cheng wrote: On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht p...@hoplahup.net mailto:p...@hoplahup.net wrote: Daniel, this does not make sense to me. All these image parsers exploits can be triggered by an img tag, or? Similarly for XML using an XHR or some particular XML formats (RSS, SVG, XHTML, ...) in markup. Sure. That's why Chrome only decodes images in sandboxed processes like the renderer. There's absolutely no difference in the mistrust we should have between content brought by an HTML page and content brought by a JavaScript, or? Hence we should just not accept the reason of knowing of broken parsers to be a reason to change the standards! The difference is that copy image to clipboard never writes a GIF/JPG/PNG to the clipboard. The trusted browser process grabs the raw decoded bitmap from the renderer, validates the size information and some other stuff, and then writes it to the clipboard as a bitmap of the appropriate format. On the other hand, supporting this from JS means the untrusted renderer would get to control and place arbitrary GIF/JPG/PNG into the clipboard. It's not really feasible to do any corresponding validation that the data isn't bad. If, as a president, you need to decide to change the roads because a particular car was built massively and needs a particularirty of your roads, you would also find it nonsense, or? You're making me feel like France which did this for a particular type of trains which required to change all platforms because their ordered trains were already built too wide It's unfortunate, but I doubt any native apps attempt to securely decode images. Previously, it didn't matter, since the clipboard content came from other native apps, and if you can't trust other native apps, you're kind of hosed anyway. However, going from web content - native crosses a security boundary, which means these sort of issues need to be taken into consideration. Paul On 9/06/15 21:15, Daniel Cheng wrote: I'm not against considering more formats to be dangerous. =) In particular: JS: I'm not support what context we'd ever want to support this, since we go out of our way to try prevent XSS in HTML pastes. XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE bugs on a semi-regular basis. Daniel On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay o...@pettay.fi mailto:o...@pettay.fi wrote: On 06/09/2015 09:39 PM, Daniel Cheng wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg - image/gif If these types are supported, malicious web content can trivially write a malformed GIF/JPG/PNG to the clipboard and trigger code execution when pasting in a program with a vulnerable image decoder. This provides a trivial way to bypass the sandbox that web content is usually in. Given this, I'd like to propose that we remove the above formats from the list of mandatory data types, and avoid adding support for any more complex formats. Daniel [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1 Why would text/html, application/xhtml+xml, image/svg+xml, application/xml, text/xml, application/javascript be any safer if the program which the data is pasted to has vulnerable html/xml/js parsing? -Olli signature.asc Description: OpenPGP digital signature
[Bug 25494] What is the status of UI Events document?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25494 Gary Kacmarcik gary...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Gary Kacmarcik gary...@google.com --- The old UI events spec (which was rather tiny) has been set aside and the previous DOM3 events spec was renamed to UI Events. We did this because UI Events is a more appropriate name and we wanted to avoid (long-term) confusion. We'll be merging some of the old UI Events stuff back into the new UI Events as appropriate. The current UI Events (formerly DOM3 Events) ss at: https://w3c.github.io/uievents/ -- You are receiving this mail because: You are on the CC list for the bug.
Re: Clipboard API: remove dangerous formats from mandatory data types
The browser could copy a terminal command to wipe the disk, and the user could run it. Or copy a URL to a web page that has a known security exploit, and then the user pastes it in to the address bar. Maybe we shouldn't allow copying anything at all? Actually I think this is just security by paranoia. If pasting corrupt images in to another app is enough of a problem to warrant concern, that app should be fixed, rather than hobble the browser. On 9 Jun 2015 21:23, Daniel Cheng dch...@google.com wrote: On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht p...@hoplahup.net wrote: Daniel, this does not make sense to me. All these image parsers exploits can be triggered by an img tag, or? Similarly for XML using an XHR or some particular XML formats (RSS, SVG, XHTML, ...) in markup. Sure. That's why Chrome only decodes images in sandboxed processes like the renderer. There's absolutely no difference in the mistrust we should have between content brought by an HTML page and content brought by a JavaScript, or? Hence we should just not accept the reason of knowing of broken parsers to be a reason to change the standards! The difference is that copy image to clipboard never writes a GIF/JPG/PNG to the clipboard. The trusted browser process grabs the raw decoded bitmap from the renderer, validates the size information and some other stuff, and then writes it to the clipboard as a bitmap of the appropriate format. On the other hand, supporting this from JS means the untrusted renderer would get to control and place arbitrary GIF/JPG/PNG into the clipboard. It's not really feasible to do any corresponding validation that the data isn't bad. If, as a president, you need to decide to change the roads because a particular car was built massively and needs a particularirty of your roads, you would also find it nonsense, or? You're making me feel like France which did this for a particular type of trains which required to change all platforms because their ordered trains were already built too wide It's unfortunate, but I doubt any native apps attempt to securely decode images. Previously, it didn't matter, since the clipboard content came from other native apps, and if you can't trust other native apps, you're kind of hosed anyway. However, going from web content - native crosses a security boundary, which means these sort of issues need to be taken into consideration. Paul On 9/06/15 21:15, Daniel Cheng wrote: I'm not against considering more formats to be dangerous. =) In particular: JS: I'm not support what context we'd ever want to support this, since we go out of our way to try prevent XSS in HTML pastes. XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE bugs on a semi-regular basis. Daniel On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay o...@pettay.fi wrote: On 06/09/2015 09:39 PM, Daniel Cheng wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg - image/gif If these types are supported, malicious web content can trivially write a malformed GIF/JPG/PNG to the clipboard and trigger code execution when pasting in a program with a vulnerable image decoder. This provides a trivial way to bypass the sandbox that web content is usually in. Given this, I'd like to propose that we remove the above formats from the list of mandatory data types, and avoid adding support for any more complex formats. Daniel [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1 Why would text/html, application/xhtml+xml, image/svg+xml, application/xml, text/xml, application/javascript be any safer if the program which the data is pasted to has vulnerable html/xml/js parsing? -Olli
Re: Clipboard API: remove dangerous formats from mandatory data types
IIUC that approach won't help, because the problem here is not necessarily invalid/malformed data, but even valid data that some decoders fail to handle gracefully. On 9 June 2015 at 14:13, Paul Libbrecht p...@hoplahup.net wrote: On 9/06/15 23:08, Daniel Cheng wrote: So the solution is to require that browsers that make known media-types in the clipboard actually parse it for its value? That sounds doable (and probably even useful: e.g. put other picture flavours in case of a pictures). I don't think I understand what this means. Since the browser is what would act on behalf of JS when putting a given data into the clipboard, it could check that this data is well formed and maybe matches the patterns of known exploits. paul
Re: Clipboard API: remove dangerous formats from mandatory data types
But then it goes even further with just about any type for which broken parsers exists. HTML is certainly a good example since its very diversely implemented. An application that lives on a desktop and fails on some images would be exposing its user if the user downloads a content and opens it with the application. Is the difference that the browser warns the user that the picture has been downloaded? I've never seen a warning about a downloaded picture. Paul On 9/06/15 23:25, Wez wrote: IIUC that approach won't help, because the problem here is not necessarily invalid/malformed data, but even valid data that some decoders fail to handle gracefully. On 9 June 2015 at 14:13, Paul Libbrecht p...@hoplahup.net mailto:p...@hoplahup.net wrote: On 9/06/15 23:08, Daniel Cheng wrote: So the solution is to require that browsers that make known media-types in the clipboard actually parse it for its value? That sounds doable (and probably even useful: e.g. put other picture flavours in case of a pictures). I don't think I understand what this means. Since the browser is what would act on behalf of JS when putting a given data into the clipboard, it could check that this data is well formed and maybe matches the patterns of known exploits. paul signature.asc Description: OpenPGP digital signature
