You should try some good homemade lutefisk. No, not just lutefisk, that's like judging burgers by only eating the patty. Rather with all the accoutrements: fried bacon, pea stew, boiled cherry potatoes, and white sauce.
"GOG GALAXY is a long-lived product with a large and complex C++ codebase." Also known as a shitshow. Hopefully the new engineer(s) will be encouraged to at least add some tests and refactor things to stay sane.
No mention of a license, though. I guess it'll stay closed source.
GOG's original and somewhat current line in the sand is "must have an offline-capable installer". For a lot of Good Old Games that is enough to guarantee DRM-free. Unfortunately in the Live Service world it is a concession that allows too many loopholes such as Sony single player games that still need a PlayStation Account and a half-dozen telemetry services active before they get to actual gameplay. Sony, as a particular example worth flogging, also makes use of the loophole that an anti-cheat rootkit can be installed offline, easy.
I think GOG is saying a lot of the right things in terms of Game Preservation being a long term goal for them. I think they are between a rock and a hard place that the store would be a lot less active if they couldn't offer the latest games from companies like Sony, and they want to be on good terms with such companies to get access to their giant back catalogs for Preservation efforts which also presumably includes sales numbers of recent titles for justification.
But yes, I'd also love to see them push back a bit harder on some of these publishers a bit further than "needs an offline-capable installer" and mabye include more steps towards some definition of "should run offline-capable", because yeah things like "Live Services" and account systems and mandatory telemetry systems and rootkit anti-cheat systems are often de facto DRM just wearing another hat of "user convenience" or "achievement tracking" or "game safety" tools. I don't think GOG can make that push alone, though. There are too many industry trends to try to buck to get further in those directions. (Thinking about the recent Anthem shutdown as a recent for instance of a mostly single player game that is entirely unplayable because EA shutdown live services this month.)
There are no games on GOG which require a PlayStation account for their single player gameplay. (AFAIK, but I think I'm pretty tuned in and would know.)
It was an early complaint about Horizon: Zero Dawn, especially but not uniquely, on GOG. Sony did walk that requirement back several months after the complaints started, but it wasn't directly because they thought they violated any of GOG's explicit policies, it seemed more directly due to the user complaints and review bombing on Steam from what I saw.
To be clear: if you buy Disco Elysium on GOG, download the "offline game installer" without using Galaxy, install it, and run the game on a desert island, it will work (the network requests fail open). But if you try to run the game after removing the bundled dylib/DLL, it will not.
Why do Galaxy-free games ship with a mandatory dependency on Galaxy?
> Why do Galaxy-free games ship with a mandatory dependency on Galaxy?
Because the developer linked the dynamic library in at compile time instead of writing additional code to load it at runtime and disabling/enabling features based on its presence.
You can call it budget limitations, incompetence or lack of respect for the customer. Doubt it's intentional DRM though.
Many games with multiplayer features require Galaxy for those multiplayer features. You can consider this DRM-equivalent if you want. However, every singleplayer game on GOG will work without Galaxy installed, and that singleplayer gameplay will be completely DRM-free in every possible way. (That's at least 99.6% of the games on GOG, but eyeballing the 22 games which don't specify that they're singleplayer games, most of them simply have incomplete metadata, so it's really 99.9% of them.)
Off the top of my head Crime Cities on launch forced me to use Galaxy to play it. I vividly remember this because the game also ran like complete crap.
Galaxy can be required for multiplayer aspects in games, but if what you say is true for the singleplayer part of the game, GOG will consider it a bug, and will get it fixed.
There's nothing in the Crime Cities GOG forum about this, nor in the various tracking threads in the main forum, and generally GOG users are extremely sensitive about anything which even reeks of forcing Galaxy, so I'd strongly expect any issue to be known.
I've seen cases where the developer implemented a bad online check, so that if you blocked the program from accessing the internet while the OS reported being online, the game would hang or crash, but being fully offline would work. Could it be that something like that was at play here? Oh, or that you simply picked the wrong installer for the game, and thus ran the Galaxy-installer rather than the offline installer?
I think too it can be misleading since on Windows the default LNK shortcut that is created after the game installation launches Galaxy with arguments instead of being a path to the direct game EXE (which works entirely without Galaxy and how I run games).
They do this to push Galaxy for convenience I suppose as most are used to clients that handle updates but it can be confusing if some wonder why for instance their offline installer shortcut opened Galaxy instead.
If the wine experience is anything to go by, if you don't have Galaxy installed at all, the shortcuts will also just point to the .exe - but yeah, I suspect it must be something like this.
> on Windows the default LNK shortcut that is created after the game installation launches Galaxy with arguments instead of being a path to the direct game EXE
I had Crime Cities lying around since it was a freebie on GOG many years ago, so I just went ahead and installed it using vanilla wine. There was absolutely no Galaxy requirement for installing or playing the single player part of the game.
Not quite. You can use Galaxy to download the offline installers (or just do that through the website), but when you install a game through Galaxy, it downloads a special build which it just copies to the right location, without running a separate installer.
The running game can also call out to Galaxy and unlock, or not unlock, ingame content based on what it hears back. It's pretty difficult to imagine a definition of "digital rights management" that doesn't include this.
As far as I remember, the only games which optionally need Galaxy running are those will online multiplayer, and only if you want to play online. This is because the original developers shutdown their own servers for matchmaking or originally used Steam servers for that. GOG servers are only replacing those.
There are also a handful of games which put some additional purely cosmetic content behind an online check. That could be the start of a slippery slope, which people are justly upset about, but they then do an injustice to their cause by generalizing from those cases.
It's not a slippery slope but already full blown DRM plain and simple. Both online functionality limited to GOG-run servers and checks for cosmetic content.
Note that for Gloomhaven, the multiplayer server is one of the players' computers. That player hosts a game and everyone else joins. There are no GOG servers and no company servers.
In version 1.0 of the GOG release, multiplayer is enabled.
In subsequent versions, multiplayer is disabled (in the sense that the button to host or join a game is greyed out) unless the game succeeds at verifying you through Galaxy. (And this is a dynamic status; you can have it enabled, shut off Galaxy, restart the game, and find that it's disabled again.
Which ones? Honest question. I only remember games for which GOG apologizes in their store page for missing cosmetics or extra features because originally tied to online services (e.g. the Mafia or Yakuza games), or ones in which they are unlocked by default for the same reason (e.g. Dragon Age Origins).
If we have DRM with some private key, then I guess your idea is I download the game files and some private key and that allows me to run the game.
If I can send you the private key and the game and it allows you to run the game with no further inputs, then the DRM is trivially broken (even without open source).
If it does some online check, then if the source is open we can easily make a version that bypasses the online check.
If there is some check on the local PC (e.g. the key only works if some hardware ID is set correctly), we can easily find out what it checks, capture that information, package it, and make a new version of the launcher that uses this packaged data instead of the real machine data.
If you use a private key to go online and retrieve more data, having it be open source makes it trivial to capture that data, package it, and write a new version of the launcher that uses that packaged data.
Basically, DRM requires that there is something that is not easy to copy, and it being open source makes it a lot easier to copy.
- the game payload is sent to you encrypted using the public key of a secure enclave on your computer
- while the game runs all its memory is symmetrically encrypted (by your own CPU) using a key private to that secure enclave. It is only decrypted in the CPU's cache lines, which are flushed when the core runs anything other than the game (even OS code)
- the secure enclave refuses to switch to the context in which the CPU is allowed to use the decryption key unless a convolution-only (not overwriteable with arbitrary values) register inside itself had the correct value
- the convolution-only register is written with the "wrong" value, by your own computer's firmware, if you use a bootloader that is not trusted by the DRM system to disallow faking the register (ie, you need secure boot and a trusted OS)
That doesn't seem to fit in any of your models. There's no online check, you can't send someone else the key because it's held in hostile-to-you hardware, you can't bypass the local-PC check because it's entirely opaque to you (even the contents of RAM are encrypted). You can crack into a CPU itself I guess?
I don't think the mechanism of the DRM being open source helps with the copying AT ALL in this design.
This design is, by the way, quite realistic: most modern CPUs support MK-TME (encrypted RAM mediated by a TPM) and all Windows 11 PCs have a TPM. Companies just haven't gotten there yet.
I don't know about how secure enclaves work, so this may be a solution I'm not aware of. Thank you for explaining!
So I guess the whole game software, or at least a significant part, is loaded encrypted and runs encrypted. It's on the users hardware but the user can't access it.
The only thing I can think of: You say the game payload is encrypted using the public key of a secure enclave. This means the open source game launcher has to pass the public key to the server doing the encryption. Could you not supply a fake public key that goes to a virtual secure enclave? I guess the public key could be signed by intel or something, is that something that happens on current TPMs?
Would it even be possible to do this if the program had to run under Proton/Wine? The original subject here is the launcher running on Linux.
I do wander about the use of an open source launcher at this point though. As someone who prefers open source software, the idea of encrypted software running on my PC makes me uncomfortable, more than just closed source software.
The public key is in fact signed by Intel and uniquely serialized to the TPM.
If the game manufacturer requires TPM register values that match Windows, it will not run under Proton/Wine (or a Windows VM). If they allow TPM register values for Linux it will run under Linux too.
Maybe it's time for some decently funded other organisation (not a teracorp) to take over Firefox specifically, then let Mozilla go its own way into the sunset. No idea how that could be arranged, though.
Just about every week I find "new" GitLab bugs which, after a quick search, turn out to be 5+ years old, with lots of community engagement, but seemingly zero movement from GitLab itself. I wonder what GitLab devs actually work on, because none of the new features in the last couple of years seem as impactful as fixing one of those bugs would be. (I still prefer it to GitHub, especially the CI model.)
"May shrink on first washing" or something like it seems to be pretty common; you might've accidentally tried something on which had that labelling (or didn't, which would suck).
No mention of value engineering? Isn't that what every big company does to a successful product? Barely-noticeable quality decreases compound over years, and more noticeable ones are rationalized away as necessary for survival. It doesn't take a genius to see where that leads.
Also enshittification, the more general trend where an initial offering is excellent, maybe even provided at a loss, to spread the word and provide great feedback, and then more and more money is squeezed out of it while riding consumer satisfaction lag, until the offering is taken behind the shed and mercy killed.
reply