Eric Charles

As shared previously a few time, I am not if favor to release this in the current state as being too risky.

This PR allows to silently replace the service manager responsible for the core feature of Jupyter (content and computing access). A hacker will easily create an good looking extension with...

Today vulnerabilities and ways to hack Jupyter should not be an argument to make the situation even worse and dangerous. Once shipped to the developers, that potential new API will...

> this PR does not change the security posture as of today, Releasing this is a no-way back (you can not remove such a feature) - in that sense I...

> From a security perspective then we seem to all agree Sorry, I am not part of the "all". Are you planning to ask position from the Security team or...

@rpwagner Thx for the feedback. Is there any minutes or documents where we can read the analysis and reasoning backing that feedback?

fyi we had done some work in https://github.com/jupyter-rtc (which could be renamed to https://github.com/jupyter-collaboration). Having such a common org for both client and server side code would remove those difficulties).

Thank you @skukhtichev for the great demo during JupyterCon and for opening the discussion to upstream the work you have been doing. I would be great to have a chat...

> I realized that the proposal needs to be adapted to the latest Jupyter Server changes (authorization, updated kernel web socket handler, etc.) Doesn't the general principle remain the same....

@kevin-bates I think @skukhtichev was mentioning 25th (next week), not 18th (this week)