It could probably be argued that the board didn’t do what was best for the investors, which is what they exist to do.
Incorrect. OpenAI LLC (the traded company) does not have a board of directors. The board of directors actually belong to the parent company, simply “OpenAI”, which is a nonprofit organization – the only thing that they’re beholden to is the OpenAI company charter.
Here’s a simplified breakdown:
Board of Directors =[controls]=> OpenAI (non-profit) =[controls]=> OpenAI LLC =[employs]=> OpenAI CEO
OpenAI LLC is obligated to act in the best financial interest of their shareholders, but OpenAI LLC does not actually have control over who sits in the CEO chair. That power goes to the non-profit “OpenAI” parent company – a company beholden to their board, not shareholders.
Wayland is Wayland. If you use a Wayland compositor, you’re getting a lot of security by virtue of design alone. Things like keyloggers and screenrecorders will not be able to intrude on your session barring vulnerability exploits. I’m not going to touch on the relative vulnerability risk of each environment since a) they’re all relatively new & b) I’ve never implemented Wayland myself
With that being said, here’s what’s not protected by Wayland regardless of the chosen compositor: microphones, webcams, keyrings, and files.
For microphones & webcams, any distro which rolls Pipewire in combination with Wayland will be sufficient to secure these. Pretty much all Wayland environments roll Pipewire so this is only important to consider if you’re running your own customized environment (be sure to disable any pre-existing PulseAudio daemon after setting up Pipewire to close this security hole)
For keyrings, these are handled by your environment’s polkit implementation. Much like Wayland, there are several implementations of polkit and they’re all just about equally secure barring any potential vulnerabilities… Just make sure that you’re using an encrypted database (usually on by default) and that you have it configured to always relock & properly prompt for the unlock key.
For file access, this is actually a core probelm with Linux as a whole – any unsandboxed application you run will be able to read any file that you can read. The solution is to use sandboxed applications whenever possible. The easiest way to achieve this is through using flathub/flatpak applications, since they will always list out and enforce their required permissions on a per-application basis. For non-flatkpak applications, you’ll need to use “jail” environments (e.g.: bubblejail, firejail) in order to artificially restrict application permissions by hand.