Re: Clipboard API: remove dangerous formats from mandatory data types
Sorry Florian, but I don't see what that has to do with whether or not the Clipboard Events spec mandates that web content can generate their own JPEG or PNG and place it directly on the local system clipboard. What is it that you're actually proposing? On Thu, 25 Jun 2015 at 13:31 Florian Bösch pya...@gmail.com wrote: No idea. Also doesn't matter jack. There could be some now or in the future. There's a variety of programs that support HDRi (photoshop, lightroom, hdri-studio, etc.). It's fairly logical that at some point some or another variant of HDR format will make its way into clipboards. The same applies to pretty much any other data format be that a file or something else.
Re: Clipboard API: remove dangerous formats from mandatory data types
On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard (as opposed to letting an app just put any bytes there), the UA has to understand OpenEXR. Since I don't see how the UA can understand every conceivable format in existence both future and past, I don't see how that should work.
Re: Clipboard API: remove dangerous formats from mandatory data types
Or should we just place that into application/octet-stream and hope whoever listens for the clipboard scans the magic bytes of an OpenEXR? On Thu, Jun 25, 2015 at 2:56 PM, Florian Bösch pya...@gmail.com wrote: Well let's say some webapp generates an OpenEXR and wants to put it into the clipboard as image/x-exr which would make sense cause any eventual program that'd support OpenEXR would probably look for that mime type. You've said you're going to restrict image types to jpeg, png and gif, and so my question is, how exactly do you intend to support OpenEXR? On Thu, Jun 25, 2015 at 2:51 PM, Wez w...@google.com wrote: Sorry Florian, but I don't see what that has to do with whether or not the Clipboard Events spec mandates that web content can generate their own JPEG or PNG and place it directly on the local system clipboard. What is it that you're actually proposing? On Thu, 25 Jun 2015 at 13:31 Florian Bösch pya...@gmail.com wrote: No idea. Also doesn't matter jack. There could be some now or in the future. There's a variety of programs that support HDRi (photoshop, lightroom, hdri-studio, etc.). It's fairly logical that at some point some or another variant of HDR format will make its way into clipboards. The same applies to pretty much any other data format be that a file or something else.
Re: Clipboard API: remove dangerous formats from mandatory data types
And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard (as opposed to letting an app just put any bytes there), the UA has to understand OpenEXR. Since I don't see how the UA can understand every conceivable format in existence both future and past, I don't see how that should work.
Re: Clipboard API: remove dangerous formats from mandatory data types
Which user agents currently allow content to post OpenEXR to the local clipboard? On Wed, 24 Jun 2015 at 19:58 Florian Bösch pya...@gmail.com wrote: No, but the specification doesn't require you to exclude it. So how're applications going to swap OpenEXR if you only let em stick in jpegs, pngs and gifs? On Wed, Jun 24, 2015 at 8:46 PM, Wez w...@google.com wrote: I don't think OpenEXR is one of the formats required by the Clipboard Events spec, is it..? On Wed, Jun 24, 2015, 18:49 Florian Bösch pya...@gmail.com wrote: And how exactly do you intend to support for instance OpenEXR? On Wed, Jun 24, 2015 at 5:44 PM, Wez w...@google.com wrote: Hallvord, Yes, content would be limited to providing text, image etc data to the user agent to place on the clipboard, and letting the user agent synthesize whatever formats (JPEG, PNG etc) other apps require. That has the advantage of preventing malicious content using esoteric flags or features to compromise recipients, but conversely means that legitimate content cannot use format-specific features, e.g. content would not be able to write a JPEG containing a comment block, geo tags or timestamp information. Wez On Sat, 13 Jun 2015 at 11:57 Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: On Thu, Jun 11, 2015 at 7:51 PM, Wez w...@google.com wrote: Hallvord, The proposal isn't to remove support for copying/pasting images, but to restrict web content from placing compressed image data in one of these formats on the clipboard directly - there's no issue with content pasting raw pixels from a canvas, for example, since scope for abusing that to compromise the recipient is extremely limited by comparison to JPEG, PNG or GIF. Well, but as far as I can tell we don't currently *have* a way JS can place pixels from a canvas on the clipboard (except by putting a piece of data labelled as image/png or similar there). So if you're pushing back against the idea that JS can place random data on the clipboard and label it image/png, how exactly would you propose JS-triggered copy of image data to work? Say, from a CANVAS-based image editor? -Hallvord
Re: Clipboard API: remove dangerous formats from mandatory data types
No idea. Also doesn't matter jack. There could be some now or in the future. There's a variety of programs that support HDRi (photoshop, lightroom, hdri-studio, etc.). It's fairly logical that at some point some or another variant of HDR format will make its way into clipboards. The same applies to pretty much any other data format be that a file or something else.
Re: Clipboard API: remove dangerous formats from mandatory data types
On Thu, Jun 25, 2015 at 2:58 PM, Florian Bösch pya...@gmail.com wrote: the magic bytes of an OpenEXR? Which is 0x762f3101 btw.
Re: Async Image - ImageData conversion
On Thu, Jun 25, 2015 at 9:40 AM, Justin Novosad ju...@google.com wrote: On Thu, Jun 25, 2015 at 5:56 AM, Ashley Gullen ash...@scirra.com wrote: I see that OffscreenCanvas also specifies a close() method for ImageBitmap. Perhaps browsers could use copy-on-write with the toImageData() method? Then you can efficiently either transfer or copy depending on if you close the ImageBitmap you transferred to an ImageData. Transfer: createImageBitmap() - imageBitmap.toImageData() - imageBitmap.close() No copy made, contents transferred to the imageData createImageBitmap() - imageBitmap.toImageData() - access resulting imageData.data Copy made on first access Copy on write is probably not a good idea because it would require injecting an observer pattern (or some kind of notification mechanism) into Uint8ClampedArray data assignment, which would realistically degrade performance of Image processing pixel loops. Having a one step transfer API (transferToImageData) avoids adding overhead to what is otherwise just a simple memory access. Something more: Blink, and probably other implementations as well, stores decoded images in alpha pre-multiplied form. ImageData is not pre-multiplied. For this reason sharing a buffer between ImageBitmap and ImageData would be somewhat inconvenient. On 24 June 2015 at 21:54, Kenneth Russell k...@google.com wrote: On Wed, Jun 24, 2015 at 1:28 PM, Ashley Gullen ash...@scirra.com wrote: Sorry for the confusion. Yes, the latest URL is: https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html I'm new to specs and WebIDL, my intent was to say those are new methods on ImageBitmap. Is partial interface ImageBitmap the correct way to say that? (I updated the URL to say that instead) The wording of undue latency in the ImageBitmap spec does not appear to rule out ImageBitmap storing its encoded image data, and lazily decoding it. However I'm not sure what the point of that would be, since it seems to be how drawing HTMLImageElements to a canvas already works. I see a couple of options: - allow lazy decoding in ImageBitmap, and therefore converting to ImageData is an explicit request to decompress - require ImageBitmap to decompress its contents, and make it available through a read-only Uint8ClampedArray like ImageData has. Therefore, converting to ImageData indicates the intent to modify this content, therefore a copy is warranted. - provide a way to neuter the ImageBitmap when converting it to ImageData, transferring its contents and avoiding any copy, which is useful if the ImageBitmap is a temporary object only being created for the purposes of getting the ImageData. I guess this would be similar to transferrable objects with workers. Perhaps this could be done by specifying a transferToImageData method. This proposal makes ImageBitmap neuterable, and there's intent to implement it in order to allow rendering to canvas contexts from worker threads: https://wiki.whatwg.org/wiki/OffscreenCanvas . -Ken - add some kind of load method on ImageBitmap. It may store its contents in compressed form, but calling load causes it to be decompressed (or loaded from somewhere else). The ImageBitmap is only guaranteed to be drawn with undue latency after the load call. Therefore for the use case of low-latency rendering load can always be called immediately after creation, but for conversion purposes not calling load avoids duplicating memory. Note for devices with discrete GPUs, it's possible that ImageBitmap stores the decompressed image data in a GPU texture but does not have it in system RAM. In this case making a copy for the ImageData is also warranted. I'm a web developer proposing this because it would be useful for my purposes, I've no idea which of these would be favoured by implementors or the spec process. I'm happy to get involved in spec work though so please let me know if you have any feedback/suggestions on anything I'm doing here. Ashley On 24 June 2015 at 19:12, Boris Zbarsky bzbar...@mit.edu wrote: On 6/19/15 5:43 AM, Ashley Gullen wrote: I've not done this before, so I've no idea if this is the right/useful approach, but I drafted a spec for it here: https://www.scirra.com/labs/specs/imagedata-blob-extensions.html Ashley, We at Mozilla were just discussing this proposal, and we have a concern. With this proposal, going from an img to an ImageData requires conversion of an intermediate ImageBitmap. Unfortunately, an ImageBitmap is specified to be paintable without undue latency, which we interpret to mean it needs to have decoded image data, and the ImageData will end up needing to copy said data in practice (because it needs an editable copy). That creates two copies of the decoded image data in memory, which seems fairly undesirable on memory-constrained devices.
Re: Clipboard API: remove dangerous formats from mandatory data types
Well let's say some webapp generates an OpenEXR and wants to put it into the clipboard as image/x-exr which would make sense cause any eventual program that'd support OpenEXR would probably look for that mime type. You've said you're going to restrict image types to jpeg, png and gif, and so my question is, how exactly do you intend to support OpenEXR? On Thu, Jun 25, 2015 at 2:51 PM, Wez w...@google.com wrote: Sorry Florian, but I don't see what that has to do with whether or not the Clipboard Events spec mandates that web content can generate their own JPEG or PNG and place it directly on the local system clipboard. What is it that you're actually proposing? On Thu, 25 Jun 2015 at 13:31 Florian Bösch pya...@gmail.com wrote: No idea. Also doesn't matter jack. There could be some now or in the future. There's a variety of programs that support HDRi (photoshop, lightroom, hdri-studio, etc.). It's fairly logical that at some point some or another variant of HDR format will make its way into clipboards. The same applies to pretty much any other data format be that a file or something else.
Re: Async Image - ImageData conversion
On Thu, Jun 25, 2015 at 5:56 AM, Ashley Gullen ash...@scirra.com wrote: I see that OffscreenCanvas also specifies a close() method for ImageBitmap. Perhaps browsers could use copy-on-write with the toImageData() method? Then you can efficiently either transfer or copy depending on if you close the ImageBitmap you transferred to an ImageData. Transfer: createImageBitmap() - imageBitmap.toImageData() - imageBitmap.close() No copy made, contents transferred to the imageData createImageBitmap() - imageBitmap.toImageData() - access resulting imageData.data Copy made on first access Copy on write is probably not a good idea because it would require injecting an observer pattern (or some kind of notification mechanism) into Uint8ClampedArray data assignment, which would realistically degrade performance of Image processing pixel loops. Having a one step transfer API (transferToImageData) avoids adding overhead to what is otherwise just a simple memory access. On 24 June 2015 at 21:54, Kenneth Russell k...@google.com wrote: On Wed, Jun 24, 2015 at 1:28 PM, Ashley Gullen ash...@scirra.com wrote: Sorry for the confusion. Yes, the latest URL is: https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html I'm new to specs and WebIDL, my intent was to say those are new methods on ImageBitmap. Is partial interface ImageBitmap the correct way to say that? (I updated the URL to say that instead) The wording of undue latency in the ImageBitmap spec does not appear to rule out ImageBitmap storing its encoded image data, and lazily decoding it. However I'm not sure what the point of that would be, since it seems to be how drawing HTMLImageElements to a canvas already works. I see a couple of options: - allow lazy decoding in ImageBitmap, and therefore converting to ImageData is an explicit request to decompress - require ImageBitmap to decompress its contents, and make it available through a read-only Uint8ClampedArray like ImageData has. Therefore, converting to ImageData indicates the intent to modify this content, therefore a copy is warranted. - provide a way to neuter the ImageBitmap when converting it to ImageData, transferring its contents and avoiding any copy, which is useful if the ImageBitmap is a temporary object only being created for the purposes of getting the ImageData. I guess this would be similar to transferrable objects with workers. Perhaps this could be done by specifying a transferToImageData method. This proposal makes ImageBitmap neuterable, and there's intent to implement it in order to allow rendering to canvas contexts from worker threads: https://wiki.whatwg.org/wiki/OffscreenCanvas . -Ken - add some kind of load method on ImageBitmap. It may store its contents in compressed form, but calling load causes it to be decompressed (or loaded from somewhere else). The ImageBitmap is only guaranteed to be drawn with undue latency after the load call. Therefore for the use case of low-latency rendering load can always be called immediately after creation, but for conversion purposes not calling load avoids duplicating memory. Note for devices with discrete GPUs, it's possible that ImageBitmap stores the decompressed image data in a GPU texture but does not have it in system RAM. In this case making a copy for the ImageData is also warranted. I'm a web developer proposing this because it would be useful for my purposes, I've no idea which of these would be favoured by implementors or the spec process. I'm happy to get involved in spec work though so please let me know if you have any feedback/suggestions on anything I'm doing here. Ashley On 24 June 2015 at 19:12, Boris Zbarsky bzbar...@mit.edu wrote: On 6/19/15 5:43 AM, Ashley Gullen wrote: I've not done this before, so I've no idea if this is the right/useful approach, but I drafted a spec for it here: https://www.scirra.com/labs/specs/imagedata-blob-extensions.html Ashley, We at Mozilla were just discussing this proposal, and we have a concern. With this proposal, going from an img to an ImageData requires conversion of an intermediate ImageBitmap. Unfortunately, an ImageBitmap is specified to be paintable without undue latency, which we interpret to mean it needs to have decoded image data, and the ImageData will end up needing to copy said data in practice (because it needs an editable copy). That creates two copies of the decoded image data in memory, which seems fairly undesirable on memory-constrained devices. -Boris
Re: Clipboard API: remove dangerous formats from mandatory data types
I don't believe I've said any such thing re jpeg, png and gif... quite the opposite, in fact. The point of this thread is that the spec currently *requires* user agents allow content to supply JPEG, PNG or GIF data directly *to the local clipboard*, which is risky. We're therefore proposing to remove that requirement - content can still supply images to the clipboard and the user agent can still synthesize whatever formats it chooses to. Whether or not user agents support web content setting other arbitrary content types (such as OpenEXR) to the local system clipboard is a separate question - there's nothing in the spec mandating that user agents support it, nor mandating that they don't - at present each user agent can choose whether or not to support arbitrary formats. I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. HTH, Wez On Thu, 25 Jun 2015 at 13:56 Florian Bösch pya...@gmail.com wrote: Well let's say some webapp generates an OpenEXR and wants to put it into the clipboard as image/x-exr which would make sense cause any eventual program that'd support OpenEXR would probably look for that mime type. You've said you're going to restrict image types to jpeg, png and gif, and so my question is, how exactly do you intend to support OpenEXR? On Thu, Jun 25, 2015 at 2:51 PM, Wez w...@google.com wrote: Sorry Florian, but I don't see what that has to do with whether or not the Clipboard Events spec mandates that web content can generate their own JPEG or PNG and place it directly on the local system clipboard. What is it that you're actually proposing? On Thu, 25 Jun 2015 at 13:31 Florian Bösch pya...@gmail.com wrote: No idea. Also doesn't matter jack. There could be some now or in the future. There's a variety of programs that support HDRi (photoshop, lightroom, hdri-studio, etc.). It's fairly logical that at some point some or another variant of HDR format will make its way into clipboards. The same applies to pretty much any other data format be that a file or something else.
Re: Async Image - ImageData conversion
I see that OffscreenCanvas also specifies a close() method for ImageBitmap. Perhaps browsers could use copy-on-write with the toImageData() method? Then you can efficiently either transfer or copy depending on if you close the ImageBitmap you transferred to an ImageData. Transfer: createImageBitmap() - imageBitmap.toImageData() - imageBitmap.close() No copy made, contents transferred to the imageData createImageBitmap() - imageBitmap.toImageData() - access resulting imageData.data Copy made on first access On 24 June 2015 at 21:54, Kenneth Russell k...@google.com wrote: On Wed, Jun 24, 2015 at 1:28 PM, Ashley Gullen ash...@scirra.com wrote: Sorry for the confusion. Yes, the latest URL is: https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html I'm new to specs and WebIDL, my intent was to say those are new methods on ImageBitmap. Is partial interface ImageBitmap the correct way to say that? (I updated the URL to say that instead) The wording of undue latency in the ImageBitmap spec does not appear to rule out ImageBitmap storing its encoded image data, and lazily decoding it. However I'm not sure what the point of that would be, since it seems to be how drawing HTMLImageElements to a canvas already works. I see a couple of options: - allow lazy decoding in ImageBitmap, and therefore converting to ImageData is an explicit request to decompress - require ImageBitmap to decompress its contents, and make it available through a read-only Uint8ClampedArray like ImageData has. Therefore, converting to ImageData indicates the intent to modify this content, therefore a copy is warranted. - provide a way to neuter the ImageBitmap when converting it to ImageData, transferring its contents and avoiding any copy, which is useful if the ImageBitmap is a temporary object only being created for the purposes of getting the ImageData. I guess this would be similar to transferrable objects with workers. Perhaps this could be done by specifying a transferToImageData method. This proposal makes ImageBitmap neuterable, and there's intent to implement it in order to allow rendering to canvas contexts from worker threads: https://wiki.whatwg.org/wiki/OffscreenCanvas . -Ken - add some kind of load method on ImageBitmap. It may store its contents in compressed form, but calling load causes it to be decompressed (or loaded from somewhere else). The ImageBitmap is only guaranteed to be drawn with undue latency after the load call. Therefore for the use case of low-latency rendering load can always be called immediately after creation, but for conversion purposes not calling load avoids duplicating memory. Note for devices with discrete GPUs, it's possible that ImageBitmap stores the decompressed image data in a GPU texture but does not have it in system RAM. In this case making a copy for the ImageData is also warranted. I'm a web developer proposing this because it would be useful for my purposes, I've no idea which of these would be favoured by implementors or the spec process. I'm happy to get involved in spec work though so please let me know if you have any feedback/suggestions on anything I'm doing here. Ashley On 24 June 2015 at 19:12, Boris Zbarsky bzbar...@mit.edu wrote: On 6/19/15 5:43 AM, Ashley Gullen wrote: I've not done this before, so I've no idea if this is the right/useful approach, but I drafted a spec for it here: https://www.scirra.com/labs/specs/imagedata-blob-extensions.html Ashley, We at Mozilla were just discussing this proposal, and we have a concern. With this proposal, going from an img to an ImageData requires conversion of an intermediate ImageBitmap. Unfortunately, an ImageBitmap is specified to be paintable without undue latency, which we interpret to mean it needs to have decoded image data, and the ImageData will end up needing to copy said data in practice (because it needs an editable copy). That creates two copies of the decoded image data in memory, which seems fairly undesirable on memory-constrained devices. -Boris
Re: Async Image - ImageData conversion
On 6/24/15 1:28 PM, Ashley Gullen wrote: I'm new to specs and WebIDL, my intent was to say those are new methods on ImageBitmap. Is partial interface ImageBitmap the correct way to say that? Yes, it is. The wording of undue latency in the ImageBitmap spec does not appear to rule out ImageBitmap storing its encoded image data, and lazily decoding it. Decoding can easily take hundreds of milliseconds. It definitely constitutes undue latency from our point of view. - require ImageBitmap to decompress its contents, and make it available through a read-only Uint8ClampedArray like ImageData has. This has the premultiplied vs non-premultiplied problem Justin points out. - provide a way to neuter the ImageBitmap when converting it to ImageData, transferring its contents and avoiding any copy, which is useful if the ImageBitmap is a temporary object only being created for the purposes of getting the ImageData. I guess this would be similar to transferrable objects with workers. This would be a viable option. Another option is to add toBlob/toImageData directly to HTMLImageElement and the other things we want it on, in addition to having them on ImageBitmap. Then you wouldn't need to go through an ImageBitmap at all. Note for devices with discrete GPUs, it's possible that ImageBitmap stores the decompressed image data in a GPU texture but does not have it in system RAM. Indeed. This is another situation where going directly from an HTMLImageElement to an ImageData or Blob would make some sense, because it would allow the UA to avoid the GPU upload and readback, right? The drawback of adding toBlob/toImageData to the various things ImageData can be constructed from is that it's a bit more spec complexity, but I don't see that as a showstopper, necessarily. -Boris
Re: Async Image - ImageData conversion
On Thu, Jun 25, 2015 at 1:57 PM, Boris Zbarsky bzbar...@mit.edu wrote: The drawback of adding toBlob/toImageData to the various things ImageData can be constructed from is that it's a bit more spec complexity, but I don't see that as a showstopper, necessarily. We should probably stick to the pattern of either having factory methods or putting methods directly on various objects. Or maybe, change them all to be static methods on the various classes: ImageBitmap.create(...) ImageData.create(...) ... I would personally prefer this last pattern for creating instances where we need to go through a promise. -- https://annevankesteren.nl/
Re: Clipboard API: remove dangerous formats from mandatory data types
Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard (as opposed to letting an app just put any bytes there), the UA has to understand OpenEXR. Since I don't see how the UA can understand every conceivable format in existence both future and past, I don't see how that should work.
Re: Clipboard API: remove dangerous formats from mandatory data types
Browsers are very visible applications. Most other applications in existence tend to work around their foibles in one fashion or another. If Browsers where to sprout another such foible as to force people to discard mime-type specification for content because browsers don't let them, it would give rise to widely confusing and homebrewn workarounds till out of that broil another mime-type standard emerged that browsers sought to repress. On Thu, Jun 25, 2015 at 4:30 PM, Florian Bösch pya...@gmail.com wrote: I'm pretty sure it can't be in the interest of this specification to force application authors to bifurcate the mime-type into one that can't be used reliably, and another informal one that's prepended to the octet-stream. Relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:27 PM, Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard (as opposed to letting an app just put any bytes there), the UA has to understand OpenEXR. Since I don't see how the UA can understand every conceivable format in existence both future and past, I don't see how that should work.
Re: Clipboard API: remove dangerous formats from mandatory data types
You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard (as opposed to letting an app just put any bytes there), the UA has to understand OpenEXR. Since I don't see how the UA can understand every conceivable format in existence both future and past, I don't see how that should work.
Re: Clipboard API: remove dangerous formats from mandatory data types
It's very simple. Applications need to know what's in the clipboard to know what to do with it. There is also a vast variety of things that could find itself in the clipboard in terms of formats, both formal and informal. Mime types are one of these things that applications would use to do that. If a UA where to restict what mime type you can put into the clipboard, that forces the clipboard user to use application/octet-stream. And in consequence, that forces any such-willing application to forgoe the mime-type information from the OS'es clipboard API and figure out what's in it from the content. In turn this would give rise to another way to markup mime-types in-line with the content. And once you've forced such ad-hoc solutions to emerge for meddling with what people can put in the clipboard, you'll have no standing to put that geenie back in the bottle, again, relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote: You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard (as opposed to letting an app just put any bytes there), the UA has to understand OpenEXR. Since I don't see how the UA can understand every conceivable format in existence both future and past, I don't see how that should work.
Re: Clipboard API: remove dangerous formats from mandatory data types
Florian, you keep referring to using application/octet-stream - that's not a format that all user agents support (although the spec says they should ;), nor is there any mention in the spec of what it means to place content on the clipboard in that format (given that platform native clipboards each have their own content-type annotations). So it sounds like you're saying we should also remove application/octet-stream as a mandatory format? On Thu, 25 Jun 2015 at 15:55 Florian Bösch pya...@gmail.com wrote: It's very simple. Applications need to know what's in the clipboard to know what to do with it. There is also a vast variety of things that could find itself in the clipboard in terms of formats, both formal and informal. Mime types are one of these things that applications would use to do that. If a UA where to restict what mime type you can put into the clipboard, that forces the clipboard user to use application/octet-stream. And in consequence, that forces any such-willing application to forgoe the mime-type information from the OS'es clipboard API and figure out what's in it from the content. In turn this would give rise to another way to markup mime-types in-line with the content. And once you've forced such ad-hoc solutions to emerge for meddling with what people can put in the clipboard, you'll have no standing to put that geenie back in the bottle, again, relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote: You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard (as opposed to letting an app just put any bytes there), the UA has to understand OpenEXR. Since I don't see how the UA can understand every conceivable format in existence both future and past, I don't see how that should work.
Re: Clipboard API: remove dangerous formats from mandatory data types
No, what I'm saying is that if you restrict mime types (or don't explicitly prohibit such restriction), but require application/octet-stream, that application/octet-stream becomes the undesirable mime-type dumping ground. And that would be bad because that makes it much harder for applications to deal with content. But if that's the only way UAs are going to act, then applications will work around that by using elaborate guessing code based on magic bytes, and perhaps some application developers will use their own mime-type annotation pretended to the octet-stream. If you inconvenience people, but don't make it impossible to work around the inconvenience, then people will work around the inconvenience. It can't be the intention to encourage them work around it. So you've got to either not inconvenience them, or make working around impossible. On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote: Florian, you keep referring to using application/octet-stream - that's not a format that all user agents support (although the spec says they should ;), nor is there any mention in the spec of what it means to place content on the clipboard in that format (given that platform native clipboards each have their own content-type annotations). So it sounds like you're saying we should also remove application/octet-stream as a mandatory format? On Thu, 25 Jun 2015 at 15:55 Florian Bösch pya...@gmail.com wrote: It's very simple. Applications need to know what's in the clipboard to know what to do with it. There is also a vast variety of things that could find itself in the clipboard in terms of formats, both formal and informal. Mime types are one of these things that applications would use to do that. If a UA where to restict what mime type you can put into the clipboard, that forces the clipboard user to use application/octet-stream. And in consequence, that forces any such-willing application to forgoe the mime-type information from the OS'es clipboard API and figure out what's in it from the content. In turn this would give rise to another way to markup mime-types in-line with the content. And once you've forced such ad-hoc solutions to emerge for meddling with what people can put in the clipboard, you'll have no standing to put that geenie back in the bottle, again, relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote: You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard (as opposed to letting an app just put any bytes there), the UA has to understand OpenEXR. Since I don't see how the UA can understand every conceivable format in existence both future and past, I don't see how that should work.
Re: Clipboard API: remove dangerous formats from mandatory data types
I'm pretty sure it can't be in the interest of this specification to force application authors to bifurcate the mime-type into one that can't be used reliably, and another informal one that's prepended to the octet-stream. Relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:27 PM, Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard (as opposed to letting an app just put any bytes there), the UA has to understand OpenEXR. Since I don't see how the UA can understand every conceivable format in existence both future and past, I don't see how that should work.
Re: Clipboard API: remove dangerous formats from mandatory data types
It still sounds like you're advocating removing the requirement that UAs support application/octet-stream (which makes sense, since its behaviour doesn't seem to be specified anyway). If you're suggesting something else, please elaborate on what that something else is. :) On Thu, 25 Jun 2015 at 16:23 Florian Bösch pya...@gmail.com wrote: No, what I'm saying is that if you restrict mime types (or don't explicitly prohibit such restriction), but require application/octet-stream, that application/octet-stream becomes the undesirable mime-type dumping ground. And that would be bad because that makes it much harder for applications to deal with content. But if that's the only way UAs are going to act, then applications will work around that by using elaborate guessing code based on magic bytes, and perhaps some application developers will use their own mime-type annotation pretended to the octet-stream. If you inconvenience people, but don't make it impossible to work around the inconvenience, then people will work around the inconvenience. It can't be the intention to encourage them work around it. So you've got to either not inconvenience them, or make working around impossible. On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote: Florian, you keep referring to using application/octet-stream - that's not a format that all user agents support (although the spec says they should ;), nor is there any mention in the spec of what it means to place content on the clipboard in that format (given that platform native clipboards each have their own content-type annotations). So it sounds like you're saying we should also remove application/octet-stream as a mandatory format? On Thu, 25 Jun 2015 at 15:55 Florian Bösch pya...@gmail.com wrote: It's very simple. Applications need to know what's in the clipboard to know what to do with it. There is also a vast variety of things that could find itself in the clipboard in terms of formats, both formal and informal. Mime types are one of these things that applications would use to do that. If a UA where to restict what mime type you can put into the clipboard, that forces the clipboard user to use application/octet-stream. And in consequence, that forces any such-willing application to forgoe the mime-type information from the OS'es clipboard API and figure out what's in it from the content. In turn this would give rise to another way to markup mime-types in-line with the content. And once you've forced such ad-hoc solutions to emerge for meddling with what people can put in the clipboard, you'll have no standing to put that geenie back in the bottle, again, relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote: You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard (as opposed to letting an app just put any bytes there), the UA has to understand OpenEXR. Since I don't see how the UA can understand
Re: Clipboard API: remove dangerous formats from mandatory data types
Yet you restrict mime-types AND you support application/octet-stream? On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote: For reasons I've already mentioned, this isn't going to happen because there is no so-called dumping ground. No one is going to risk their paste turning into thousands of lines of gibberish because they tried to stuff binary data in text/plain. Daniel On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote: No, what I'm saying is that if you restrict mime types (or don't explicitly prohibit such restriction), but require application/octet-stream, that application/octet-stream becomes the undesirable mime-type dumping ground. And that would be bad because that makes it much harder for applications to deal with content. But if that's the only way UAs are going to act, then applications will work around that by using elaborate guessing code based on magic bytes, and perhaps some application developers will use their own mime-type annotation pretended to the octet-stream. If you inconvenience people, but don't make it impossible to work around the inconvenience, then people will work around the inconvenience. It can't be the intention to encourage them work around it. So you've got to either not inconvenience them, or make working around impossible. On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote: Florian, you keep referring to using application/octet-stream - that's not a format that all user agents support (although the spec says they should ;), nor is there any mention in the spec of what it means to place content on the clipboard in that format (given that platform native clipboards each have their own content-type annotations). So it sounds like you're saying we should also remove application/octet-stream as a mandatory format? On Thu, 25 Jun 2015 at 15:55 Florian Bösch pya...@gmail.com wrote: It's very simple. Applications need to know what's in the clipboard to know what to do with it. There is also a vast variety of things that could find itself in the clipboard in terms of formats, both formal and informal. Mime types are one of these things that applications would use to do that. If a UA where to restict what mime type you can put into the clipboard, that forces the clipboard user to use application/octet-stream. And in consequence, that forces any such-willing application to forgoe the mime-type information from the OS'es clipboard API and figure out what's in it from the content. In turn this would give rise to another way to markup mime-types in-line with the content. And once you've forced such ad-hoc solutions to emerge for meddling with what people can put in the clipboard, you'll have no standing to put that geenie back in the bottle, again, relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote: You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard
Re: Clipboard API: remove dangerous formats from mandatory data types
For reasons I've already mentioned, this isn't going to happen because there is no so-called dumping ground. No one is going to risk their paste turning into thousands of lines of gibberish because they tried to stuff binary data in text/plain. Daniel On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote: No, what I'm saying is that if you restrict mime types (or don't explicitly prohibit such restriction), but require application/octet-stream, that application/octet-stream becomes the undesirable mime-type dumping ground. And that would be bad because that makes it much harder for applications to deal with content. But if that's the only way UAs are going to act, then applications will work around that by using elaborate guessing code based on magic bytes, and perhaps some application developers will use their own mime-type annotation pretended to the octet-stream. If you inconvenience people, but don't make it impossible to work around the inconvenience, then people will work around the inconvenience. It can't be the intention to encourage them work around it. So you've got to either not inconvenience them, or make working around impossible. On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote: Florian, you keep referring to using application/octet-stream - that's not a format that all user agents support (although the spec says they should ;), nor is there any mention in the spec of what it means to place content on the clipboard in that format (given that platform native clipboards each have their own content-type annotations). So it sounds like you're saying we should also remove application/octet-stream as a mandatory format? On Thu, 25 Jun 2015 at 15:55 Florian Bösch pya...@gmail.com wrote: It's very simple. Applications need to know what's in the clipboard to know what to do with it. There is also a vast variety of things that could find itself in the clipboard in terms of formats, both formal and informal. Mime types are one of these things that applications would use to do that. If a UA where to restict what mime type you can put into the clipboard, that forces the clipboard user to use application/octet-stream. And in consequence, that forces any such-willing application to forgoe the mime-type information from the OS'es clipboard API and figure out what's in it from the content. In turn this would give rise to another way to markup mime-types in-line with the content. And once you've forced such ad-hoc solutions to emerge for meddling with what people can put in the clipboard, you'll have no standing to put that geenie back in the bottle, again, relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote: You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend to make it say, safe to put OpenEXR into the clipboard (as opposed to letting an app just put any bytes there), the UA has to understand OpenEXR. Since I don't see how the UA can understand every conceivable
Re: Clipboard API: remove dangerous formats from mandatory data types
No UA supports it today. No UA is likely to support it anytime soon. Daniel On Thu, Jun 25, 2015 at 10:38 AM Florian Bösch pya...@gmail.com wrote: Yet you restrict mime-types AND you support application/octet-stream? On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote: For reasons I've already mentioned, this isn't going to happen because there is no so-called dumping ground. No one is going to risk their paste turning into thousands of lines of gibberish because they tried to stuff binary data in text/plain. Daniel On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote: No, what I'm saying is that if you restrict mime types (or don't explicitly prohibit such restriction), but require application/octet-stream, that application/octet-stream becomes the undesirable mime-type dumping ground. And that would be bad because that makes it much harder for applications to deal with content. But if that's the only way UAs are going to act, then applications will work around that by using elaborate guessing code based on magic bytes, and perhaps some application developers will use their own mime-type annotation pretended to the octet-stream. If you inconvenience people, but don't make it impossible to work around the inconvenience, then people will work around the inconvenience. It can't be the intention to encourage them work around it. So you've got to either not inconvenience them, or make working around impossible. On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote: Florian, you keep referring to using application/octet-stream - that's not a format that all user agents support (although the spec says they should ;), nor is there any mention in the spec of what it means to place content on the clipboard in that format (given that platform native clipboards each have their own content-type annotations). So it sounds like you're saying we should also remove application/octet-stream as a mandatory format? On Thu, 25 Jun 2015 at 15:55 Florian Bösch pya...@gmail.com wrote: It's very simple. Applications need to know what's in the clipboard to know what to do with it. There is also a vast variety of things that could find itself in the clipboard in terms of formats, both formal and informal. Mime types are one of these things that applications would use to do that. If a UA where to restict what mime type you can put into the clipboard, that forces the clipboard user to use application/octet-stream. And in consequence, that forces any such-willing application to forgoe the mime-type information from the OS'es clipboard API and figure out what's in it from the content. In turn this would give rise to another way to markup mime-types in-line with the content. And once you've forced such ad-hoc solutions to emerge for meddling with what people can put in the clipboard, you'll have no standing to put that geenie back in the bottle, again, relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote: You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give
Re: Clipboard API: remove dangerous formats from mandatory data types
I'm sure you're aware that you can encode any binary blob as UTF-8 text/plain. If you don't support application/octet-stream, then that just becomes the dumping ground. On Thu, Jun 25, 2015 at 7:39 PM, Daniel Cheng dch...@google.com wrote: No UA supports it today. No UA is likely to support it anytime soon. Daniel On Thu, Jun 25, 2015 at 10:38 AM Florian Bösch pya...@gmail.com wrote: Yet you restrict mime-types AND you support application/octet-stream? On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote: For reasons I've already mentioned, this isn't going to happen because there is no so-called dumping ground. No one is going to risk their paste turning into thousands of lines of gibberish because they tried to stuff binary data in text/plain. Daniel On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote: No, what I'm saying is that if you restrict mime types (or don't explicitly prohibit such restriction), but require application/octet-stream, that application/octet-stream becomes the undesirable mime-type dumping ground. And that would be bad because that makes it much harder for applications to deal with content. But if that's the only way UAs are going to act, then applications will work around that by using elaborate guessing code based on magic bytes, and perhaps some application developers will use their own mime-type annotation pretended to the octet-stream. If you inconvenience people, but don't make it impossible to work around the inconvenience, then people will work around the inconvenience. It can't be the intention to encourage them work around it. So you've got to either not inconvenience them, or make working around impossible. On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote: Florian, you keep referring to using application/octet-stream - that's not a format that all user agents support (although the spec says they should ;), nor is there any mention in the spec of what it means to place content on the clipboard in that format (given that platform native clipboards each have their own content-type annotations). So it sounds like you're saying we should also remove application/octet-stream as a mandatory format? On Thu, 25 Jun 2015 at 15:55 Florian Bösch pya...@gmail.com wrote: It's very simple. Applications need to know what's in the clipboard to know what to do with it. There is also a vast variety of things that could find itself in the clipboard in terms of formats, both formal and informal. Mime types are one of these things that applications would use to do that. If a UA where to restict what mime type you can put into the clipboard, that forces the clipboard user to use application/octet-stream. And in consequence, that forces any such-willing application to forgoe the mime-type information from the OS'es clipboard API and figure out what's in it from the content. In turn this would give rise to another way to markup mime-types in-line with the content. And once you've forced such ad-hoc solutions to emerge for meddling with what people can put in the clipboard, you'll have no standing to put that geenie back in the bottle, again, relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote: You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec doesn't currently mandate OpenEXR be supported, so it's currently up to individual user agents to decide whether they can support that format safely. On Thu,
Re: Clipboard API: remove dangerous formats from mandatory data types
My point is that if you leave no other way out, that is what will happen. On Thu, Jun 25, 2015 at 7:57 PM, Daniel Cheng dch...@google.com wrote: That's the case today already, and I haven't seen this happening. Daniel On Thu, Jun 25, 2015 at 10:48 AM Florian Bösch pya...@gmail.com wrote: I'm sure you're aware that you can encode any binary blob as UTF-8 text/plain. If you don't support application/octet-stream, then that just becomes the dumping ground. On Thu, Jun 25, 2015 at 7:39 PM, Daniel Cheng dch...@google.com wrote: No UA supports it today. No UA is likely to support it anytime soon. Daniel On Thu, Jun 25, 2015 at 10:38 AM Florian Bösch pya...@gmail.com wrote: Yet you restrict mime-types AND you support application/octet-stream? On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote: For reasons I've already mentioned, this isn't going to happen because there is no so-called dumping ground. No one is going to risk their paste turning into thousands of lines of gibberish because they tried to stuff binary data in text/plain. Daniel On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote: No, what I'm saying is that if you restrict mime types (or don't explicitly prohibit such restriction), but require application/octet-stream, that application/octet-stream becomes the undesirable mime-type dumping ground. And that would be bad because that makes it much harder for applications to deal with content. But if that's the only way UAs are going to act, then applications will work around that by using elaborate guessing code based on magic bytes, and perhaps some application developers will use their own mime-type annotation pretended to the octet-stream. If you inconvenience people, but don't make it impossible to work around the inconvenience, then people will work around the inconvenience. It can't be the intention to encourage them work around it. So you've got to either not inconvenience them, or make working around impossible. On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote: Florian, you keep referring to using application/octet-stream - that's not a format that all user agents support (although the spec says they should ;), nor is there any mention in the spec of what it means to place content on the clipboard in that format (given that platform native clipboards each have their own content-type annotations). So it sounds like you're saying we should also remove application/octet-stream as a mandatory format? On Thu, 25 Jun 2015 at 15:55 Florian Bösch pya...@gmail.com wrote: It's very simple. Applications need to know what's in the clipboard to know what to do with it. There is also a vast variety of things that could find itself in the clipboard in terms of formats, both formal and informal. Mime types are one of these things that applications would use to do that. If a UA where to restict what mime type you can put into the clipboard, that forces the clipboard user to use application/octet-stream. And in consequence, that forces any such-willing application to forgoe the mime-type information from the OS'es clipboard API and figure out what's in it from the content. In turn this would give rise to another way to markup mime-types in-line with the content. And once you've forced such ad-hoc solutions to emerge for meddling with what people can put in the clipboard, you'll have no standing to put that geenie back in the bottle, again, relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote: You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't
Re: Clipboard API: remove dangerous formats from mandatory data types
I think you're missing the point: there is already no other way out, and that has not happened. Daniel On Thu, Jun 25, 2015 at 11:08 AM Florian Bösch pya...@gmail.com wrote: My point is that if you leave no other way out, that is what will happen. On Thu, Jun 25, 2015 at 7:57 PM, Daniel Cheng dch...@google.com wrote: That's the case today already, and I haven't seen this happening. Daniel On Thu, Jun 25, 2015 at 10:48 AM Florian Bösch pya...@gmail.com wrote: I'm sure you're aware that you can encode any binary blob as UTF-8 text/plain. If you don't support application/octet-stream, then that just becomes the dumping ground. On Thu, Jun 25, 2015 at 7:39 PM, Daniel Cheng dch...@google.com wrote: No UA supports it today. No UA is likely to support it anytime soon. Daniel On Thu, Jun 25, 2015 at 10:38 AM Florian Bösch pya...@gmail.com wrote: Yet you restrict mime-types AND you support application/octet-stream? On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote: For reasons I've already mentioned, this isn't going to happen because there is no so-called dumping ground. No one is going to risk their paste turning into thousands of lines of gibberish because they tried to stuff binary data in text/plain. Daniel On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote: No, what I'm saying is that if you restrict mime types (or don't explicitly prohibit such restriction), but require application/octet-stream, that application/octet-stream becomes the undesirable mime-type dumping ground. And that would be bad because that makes it much harder for applications to deal with content. But if that's the only way UAs are going to act, then applications will work around that by using elaborate guessing code based on magic bytes, and perhaps some application developers will use their own mime-type annotation pretended to the octet-stream. If you inconvenience people, but don't make it impossible to work around the inconvenience, then people will work around the inconvenience. It can't be the intention to encourage them work around it. So you've got to either not inconvenience them, or make working around impossible. On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote: Florian, you keep referring to using application/octet-stream - that's not a format that all user agents support (although the spec says they should ;), nor is there any mention in the spec of what it means to place content on the clipboard in that format (given that platform native clipboards each have their own content-type annotations). So it sounds like you're saying we should also remove application/octet-stream as a mandatory format? On Thu, 25 Jun 2015 at 15:55 Florian Bösch pya...@gmail.com wrote: It's very simple. Applications need to know what's in the clipboard to know what to do with it. There is also a vast variety of things that could find itself in the clipboard in terms of formats, both formal and informal. Mime types are one of these things that applications would use to do that. If a UA where to restict what mime type you can put into the clipboard, that forces the clipboard user to use application/octet-stream. And in consequence, that forces any such-willing application to forgoe the mime-type information from the OS'es clipboard API and figure out what's in it from the content. In turn this would give rise to another way to markup mime-types in-line with the content. And once you've forced such ad-hoc solutions to emerge for meddling with what people can put in the clipboard, you'll have no standing to put that geenie back in the bottle, again, relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote: You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was
Re: Clipboard API: remove dangerous formats from mandatory data types
That's the case today already, and I haven't seen this happening. Daniel On Thu, Jun 25, 2015 at 10:48 AM Florian Bösch pya...@gmail.com wrote: I'm sure you're aware that you can encode any binary blob as UTF-8 text/plain. If you don't support application/octet-stream, then that just becomes the dumping ground. On Thu, Jun 25, 2015 at 7:39 PM, Daniel Cheng dch...@google.com wrote: No UA supports it today. No UA is likely to support it anytime soon. Daniel On Thu, Jun 25, 2015 at 10:38 AM Florian Bösch pya...@gmail.com wrote: Yet you restrict mime-types AND you support application/octet-stream? On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote: For reasons I've already mentioned, this isn't going to happen because there is no so-called dumping ground. No one is going to risk their paste turning into thousands of lines of gibberish because they tried to stuff binary data in text/plain. Daniel On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote: No, what I'm saying is that if you restrict mime types (or don't explicitly prohibit such restriction), but require application/octet-stream, that application/octet-stream becomes the undesirable mime-type dumping ground. And that would be bad because that makes it much harder for applications to deal with content. But if that's the only way UAs are going to act, then applications will work around that by using elaborate guessing code based on magic bytes, and perhaps some application developers will use their own mime-type annotation pretended to the octet-stream. If you inconvenience people, but don't make it impossible to work around the inconvenience, then people will work around the inconvenience. It can't be the intention to encourage them work around it. So you've got to either not inconvenience them, or make working around impossible. On Thu, Jun 25, 2015 at 5:07 PM, Wez w...@google.com wrote: Florian, you keep referring to using application/octet-stream - that's not a format that all user agents support (although the spec says they should ;), nor is there any mention in the spec of what it means to place content on the clipboard in that format (given that platform native clipboards each have their own content-type annotations). So it sounds like you're saying we should also remove application/octet-stream as a mandatory format? On Thu, 25 Jun 2015 at 15:55 Florian Bösch pya...@gmail.com wrote: It's very simple. Applications need to know what's in the clipboard to know what to do with it. There is also a vast variety of things that could find itself in the clipboard in terms of formats, both formal and informal. Mime types are one of these things that applications would use to do that. If a UA where to restict what mime type you can put into the clipboard, that forces the clipboard user to use application/octet-stream. And in consequence, that forces any such-willing application to forgoe the mime-type information from the OS'es clipboard API and figure out what's in it from the content. In turn this would give rise to another way to markup mime-types in-line with the content. And once you've forced such ad-hoc solutions to emerge for meddling with what people can put in the clipboard, you'll have no standing to put that geenie back in the bottle, again, relevant XKCD quote omitted. On Thu, Jun 25, 2015 at 4:48 PM, Wez w...@google.com wrote: You've mentioned resorting to application/octet-stream several times in the context of this discussion, where AFAICT the spec actually only describes using it as a fall-back for cases of file references on the clipboard for which the user agent is unable to determine the file type. So IIUC you're suggesting that user agents should implement application/octet-stream (as is also mandated by the spec, albeit without a clear indication of what it means in this context) by putting the content on the clipboard as an un-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny any formats but those a UA can interprete and deem well-formed. If such a thing where to be done, that would leave any user of the clipboard no recourse but to resort to application/octett-stream and ignore any other metadata as the merry magic header guessing game gets underway. For all you'd have achieved was to muddle any meaning of the mime-type and forced applications to work around an unenforceable restriction. On Thu, Jun 25, 2015 at 3:21 PM, Wez w...@google.com wrote: And, again, I don't see what that has to do with whether the spec mandates that user agents let apps place JPEG, PNG or GIF directly on the local system clipboard. The spec
Re: Clipboard API: remove dangerous formats from mandatory data types
I think you underestimate the integrative need that web-apps will acquire and the lengths they will go to faced with a business need to make it work once clipboard API becomes common developer knowledge.
Custom Elements bugs will be also migrated. [Was: Re: Shadow DOM spec bugs will be migrated into GitHub issues]
I am thinking about migrating Custom Element bugs[1] to Web Components GitHub Issues [2], as I did it for Shadow DOM a few weeks ago, for the consistency. Could someone turn off the automatic email to public-webapps for Custom Elements Bugs in the bugzilla so that we won't receive the mass flood of bugspam by marking the all bugs MOVED? I'm assuming the automatic email is on for public-webapps@. If you have any concerns about migrating, let me know that. [1] https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968hide_resolved=1 [2] https://github.com/w3c/webcomponents/issues On Thu, May 28, 2015 at 10:35 AM Hayato Ito hay...@google.com wrote: I totally agree. I'm really sorry for spamming. I forgot that closing a bug would trigger sending a mail to public-webapps@. My bad. I thought that a closing bug would notify only people who opted-in to add themselves to a list of cc in each bug. That might be a good opportunity for them to keep tracking of the bug status by subscribing a migrated bug on GitHub Issues. On Thu, May 28, 2015 at 6:49 AM Tab Atkins Jr. jackalm...@gmail.com wrote: Note for the future (to you and editors of other specs in WebApps): Before doing this kind of mass bug editting, please turn off the automatic email to public-webapps. If you can't do that yourself, Mike Smith can (at least, he's done it in the past). That prevents the mass flood of bugspam from clogging up people's inboxes. ^_^ ~TJ On Tue, May 26, 2015 at 8:30 PM, Hayato Ito hay...@google.com wrote: PSA: I've finished the migration. All open bugs are now marked as MOVED with a link to the corresponding GitHub issue. On Mon, May 25, 2015 at 5:58 PM Hayato Ito hay...@google.com wrote: Regarding with the Shadow DOM spec, more and more workflows are happening [1] on GitHub w3c/webcomponents repository recently. Therefore, I am thinking about migrating the bugs of the Shadow DOM spec, from the bugzilla [2], to the GitHub issues [3], as some of other specs are already doing so. As an experiment, I've just migrated the existing open bugs on the bugzilla to the GitHub issues, by a tiny script I've written using GitHub APIs. Unless there is an objection to the migration, I am going to close the existing open Shadow DOM spec bugs on the bugzilla, with a link to the corresponding bug on the GitHub issues. Please let me know if you have a concern. [1] https://github.com/w3c/webcomponents/commits/gh-pages [2] https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978 [3] https://github.com/w3c/webcomponents/issues
