<br><br><div class="gmail_quote">On Wed, Jan 9, 2013 at 4:49 PM, Brian Granger <span dir="ltr">&lt;<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">&gt; I really can&#39;t imagine that it will come to this - you are talking about<br>
&gt; disabling pandas table printing,<br>
&gt; and simple rich text reprs.  That doesn&#39;t seem tenable.  It&#39;s also disabling<br>
&gt; sized images, since our message spec so far has foolishly excluded shape<br>
&gt; information for images, etc, or the ability to display any kind of<br>
&gt; formatting (e.g. two images side-by-side).<br>
<br>
</div>Sorry I wasn&#39;t clear.  I meant to just remove the &lt;script&gt; tags, not<br>
all of the HTML ouput.  In your language &quot;sanitize&quot; it.<br>
<div class="im"><br>
&gt; We should be able to sanitize Javascript from HTML - both in rendered<br>
&gt; markdown and HTML output data. This, in turn, could allow script detection<br>
&gt; and give an &#39;unsafe dynamic content, only allow if you trust...&#39; message.<br>
<br>
</div>Yep.<br></blockquote><div><br></div><div>Ah, sorry I misunderstood.  I thought you were saying we were going to remove HTML reprs entirely,</div><div>not scrub javascript from existing HTML reprs.  I still think we might want to have a warn/allow mechanism,</div>

<div>rather than a strict &#39;no js&#39; policy, but 90% of the work for those two is actually the same,</div><div>so we can fight over that molehill when we get there :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<span class="HOEnZb"><font color="#888888"><br>
Brian<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
&gt; The cost of what you are proposing is *extremely* high.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt; This is a slight difference than displaying javascript with the<br>
&gt;&gt; &gt; Javascript object that actually evaluate the string of code.<br>
&gt;&gt; &gt; It is also dangerous in multi-user context, even if this javascript is<br>
&gt;&gt; &gt; not runned at load time.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I think that Json plugin are much better than current structure because<br>
&gt;&gt; &gt; one of the first plugin you can write can evaluate javascript<br>
&gt;&gt; &gt; code, so it actually does the same as Javascript object.<br>
&gt;&gt; &gt; But, If you design a custom plugin that deal with a specific type of<br>
&gt;&gt; &gt; json data, then you get the ability for this data to be used<br>
&gt;&gt; &gt; at load time as the json repr is stored.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; And I do agree that we need to give users a way to still display JS.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I still think we should **strongly** encourage them not to use<br>
&gt;&gt; &gt; Javascript object because of it&#39;s inherent evaluation<br>
&gt;&gt; &gt; which is not stored. It is nice for prototyping, but it does more harm<br>
&gt;&gt; &gt; than anything for sharing.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Finally I suppose it will be doable and a good thing to develop the<br>
&gt;&gt; &gt; ability to plug those jsplugin to nbviewer.<br>
&gt;&gt;<br>
&gt;&gt; Yes, I agree.<br>
&gt;&gt;<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; Matthias<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; IPython-dev mailing list<br>
&gt;&gt; &gt; <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
&gt;&gt; &gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Brian E. Granger<br>
&gt;&gt; Cal Poly State University, San Luis Obispo<br>
&gt;&gt; <a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; IPython-dev mailing list<br>
&gt;&gt; <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
&gt;&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; IPython-dev mailing list<br>
&gt; <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
&gt;<br>
<br>
<br>
<br>
--<br>
Brian E. Granger<br>
Cal Poly State University, San Luis Obispo<br>
<a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br>