The only way an attack vector is possible here is if you think GitHub themselves would maliciously inject an altered version of the code in the repo, and even then you'd be able to see the code and network requests in your developer tools.
Just distribute the code for local execution? Sure, it's less accessable for the target audience, but it is more transparent.
But what else is new? Most users are willing to sacrifice privacy and security for convenience. That's how we got into this whole mess.
I mean, I get what you mean, but this is literally what's already happening. It's distributed via HTTP, and executed in your browser. You can save it (Ctrl-S, still a thing browsers do), and -- since it's distributed in source form -- easily inspect it, or reopen it later, in a different browser on a different computer. A zip file of the same thing is available on the repo (it's a zip of the repo).
If you don't trust that it won't access the web, disable your internet while running it or some such, as with other code you don't trust. If you don't trust it to mess with your files, well, you're in luck because modern browsers are probably the best audited sandbox out there.
I say I get what you mean, because most people won't do any of it. Instead of saving the page and running what they trust or have verified to be a safe snapshot of the page, they'll reopen the hosted version, trusting that it's still safe, even though the page may have been replaced with one that does upload their files.
I did not suggest distributing an executable. I suggested distributing code, so that the user could audit it before execution.
I did not realize this tool executed all of its logic in the client when I made that post. It is rare to find websites with plainly-written, unobfuscated, uncompressed, vanilla Javascript that don't rely on any server-side processing.