I'm a little worried about this, as if this is pushed on EU citizens, could they make it biased against specific political or philosophical searches?? Especially as a more 'conservative' person, I worry if the EU could use this against people trying to search for information that promotes right-wing or right-leaning ideas.

Outside of that, I don't really see the issue with our current search engine list. Google, DuckDuckGo, Brave, Bing, I've never had a issue with them.

@SirMCJeager It's good that you worry, I don't think they will, but only because concerned citizens like you exist.
On what is wrong with that list form an eu standpoint.
I can give you a few suggestions:
Each of these parties is stationed in the USA, which makes them basically by definition non-gdpr compliant, since Trump signed away the privacy shield.
This same Americanity also associates it with Trumps recent instability including his tendency to modify and forbid certain delivery of service in the EU.
Each of these parties has done exactly what you worry about the EU doing and often synchronous for one point, so they've reason to distrust them for that exact reason.

View this comment - View article - View full comments

This sounds like huge news.
Even if it is not that huge anymore physX has been king for long and it could at least allow us to support older titles and probably even compete with what people are using nowadays.

View this comment - View article - View full comments

@CatKiller, which is why each and every of my alternatives doesn't lock down the kernel.
the first one ignores the kernel existence by hardening the executable itself.
The second one only confirms the existence of the trusted functions(how it achieves that is even secondary).
The third one checks behavioral patterns in the firmware.

View this comment - View article - View full comments

@CatKiller
On alternate solutions to anti-cheat compatibility with anti-cheat.
I've been thinking about it and doing research.
I know I'm preaching to the choir, but you still get my proposed solutions.

1. Linktime ASLR(adress space layout randomization). This one is the most research based and the most "open". Most cheats work by mapping out the memory offsets of the program and using these to find the data and code they want to edit. This could be fixed by shipping different memory offsets. In theory all that is needed for this is an advanced linker script and relinking the code every time you ship a binary.
Attackers could still edit one binary and ship it to their customers, but a. that would upgrade their activity to copyright infringement(cheating is arguably legal, since you don't actually copy any code or assets and just modify what the vendor provided) and b. that is easily countered by giving each shipped version a random id and blocking the ones spotted too often from too many different ips at the same time.

There is no security through obscurity in this entire story, so publishing the source code wouldn't harm its effectiveness and you don't even harm individual modders that much.
2. Trusted KASLR(Kernel adress space layout randomization). KASLR is an individual Linux feature that as long it's not compromised should keep more cheaters away than the entire closedness of Windows. It's pretty Linux specific and its aimed goal is to keep hacked compromised kernel code from effectively accessing parts of the kernel it didn't need access to at compile time. It's not perfect, but much better than anything Apple or Microsoft offers. The problem is that it operates purely on your computer and as such you can read and edit it completely.
If you give something with root access the KASLR seed it can check if it has behaved like KASLR should behave, but also compromise KASLR.
The seed also changes every reboot.
I've thought up a protocol through which one can make the KASLR seed predictable only for parties with access to one of all seeds used after initializing it for this protocol, which maintains all the other security guarantees of KASLR, allowing Kernel level anti-cheat providers to provide their own initializing seed and theoretically checking for correct KASLR at their leisure.
The problem is that if one can observe during system boot the seed is used and can thus be extracted.
My hypothesis is that running this initialization step in a trusted execution environment or using homeomorphic encryption could bypass this problem.

Something both these solution have in common is that they're actually better than signed kernels, because they could work even if the entire firmware stack is controlled by the owner of the device.

3. Measured boot could work.

EDIT:
a drawback to solution 1 is that it's platform agnostic and might thus not be such a convincing argument to allow Linux to play a game.
The advantage is that it's the most "open" and vendor trusting solution.

View this comment - View article - View full comments

@Pyrate good observation.
They can't rule Linux gaming.
Valve is already on that path.
They can't rule x86 gaming Valve already does.
They can't rule Mac gaming, Apple does(they're a bad king, but still a king).
Releasing your own console is a risky business.
ARM Windows provides yet untried ground.

View this comment - View article - View full comments

@Purple Library Guy
The plan is solid, but clearly not formulated by a ruthless technogarch.
You took into account market demand and vendor lock-in, but not the logic to expect of others what one exepects of oneself.
It depends on Steam's support for a product that undermines one of their goals.
They could simply detect your xbox handheld and refuse to function.

To make this work assuming Valve is just as much an anti-competitive behemoth as Microsoft one has to convince Valve in some way not to do that stick and/or carrot.

View this comment - View article - View full comments

@TrainDoc for windows software it does help.
Check WineHQ.
Wine was orginally made for exactly that purpose.

View this comment - View article - View full comments

I consider this individual effort as doomed to fail, but Microsoft powerful enough to be a serious threat after this failure.
I think it will at first be incompatible with anything except the Xbox and windows Gamestore.
That will fail and they will open up.
After that it will become interesting.
For pc style gaming Microsoft will need Steam.
Will Valve not actively fight running steam on a young platform with no currently existing market share and an active attempt at undermining their position.
I don't know and for what price.

View this comment - View article - View full comments

@Pyrate I disagree with @Shmerl with that the only way to get supported is downstream support.
Wine is a shining example how with enough effort lack of downstream support can be circumvented.
I do agree that the chance is low.
One would either need to trick the verification system NVIDIA uses to detect their own drivers and reverse engineer the apis or implement their own version through a minefield of patents, reverse engineering, AI copyright problems, etc.
Which one is easier depends on whether you're talking to a lawyer or an engineer.

View this comment - View article - View full comments

A setting that is steadily becoming all that much closer to reality.

Yeah, I quit that job at the (non-mega) corp to do it freelance.
It doesn't yet involve a lot of actual robot psychology like in the game, just a solid understanding of big tech corporation behavior.

View this comment - View article - View full comments