[IPython-dev] Some Thoughts on Notebook Security
Wed Dec 12 11:46:25 CST 2012
OK trying to catch up with this thread...
* Matthias brings up a great point that we need to consider
forged/hostile notebooks that were not created with our notebook
server. The solution to this is to make sure that our notebook server
can "clean" notebooks before displaying them. The solutions that I
posted above will address this completely and allow people to simply
open notebooks from the web without worrying about them.
* I still feel like I don't have a straight answer to my question:
will the solutions I proposed solve all of the security problems while
allowing us to serve authenticated notebooks on single domains? If
now, what security problems would remain?
* I am confused about the multiple domain solution that is being
would be served from a separate domain that does not offer any
authentication. The authenticated notebooks would live on a second
that needs to be private? But my biggest complaint about this is that
it completely cripples one of the most important features of the
notebook - the possibility of sharing notebooks+kernels with other
people. These features are infinitely more important that allowing
* I don't see any fundamental different between "static notebooks" and
security issues and I don't think it makes sense to try and handle
On Tue, Dec 11, 2012 at 9:15 AM, Matthias BUSSONNIER
> Le 11 déc. 2012 à 16:10, Carl Smith a écrit :
>> Hi Brian
>>> 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
>>> 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
>>> 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
>>> And could lead to self propagating notebook through account that can infect
>>> 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
>>> "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".
>> That's just my take on all this.
>> IPython-dev mailing list
> IPython-dev mailing list
Brian E. Granger
Cal Poly State University, San Luis Obispo
email@example.com and firstname.lastname@example.org
More information about the IPython-dev