[Magisk] pndwal:
Most here are aware of that quote, and as has been pointed out, it was private, he didn't 'say it on Reddit', it was only part of a much longer communication and the 'leak' was not appreciated, but my guess is that many colaborators will be in the loop.

I don't think G needs him to spill the beans on 'blocking' Magisk; they're quite aware of how it works. It's source is open, after all...

But if you meant blocking attestation spoofing / bypassing (MagiskHide, some modules, and other), they already know how to make this foolproof. It does require compliant hardware to implement however, and it seems that when some target percentage of devices have launched with tee, a switch will be flipped, and spoofing attestation, and hence MagiskHide at least outside of userspace (ie bootloader Unlocked / verified boot, will become impossible for practical purposes for most users.

MagiskHide will still be able to hide root from apps within userspace, but these can still check secure boot status through tee attestation, and will likely report 'root/jailbreak' but actually mean 'insecure boot environment'.

Expect the pool of those still able to hide bootloader status to be reduced, for practical purposes, to those running custom OSs with inbuilt spoofing or Magisk on devices with launch version < or = to Android 7 (last version without requisite keymaster 3) overnight. (Nb. Hardware-backed Keystore began to be hardened from Android 6)

https://source.android.com/security/keystore

Hardware TEE of course, stands for Trusted Execution Environment, and it is not just implemented by Google.

It actually facilities security in RISC, IBM, AMD, Intel, Apple, as well as Qualcomm, MediaTek, Samsung and Huawei SOCs running various systems. Here's an article focussing on ARM implementation:

https://embeddedbits.org/introduction-to-trusted-execution-environment-tee-arm-trustzone/

Interestingly, it states:

Well, it doesn't bypass it; it gives superuser access as well as ways to overlay mods on an OS, and both things are certainly allowed by design if bootloader is unlocked.

There are ways to prevent such unlocking, but Google doesn't do that. That's not to say they don't know how however. That would be laughable; It is their system (both open source Android framework and proprietary apps). They simply leave that to OEMs to implement, and, of course, a number take such measures.

They NEVER said that.

They have protected their proprietary apps by forbidding bundling GApps with custom ROMs, originally ordering Steve Kondik to 'cease and desist' bundling with CyanogenMod, but offered an olive branch in quick succession when he assumed project was dead, allowing individual users to sideload the same, and sites like OpenGApps to host them.

They have also expressly stated they DON'T oppose either root or custom ROMs, even recently. Eg from Tech Lead for Android hardware-backed security subsystems:

www.twitter.com/shawnwillden/status/1394665579076743175

In line with the above, they state clearly that if you choose to mod your device, "you lose some of the security protection provided by Google", and they do have recommendations, including "Use a different device for important accounts & sensitive data"

https://support.google.com/accounts...s-with-modified-rooted-android-versions?hl=en

Also, rather than prevent their own proprietary apps from running in custom modded systems, they allow these to appear on PlayStore and be used freely. Very few are restricted at all, unless for good (security, corporate partners requirements etc) reason. GPay comes to mind here.

They could, of course, prevent this (especially when HKA is fully functional), simply by requiring PlayProtect Certified Device, but so far they have PURPOSELY allowed custom modders even with uncertified (Chinese etc) devices to add their devices to their online White List that allows them to run the very GApps (without spoofing) that they were prevented from using w/ stock ROMs.

This sets an example to others (wish likes of Maccas would wake up), but SafetyNet API and PlayProtect certification are available for apps / code deemed a security risk... Of course, SafetyNet Implementation can be abused, but Google's stance is that the code's author has the right to be informed about the execution environments status and make such decisions.

Interestingly, it seems not only that Google is unopposed to custom ROMs, but they are not averse to the idea of certifying these / issuing appropriate signing keys so bootloader can be locked to allow full SafetyNet pass (with no spoofing), and GApps can be included legitimately. Of course, this solution evidently precludes root.

The spiritual successor of CyanogenMod, LineageOS, is in a good position to get such an agreement as they already take pains not to 'subvert Google's security model', never bundling GApps, pre-root, signature spoofing (MicroG would come unstuck here 😉) or any other spoofing mods or techniques. Note this conversation between Shawn and Luca Stefani ('Director for LineageAndroid & Developer'):

www.twitter.com/shawnwillden/status/1238161446200127488

That ones been a while (time of initial Google Hardware Key Attestation testing), but I hope we see more on the front. 😛

In short, Google is against subverting their security model, which includes SafetyNet implementation which ALLOWS code to run in insecure environments (even with superuser privileges) WITHOUT subverting it, by making TEE attestation results available to interested parties. Hardware TEE just ensures that the attestation is accurate... And Google didn't invent it either!

Here's a bit I posted re. mainstream influence on Google's decision to implement Hardware backed attestation for for verified boot and Trusted Execution Environment:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-83280363

I don't want to take sides in this; only to give perspective. There's certainly room for many viewpoints. Take what John said on the subject just 4 months ago:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-84398495

... I wonder what he's thinking now! 😜 PW