Adding Web Serial API through extension

[UCyborg]

Just curious if it would be possible, at least in theory, to add this to the browser through an extension in a way that existing web apps could use it without modifications.

[vannilla]

Why in the name of all that is sacred would you add serial port access to a web browser? Or any hardware port, for that matter.
"But node.js" is not an excuse since node.js uses Chromium's engine, i.e. a web browser.

through an extension

UXP would need to provide an interface to the hardware first and as far as I know it doesn't provide anything for any kind of port.

[Moonchild]

If you need this, you should use a dedicated application that can use any hardware access you need. If you insist you need this in a browser, then that is what NPAPI plugins are for (you know, the technology that got chucked for "security reasons"). How is an always-on Web API more secure than an on-demand plugin? That's right, it isn't.

Important questionsto ask yourself (and which Web Serial API designers should also have asked):

• Who outside of very specialized use cases still uses serial ports?
• Why would web code need access to these ports?
• Why would you want to expose hardware ports and any attached hardware to internet pages?

... and of course the third question should be asked about any Web * API that offers access to client hardware directly or indirectly.

[Gemmaugr]

If you need this, you should use a dedicated application that can use any hardware access you need. If you insist you need this in a browser, then that is what NPAPI plugins are for (you know, the technology that got chucked for "security reasons"). How is an always-on Web API more secure than an on-demand plugin? That's right, it isn't.

Important questionsto ask yourself (and which Web Serial API designers should also have asked):

• Who outside of very specialized use cases still uses serial ports?
• Why would web code need access to these ports?
• Why would you want to expose hardware ports and any attached hardware to internet pages?

... and of course the third question should be asked about any Web * API that offers access to client hardware directly or indirectly.

Sadly, it's https://en.wikipedia.org/wiki/Internet_ ... kin=vector (because of course everything needs to be online. So much easier to track..and limit it behind paywalls: https://www.bbc.com/news/technology-63743597 & https://www.bbc.com/news/articles/c62weyp4qqgo, or shut off entirely: https://www.smartenergygb.org/about-sma ... -off-power, etc etc)

[Lucio Chiappetti]

I am assuming the OP wants access via a browser to a local resource on his own web server.
Whether this access is just from his own machine or open to anybody in the world is up to him, though I would be rather scary of the latter.

Well ... if you want to have an UI via a web page to something on your own machine ... there is a very old way ... CGI scripts. Write a script (*) which does what you want and call it from/as a web page.
I do it for things like an interface to mysql (MariaDB databases), lsof etc.
(*) a CGI program could also be a program written in any language (I have a Fortran CGI ). Another also old-fashioned way are java servlets.

[Moonchild]

I am assuming the OP wants access via a browser to a local resource on his own web server.

...which is a real corner case.
And even then, that doesn't seem to be what this API would be for. it would be for accessing a local resource on the client machine through the browser.

Whether this access is just from his own machine or open to anybody in the world is up to him, though I would be rather scary of the latter.

But having the API in a browser makes it an attack vector for every browser user.

Once again, a web server under OPs control could respond to any dedicated application for this purpose that isn't a web browser. The server API can be whatever they want. The local port access can be from an application that communicates with the server through that API. That way the application will be restricted to only what is configured in it, and isolated from potentially hostile content on the web. I really don't recommend exposing peripherals to the web through a general purpose browser and Web API.

[UCyborg]

This is mostly out of academic curiosity. Because it would take me forever to figure out on my own if extensions can extend web accessible APIs, in this case adding "serial" object to "navigator". I'm not sure if most users here are aware of this, but extensions already have the power that goes beyond messing with the browser itself. They're free to call underlying APIs of the OS the browser runs on. So they could probably talk to serial ports as well (and encrypt your data and kill your children, if we're going into sinister direction).

It's an idea I had for the web based software at work to handle entering card numbers into it through portable reader that makes virtual COM port over USB. Old software was desktop application and supported this scenario, but that's long abandoned and in the land of deprecated and unsupported. The current solution is a separate application that reads the data and emulates keystrokes to enter the number in whatever text field is focused, which isn't as elegant. I played with Chromium's API and it does integrate pretty neatly in the app. It may clear some confusion regarding usability, at least for Chromium users, which are in majority.

Potential Pale Moon extension would probably be for me alone, since I seem to be the only Pale Moon user in real life. Which consequentially means I'd have to make it on my own, which isn't realistic for multiple reasons.

Web Serial is already made in a way you have to grant access to specific device to specific web page. Is that much different from on-demand NPAPI plugins?

[Moonchild]

Extensions can only use the capabilities of the underlying browser code. If the browser doesn't have the code to communicate with serial ports on a hardware level, then extensions can't change that. The base code must be present. This is also why NPAPI is better (see below). An extension could extend the navigator object with the front-end code for it, but it won't be able to provide the actual functional hardware back-end code for it to be functional.

Web Serial is already made in a way you have to grant access to specific device to specific web page. Is that much different from on-demand NPAPI plugins?

Yes there is an essential difference because with NPAPI the user has to install and enable the plugin for the browser to be capable. If built into the platform and dependent on a permissions system then that permissions system becomes the point of failure and opens up every user, including those who will never need the functionality, to potential exploits or more likely spoofs.
On top, NPAPI plugins get unloaded after a certain amount of time of not being used so even if there's a code vulnerability that could give an actor binary address access, the code will simply not be present (unlike if it's part of the core).

[UCyborg]

Extensions can only use the capabilities of the underlying browser code.

And one of those capabilities is calling into native code. They can load system DLLs and call their functions, they can supply and load their own DLLs and call their functions. Memory can be shared between native and JavaScript code. There could be hurdles, but it wouldn't surprise me if backend talking to serial ports could be implemented that way. Obviously, you'd need separate implementations for different operating systems.

[Moonchild]

And one of those capabilities is calling into native code.

But the browser core does not have native code talking to serial ports. That's my point when I say "underlying browser code". There has to be some native code inside the browser to make this communication possible. If that's not present, then extensions can't call into it.
Now, I'm not sure to what extent extensions can load an arbitrary .dll or .so off the top of my head, so that might be a route... or perhaps with binary XPCOM components included in the extension, but it's not straightforward and it would have to be an explicit installation of an extension if that can be done (as opposed to a browser core offering many many "Web APIs" that all become potential attack vectors for being present and active for every user.

[Kris_88]

In fact, you can work with a COM port like a regular file.
And besides, there's ctypes, so you can call almost any OS function. There's no need for additional external components like DLLs.

[UCyborg]

I saw one example in C how it's done on Windows. There are some specifics with COM ports that aren't clear to me at this point.

Interestingly, there seems to be at least one new function in Windows 10 for dealing with COM ports, GetCommPorts. Windows 10 also added out-of-box support for Serial over USB devices. Technically, the driver was present in older Windows versions, but there wasn't an INF file to set it up, so manufacturers had to provide their own. Now you need an INF only if you really want specific name of the device in Device Manager rather than generic "USB Serial Device". macOS doesn't need any special configuration, Linux may need some fiddling with permissions.

I mentioned a separate DLL just as an example, I used to need one extension that came with a DLL back before my bank made it so you needed a smartphone. That extension was used for signing transactions with your certificate. Why and how, I have no idea, but I suspect they used the DLL to be able to re-use its functions for Chromium. Because the only way for web extensions to do something crazy (indirectly) is by installing a separate program that talks to the extension via native messaging. That program loaded the DLL and talked to the extension via native messaging while extension for Mozilla based browsers loaded DLL directly via ctypes.

I played with ctypes this weekend. Very interesting and powerful module that isn't mentioned often. It took me hours to wrap my head around it, but I managed to make a custom button (with the help of Custom Buttons extension) that shuts down computer half-hour from now (another click aborts the shutdown) or puts it to sleep immediately, depending on which mouse button you click it with. The final result doesn't look too complicated, but I'm slow.

I can share the code if anyone's curious. A bit longer example is at Using COM from js-ctypes. Both examples are Windows specific. You have to write definitions of the structs that are used by the API functions you call in ctypes way and when you know how to pass pointers and dereference them, then it gets easier than it looks at first.

[Kris_88]

I'd try osfile first. It might be enough.
https://udn.realityripple.com/docs/Mozi ... ain_thread

Regarding GetCommPorts, here is some useful information:
https://stackoverflow.com/questions/138 ... s-in-win32

[Moonchild]

In fact, you can work with a COM port like a regular file.

Ah yeah I forgot about that. That might be a feasible route as well. It's been decades since I worked with COM ports so it kind of faded.

[UCyborg]

Looks like someone had the similar idea and did it for Firefox.

https://addons.mozilla.org/en-US/firefox/addon/webserial-for-firefox/