> Riot went as far as pushing a UEFI firmware update to Valorant players to close a hardware attack — the first time an anti-cheat has reached below the operating system to change your firmware
I don't believe Vanguard did this at all? It told users they need to update their firmware to play, it didn't touch the firmware itself.
> Cheats started in user space, so anti-cheat moved into the kernel to see them. Cheats followed into the kernel, and then below it into hypervisors
I think cheats moved into kernel space before anti-cheats did.
> Even with a rooted phone you can't mess or snoop on data in the trusted execution environment
A rooted phone can have a modified runtime/kernel that can inject code into whatever processes it sees fit, including Google Pay.
Which can expose information being sent to and read from the TEE by the app.
> Plain wrong. PSD3 does not apply to "digital wallets" [1] ("This Directive also does not cover, in its scope, the provision of technical services including processing or the operation of digital wallets.").
The legislation still applies to the bank behind Google Pay.
I think some of these game studios got so content with Microsoft constantly paying that they forgot to make games that would actually sell.
South of Midnight took 7 years to make and cost $100 million to make... yet sold hardly any copies and I'm not even sure who they were trying to make it for.
Meanwhile you have studios like Sandfall and Warhorse pumping out games on a fraction of the budget that ship millions (and imho, make better games).
PCI-DSS (enforced by banks/payment processors) means the EMV token store on your Android phone must be in an isolated uncompromised location (usually the TEE).
If your phone is rooted or has an unlocked bootloader then it's possible that trusted store is no longer secure or can be snooped on by a third party. Given Google Wallet/Pay handles EMV tokens and stores them on the phone, it has to pass PCI-DSS before banks will allow it.
This is the biggest reason why Google tries as much as possible to block Google Pay on rooted/unlocked devices. If a device fails compliance (a rooted phone certainly does), as far as banks are concerned it's not safe.
But people just find it easier to say "Google is Evil".
You also have the EUs Payment Services Directive (so a law) which require strong customer authentication, rooted devices can also fail up here. If anyone else than the user is able to unlock the screen (and thus authenticate a payment), you've failed the Payment Services Directive.
It doesn't run GNOME Shell, which is the main memory hog of GNOME.
It uses some GNOME services, namely so it doesn't have to invent it's own. None of these services are memory heavy and all have a purpose (e.g. managing Bluetooth)
> but good news, Nebula Security found it before attackers do.
Which is why they released the code to the exploit before it's been patched, meaning bad actors now likely have months to profit off it before a meaningful % of devices are patched.