Its funny that you link to the ancient XScreenSaver FAQ; in current X.org servers, Ctrl-Alt-BackSpace is disabled by default, and must be explicitly enabled. Further, on modern systems, XScreenSaver does not need setuid.
Finally, Ctrl-Alt-BackSpace is not a hole in the way that XMir VT switching is a hole. It kills the X server; you end up on the VT that launched X, which takes over the display before it starts processing input. XMir VT switching is far more insidious; you've switched display to the new VT, your input is clearly going to the new VT, and yet the same input is *also* going to the hidden XMir session.
Now, when XMir catches up and discovers that the VT switch has happened, it'll stop accepting input, but that's an unknown time in the future. But (to give an example), if you do what I typically do when X appears to lock up, and press Ctrl-Alt-F2 to get a new VT, wait for the login prompt, and log in as root so that I can examine the state of the system as a whole and make changes, you've now created an opportunity under XMir for a malicious application to stall X with a big chunk of work, and then capture all input. Hey presto, it's caught my root password. Joy.
So the important difference is that in the case mentioned in JWZ's FAQ, I can avoid being caught out by watching the screen. If it changes to a VT, I should stop typing immediately, and then I won't lose more than a character or two to the wrong process. In the XMir case, I have to somehow wait for XMir to catch up, which takes unbounded time thanks to the nature of the X protocol - oh, and I can't examine the state of the system to tell when XMir has caught up.
Re: Security is relative, and short-term user-visible benefit was prolly never the point
Finally, Ctrl-Alt-BackSpace is not a hole in the way that XMir VT switching is a hole. It kills the X server; you end up on the VT that launched X, which takes over the display before it starts processing input. XMir VT switching is far more insidious; you've switched display to the new VT, your input is clearly going to the new VT, and yet the same input is *also* going to the hidden XMir session.
Now, when XMir catches up and discovers that the VT switch has happened, it'll stop accepting input, but that's an unknown time in the future. But (to give an example), if you do what I typically do when X appears to lock up, and press Ctrl-Alt-F2 to get a new VT, wait for the login prompt, and log in as root so that I can examine the state of the system as a whole and make changes, you've now created an opportunity under XMir for a malicious application to stall X with a big chunk of work, and then capture all input. Hey presto, it's caught my root password. Joy.
So the important difference is that in the case mentioned in JWZ's FAQ, I can avoid being caught out by watching the screen. If it changes to a VT, I should stop typing immediately, and then I won't lose more than a character or two to the wrong process. In the XMir case, I have to somehow wait for XMir to catch up, which takes unbounded time thanks to the nature of the X protocol - oh, and I can't examine the state of the system to tell when XMir has caught up.