This is something I've been investigating. If one had a gateway that spoke Reddit's API, the apps wouldn't even really have to pivot, just change the API base URL.
And in theory not even that. As long as the traffic can be redirected to a different server it should still work. In practice, however, at least Apollo has some server-side components so it wouldn't be totally plug-and-play without developer support.
Sadly, I'm not sure how to get in touch with the developers/users who may be interested.
(I've also heard that someone's working on a Reddit/Lemmy gateway, but I don't know who they are or how far they've gotten.)
Some background: Currently PCVR is basically 100% Windows. It's possible to stream VR games from a PC to a standalone headset (ie: with the Quest AirLink) but it depends on network conditions. For example, if both computer and headset are connected via WiFi, and neither has line of sight to the router, performance is likely to be questionable, at best. In theory a computer could use it's own WiFi chipset to make a direct connection, but there's also a WiFi 6 dongle that allows for a direct link between computer and headset.
With that said: Apple already has devices that talk to each other, laptops with high-speed WiFi chips, and now they're making a VR headset. So they have all the parts for a really slick PCVR (er, MacVR?) experience, except the games.
So I 100% don't think the timing is coincidental. They're almost certainly targeting PCVR, although I don't know what they will do with motion controllers. That said, there's still nearly a year until launch, so maybe they haven't shown us everything (or maybe it's not ready).
Edit: should also add that this might be really important for VR gaming because we don't know how much compute is available for apps. However, the dual-chip design implies that a single M2 was not enough for visionOS, which does not bode well.
FWIW, the Quest Pro can do both eye and face tracking on avatars right now, although whatever app you're using needs to support it and it's not yet photorealistic. (Meta's been working on photorealistic avatars but my understanding is they're currently too computationally expensive)
Part of the confusion comes from the fact that there are several different points do be discussed, and they're easy to mix up. For instance: software trust in general, web server security vs repository security, reproducibility, etc.
In this case, even "curl is dangerous" has at least two variations. The first is not knowing what the server is sending, the second is that the server can change what it is sending. My complaint is with the latter.
For example, a file in a repository somewhere or uploaded to a compromised web server is static. Everyone who downloads the file gets the same thing.
A file served by `curl | bash`, however, isn't. The server could send different files at different times of day, or only send malicious payloads to certain IPs (like known TOR exit nodes), or certain geographic locations, etc. which is something no repository I know of is even capable of.
Archives, packages, and installers downloaded from a server (instead of a repository or FTP server or S3 bucket where the attacker controls the file but not the server) share this weakness, so that alone doesn't make curl uniquely dangerous.
Where `curl | bash` differs from installers, however, is that it's interactive, so the server can alter its behavior on the fly. This is dangerous because, with installers, the attacker must commit to sending either a clean or infected payload before the installer can tell them if it's being run or not. In this way, even archives serve as a kind of a poor zero-knowledge proof of what the software is, since the attacker needs to commit to a version before knowing what the user intends to do. There's normally also a file left on disk as well.
With `curl | bash`, however, the server has the unique opportunity to get a callback from the installer before it has finished sending it, which means the server doesn't have to commit to sending malicious code blindly and hoping it's not being saved by someone who intends to audit it. Also, `curl | bash`, by default, leaves no trace, further frustrating auditing/reverse-engineering attempts. (Adding insult to injury, there's no way to check the malicious payload before running it, since running it is what causes it to appear. Even if run inside a VM, this can also be abused by an attacker to try to cover their tracks in real time)
In this way, `curl | bash` allows for obfuscation/anti-debugging techniques that no other method I know of offers. Hence, my opinion that `curl | bash` is "uniquely" dangerous.
Edit: Thinking about this more, this generalizes to any installer that interacts with the network, since all the attacker needs is a way to detect execution and some way to avoid leaving artifacts. In this way, curl is indeed not quite "uniquely" dangerous, since it's tied with other network-based installers. However, since the other popular installation methods don't have the ability to obfuscate their initial payload like this, I think the point still stands. (Obviously feel free to correct me if I overlooked something)
I'm surprised that no one has yet mentioned that piping curl to bash can be detected by the server (previous discussion at https://news.ycombinator.com/item?id=17636032). This allows an attacker to send different code if it's being piped to bash instead of saved to disk.
IMHO, "curl to shell" is uniquely dangerous, since all the other installation vectors mentioned don't support the bait-and-switch.
You might be interested in something like ORWL[1], which is arguably the most secure consumer PC I've ever heard of. It has tamper-resistant features, full disk encryption, and a secure co-processor which does things like disable the USB data paths when the system locks.
Admittedly, though, it's not a laptop.
As far as laptops go, the librem 13[2], with Qubes OS and coreboot would be a pretty good bet.
If you haven't already, definitely take a look at Qubes OS[3]. It offers security by compartmentalizing different workspaces in different vm's managed by Xen so, in theory, even a kernel exploit isn't getting very far into the system.
The buzzword is "risk compensation". There's a whole article on Wikipedia about it (and lots of studies) but, to make a long story short, "measures, designed to improve traffic safety, may bring along negative consequences in a way that individuals increase the riskiness of their driving behaviour because they feel safer (Dulisse, 1997)"
And in theory not even that. As long as the traffic can be redirected to a different server it should still work. In practice, however, at least Apollo has some server-side components so it wouldn't be totally plug-and-play without developer support.
Sadly, I'm not sure how to get in touch with the developers/users who may be interested.
(I've also heard that someone's working on a Reddit/Lemmy gateway, but I don't know who they are or how far they've gotten.)