[joe_mamba]

>I don't know what Microsoft is thinking even allowing and enabling this sort of thing

This has been a feature since Windows 7, and it worked great since it would pull all necessary drivers after installation without you going hunting on the internet like in the Windows XP days.

Just that no HW manufacturer thought to push spyware in their driver repos at that point to improve some team's KPIs.

[coldtea]

>and it worked great since it would pull all necessary drivers after installation without you going hunting on the internet like in the Windows XP days.

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.

[threetonesun]

And then what, ever single gaming mouse/keyboard config is going to appear in the Windows UI dialog? I think extra options in an app is fine, but you should have to download it. At which point who knows what you’ve opened yourself to but at least you chose to do it.

[VorpalWay]

> And then what, ever single gaming mouse/keyboard config is going to appear in the Windows UI 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.

[threetonesun]

As a user I agree, but I think this misunderstands the Windows market. Forget about mice for a second, if you look at GPU drivers between Linux and Windows on Linux they... just work, and you can use some apps to modify exposed features, like you said.

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.

[coldtea]

>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.

[isityettime]

Configurable peripherals should store their configurations entirely on-board, and they should be configurable using a well-understood protocol. Users can then use either the vendor's application, a common third-party application, or the configuration interface native to their desktop environment to configure them. When they plug them into a new machine, they should just keep working without having to install any configuration software.

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.

[coldtea]

>And then what, ever single gaming mouse/keyboard config is going to appear in the Windows UI dialog?

Yes. Via some standard protocol to show checkboxes, radio buttons, drop down selections, etc.

[solarkraft]

Yes! Extra apps suck.

[LucasOe]

Drivers should just make my stuff work. If I want to configure my hardware, I download the app from the manufacturer's website.

[michaelmrose]

Linux users think of a driver as the thing that makes my silently hardware do the existing things its supposed to do like every other item in its class.

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.

[MatejKafka]

How exactly do you propose to sandbox drivers running in kernel space? Do you even know how drivers work? (I'm guessing no, based on this comment)

[milesvp]

There are people working on this problem honestly. The general solution 10 years ago was a micro kernel. Today, I’m not sure. The linux model is starting to look dated, with similar problems elsewhere. Modern hardware design looks less and less like classic textbook design, with all kinds of random chips having direct memory access to memory the cpu uses on some shared bus. Where even things like on board blue tooth chips can become attack vectors on the system.

There was a good keynote on the topic 5 years ago By Timothy Roscoe

https://www.usenix.org/conference/osdi21/presentation/fri-ke...

[MatejKafka]

Agree with all of those points and there are some partial solutions (IOMMU, userspace drivers, virtualization,...), but we're still quite far from being able to safely connect untrusted hardware and load its driver without effectively giving it privileged access.

[toast0]

Microsoft has a program to do static and dynamic analysis of drivers... not a sandbox, but better than nothing. Of course, wonky drivers plus wonky hardware can still do bad things (io-mmu can help, a bit).

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.

[masfuerte]

The User-Mode Driver Framework is a thing. Most plug-in devices do not need (or have) a kernel-mode driver.

[MatejKafka]

Yes, but unless all 3rd party drivers can run in userspace (which is not really feasible), Microsoft needs to give vendors the option to install a kernel driver, at which point a vendor can always decide to ship a kernel driver and bypass any restrictions.

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.

[dwattttt]

Drivers still need to pass certification & get signed. Microsoft does get to reject them.

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.

[MatejKafka]

I expect that process to be mostly automated, I wouldn't expect the MS folks at the testing lab to do much (if any) manual testing, especially for a new version of a previously approved driver.

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).

[coldtea]

First of all, drivers don't have to run in kernel space. Do you know that? I'm guessing no, based on your comment.

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.

[MatejKafka]

To answer in a more constructive way:

No mainstream desktop OS tries very hard to sandbox drivers. Some drivers on both Windows and Linux (not very familiar with Mac) can be implemented as userspace drivers, as long as the performance hit is acceptable, but for many devices (e.g., graphics drivers), you need a kernel driver to get reasonable performance.

Therefore, if your OS supports loading 3rd party binary drivers (Windows do, Linux technically does as well, but tries to make them hard to use in practice), it cannot really refuse to load kernel drivers and only allow userspace ones without breaking a lot of machines.

Even if you have a userspace driver, the device may still get DMA access to RAM. IOMMU is a thing, but due to backwards compatibility, the driver chooses whether to enable IOMMU protection for the specific device on Windows.

If you're willing to write your own microkernel and bootstrap its driver ecosystem from scratch, your claims would be reasonable. With current desktop OS architecture, not really.

As for the accompanying software, there is a good explanation in another comment of all the valid use cases it has (printer dialogs, audio interface configuration,...). LG abusing that to show ads is primarily LG's problem.

[MatejKafka]

Read sibling comments to get answers to all your (non)questions.

[coldtea]

Strange how you didn't read them then, based on your rude and false response to my comment.

[Dylan16807]

You don't have to counterbalance every useful sentence with a toxic message.

[coldtea]

You do, when you're responding to "Do you even know how drivers work? (I'm guessing no, based on this comment)". I'm merely giving them back their toxic comment right back.

[Dylan16807]

I'm not sure how I missed they did it first, but doing it more isn't really helping. Oh well, I shouldn't have said anything, it's not great but it's not worth fussing about.

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.

[wat10000]

Auto-run when inserting a CD worked great, until people realized you could do bad stuff with it. User action must be required to run or install new software.

[jayd16]

OK so you get a pop-up that says "install driver or it won't work" and so you do and then you're at the same situation.

[wat10000]

Or you don’t and you return this piece of garbage for a refund. I hope you can see how this is much superior to auto-installing malware.

[marcosdumay]

> Just that no HW manufacturer thought to push spyware in their driver repos at that point to improve some team's KPIs.

Except for every printer, some popular GPUs, Microsoft's peripherals...