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

2016-02-08 Thread Wez
Hallvord,

IIUC the issue is that while transcoding complex formats via formats that
can be easily sanity-checked by the browser takes care of letting content
set complex formats like JPEG, GIF while protecting local content, but it
loses the ability for content to pass that content to other local
applications losslessly.  e.g. transcoding to BMP would remove JPEG
location, time/date, etc annotations.

The bug you refer to looks like it's talking about intra-Browser, i.e.
content->content, copy/paste operations for arbitrary MIME-types?

Cheers,

Wez @ Google


On 6 February 2016 at 05:01, Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

> BTW, we have a slightly related and interesting discussion regarding
> custom data types going on here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=860857
>
> I should try to sum up some of the arguments and proposals and present
> them on this list but if anyone wants to chime in, I'd appreciate more
> ideas in that bug too. I'll do my best to present them objectively and
> fairly on the list :)
> -Hallvord R
>
>


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

2016-02-08 Thread Hallvord Reiar Michaelsen Steen
On Mon, Feb 8, 2016 at 7:45 PM, Wez  wrote:
> Hallvord,
>
> IIUC the issue is that while transcoding complex formats via formats that
> can be easily sanity-checked by the browser takes care of letting content
> set complex formats like JPEG, GIF while protecting local content, but it
> loses the ability for content to pass that content to other local
> applications losslessly.  e.g. transcoding to BMP would remove JPEG
> location, time/date, etc annotations.

There is an issue here. Would it be possible to add another clipboard
entry for metadata or something?

> The bug you refer to looks like it's talking about intra-Browser, i.e.
> content->content, copy/paste operations for arbitrary MIME-types?
>> https://bugzilla.mozilla.org/show_bug.cgi?id=860857


It's basically about being able to place content labelled as an
arbitrary MIME type on the clipboard (i.e.
clipboardData.setData('application/x-foo', 'my custom data')) but -
correct me if I'm wrong - I don't think the browser has any real,
cross-platform way to distinguish a MIME type the JS just invented and
a MIME type that is known to and used by some other application on the
system. Hence I think the discussions of writing "data in formats
native apps use" and "data in formats custom to the script creating
them" are not two separate discussions.

It may be possible to distinguish an "already registered" and a "not
known to system" type on Windows, but even that isn't really a
guarantee that some format description isn't used by other software -
and on Mac/nix it's harder because they have a different model than
Windows's "registered types" model.

If it is possible to draw such distinctions on all/some platforms
please enlighten me, and we can perhaps untangle this into two
separate topics again :)
-Hallvord



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

2016-02-08 Thread Paul Libbrecht
(Finally found some time to resume this old discussion - if you've all
forgotten the details by now the thread started here:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html
)

cool!
>> But copying a fragment of HTML in the wild without reformulating it will
>> lead to privacy breach: it would copy references to external content. I
>> believe all browsers have an "inlining" method to solve that problem when
>> pasting from a web-page (I believe "save as web page complete" also does a
>> part of that).
>
> I think the proposed solution may be worse for privacy than the
> original problem: images you would "inline" might have sensitive data
> in them.. AFAIK it's not common to do any image inlining or URL
> mangling when pasting HTML copied from another site, is it?

It's the way it currently works on FF apparently (tested MacOSX 10.11
and Windows 7) and on Safari: all images are converted to data-urls.
I don't really see why it would be worse.
Would sensitive data be something such as the metadata? That could
certainly be stripped by transcoding.
>>> Why should JSON be unsafe? Parsing JSON should be pretty easy, so hopefully
>>> most parsers would be safe.
>> I think the danger lies beyond parsers.
>> In XML, you would have XInclude which can be used in many tools to include
>> content from outside.
>> I believe I have seen JSON syntaxes that had external references as part of
>> their specs but I can't remember which now.
>> As long these formats are copied as is and parsed blindly the risk of
>> external inclusion remains.
>
> XML: good point.
> JSON: nope, there's no such thing as "external inclusion" in JSON, and
> there never will be.
You can certainly exchange a Bookmark-list over json (e.g.
http://kb.mozillazine.org/Bookmarks)... that would be a simple example
of some JSON whose URLs you should not "GET" without some concerns (e.g.
localhost servers).
Similarly XInclude-enabled XMLs or even other remote-including-XMLs
(e.g. through DTD) should ask the users, deny, or inline.
>>> For the unsafe formats, the warning could say that the UA-implementors
>>> should only support the flavour if they have a method to make this content
>>> safe so that local applications (which do not expect untrusted content)
>>> receive content they can trust when pasting. Methods to make the content
>>> safe include the following: transcoding a picture, inlining all external
>>> entities for html, xml, mathml, or rtf).
>> On Windows I believe images are transcoded to and from DIB - device
>> independent bitmap format anyway. Is there any equivalent graphics
>> interchange format on other platforms? Does mandating such transcoding help
>> guarantee against payloads that might trigger vulnerabilities in target
>> software?
>>
>> All platforms I know of have some sort of transcoding of pictures (in Macs
>> it is PDF as the central format).
>> I think this is a very safe mechanism to rely on.
>
> I've just done a small test in Safari on Mac. It allows writing a
> random string to the clipboard and labelling it image/tiff (and
> helpfully adds a "public.tiff" clipboard entry with the same random
> data). There's no transcoding or similar.
Please share the test, this is exactly the kind of things we need around
to see how crooked one could touch upon.
E.g. MS Office documents nowadays display a "kind" of mistrust so the
user can bless if macros should be run. This kind of mistrust is
probably the future.
However, going as far as refusing any picture you
right-click-copy-picture from a web-browser because it is unsafe is far
from being what the users expect nowadays.
>> I expect it adds a significant hurdle against exploits, but I'd like input
>> from Daniel Cheng and perhaps from people who have worked on image
>> decoders..
>
> I'd still like Daniel Cheng to chime in again if he has time :)
> So, the question (for recap) is: would it be OK to let JS write binary
> data labelled as an image type if the browser was required to
> transcode it to TIFF or DIB and only update the clipboard if such
> transcoding succeeded?
My answer is definitely yes as we should*assume that image transcoders
should remove the dangers of flawed parsers as they could happen
otherwise in other situations (e.g. in doing screenshots).
> (Obviously we also need the reverse mechanism - on paste, if there's
> TIFF or DIB on the clipboard offer JPEG and/or PNG to JS).
yes

Paul