It's a good question, and it depends on what exactly you mean by data leakage. PyScript is a frontend library, and all code run is entirely in the browser window. So no code objects ever need to travel back to a server, because there is no particular need for a server, other than to hand off the HTML page with your code to the end user.

That said, when PyScript starts up, it loads a copy of the Python interpreter (Pyodide/Cpython at this point, soon Micropython will also be an object). By default this comes from Pyodide's CDN - if you didn't want that network access to potentially be observable, you'd need to locally host the Pyodide runtime.

When you install packages (using the packages key in py-config), those packages are fetched from either (a) the same base URL that it fetched Pyodide from, (b) straight from PyPI for pure Python packages, or (c) a wheel file specified by URL. If you don't want, say, PyPI to see that your users are downloading those specific packages when the app starts, you'd need to locally host a copy of those packages as well.

Finally, as far as "running a web app from within a network drive," there are a couple of features like [[fetch configurations]] which grab other files off the network and load them into the Python environment for use by your program. If you open your page straight from disk, by double-clicking on your HTML file say, most browser's won't allow access to other files on the disk, and fetching those files fails. We recommend running a simple local server to solve this - you could potentially have a shell/batch script in the same folder to start this server for your users.

File "upload" and "download" are by their nature secure - the files need never leave the client's web browser, assuming you're doing any processing inside of PyScript and not just pushing the data on to a server somewhere.

I think the unofficial builds are more for WASI testing purposes.

As using default python-wasm builds in the browser apart from a synchronous REPL, is not so easy and lacks some way to interface quickly with the DOM.

Also default build cannot import wasm wheels since it has no pypi repo and no machinery for that.

for a more interactive version of libpython-wasm have a look here https://pygame-web.github.io/showroom/pythondev.html?-d where you can import eg pygame or numpy

and for a more "pyscript experience" based upon stock libpython-wasm have a look here https://pygame-web.github.io/wiki/pygame-script

anyway pyscript will soon use the stock libpython via the pyodide underway upgrade https://github.com/pyodide/pyodide/pull/3252