<br><br><div class="gmail_quote">On Wed, Jan 9, 2013 at 2:21 PM, Brian Granger <span dir="ltr"><<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Jan 8, 2013 at 11:37 PM, Matthias BUSSONNIER<br>
<<a href="mailto:bussonniermatthias@gmail.com">bussonniermatthias@gmail.com</a>> wrote:<br>
><br>
>> I do appreciate the concern, and we need a solution to the issue.<br>
>> I just don't think we have a complete one yet.<br>
>> Right now, we have a supremely flexible (and thus insecure) situation,<br>
>> whereas jsplugins-only is secure, but not remotely flexible from a user's perspective.<br>
>><br>
>> This is an extremely serious incapacitation of the notebook.<br>
>> The trouble is that jsplugins is a relatively tolerable substitue<br>
>> for the single-user notebook, but where the problem is worst<br>
>> is when users don't actually have access to the server<br>
>> to install jsplugins. So it's precisely the case where we<br>
>> would not allow custom js that jsplugins fail most dramatically<br>
>> as a substitute.<br>
>><br>
>> Is it really our intention to require *server* installation of a plugin<br>
>> for a user to gain access to a new widget? That seems to eliminate a *huge* portion of exactly what makes the notebook interesting.<br>
>><br>
>> If we have a way that js plugins can be loaded at runtime by the user without access to the server (presumably with a 'do you trust this guy?' confirmation),<br>
>> then that would go a long way toward preventing the total castration of the notebook.<br>
>><br>
><br>
> The problem is that if we escape javascript in output to prevent js execution at load time we do make<br>
> injecting javascript **script tag** useless in markdown and cell ouput.<br>
<br>
</div>I don't see any way that we can allow <script> tags in markdown and<br>
HTML output. Those is the most dangerous case as they are run at<br>
notebook load time and there is no hook for us to prevent that. All<br>
we can do it strip them.<br></blockquote><div><br></div><div>I really can't imagine that it will come to this - you are talking about disabling pandas table printing,</div><div>and simple rich text reprs. That doesn't seem tenable. It's also disabling sized images, since our message spec so far has foolishly excluded shape information for images, etc, or the ability to display any kind of formatting (e.g. two images side-by-side).</div>
<div><br></div><div>We should be able to <a href="http://stackoverflow.com/questions/295566/sanitize-rewrite-html-on-the-client-side">sanitize</a> Javascript from HTML - both in rendered markdown and HTML output data. This, in turn, could allow script detection and give an 'unsafe dynamic content, only allow if you trust...' message.</div>
<div><br></div><div>The cost of what you are proposing is *extremely* high.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> This is a slight difference than displaying javascript with the Javascript object that actually evaluate the string of code.<br>
> It is also dangerous in multi-user context, even if this javascript is not runned at load time.<br>
><br>
> I think that Json plugin are much better than current structure because one of the first plugin you can write can evaluate javascript<br>
> code, so it actually does the same as Javascript object.<br>
> But, If you design a custom plugin that deal with a specific type of json data, then you get the ability for this data to be used<br>
> at load time as the json repr is stored.<br>
><br>
> And I do agree that we need to give users a way to still display JS.<br>
><br>
> I still think we should **strongly** encourage them not to use Javascript object because of it's inherent evaluation<br>
> which is not stored. It is nice for prototyping, but it does more harm than anything for sharing.<br>
><br>
> Finally I suppose it will be doable and a good thing to develop the ability to plug those jsplugin to nbviewer.<br>
<br>
</div>Yes, I agree.<br>
<div class="im HOEnZb"><br>
> --<br>
> Matthias<br>
><br>
><br>
><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>
<br>
<br>
<br>
</div><div class="im HOEnZb">--<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>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<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>