[IPython-dev] Some Thoughts on Notebook Security

[Matthias BUSSONNIER]

Le 11 déc. 2012 à 16:10, Carl Smith a écrit :

> Hi Brian
>> 
>> The idea is that the extra Javascript cool-stuff will be installed by
>> the person who runs the notebook server once and for all notebooks on
>> that server.  Similar to how python packages are installed = you do
>> this before you start python.  To get data from python to the
>> Javascript plugins we will use JSON objects and trigger the callbacks
>> to handle them.
> 
> This seems to be dependent on a kernel, which static notebooks don't
> have? If I generate a static notebook, which is just a web page, then
> post that page to a hosting service, or email it to someone, how would
> the plugins work? Maybe we're looking at two slightly different
> scenarios. I'm focussed on static views only. The host should not have
> to allow anything more than posting and getting HTML documents.

IIRC, you can embed several repr in the ipynb file. 
So you could provide a plugin that can "render" object on static view. 
(like d3.js graph, you don't need the kernel to do that)

> ================
> 
> Hi Matthias
> 
>> Static notebooks, served from a different domain, could be rendered
>> inside iframes, enabling us to embed them inside other webpages and
>> applications. These notebooks would still be superficially served by
>> our own servers, so the UX wouldn't be effected.
>> 
>> keep in mind that iframe are not sandboxed, and you can inject js on parent
>> frame.
>> Unless you use the sandbox attributes, which is part of html5 but not
>> implemented in every
>> browser… And not yet infallible, it is more a "we'll help you embed other
>> pages by providing a separate
>> js namespace but we don't guaranty yes that the VM is unbreachable"
> 

> I pretty sure iframes are sandboxed in the sense that a parent page
> and an iframe can not communicate unless they have the same origin,
> and this is an old feature. The new sandbox attribute in HTML5 is for
> a different purpose.

But this is still kind of a problem, as usually the static view will be served from the "same origin" 
as the rest of the website. 

If you don't want to make a notebook fully public, you have to have some kind of authentication 
that allows you to load it. 

I'm still doubt a little about what frames are supposed to do and what they actually do.
I'm not an expert on that, but it is still worth digging.

>> Responsible disclosure don't want to say much more but but having a
>> statically display
>> notebook is often link to having a "sharing/import" button which is
>> dangerous.
>> And could lead to self propagating notebook through account that can infect
>> other
>> notebooks, or share itself on twitter...
> 
> Any buttons, like for importing a notebook, would live in the parent
> page and would have no access to, nor allow access from, the iframe.
> The parent page would know which static notebook it embeds in the
> iframe though, so it could provide buttons that connect to the actual
> notebook in question, which is a totally different file to the static
> notebook being rendered in the iframe anyway.

I understand what you want to do, I guess the definition of "static" is blurry. 
If you want a perfectly static version (does it make sense in html) you can go with iframe. 
If you want the ability to comment on a particular cell, then you have to build iframe for 
every cell. 
and you lose the ability to comment "inline" as github does.


> 
>> Multi domain is a real good idea. I have a clear view in my head on how we
>> could use that in a way close to OAuth to allow javascript by still having
>> "logged-in" users.
>> It wouldn't be as seamless a something like github, but close.
> 
> I think we're looking at things differently: You seem to be
> considering static views as something generated on the fly and on
> demand, nbviewer style. I'm thinking about running nbconvert on a
> notebook, then keeping the output as a webpage to be copied and passed
> around freely. Once the static notebook exists, it's a done deal.
> There's no chance of any changes to IPython breaking it. It's a
> independent webpage. Updating it would amount to deleting it and
> replacing it with a new version.

I don't think those are quite different.
You can have a "perfectly static" version that embeds bad js and require some kind of authentication to be seen. 
The line between "on the fly" and static is thin.

> 
>> The **big** question is:
>> Are viewer logged in (in any way) to the given server, and if so do they
>> have the right to do anything else with those credentials ?
>> If it is just a public notebook viewer, then it's fine.
>> 
>> If you want something more "interactive" (sharing/ permissions…etc, and the
>> display any JS ) you won't have much choice.
>> Or you will have a painful multi-login.
> 
> I'm very much against hosting user submitted notebooks on any domain
> with cookie based authentication. It needs to be divided into 'trusted
> domain', where no user's JS will ever be served, and 'hosting domain'
> that has no account system of it's own. The trusted domain would
> control the hosting domain, as a kind of slave.

Yep, kind of what I have in mind. 
The hosting domain can have "tokens" 
Publish this comment on this notebook on the behalf of ...
The you have to "validate" those action on the "trusted domain".
-- 
Matthias



> 
> That's just my take on all this.
> 
> Cheers
> 
> Carl
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev