[IPython-dev] Scipy central & IPython notebook.

[Brian Granger]

On Mon, Sep 24, 2012 at 12:37 PM, Matthias BUSSONNIER
<bussonniermatthias at gmail.com> wrote:
>
> Le 24 sept. 2012 à 21:19, Brian Granger a écrit :
>
>> On Mon, Sep 24, 2012 at 12:49 AM, Matthias BUSSONNIER
>> <bussonniermatthias at gmail.com> wrote:
>>>
>>> Le 24 sept. 2012 à 01:13, Fernando Perez a écrit :
>>>
>>>> On Sun, Sep 23, 2012 at 1:19 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>>>>>> From my perspective, nbviewer is a poor name for this. The focus
>>>>> should be on the content (scientific Python example code), not the
>>>>> tools (the notebook). Within that, we can promote the Notebook, but
>>>>> naming the site after it would be putting the cart before the horse.
>>>>
>>>> Jumping in a little late here...  Here's my perspective on this:
>>>> IPython is an important piece of the pylab ecosystem, and as I argued
>>>> vociferously on the scipy-user discussion, I think the notebook should
>>>> play an even more prominent role in there.  But it's also very
>>>> important to keep this in mind: ipython and the notebook are also used
>>>> by, and important to, communities that have nothing to do at all with
>>>> scientific work.
>>>>
>>>> And in the spirit of pylab being a federation of collaborating
>>>> projects, I think the right solution here is to find a way for say
>>>> 'pylab-central' (were it to exist) to use something *like* nbviewer,
>>>> or nbviewer itself, but without having to tightly couple it to pylab
>>>> central, so that it can be equally used by other projects and
>>>> communities that don't have scientific uses in mind.
>>>>
>>>> Pylab-central could, for notebooks, simply embed (perhaps in an
>>>> iframe) the nbviewer-rendered version of a notebook.
>>>
>>> Certainly not as is !
>>> Nbviewer embed remote javascript which would be high security risk for any website
>>> or user that **trust** ipython.org
>>
>> I am beginning to think we should remove <script> tags from markdown
>> cells because of this.
>
> This is **not** an issues of <script> tag in markdown cell.
> you can insert html almost everywhere, we should totally assumed
> that people can forge a false notebook file on their own.

As far as I know a valid notebook file can only load <script> tags in
two locations:

* In markdown cells.
* In JS/HTML output.

Are there others that I am missing?

Here is my current thinking about this issue:

1. We should *never* allow JS code to be run without the user of the
notebook explicitly asking for it.  This mean that merely
loading/rendering a notebook should never cause JS code to run.
2.  This means that we should strip <script> tags out of markdown
cells completely as markdown is rendered to HTML and displayed at load
time.
3.  I don't don't what to do about JS/HTML output - it one of the most
useful parts of the notebook.  We should probably investigate
sandboxing techniques...but minimally we should probably warn users
before we run this code (although what a pain from the UI
perspective).

Cheers,

Brian

> So script in html output, or maybe even in code cell source.
>
> One way I see is iframe sandboxing with recent browser.
> --
> Matthias
>
>
>>
>>> This is one of the reason that I'm reluctant to add github (or other) authentication on nbviewer.
>>> The day we add something like that to nbviewer of if so embed it in another website without proper
>>> care, it is the golden goose for anyone that want to do javascript injection.
>>
>> Yep, this is a huge issue.
>>
>>> In the long term it would be nice to have an api.nbviewer.ipython.org that serve something clean,
>>> but I just don't want people to try this kind of things for now.
>>> --
>>> Matthias
>>>
>>>
>>>> It will be up tow
>>>> the pylab central developers to decide whether they want to get into
>>>> the business of hosting notebooks or they point to people's gists or
>>>> full-fledged repos. nbviewer doesn't care where things are: as long as
>>>> there's a public URL for an ipynb file, it can render it.
>>>>
>>>> This loose-coupling model seems to me better both in terms of
>>>> acknowledging the structure of the pylab/ipython Venn diagram as well
>>>> as in the spirit of federated collaboration we're trying to establish
>>>> with pylab.
>>>>
>>>> Cheers,
>>>>
>>>> f
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com