[embedding-shape]

I don't see any details in any of the texts I came across, but in theory the implementation could be that Windows sees the ID of the monitor once connected through any sort of connection, then when matching ID is found it installs the malware. Rather than the installer is sent from the monitor to the computer. Would make updates a lot easier, and if they really want to spread this malware, can activate it for a lot more monitors.

[jdw64]

Most commercial solutions are Windows-based and use the Windows API. HDMI and DP also have two-way communication channels. This is something you learn when you do hardware coding.(Of course you already know this, but this is for the other people reading this comment.)

Typically, the Windows update server downloads packages mapped to hardware IDs in the background. Since LG's business in Korea has been failing and their AI efforts are stagnating, they exploited their McAfee partnership marketing as a pipeline. Windows' Plug and Play does make development convenient. The DX experience is good.

Linux is quite fragmented. That's good from a 'my computer' perspective, but not from a 'product' perspective. And then there's the jitter issue. Windows has stable paid solutions, while Linux has version discrepancies.

In fact, the reason Linux is considered secure is simply because hardware vendors haven't standardized enough to build automatic deployment pipelines.

In programming terms, we all know singleton is bad, but for Plug and Play, it's overwhelmingly convenient.

[drnick1]

> In fact, the reason Linux is considered secure is simply because hardware vendors haven't standardized enough to build automatic deployment pipelines.

The Linux security model (sudo to install or update software) doesn't allow this. No reputable distribution would include a program that scans hardware identifiers and prompts the user for permission to install proprietary software from a third-party source. This is possible on Windows because of the "universal backdoor," aka Windows Update, with Microsoft's consent.

[zahlman]

> simply because hardware vendors haven't standardized enough to build automatic deployment pipelines

Wouldn't it require cooperation from the distros anyway? You say "HDMI and DP also have two-way communication channels", but that doesn't force the OS to communicate over those channels. And it also doesn't force the "mapping of packages to hardware IDs" to be what the hardware manufacturer wants it to be.

[jdw64]

Your point is idealistically correct, but realistically it's not. Because when people install Windows, they don't want to go through the process of installing drivers for other hardware devices. And usually the driver versions depend on the OS version too.

Right away, with numerous distributions like Ubuntu and Arch, it's hard to account for all the possible cases from a production standpoint. But Windows has very few versions. As long as you pass Microsoft's standard specification, it just runs on Windows. That difference is huge. What you're saying is ideal, but when selling a product, time is money.

In other words, to summarize our conversation:

'As you said, separating them is the right thing to do. But UX Uesrs basically wanted that kind of deployment authority, and in the process, the problem of abusing it arose.'

It's a beginner level problem, but at the same time, it's also a difficult one.

[onaclov2000]

That makes some sense to me, I think for some reason my brain assumed they were like actively controlling the PC to download things other than updates, (and low key assumed part of this update was supposed to be for software on the monitor not the desktop)