<script type="shell"> to execute arbitrary shell commands, and import stdout or result written to local file as a JavaScript module

[guest271314]

Note, this is just a concept that have been mulling over for a few months. Given

<script type="shell" src="file:///home/USER/.config/SHELL_SCRIPTS/ls.sh"></script>

or

<script type="shell">
#!/bin/bash
touch export.txt
ls -l > export.txt
</script>

or

<script type="shell, module">
#!/bin/bash
touch export
ls -l > export

# some mechanism to export the result of `stdout` or created local file "export.txt" as a JavaScript "module"
</script>

<script type="module"> import {stdout} from "./export" </script>

This is a concept roughly based on Native Messaging available at Chromium and Firefox browsers.

We could provide some form of notification to the user where permission is either granted or not (similar to navigator.getUserMedia(), navigator.registerProtocolHandler(), etc.) for a given local folder either containing the binary itself or having adequate permissions to be executed as a program; and sandbox the permissions to the specific folder to avoid permission escalation concerns.

We could also create some form of wrapper for stdout of the command(s) or fetching of a temporary created file for the purpose of using export {<export result of shell command here as JavaScript module>}.

Has this concept or inquiry been previously presented to and considered by HTML Standard?

What is the viability, and security considerations of adding "shell" to <script> element type to execute arbitrary shell commands where src requests resources from file: protocol?

[domenic]

I don't think any browser is interested in introducing new languages to the web, such as bash.

[guest271314]

The concept does not intend to introduce a new language to the web. The concept is based on allowing execution of existing binaries already available at the user OS, and wrapping stdout as a JavaScript module which can be imported as a JavaScript module. The execution of the binary would occur at the OS level. Perhaps utilizing WebAssembly Language virtual machines #535 or other means internally to achieve the requirement.

[guest271314]

The user could configure the sandboxed environment for the specific commands which are authorized, for example excluding rm; though the language used at the OS could be any binary, PHP, python, C++, etc. We would not allow, for example, external resources to be requested.

We can already do this using Native Messaging. The concept is to allow the same procedure at <script type="shell"> element.

[guest271314]

@domenic Have certainly not worked out all of the details, nor even composed a POC specific to parsing a <script type="shell"> element. Just sharing a concept. It took quite some time for this user to gather the proper usage of Native Messaging protocol for the ability to call a single binary from a Chrome App - without starting a local server and GET or POST.

HTML has used type other than "application/javascript" in the past; i.e.g. 18 Scripts, and am curious if that implementation could be revisited within the current era of HTML.

If the concept is not viable at <script> element whatsoever will explore other options to run local commands within a sandboxed environment from HTML without using an "app", extension or local server, then formatting the output for the ability to import the result of the command as a JavaScript module.

Is the concept not viable?

[domenic]

In general I don't think breaking out of the web sandbox and running binaries on a user's OS is something we want to allow at all. It drastically breaks the web's security model. Using a cooperating local server, which the user has to install via out-of-band trusted channels, is the canonical way to do this.

[guest271314]

Fair enough. Suppose was trying to avoid manually opening terminal to start the local server; and manually stopping the server when that particular tab or browser instance itself was closed. Possibly using Chromium --proxy flag, though uncertain how to tie the browser instance to starting and stopping the local development server, which is more than likely beyond the scope of this issue.

Not sure if it is possible to somehow use the existing Native Messaging implementation as an underlying process of the present concept - again, without specifically using the Chrome App to achieve the same.

In any event, your feedback is helpful.

[annevk]

Yeah, this is out-of-scope. Not really sure what a viable place would be to have this discussion, sorry.

[sashafirsov]

The access to native apps and OS resources been presented in HTML from very beginning. HTA stands for HTML application and was available in IE up to now. Similar approach been considered by other browsers.
The shell is not something which comes out of the box but with ability to run any executable and trapping std streams by JS, it is not a showstopper. I have used this approach back in 2006 in commercial cross-platform CDs for DOCSIS modem provisioning. Of course there was no unified standard, but was doable. Modern browsers are bit more restrictive and it creates the challenge to make HTML-based native app.

@annevk , the type=bash has sence only in context of HTML application(not as web page). Should this subject be addressed in such context?

[annevk]

@sashafirsov maybe; that would go counter to the cross-platform nature of HTML and is therefore out-of-scope here.

[guest271314]

@annevk How exactly would adding a type="<scripting language>" be counter to the cross-platform nature of HTML?

"Monstruous" softwares like Electron, NW.js, CEF, webviews runtime and others, which are highly inconvenient to build and distribute, exist only because browsers did not implement a simple and secure way to give to web applications native capabilities such as running a local program or script, via a secure model based on permissions approved by the end-user in the context of digitally signed web applications.

The web and computing in general would be way better if one could simply build desktop applications into the browser that could naturally interact with local resources.