[Python-ideas] A tuple of various Python suggestions

[Cory Benfield]

> On 10 Apr 2016, at 22:24, Keith Curtis <keithcu at gmail.com> wrote:
> 
> Python can run in sandboxes as well:
> https://wiki.python.org/moin/SandboxedPython. People who care about
> code being intercepted and manipulated should use SSL or sign it.

I don’t think you’ve understood the problem here: you seem to be saying that we can solve the lack of trust issue by “rubbing some crypto on it”. But that doesn’t solve the problem at all.

Let’s take this apart.

“People who care about code being intercepted and manipulated”: if that code runs directly on the user’s machine then *everyone* should care. Put another way: it doesn’t matter what the *author* of the code cares about, it matters what the user cares about, and all users care about executing safe code! Otherwise, I can insert whatever Python code I like and run arbitrary code with the permissions of the browser. This opens the entire machine up to attack: an attacker can consume their CPU resources, transition into FS access, and basically do all kinds of wacky things.

But wrapping this in SSL or signing the code doesn’t solve the problem at all. I opened a new browser window, turned my ad blocker off, and then loaded www.wired.com. The following domains loaded and executed Javascript code (this isn’t a complete list either, I gave up and got bored):

- ads.rubiconproject.com
- 5be16.v.fwmrm.net
- optimized-by.rubiconproject.com
- cdn.optimizely.com
- rtb.adgrx.com
- player.cnevids.com
- dy48bnzanqw0v.cloudfront.net
- cdn-akamai.mookie1.com
- cdnjs.cloudflare.com
- tpc.googlesyndication.com
- securepubads.g.doubleclick.net
- c.amazon-adsystem.com
- s.update.rubiconproject.com
- b.scorecardresearch.com
- aax.amazon-adsystem.com
- static.chartbeat.com
- segment-data.zqtk.net
- wired.disqus.com
- animate.adobe.com
- aam.wired.com
- pagead2.googlesyndication.com
- condenast.demdex.net
- www.googletagservices.com
- h5.adgear.com
- dpm.demdex.net
- a.adgear.com
- i.yldbt.com
- use.typekit.net
- assets.adobedtm.com
 - z.moatads.com

The point is that I, the user, did not consent to *any* of those. This is the way the web platform works: users don’t get asked who gets to execute code on their machine. Most users would not download a random binary to their machine from one of those domains and execute it. Wrapping that code in SSL or signing it prevents man-in-the-middle attacks on the code, but doesn’t in any sense prevent those actors listed there from doing terrible stuff!

It is well known that Sony wrote an actual rootkit that they used as DRM and distributed it via CDs. If you believe that one of the above sites wouldn’t do something equally malicious with full access to my machine, you’re living in a fantasy world. This means that any code that those domains are allowed to execute needs to run in an absurdly restricted context: because neither I nor any other user trusts arbitrary domains to run arbitrary code!

A Python sandbox that allows access to any code not distributed via the web browser is not restrictive enough. That Python tells you too much about the machine on which it is running. This is doubly bad if that Python is capable of calling into native code extensions distributed outside the browser (such as NumPy), because sandboxing code like that requires running a complete virtual machine. Either distributing that code would be a nightmare, or you’d be forcing users to run a complete x86 virtual machine in order to keep them safe from the arbitrary code that these actors are delivering.

> People who write their own code to run on their own machine would
> likely prefer to be able to just directly reference the Python runtime
> they've already setup.

People who write their own code to run on their own machine can write Python directly. They don’t need a web browser. Hell, they can bundle Flask and provide a localhost website that runs Python code. Those users are currently served just fine.

> I wonder whether the sandbox can be used outside of Web Assembly so
> that code distribution and security are not so intermingled. I did see
> someone write that WebAssembly is the "dawn of a new era", but I
> wonder whether it is mostly a bunch of Javascript people trying to
> solve their own problems rather than those who care about making
> Python work well on it.

Python will work just fine on it if you don’t add the bizarre requirement to be able to access the user’s machine from inside the browser sandbox.

Python on the web is a laudable goal, and should be pursued, but the idea of a Python-on-the-web as powerful as Python-on-the-machine is not. No-one wants their website Javascript to be able to call into a Node.js installed on the user’s machine, because they know that’s absurd. We shouldn’t want Python to be able to do it either.

Anyway, at this point I think we’re about as off-topic as we can get for this list, so I’m stepping back out of this conversation now. Feel free to follow-up off-list.

Cory

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160411/b9da54dd/attachment.sig>