Re: Clipboard API: remove dangerous formats from mandatory data types
On Tue, 28 Jul 2015 08:24:17 -0400, Hallvord Reiar Michaelsen Steen wrote: On Tue, Jul 28, 2015 at 1:08 PM, Chaals McCathie Nevile < cha...@yandex-team.ru> wrote: I'm just thinking out loud here, but this problem is similar to one already faced by email clients, especially those which are web-based... On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen < hst...@mozilla.com> wrote: So PNG, JPG et al go in the "support reading from clipboard" list, and the "support writing" starts out with text/plain, text/html and text/uri-list - although it would be nice if CSV was also considered safe enough. I'm not sure you should directly read image formats from the clipboard, especially if you don't know how they got there. What are your concerns exactly? As Wez mentioned we may have to add some transcoding - but if there's a chunk of binary data labelled as JPEG on the clipboard, and the user wants to paste this into her blog editor, how would we do that if web content "shouldn't" read image formats from the clipboard? Essentially only certain things would be delivered from the clipboard - a picture in the desired format, and hopefully a certain amount of metadata. But we would be pretty explicit that unexpected stuff may well be dropped - and probably *should* in various cases like images (I think we might actually agree in practice, and be looking for words) cheers You shouldn't write stuff there that can be dangerous, but you really shouldn't read it direct. So maybe what happens is that when stuff gets written, it goes through a process like painting it onto a canvas, and then being scraped back off as coloured pixels and "safe" metadata. Indeed, if that's what it takes.. like the addImageFromCanvas() suggestion below. Regarding that suggestion you asked: Is it more than syntactic sugar? If we allow adding image data as blobs, the "normal" way with clipboardData.items.add() it would be just a convenience method. Since Daniel Cheng has serious concerns and good arguments against allowing that, something like addImageFromCanvas() might be a workaround that would let users put images on the clipboard in a safe way.. If we have neither, I guess we'll see data:image/jpeg URLs placed on the clipboard as plain text. -Hallvord R. -- Using Opera's mail client: http://www.opera.com/mail/
Re: Clipboard API: remove dangerous formats from mandatory data types
On Tue, Jul 28, 2015 at 1:08 PM, Chaals McCathie Nevile < cha...@yandex-team.ru> wrote: > I'm just thinking out loud here, but this problem is similar to one > already faced by email clients, especially those which are web-based... > > On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen < > hst...@mozilla.com> wrote: > > So PNG, JPG et al go in the "support >> reading from clipboard" list, and the "support writing" starts out with >> text/plain, text/html and text/uri-list - although it would be nice if >> CSV was also considered safe enough. >> > > I'm not sure you should directly read image formats from the clipboard, > especially if you don't know how they got there. What are your concerns exactly? As Wez mentioned we may have to add some transcoding - but if there's a chunk of binary data labelled as JPEG on the clipboard, and the user wants to paste this into her blog editor, how would we do that if web content "shouldn't" read image formats from the clipboard? > You shouldn't write stuff there that can be dangerous, but you really > shouldn't read it direct. So maybe what happens is that when stuff gets > written, it goes through a process like painting it onto a canvas, and then > being scraped back off as coloured pixels and "safe" metadata. > Indeed, if that's what it takes.. like the addImageFromCanvas() suggestion below. Regarding that suggestion you asked: > Is it more than syntactic sugar? > > If we allow adding image data as blobs, the "normal" way with clipboardData.items.add() it would be just a convenience method. Since Daniel Cheng has serious concerns and good arguments against allowing that, something like addImageFromCanvas() might be a workaround that would let users put images on the clipboard in a safe way.. If we have neither, I guess we'll see data:image/jpeg URLs placed on the clipboard as plain text. -Hallvord R.
Re: Clipboard API: remove dangerous formats from mandatory data types
I'm just thinking out loud here, but this problem is similar to one already faced by email clients, especially those which are web-based... On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen wrote: On Tue, Jun 9, 2015 at 8: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 Hi Daniel, I've been pondering this a bit and I think a first step is to split the list of "mandatory data types" into two: one list for types you must support reading from the clipboard, and one (smaller) for types you must support writing to the clipboard. So PNG, JPG et al go in the "support reading from clipboard" list, and the "support writing" starts out with text/plain, text/html and text/uri-list - although it would be nice if CSV was also considered safe enough. I'm not sure you should directly read image formats from the clipboard, especially if you don't know how they got there. You shouldn't write stuff there that can be dangerous, but you really shouldn't read it direct. So maybe what happens is that when stuff gets written, it goes through a process like painting it onto a canvas, and then being scraped back off as coloured pixels and "safe" metadata. A use case for the latter is the fabled "embedded accessibility" that could have made longdesc obsolete in 1997 - although the more likely use case for most people is getting the right geospying in their photo stream, and proving to the world that their camera clock flashes like a video player from 1987. So essentially we don't restrict what is in the clipboard, but we do put restrictions on what we will take out, and if you want to be well-behaved you would follow those restrictions before you put anything there. Can we safely implement a clean/dirty flag similar to canvas, to help avoid double-sanitizing? Is that worth worrying about? It would also be good if we could come up with an API for safely writing images to the clipboard. Just playing: event.clipboardData.addImageFromCanvas(canvasElm, 'image/png') Hot or not? Safely DrawMeA(sheep) is certainly worth pondering. Is it more than syntactic sugar? cheers -- Using Opera's mail client: http://www.opera.com/mail/
[Bug 28614] Weaken the requirement of the time of running async steps
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28614 Bug 28614 depends on bug 26440, which changed state. Bug 26440 Summary: Allow fullscreenchange events to be synchronized with animation frames https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 16502] Define multiple monitor support and per-subdomain
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16502 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #7 from Anne --- Closing this in favor of that. Perhaps once there are primitives for other monitors we can solve this better, but I don't plan on pioneering that. If you have the resources and want to solve this, do let me know and I'll help you out. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27674] requestFullscreen should return a promise
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27674 Bug 27674 depends on bug 26440, which changed state. Bug 26440 Summary: Allow fullscreenchange events to be synchronized with animation frames https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26516] Make resize events etc to be synchronized with animation frames
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26516 Bug 26516 depends on bug 26440, which changed state. Bug 26440 Summary: Allow fullscreenchange events to be synchronized with animation frames https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26440] Allow fullscreenchange events to be synchronized with animation frames
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #29 from Anne --- Let's close this in favor of https://github.com/whatwg/fullscreen/issues/16 Any new issues should be filed on GitHub. -- You are receiving this mail because: You are on the CC list for the bug.
