tube-get VS quickjs

To understand why, I have a far simpler tool that focuses on a subset of sites (adult content video aggregators)

https://github.com/kristopolous/tube-get

It too deals with this problem but does so in a way that'd be easy to maliciously sabotage

Look right about here https://github.com/kristopolous/tube-get/blob/master/tube-ge...

Add to why this exists, this was originally written between about 2010-2015 or so so it technically predates the yt-* ecosystem.

The tool still works fine and it's not a strict subset of yt-dlp or YouTube-dl because being a different approach, although it's overall site coverage is smaller, I've had it be a "second try" system when yt-* fails and it comes up with success maybe about half the time

You can use it as en embedded scripting language within Python.

[1] https://github.com/PetterS/quickjs

You could run the webextention javascript in quickjs.

I was interested to see that this uses the DukPy wrapper around Duktape for the JavaScript interpreter: https://browser.engineering/scripts.html

This made me start digging into whether this was considered a "safe" way of executing untrusted JavaScript in a sandbox.

its not completely clear to me if DukPy currently attempts safe evaluation - it's missing options for setting time or memory limits on executed code for example: https://github.com/amol-/dukpy

There's a QuickJS Python wrapper here which offers those limits: https://github.com/PetterS/quickjs

I'm pretty paranoid though any time it comes to security and dependencies written in C, so I'd love to see a Python wrapper around a JavaScript engine that has safe sandbox execution as a key goal plus an extensive track record to back it up!