One thing that ultimately allowed the impact of this event to be greatly reduced is that Android devices do not check the expiration date of the Root CA Certificate when establishing trust in the certificate chain... This means that it is still possible to anchor on the expired IdenTrust Root CA, and those Android devices would work, //

The 'New Default Chain' still ultimately anchors on the IdenTrust Root CA, meaning compatibility with Android devices that won't check the expiration date, but it passes through the new Let's Encrypt ISRG Root X1 CA which more modern clients will have in their trust store. This means those modern clients will stop the chain there and accept it as trusted too. Win-win. //

One interesting side effect of this though is that you can then modify the Root Certificates in the trust store and because no signature validation is taking place, meaning no integrity check is taking place, the modified Root Certificate will be treated as perfectly valid. This is the part that I'd never thought about. //

When first thinking about this issue, I felt a little bit like I did when I first found out, all those years ago, about signatures not being validated on roots and how that seemed ridiculous. Once you think about this more though, you realise that it does make sense and that it just doesn't seem logical upon first thought. In order to make this change and it actually have an effect on the client, you need to have access to that client with administrative privileges to change the root store. If your concern is that an attacker might do something like this, well, I'd suggest you have far bigger issues to concern yourself with given that the attacker has admin/root and is on your device!