Nothing. This is just a proof of concept that is ridiculously easy to detect. If your attackers can drop files in your /boot or /boot/efi directory, I think you have much worse things to worry about than this.
In fact, this bootkit would be about the least thing I would worry about. Because by the time an attack can write to /boot, they can also write to /etc/init.d . And the later is not protected by "secure boot".
How is an infection hidden somewhere in the friggin entire rootfs easier to detect and remove that one that literally replaces the one file for your kernel /boot ? What advantage could the latter possibly have ? Not to mention that something from a bootkit bootstrapping an infection in the root filesystem is the realm of useless tech demos like this one; while for something that can already write your rootfs, infecting the kernel is trivial.
The entire boot system has much, much fewer places for malware to hide compared to the entire "rootkit" OS attack surface which is astronomically larger. Secure Boot has always targeted the smaller and most useless of the swiss cheese holes.
No, I wasn't "asked" by the browser publisher to trust them unless you use the word "ask" in a very broad (almost to the point of meaninglessness) sense: when I installed my browser, it simply started using its pre-packaged bundle of CA certificates. Which it regularly updates, I imagine, although it also never asked me about what the update source I'd like to use either.
You can say that I implicitly trust the browser vendor's judgement in what CAs to trust, by the virtue of using the browser, and I'd agree with that. But saying that I was asked by the browser publisher to trust them? No, I disagree, I wasn't. It was a silent decision.