Egregoros

@sickburnbro I'm not a security expert and I thought the same but when I rotate the problem in my head I immediately start thinking about symlinks, relative paths or the simple fact that an attacker might just tell you to drop the "helpful script" straight into ~/ or C:\Users\USERNAME

I imagine this might be a bit more complex. But it is a shame, yes. This change means simple html sites simply won't work locally anymore and I reckon there were a couple other neat usecases apart from tabletop rpg piracy lol

@hazlin @sickburnbro whoops I guess I kinda lost you. I posted the reasoning for why 5etools doesn't work locally in another reply to my OP. The browsers blocked this behavior
The reason is that if you can read file:// from file:// then a malicious script could exfil anything on your drive. that's what I was referring to because sbb made a good point that this is kinda pointless and you can just as well sandbox it to it's directory. Which running npm serve or the python thingy does btw.

@hazlin @sickburnbro yeah I guess so. I was hoping I could avoid serving in a web server for portability reasons. My assumption was that this was a change the 5etools devs made for their own development convenience or "new shiny" or something like this. But it turns out it's literally not possible to do it like they had it before, and have modern browsers open the page.

I'll have to do it with the python thing I guess. Idk yet. My idea was actually to clone 5etools for another system but it's now 2 hours later and I haven't even started lol

Nah I read that, and it makes sense.

Also, you're wrong about the Python approach. Yes, Python does run locally, but you're only using it to run a preinstalled web server module that it ships with, which will make all the files in the local directory accessible to the browser in a way that doesn't require breaking its sandbox.

As long as your Python installation is from a legit source, this is fairly safe. Running it this way will NOT execute any code from that directory – the browser will only be able to access files from the directory you started the server in, nothing else.

In that sense, the using Node is actually more risky, because that WILL run code outside the browser's sandbox, and they could technically smuggle anything in there.

@Verfassungsschmutz I never said that it would
I'm saying the threat model why browsers disabled file-to-file access was "what if someone sends you a html that opens other files on your pc and exfils the data"
but now that this won't work anymore, they will send you a "local version" of the webapp and a tainted python command to "start the server" which exfils the data.
So the question is what threat to the normal person have we actually stopped here. You'd have to be at least a bit savvy to know what the server commands do.

>node more risky
is that so? npm run serve:dev is not gonna execute code, is it?
Should just host the files

Right, that's why I said it's safe IF you use a local Python installation from a legit source (i.e. MS Store on Windows or your distro package manager on Linux).

But node doesn't have a built-in webserver (although it's trivial to write one), so running any node commands will definitely execute some sort of custom code. I looked at the repo, and in this case, npm run serve:dev will execute this package, which is downloaded when you run npm ci (short for clean-install).

It's likely safe, since it has a high version number, millions of downloads per week, and no updates in 4 years (meaning it's stable), but in general, this IS a possible attack vector, even if the package author is trustworthy – a few years ago, someone managed to hack a guy who owned hundreds of popular NPM packages, stole his keys, and used them to upload modified versions of some of his packages that contained malware, which would try to scan the system for API keys and login info for various web services and send them to a server he controlled, so he could start mining crypto on their AWS accounts or whatever.

So if you want to be on the safe side here, I'd say stick to the Python version, and make sure you use an official Python distribution.

Well, Go really isn't inherently safer than Node, it has a similar package ecosystem that could be attacked in the same way.

The only reliable way to be safe when using ANY programming language with packages downloaded from the Internet (which is basically all modern languages) is to run them in a Docker container. That's gonna add a bit of overhead to your system (mostly increased RAM usage), and require downloading even more stuff, but at least whatever damage the thing can do will be contained to its own VM.

Now, what the hell does Playwright have to do with any of that?