4 ms·

Why in the world would a keyboard driver need to run a webserver? Client software should just be able to call driver functions directly in order to configure t

Why in the world would a keyboard driver need to run a webserver? Client software should just be able to call driver functions directly in order to configure the keyboard. It sounds like they hired a web developer to write their driver configuration tool and didn't give any architectural constraints or have someone managing the project who knows best practices or security principles.

nemothekid 7y ago
I don’t have the keyboard, but it’s my understanding that application developers can customize the lights on the keyboard. For example if you die in the game your keyboard turns red. To do that you need IPC, and a JSON endpoint is the most popular form of RPC. If the server listens on localhost, I don’t see any issue with it - any issue you would have with IPC, you would have with this style of of RPC. Now they could have provided a library to communicate directly with the keyboard - but I think the drawback was games developers didn’t want to integrate it into their games.
- deleted 7y ago
  [deleted]
- Slartie 7y ago
  > Now they could have provided a library to communicate directly with the keyboard They could have also opened a named pipe. Much cleaner, faster, less overhead than a web server, and way more secure (last time I checked, a website could not simply perform a request on a named pipe via JavaScript. With a local web server however...).
Slartie 7y ago
> they hired a web developer to write their driver configuration tool This is the real problem behind all of these cases of "why the heck is tool/driver/app/whatever X running a web server locally?" - the market is full of developers only knowing HTTP, and when someone just has a hammer, every problem looks like a nail. There is a real shortage of devs who know about all the other IPC techniques supported by modern OSes (of which practically all of them are much faster, lower latency, less overhead-y, more secure and come with less unintended side effects than a local web server).

nemothekid 7y ago

I don’t have the keyboard, but it’s my understanding that application developers can customize the lights on the keyboard. For example if you die in the game your keyboard turns red. To do that you need IPC, and a JSON endpoint is the most popular form of RPC. If the server listens on localhost, I don’t see any issue with it - any issue you would have with IPC, you would have with this style of of RPC. Now they could have provided a library to communicate directly with the keyboard - but I think the drawback was games developers didn’t want to integrate it into their games.

deleted 7y ago
[deleted]
Slartie 7y ago
> Now they could have provided a library to communicate directly with the keyboard They could have also opened a named pipe. Much cleaner, faster, less overhead than a web server, and way more secure (last time I checked, a website could not simply perform a request on a named pipe via JavaScript. With a local web server however...).

Slartie 7y ago

> they hired a web developer to write their driver configuration tool This is the real problem behind all of these cases of "why the heck is tool/driver/app/whatever X running a web server locally?" - the market is full of developers only knowing HTTP, and when someone just has a hammer, every problem looks like a nail. There is a real shortage of devs who know about all the other IPC techniques supported by modern OSes (of which practically all of them are much faster, lower latency, less overhead-y, more secure and come with less unintended side effects than a local web server).