[Bug 25494] What is the status of UI Events document?

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25494

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Gary Kacmarcik  ---
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

[Ashley Gullen]

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"  wrote:

> On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht  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  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

[Paul Libbrecht]

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  > 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

Re: Clipboard API: remove dangerous formats from mandatory data types

[Wez]

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  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

[Paul Libbrecht]

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

[Daniel Cheng]

On Tue, Jun 9, 2015 at 1:25 PM Paul Libbrecht  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  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  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 Cheng]

On Tue, Jun 9, 2015 at 1:17 PM James M. Greene 
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"  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  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

[Paul Libbrecht]

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  > 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 > > 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

[Daniel Cheng]

On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht  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  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

[James M. Greene]

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"  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  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

[Paul Libbrecht]

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  > 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

[Daniel Cheng]

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  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

[Olli Pettay]

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

Clipboard API: remove dangerous formats from mandatory data types

[Daniel Cheng]

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: Custom Elements: is=""

[Alice Boxhall]

On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren  wrote:

> On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall 
> 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 al

Re: Custom Elements: is=""

[Justin Fagnani]

On Jun 9, 2015 8:45 AM, "Dimitri Glazkov"  wrote:
>
> On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren 
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  and 

Re: Custom Elements: is=""

[Dimitri Glazkov]

On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren  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=""

[Anne van Kesteren]

On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall  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=""

[Anne van Kesteren]

On Mon, Jun 8, 2015 at 11:48 PM, Justin Fagnani
 wrote:
> And I'm still concerned that removing is= would severely harm the cases
> where you need access to special parsing behavior like  and
>