A driver shouldn't be a front-facing program that shows ads of any kind. It should be sandboxed and follow strict APIs to talk to the OS and that's it - any extra options should be shown inline in the main e.g. printer or mouse dialog.
Actually, why not? The driver could declare a list/tree of extra configurable options, and windows could generate a configuration dialog for them. I think this is already is thing in Windows for NICs, I remember seeing TCP offload options when I go into properties for a NIC in the device manager.
You just need to make it a bit more accessible to non-tech users and with more modern control options such as colour wheels for RGB.
And the Linux software for these sort of devices (when such software exist) don't tend to be as bloated. Usually the driver just exposes some control files under /sys and someone else builds a GUI or such on top. But there is no reason you couldn't also expose a schema that describes what the options do to make a more generic GUI for those.
On Windows out of the box they kind of work, but you really need a manufacturer's software suite to take full advantage of them, and that software suite is, surprise, an advertising and analytics platform, a situation I think both Microsoft and the peripheral manufacturers are very happy with.
What we're saying is this shouldn't be allowed by the OS to begin with. Not to merely use the peripheral in any case.
Whether Microsoft is happy with allowing it, is another matter.
Perhaps some law accompanied with hefty fines can make them less happy doing it.
Many generations of Roccat peripherals were usable this way on Linux, thanks to the work of one generous volunteer who reverse-engineered them.
Companies like Logitech don't store their devices' configs in firmware in a way that "forces" you to run some additional shit to use all of their features (some features aren't implemented in software). It's a convenient excuse that allows them to push their spyware onto users, but it's totally unnecessary.
A vendor that was actually "user friendly" in the deep sense (opposite of "user hostile") would do this themselves; configuration would be upstream-first via libratbagd or whatever, and then they'd provide their own configuration interface as a value-add for a uniform cross-platform experience, or in areas where they thought they could provide a better UI than the design principles of KDE and GNOME, or so that they could have a uniform interface to refer to in their documentation.
Yes. Via some standard protocol to show checkboxes, radio buttons, drop down selections, etc.
Windows users think of the driver as what makes the hardware do what everything in its class does but subtly different and somehow glued to a command center with its own unique and bad GUI auto started, in the tray, with its own update schedule, and ads.
There was a good keynote on the topic 5 years ago By Timothy Roscoe
https://www.usenix.org/conference/osdi21/presentation/fri-ke...
Imo, the only thing Microsoft can meaningfully do here from their side is threaten LG with pulling all their drivers if they keep doing this.
I can't imagine the group doing this validation is sufficiently manned/funded; it's a cost centre, and the effects of cutting it don't show up for years.
I'm not surprised that the driver got approved, especially if the previous versions already had some user UI and this update "just" added the ads. What I would hope now is for MS to either pull the updated driver or ask LG to roll the change back themselves, possibly under the thread of pulling their drivers altogether (iirc they done that with other companies in the past).
The problems tend to be in the userspace software that's also installed with the driver. Sometimes there's also some pretty derpy stuff where the driver wants to talk to the userspace software but there's no validation/verification and that opens up a big hole.
Second, we're not talking about the drivers per se, as those aren't what shows you ads, it's the configuration software and accompanying crapware. Did you get that? I'm guessing no, based on your comment.
Third, there are capability-based kernels, microkernels, drivers that are allowed into as restricted bytecode, IOMMU, and several other layers of security. Do you know that? I'm guessing no, based on your comment.
Though there is a limit to how much you can effectively sandbox a driver for most devices. They do have a point even if they made it badly. I know you listed some methods but they don't generalize to arbitrary devices very well.
>Though there is a limit to how much you can effectively sandbox a driver for most devices. They do have a point even if they made it badly. I know you listed some methods but they don't generalize to arbitrary devices very well.
Likely not, but the rarer cases could always be exceptions.
Most devices, screens, printers, mice, audiocards, etc should not have to go through this, at least not for basic functioning.
Which is why I like e.g. "class compliant" devices for example, whereas the configurations can be managed directly from the OS with no third party driver loaded. Some of those do come with the custom proprietary driver, but for most I don't even bother installing it.
Except for every printer, some popular GPUs, Microsoft's peripherals...