<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - text/rtf clipboard data is empty (makes TinyMCE and textbox.io require Flash)"
href="https://bugs.webkit.org/show_bug.cgi?id=124391#c14">Comment # 14</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - text/rtf clipboard data is empty (makes TinyMCE and textbox.io require Flash)"
href="https://bugs.webkit.org/show_bug.cgi?id=124391">bug 124391</a>
from <span class="vcard"><a class="email" href="mailto:rniwa@webkit.org" title="Ryosuke Niwa <rniwa@webkit.org>"> <span class="fn">Ryosuke Niwa</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=124391#c11">comment #11</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=124391#c10">comment #10</a>)
> > The issue here is that:
> > 1. It can leak private data embedded in RTF from third party applications
> > 2. IT can leak cross-origin content if the user had copied a range of
> > content across an cross-origin iframe.
> >
> > We need to solve both of these problems in order to enable this feature.
> >
> > For 1, we probably need to paste RTF content into a document ourself, and
> > then re-generate RTF out of the said document. For 2, we probably need to
> > stop copying contents across an cross-origin iframe.
>
> I am not sure I understand 1. I think it would be that third party app's
> responsibility to to put in the clipboard private data.</span >
No, we can't do that. Third party applications aren't expecting their RTF to be exposed to a random Web page.
This is why, for example, we don't expose raw HTML, which contain sensitive information such as local file path, real user name, etc... included in link/meta elements that aren't even visible in the page.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>