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.

I couldn't find a really good demo, but this should give a decent idea: https://www.youtube.com/watch?v=lt0O4_56_qE

Meta also announced plans to use face tracked avatars for video calling in What's App and Messenger, although I'm not sure the status of that.

Apps on iOS are kept encrypted until runtime, presumably to deter piracy.

Obviously this makes reverse engineering/studying apps difficult, hence all the interest in a way to get unencrypted apps

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)

IMHO, "curl to shell" is uniquely dangerous, since all the other installation vectors mentioned don't support the bait-and-switch.

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.

[1] https://www.crowdsupply.com/design-shift/orwl [2] https://puri.sm/librem-13/ [3] https://www.qubes-os.org