npm is plagued by backdoors. It is inacceptable for a decentralized project to depend on backdoored packages. Decentralized projects are priority targets for adversaries who want to discourage use of decentralised projects by attacking everyone using them, because relyance of people on centralysed software allows to better control them.

• An example of a decentralised project that has been backdoored and later exploited to attack people in bulk is pybitmessage.

Cargo and crates are examples of a package manager and a repo inheriting npm weaknesses.

Rust itself is also not very good, since most of packages require nightly version of rust, and the way of installing it is known as highly controversal from the point of security. Distros usually don't ship packages for rust nightly versions.

Some features of ECMAScript make it especially suitable for hard-detectable backdoors.

• Some examples:
  • [] syntax for properties access, making the RCE code look like innocent collection access. One just generates the string eval in runtime, and then window[g3n3v4l()]() and there is no eval token in the code.
  • lot of legacy functions, methods and HTML DOM properties provide primitives to execute arbitrary code.
• The eval backdoor in pybitmessage was not hidden at all (and even though it was spotted only when people got mass attacked), but if pybitmessage was written in JS and if there was an intent to actually hide the backdoor, it would be easier to do that with the antifeatures described above.
  • python has getattr, but it can be easily detected, using getattr is a potential marker of obfuscation.
  • python has facilities for hidden code execution called pickle, any package using pickle is a potential backdoor. Unfortunately some free software developers are either idiots or assholes with the position if you don't trust our package, just don't use it. PR closed. But using pickle can be detected by static analysis.
  • importlib and __import__ are also big red flags since they can import packages by dynamically generated names.
  • as you see, for python attack surface is a bit more controllable than for ECMAScript. Not perfectly though. When considering a language for the software with such security requirements as this one, one should think about how well security is integrated into the language itself. I have some ideas about controlling attack surfaces by the means of language runtime even better (unfortunately I have not managed to proove it, without proofs they are just snake oil), just write if you want to discuss it.

Electron is a heaviyweight piece of Chromium. Large, slow, heavyweight, bloaty. It may be much better to just start a local webserver and control it using any browser of user's choice, such as Firefox.

svelte is a framework, but it is essentially redundant. Modern HTML DOM has enough API allowing to write modern websites completely without frameworks, in Vanilla JS. Maybe with a bit more code, but the benefits are great, sites on vanilla.js tend to have less overhead and better understandability, because everything is interacting directly to browser. No frameworks, and no surprises to be hidden within them, and much easier debugging since devtools see the actual event listeners, not the ones of framework calling the framework user's ones via closures.