iscoelho
You used AI to write that, didn't you? Please don't do that, it's disrespectful.
2) Tailscale's control plane model for peer distribution avoids every concern affecting IPsec in regard to protocol negotiation security and compatibility.
TL;DR, diverging from WireGuard & supporting AES (via protocol negotiation with hardware acceleration), would be relatively painless.
1) the WireGuard kernel implementation, despite not even being zero-copy, exceeds the performance of the userspace implementation
2) implementations utilizing the userspace network stack have a maximum potential performance (context switch + memcpy is very slow, and that affects UDP disproportionately). It's the wrong approach for meaningful improvement.
So it's not that simple: it's impossible for Tailscale to use any existing kernel or accelerated WireGuard implementation. They could derive inspiration, but a kernel module for Linux won't fix Windows & Mac. With that said, I feel they have enough funding to maintain a few platforms (:
It is slow. It cannot achieve speeds of greater than 1Gbps on clients systems (Windows & Mac), where you'd normally see it being used. On Linux, it struggles to achieve 10Gbps even when using a synthetic large packet benchmark [1]. With an IMIX benchmark, it would not be competitive whatsoever.
This problem is fixable. WireGuard achieves higher performance (Kernel vs Userspace implementation) and IPsec implementations can achieve 100Gbps/400Gbps (DPDK/XDP). Zero-copy networking.
From this blog post, I can say Tailscale still seems to not have the appetite for that, which is a shame.
Etcd corruption and loss of quorum is extremely common in practice and the GitHub issues sit for years. The design is simple, the performance is modest, yet it still has still never been reliable, despite being marketed as so. I can't speak to whether this is specifically due to their Raft implementation, but I'd argue the entire codebase is over-engineered and questionable.
[1] https://elegantnetwork.github.io/posts/comparing-open-source...
The entire point of the iPhone Upgrade Program was to make it painless to swap to the newest iPhone every year. Without that, there's no value proposition.
If you are successfully baited and detected, you also get HWID banned, so it only takes once. This makes cheating via pixel bot unviable.
On the contrary, DMA is so desired because it eliminates this risk.
1) When DMA is fully blocked, Aimbot resorts to being a pixel bot.
2) Once you're relying on a pixel bot, all the anti-cheat has to do is "bait" the bot. After you click the bait a few times, you're banned. (:
RuneScape is actually the pioneer of this technique.
1) There's too many players.
2) Closet cheaters are extremely subjective: automated & manual moderation would be full of false positives. In these cases, functional anti-cheats actually serve to vindicate these players.
I'm sad I'm not seeing that honesty elsewhere in this thread.
As for faking the input device: I'm sure it's possible, but I'm also sure that perfectly spoofing an input device is much easier said than done.
Even if it is possible, all they have to do is make it hard enough to where the percentage of players cheating is at the point where you will rarely if ever encounter a cheater in your matches. As far as I'm aware, Valorant is one of the only games that has accomplished that.
You can already completely compromise the average user's privacy with an underprivileged process (nearly all of your personal information is accessible with zero privileges!), and you can already persist with administrator privileges (that is routinely given on Windows).
In regard to the "RCE attacker risk", attackers can RCE to escalate just as easily into vulnerable Windows services (there's too many to count). Kernel drivers aren't that special.
In regard to the "CrowdStrike risk", that's not privacy related and is extremely overblown.
What exactly does a kernel driver change regarding privacy? Nothing I can think of.
It's this simple: If games want your personal data, they don't need a kernel driver to get it.
1) only allows a single mouse input device at a time
2) completely ignores virtual mouse input
3) flags "special"/"uncommon" input devices
Their anti-cheat is actually much more involved and effective than most would assume.
Just for fun (not saying I believe this!): Did you ever consider that a malicious Microsoft employee may have intentionally planted this exploit? They don't have access to signing keys. They aren't able to make custom firmware. However, what they can do is leave innocent looking code in Windows that they and their co-conspirators can exploit later. Completely possible (-:
> I think that level of pushback against the claims is a valid (and small) amount of "downplaying". I haven't seen anyone claiming this isn't a serious issue.
If you look in the other threads about this, it's much more obvious. Look for brand new users. There's comparatively few in this thread, but the pattern is there: if the user's name is green, they're downplaying this.
This exploit is only ever relevant with BitLocker enabled (as a method to "bypass" BitLocker's security premise [categorically classifying this as, dare I say, a "BitLocker bypass"]).
To avoid typing 1)2)3)4) a bunch of more times, I'll just say 2/3/4) all still fit the definition of downplaying the situation.