Alternative to custom protocols (URI schemes)

Question

I have been extensively using a custom protocol on all our internal apps to open any type of document (CAD, CAM, PDF, etc.), to open File Explorer and select a specific file, and to run other applications.

Years ago I defined one myprotocol protocol that executes C:\Windows\System32\wscript.exe passing the name of my VBScript and whatever argument each request has. The first argument passed to the script describe the type of action (OpenDocument, ShowFileInFileExplorer, ExportBOM, etc.), the following arguments are passed to the action.

Everything worked well until last year, when wscript.exe stopped working (see here for details). I fixed that problem by copying it to wscript2.exe. Creating a copy is now a step in the standard configuration of all our computers and using wscript2.exe is now the official configuration of our custom protocol. (Our anti-virus customer support couldn't find anything that interacts with wscript.exe).

Today, after building a new computer, we found out that:

• Firefox doesn't see wscript2.exe. If I click on a custom protocol link, then click on the browse button and open the folder, I only see a small subset of .exe files, which includes wscript.exe, but doesn't include wscript2.exe (I don't know how recent this problem is because I don't personally use FireFox).
• Firefox sees wscript.exe, but it still doesn't work (same behavior as described in my previous post linked above)
• Chrome works with wscript2.exe, but now it always asks for confirmation. According to this article this seems to be the new approach, and things could change again soon. Clicking on a confirmation box every time is a big no-no with my users. This would slow down many workflows that require quickly clicking hundreds of links on a page and, for example, look at a CAD application zooming to one geometry in a large drawing.

I already fixed one problem last year, I am dealing with another one now, and reading that article scares me and makes me think that more problems will arise soon.

So here is the question: is there an alternative to using custom protocols?

I am not working on a web app for public consumption. My custom protocol requires the VBScript file, the applications that the script uses and tons of network shared folders. They are only used in our internal network and the computers that use them are manually configured.

Enterprise

Answer 1

First of all, that's super risky even if it's on internal network only. Unless computers/users/browsers are locked out of internet, it is possible that someone guesses or finds out your protocol's name, sends link to someone in your company and causes a lot of trouble (possibly loss too).

Anyway...

Since you are controlling software on all of the computers, you could add a mini-server on every machine, listening to localhost only, that simply calls your script. Then define host like secret.myprotocol to point to that server, e.g., localhost:1234.

Just to lessen potential problems a bit, local server would use HTTPS only, with proper certificate, HSTS and HPKP set to a very long time (since you control software, you can refresh those when needed). The last two, just in case someone tries to setup the same domain and, for whatever reason, host override doesn't work and user ends up calling a hostile server.

So, links would have to change from myprotocol://whatever to https://secret.myprotocol/whatever.

It does introduce new attack surface ("mini-server"), but should be easy enough to implement, to minimize size of that surface :). "Mini-server" does not even have to be real www server, a simple script that can listen on socket and call wscript.exe would do (unless you need to pass more info to it). Real server has more code that can have bugs in it, but also allows to add more things, for example a "pass through" page, that shows info "Opening document X in 3 seconds..." and a "cancel" button. It could also require session login of some kind (just to be sure it's user who requests action, and not something else).

Cacomistle

I don't understand how this would help running something on the client's machine. – Enterprise

Every machine would have such "mini-server" installed on it. That server would call wscript.exe on request from the browser. So, it would work as a kind of a proxy passing request from the browser to wscript.exe. – Cacomistle

I did not want to force any language/framework in my answer, but it would be quite easy to write such "mini-server" in node.js, python or similar languages. Even just as a proof-of-concept to be replaced by small, stand-alone executable later :). – Cacomistle

Can you confirm that I understand? Today's setup: add xxx.vbs, copy wscript.exe to wscript2.exe, add protocol to the registry. New setup: install python, add miniserver.py, execute miniserver.py at startup. Newer setup maybe: use py2exe and avoid the installation of python. Could I use localhost:4567 instead of configuring a sub domain? – Enterprise

Yes for new setup, but I'm afraid that custom domain/subdomain is needed. At least for Chrome. Link from a page on example.com is blocked when it points to 127.0.0.1 and user confirmation (same as for custom protocol) is required when it points to localhost. But i'm guessing that it does not have to be a domain/subdomain that's public. You could add "virtual" domain through a "hosts" file on Windows (but it's been few years since i've used Windows, so better check it first. I've found this: #42637211). – Cacomistle

Answer 2

The title of this blog post says it all: Browser Architecture: Web-to-App Communication Overview.

It describes a list of Web-to-App Communication techniques and links to dedicated posts for some of them.

The first in the list is Application Protocols, which I have been using for years already, and it started to crumble in the last year or so (hence my question).

The fifth is Local Web Server, which is the one described by ahwayakchih.

UPDATE (this update follows the update on the blog post above mentioned)

Apparently I wasn't the only one thinking that this change in behavior was a regression, so a workaround has been issued: the old behavior (showing a checkbox that allows to remember the answer) can be restored by adding these keys to the registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Chromium]
"ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000001

Enterprise