1,419 karma · joined January 23, 2023
I would guess just down clocking the CPU or something.
Declarative, reproducible, and no fiddling with macOS specific stuff.
Plus, we had instructions in our wiki for dealing with homebrew package installation failures and conflicts with macOS-installed versions of required software, needing to install other programs like Ruby version manager, etc to fix these issues. but with Nix I just setup a devshell and got the exact version we needed installed with no issues.
And this can be pinned and reproduced for every developer using Nix, eliminating the hassle for everyone.
Seems it's a design decision not to.
Current cat-and-mouse game is to spoof props to a device that doesn't support hardware attestation, but Google is somehow able to detect props used for spoofing (as opposed to using the actual device with those profs) and bans them.
Once Google decides that enough devices support hardware attestation and they get rid of software attestation, even unlocking the bootloader will trip it and you won't be able to use apps that request this level, and this level is impossible (barring exploits) to spoof.
--E-mail from a Vietnamese student. She got an A in my trigonometry class, dominating the other students despite not knowing much English. Yes, she did work in a nail salon, and no, she didn’t graduate the equivalent of high school in her native country.
What does a nail salon have to do with your point?
From my understanding the BFU state is much harder given that the keys are not in memory but in the TEE. Although there has been exploits for that in the past, not sure if they can extract encryption keys.
It's also interesting to consider what's possible with arbitrary code execution vulnerabilities in early boot stages - would they be able to influence the ARM TZ?
What is this trying to say?