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
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
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
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
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
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
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
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.
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
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
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
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
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'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
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25494
Gary Kacmarcik gary...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
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
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
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
19 matches
Mail list logo
