One-Click RCE in Asus's Preinstalled Driver Software

The issue with Bluetooth is that these earphones are ear-specific, and headphones cover both ears so you can't lay on an ear

I listen to audio books while falling asleep, having just one earphone in because I don't want to lay on one (they're plenty sturdy, but my ear is not)

Falling asleep is harder if you want to turn around but need to now look on the nightstand (if available, not always the case in a ho(s)tel room) for where you've left the other one, place the one you took out in the right spot, and your model needs to have pause/play available on both sides so you can extend the sleep timer on the audio book player. Ideally, they also work for meetings because you already have a set of earphones so why not dual-purpose them?

This sounds like a tall order when I write the requirements out, but the second-cheapest earphones models, the variant with a mic and button built into the cable for like 15€ when I last bought a pair, worked just fine ever since I was a child (Nokia 6230i) until now (S10e battery is on its last leg and the screen is discoloring pretty badly, idk what's wrong with this unit, I didn't drop it...). There just aren't performant phones with a headphone jack left, only this Asus "not your phone" device, cheap tablet-sized phones, and old models that won't run modern apps after a few years (not for performance reasons, just minSdk)

The pains of growing old and having to go with the times I guess

> Considering how the submitted article is about a shitty implementation in a regular Windows program, you can be sure the implementation in UEFI is even shittier (may not check certs, may not even use HTTPS, etc)

I don't think it's fair to conflate the security of perpetually running daemon that allows arbitrary instructions from remote endpoints with a manual download that's only initiated in very specific circumstances. Yes, it would be bad not to check certs or use HTTPS, but I'm not sure I buy that this would be "too insecure to fix" compared to trying to allow something to remotely push updates that I never asked for. You don't have to accept that my threat model where I've decided that I'm willing to risk one manually-initiated request that might be somewhat unsafe every few months or so is worth it, but I don't see how you can argue that it's somehow _more_ dangerous than the version that runs continuously at all times and doesn't require any input from me.