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.
It is also their first Vision generation, and it is spec:ed more closely to a Mac Pro than anything else really. Which makes me think of this as a devkit to see what devs are going to do with it.
100% agree with you on targeting PCVR Gaming, which is why I am a bit pissed off that they just dragged in wine as an abstraction layer. It means they are not really committing to working with gaming companies, they just want the fruits of their labour and can at any time just yeet that layer out of the OS.
They could have come with Wine at the same time they did Rosetta 2 but they chose not to. Had they done that, then I would have been less suspicious of their motives.
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)
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.
To me, this seems like only a slightly more advanced version of sending malicious payloads only to curl user agents and not something uniquely dangerous.
If I was already using curl to predownload and audit the script, I'd probably just execute the script I already downloaded which would be safe. Most of the people piping to bash directly do no auditing at all because they trust the source. If you're going to put a malicious payload in a script, you don't have to be that tricky about it.
Most people wouldn't know anything was up in any event until someone else discovered the attack and started raising a fuss on social media. I don't think serving the malicious script just to people who pipe it to bash (or really just download it slowly for any reason) would stop everyone from finding out. It would just make the malicious script more notable when found.
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)
The author's rebuttal to user agent attack doesn't rely on how the server decides what content to serve, and so is naturally generalizable to the timing attack. It's unfortunate how that section is named, because it fools people who didn't read the article into thinking they had a novel counterpoint, when in fact the author already anticipated their exact argument.
If the folks at rust-lang.org are malicious and willing to put in some extremely customized web-server logic to serve up evil code when they think it won't be noticed, why wouldn't they just sneak it into ./configure or some unnoticed corner of the compiler's source or the standard library or a precompiled binary?
To be clear, when I go to rust-lang.org, my goal is to download a large amount of extremely complex code that I never plan to audit myself and run it repeatedly on my computer, plus also trust it to download even more code that for the most part I plan to never read, and finally I'm going to trust it to take code and turn it into binaries which at least some of the time will run as root. In fact, it's very hard for me to imagine a scenario where an attacker is able to implement the timing attack in the grandparent post (which, to be clear, is very cool and clever and interesting), but is unable to pwn my computer in a huge number of ways that are both technically simpler and harder for me to detect.
The OP's point, as I understand it, isn't that it's impossible to pwn people via `curl | sh`, it's that in many cases, such an attack doesn't fit into a reasonable threat model.
I disagree. I think "webserver got hacked, and no one noticed" is a very realistic threat model. The webpage tells me to get a script from "sh.rustup.rs" -- what is the security behind this server? How can I be sure that it was not hacked? If the server was hacked, how long would it be before the hack it is detected?
I have full trust in Rust team, but even kernel.org was hacked once! And the worst part, experienced users won't likely to notice that installer does something weird -- because it is fully opaque, and because it
An alternative approach is a manual "git clone". This is way more secure, because the same endpoint and protocol is used by both new users and devs doing daily work.
Can someone compromise dev account and backdoor git repo? Sure. How long before this is detected? Not very long at all, I bet there are people who work on Rust and watch every incoming change.
An unmodified curl invocation does not require weird timing based attacks, it sends an appropriate user-agent header the server can use (and which the article already adresses).
by detecting the usage of `curl | bash` you can serve a different script only when someone does it, so someone doing `curl -O /tmp/some_script.sh` to audit the script wont see the harmful code.
It opens you up to a literally undetectable attack.
nonetheless, the point of the article author does have some truth. there is always a degree of trust involved when you're installing binaries from a third party. by using curl|bash you're just increasing the required trust a bit.
Piping through tee doesn't trigger the sever side detection (it doesn't stop to read every few ms) and using the x flag isn't inherited, so it's gone as soon as subshells are invoked, which is pretty normal for an installation script.
This has all been mentioned in the linked comment thread
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)"
With cycling, in particular, it's not just individuals making judgments about their own safety, either; a 2006 UK study shows that drivers passing cyclists give helmet wearers less clearance, perhaps out of some subconscious sense that they'd do better if they get hit, or maybe that, being risk-averse helmet-wearers, they're less likely to lash out and do something unexpected. (see http://www.helmets.org/walkerstudy.htm )
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.)