Game launcher installs Root CA certificate on your machine (2024) | Hacker News Reader

Game launcher installs Root CA certificate on your machine (2024)

github.com

61 pointsvandalism22 comments

The entitlement of application authors to do whatever the fuck they want on your machine is astounding to me.

Root CAs, background processes 24/7, uploading of the full process list, clipboard spying, local network scanning, surveillance (aka telemetry) - when did developers decide that our machines aren’t ours anymore?

This appears to be a server emulator for the defunct MMO Need for Speed World. My guess is that need they need to spoof the TLS certs and install local host entries to get the original game client to work.

The certificate is used for nothing more other than checking whether the launcher is "signed". The whole scheme is full of security holes, the certificate check mostly seems like it was a programming exercise for the author.

There is no need for the certificate installation with regards to any emulation functioning. Also, worth noting that this is an ongoing issue: this reboot of the game still has a decent daily player count and the CA installation concern has not been addressed, the launcher still does this.

(It's also not a server emulator, it's just a launcher for the game client, used by players of the game.)

Codesigning is expensive. You have to purchase a $500 cert and renew it every year. Or, you can issue your own CA capable of code signing and sign your own stuff. But the OS won't think it's really signed unless the OS also has the CA in it's trust store.

This is just a case of them wanting to save money on code-signing certificate renewal fees.

A code signing certificate does not cost $500 a year. The OP links to an offering by Certum which is just $25 a year plus the cost for a reusable smart card.

Personally, I recently acquired a certificate from HARICA which costs $55 a year if you only buy one year at a time.

Add to the list exfiltration of $ENV (environment variables), which often include secret keys and app tokens. I have seen many young developers expose their $ENV on GitHub when other developers asks them to share their “go env”, or similar commands, while debugging a problem.

It would be nice if desktop software had to explicitly request access to different APIs on the system (network, filesystem, etc) as well as only request access to specific filesystem paths, then give us prompts that list the permissions that the app wants. Something like pledge (https://man.openbsd.org/pledge.2) from OpenBSD/Serenity but integrated into the desktop systems GUI.

That would indeed be very nice, compared to the current standards out there for desktops...

Ironically, I -think- UWP tried to 'solve' this in some ways but OTOH adds new problems instead...

I also know Microsoft had a different idea when it came to .NET before core, where libraries could be run in 'Partial trust' but with 'Link Demands'... And I've never seen a shop actually do that right vs just YOLOing with 'full trust' and/or abuse of AllowPartiallyTrustedCallersAttribute...

Which I guess is a roundabout way of saying I feel like Microsoft has tried twice but completely lost the plot early on and failed to deliver a usable product (What even is the state of UWP questionmark, and .NET Code Access Security was given up in Core....)

MacOS has been moving more and more in this direction, and it’s good.

The alternative being a walled garden like Apple or (increasingly) Android, where they don't have access to anything (at least without a prompt asking if you grant said permission). If you run a system that lets you do what you want to it, you need to accept that others might try to do what they want to it, too.

Prompts are completely fine. I am happy with the prompts GrapheneOS offers me

Reply on news.ycombinator.com