No, that's security through secrecy, not obscurity. That's the difference between "This piece of text is encrypted with a mechanism, I don't know what algorithm.", and "This piece of text is encrypted with the old Ceasar Cipher.", and "This piece of text is encrypted with IDEA.". Statement 1 is using security through obscurity. You don't even know how to proceed. Statements 2 and 3 are using security through secrecy. You know what algorithm they're using so you know _how_ to decode it, if you know the secret key. How is this different than statement 1? The difference is that you happen to know that the Ceasar Cipher is trivial to brute-force, IDEA not so much. (Of course this doesn't mean that "security through secrecy" is guaranteed better than obscurity, just that obscurity is simply hoping that someone doesn't discover your vulnerable spot.)

It does. Tried to change the "sleep time" and kaboom. Not even something weird, just changing a normal setting.

Look up a product called the FrogPad. One-handed keyboard (comes in left and right-handed versions). Does punctuation and backspace (and arrows, and other special keys).

Pointing at the wrong failure. CRLs aren't the problem here. The CA that's publishing the CRL is. If the user is validating certs, and the cert cannot be validated, then they cannot know that they are dealing with Bob's Computer Bits, or Dewey Screwem and Howe.

So you're misusing the system, and complaining. When you revoke the old cert, you are stating that it is no longer to be trusted. And now you complain when it says "don't trust this"? I guess a car analogy: (Where I live, you are required to have proof of insurance stickers on your license plate.) You give a properly insured car to your buddy. 2 days later you go and remove the insurance stickers from the car. A week later, your friend is pissed off because the cops gave him a ticket for being uninsured. "But it was insured when I gave it to him."

And this is the problem with security. People want the security/safety.... unless it's inconvenient. And yes, there is something "wrong" with the certificate. It is unverifiable as to whether it is still valid. Which you asked it to do.

Note the "lets say OmniGraffle". Pick an app which is only distributed via the App Store. Say, the Blink SIP soft phone. Both the Lite and Pro versions are only available through the App Store.

But you have not said anything about how this applies to IT shops. How do I buy 30 licenses for (lets say OmniGraffle). How does one then assign those licenses to the 30 people that need them? Then later I fire #14 and hire a new person? So far the options are: 1) Buy the app under the employee's own Apple ID. But then #14 takes a copy of the software when he leaves. 2) Buy the app under the employee's corporate Apple ID. But then #14's Apple ID isn't in the company anymore, and nobody has that license. 3) Buy the app under some anonymous corporate Apple ID. (emp14@example.com). When I replace #14, the replacement gets _all_ of the Apps that #14 had. And #3 has another problem that IT would have to retain (and manage) the passwords to all of the emp## accounts as the App literally has to be bought under that account, so IT would need to change the password, attach a credit card, buy the app, detach the credit card, change the password back. Previously, one would buy 30 licenses of OmniGraffle, download the .dmg file, install on the appropriate 30 machines.

Don't do that either.

The objection that I see is that the platform supports the capability of loading arbitrary OSes, but if the manufacturer wants to run Windows on it, they must go out of their way to make it more difficult for the end user to run other OSes. As opposed to declaring that the device must be shipped in the way that enforces signed bootloaders, but the end-user may turn that enforcement off to load their own arbitrary OSes.