[Magisk] pndwal:
The reasoning really had not so much to do with root. Many apps will declare root / jailbreak if they detect any modification to TEE (Trusted Execution environment).

As such, Magisk / John / other devs and modders can do nothing to improve this without hiding / spoofing SafetyNet attestation to TEE, CTS (Compatibility Test Suite) result and Play Protect certification, or other flags indicating TEE has been modified.

However Tee is not broken by root; a 'chain of trust' is broken as soon as bootloader is unlocked these days (was different once), and new flags are set for non-verified boot. AVB (Android Verified Boot) and associated DM-Verity (device-mapper-verity kernel feature) have been added / improved since Android 4.4.

- https://source.android.com/security/verifiedboot

- https://source.android.com/security/verifiedboot/dm-verity

Magisk / root simply gives mods more permissions than the apps / processes that detect have to hide such traces.

Well actually denylist does work for such apps exactly as intended!

Further re. this John recently said:

So John states clearly that while he won't work on these personally, 'modules can either utilize the DenyList feature for "hiding" purposes or do everything needed for hiding prrposes tthemselves'. Such 'invasive methods (the only way to workaround HW KA.)' will need to be implemented by others and he says outright 'spending effort such on hide modules is much more productive than Magisk forks'. Earlier he even stated that these would be trivial to produce.

Unfortunately:

Yes, John actually continues to make the Magisk framework 'more capable of hiding things' despite what nay-sayers argue. He's both done us invaluable service and continues to do so.

Fair point? 😬

I think it's pretty clear from the above that John won't be adding this (or old MagiskHide) back as it involves 'invasive methods' that 'attempt to manipulate other signals on the device', and as he said in his recent 'State of Magisk 2021' article

I discussed above how a chain-of-trust used by AVB and DM-Verity is broken if any such modification is made, including unlocking. Effectively there is no TEE any longer in which to execute code. Really, it's the security of the whole code execution environment that concerns them as it is precisely that that allows you / others to 'mess with' (hack) their app.

I've mentioned Google's stance on this here before:

I put a bit more here:

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

And this has info on Googles own concessions to modders:

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

John / community has known that effective hiding days are numbered since Google first switched on the newer form of TEE, HK TEE attestation (Hardware Key based TEE) Seems we've been in a testing phase for some time, possibly already longer than expected due to OEMs like OnePlus botching required hardware implementation, but that the switch (aka BIG hammer) for enforcing hardware TEE (no more fallbacks to Basic attestation) could be thrown at any tick of the clock (aka final whistle / game over).

In the meantime (while SafetyNet attestation remains unreliable at best), banks / other parties are resorting to myriad 'custom' ways to detect untrusted (read any modified) environments ('root' in very loose sense) to prevent their code running in these.

A simple way to see the issue is to envisage GPay or bank apps set up to call GPay etc to make payments on such a device. You may think these are secure enough, but if stolen such a device can be a windfall for the unscrupulous; they can likely simply unlock the device using an active ADB (Android Debug Bridge) or installed TWRP and make payments (empty your bank account), access bank / other details etc... Banks want to protect you from now widespread fraud as well as to protect themselves from litigation etc. Also, they will often cover losses from such fraud for customers but need to ensure no doors are left open to abuse for obvious reasons at the same time as such costs are rising every day... There are many more reasons these institutions don't want their code running in untrusted environments (read on devices with any changes OS including bootloader and other partitions) also.

In summary, don't expect John to do any more re. hiding... He's done plenty.

Hopefully we'll see @kdrag0n and other skilled Devs passionate about hiding continue / start "doing their job"!

'Enjoy it while you can!' 😅 PW