No, it won't make it more vulnerable. Security by obscurity is not a proper security approach. Security is achieved by the means of proper authentication, encryption and etc. The code of the authenticating client and the protocol of authentication and encryption if any can be perfectly open and known. It won't make the system any less secure, if the authentication and backend security are properly implemented. If anything, obscurity only reduces security, since the closed client can't be fully trusted.

That being said, it gets two thumbs up from me....it'd certainly be nice to have the choice to use such an updater, at the very least

I'd rather see them publish a documented web API for account information, game management, and the community, then let people run with whatever they want to do.

It seems like a waste of resources for them to develop a Steam-like client and then deal with the challenge of managing an open source community. I'd rather them continue to focus on the games and let the community take care of the rest.

Shinook: First of all, if GOG is to going to develop such a thing (incremental updates functionality), they will have to develop the backend for it, i.e. server side, the services which manage updates and etc. As well as the protocol of how all this would communicate with the client. Then they'll for sure develop their own client for it, don't you know GOG? My point was that this client can be open source to enhance trust. Of course if the protocols and APIs would be published and documented community can develop alternative clients. But that wasn't the main point of the request.

Why I think GOG is going to develop such a thing. Simple answer - competition. In order to compete with Steam GOG will have to provide even higher level of usability. And incremental updates come to mind right away.

GOG, listen to shmerl. He's a smart cookie. GOG would gain so much good will from the Linux community and the open source community at large if this were to happen. My wallet would empty itself quicker than ever before as well, much to my detriment.

Future_Suture: GOG will surely decide for themselves, but at least I wanted to give some food for thought :) There can be several barriers for making such client in practice. First unfamiliarity with managing an open source project. Second, it requires one to chose technologies properly, and if for example GOG would use something not open (3rd party technology), this can bar them from opening the client. But I'm still hopeful that this should be possible.

While I'm avid supporter of open source I think for this specific case also a good web-based approach would do to.
I mean, the core problem at the moment is that the cadence of updates for NEW games is to slow and having GOG as (unneeded?) man-in-middle. Could be solved if it would be allowed that the trusted and caring game developer themself can push stand-alone patches to the GOG game library.

When GOG would decide to go the game client way, cooperation with existing Open source game update clients could be considered: e.g. or [url=http://tiggit.net/]Tiggit

About the general problem of having unique assets against the competition (AKA Steam) I would also like if GOG would add in general a ffith leg to their Qualities (additional to DRM-free, one world-air price, extras and free games) called something like: "Preservation of Games by open sourcing". To Idea would be to fight the ongoing problems with unsupported and lost games by acting as archivar and advocat of the open source idea who tries to bring out the source code from publishers and developers into some form of open source to prevent the further loss and missing support. GOG would be the first and only one with this role. This would allow the community to preserve, fix, port, translate and mod in future a game as it is required while the game could be still sold per GOG (as maybe only the source code wa srleaed while the other game assests are still proprietay like with Arx Fatalis)

This would positioning GOG as unique advocat of game preservation as also of the open-source community... a far betteruse-case than steam and the community would love it. :)

PS: I think I will make a own wish/proposal about the second part.

Question.
What functions could potentially go into this client, and what would stop stupid features (see all the extra shite on the Steam client which are unnecessary) from being added in the future because a bunch of people can't live without feature x in another client?.
I would think many of us would prefer it just to be a download client rather be central place for gog installers to install games?.Or am i wrong?

shaddim: I'm not sure what you meant by developers pushing updates and etc. Any update service requires review, in order to avoid security issues. Unless you mean that GOG will have a set of contributors who would be allowed to push updates to their service. The approach is surely going to be web based - i.e. the protocol will run through the Internet, what else do you expect? If the protocol will be documented, there can be even alternative clients written, as others suggested above. Or if mean the updater should work through the browser? I'm not sure what would be the point of it. It's an extra overhead of plugging the whole thing into the JavaScript which is not very suitable for complex protocol implementation, since even WebSockets and WebRTC have certain limitations. It's much easier to make a standalone client.

About opening old games - it's probably a very difficult task. Sources can be simply already lost, or useless except for the sake of pure research, since they were intended for old compilers and systems (like the source for original Prince of Persia which was published).

What GOG could do, to enhance their specialty of preserving classic games is to help contributing to open source projects which provide alternative engines for closed games. Such as Nerverhood in ScummVM (http://wiki.scummvm.org/index.php/Neverhood), or for example open Morrowind (https://openmw.org) and the likes of these.

It's about the chain of trust... GOG reviews a developer and decided to trust a developer, let's say Almost human (Grimrock), who are allowed to push this patches directly to the game library. Then the users are informed about a update. Fastest possible solution while giving the control about when and if to update completely to the user.

Gog could also do this: https://secure.gog.com/wishlist/site/obtain_source_code_for_games_where_possible what I would call "Preservation of Games by open sourcing" and is far superior than reimplementing, see the several already existing cases listed in wikipedia or the example Arx Fatalis which had now the community fix, port and translation project Arx Libertatis (with porting to Linux and other platforms).

Chain of trust can be good, it's a general practice for package maintainers in many projects. But it's ultimately up to GOG to decide how to set this up in a manageable fashion. But such thing would still go through the GOG "repository" I guess. I.e. upstream can produce the patch, and upload it to GOG. Then users would get it through the updater service. You don't want to pull patches from a hundred of separate sources - it's a mess.

No idea. We are just guessing what that would be. GOG will make these decisions ultimately. I think updater is quite a basic thing to expect. What other features GOG can come up with - no idea. Repair for broken installations or what not. It's up to your imagination. Don't forget, GOG will have to preserve the DRM free nature of the service, so simple download should be expected to be always there. But it can be improved from the current one. I.e. you can download a full package for the installer, but that would change with each updated version. In addition GOG can enable dowlnoading standalone patches, which can be added to some previously downloaded installer / package to perform manual incremental update. That would save the hassle of redownloading updated packages anew for those who create DRM free packages/installers backups.

I'm not sure if I want a centralized update client, I think I would preferre a "full control for the user" approach with separated patches (backup able and downloadable) and a good information system. I think I would be also fine with a update client which: 1.) would not enforce updates , 2.) is not required to play 3.) and would not compromise my privacy (intransparent spying and data taking) (solved e.g. by open sourcing).

I think the core problem at the moment the to slow update cadence (by GOG being the repackager in the middle) what can be be effectivly solved by shifting the update responsiblity to the party who is in the end responsible, the game developer.

I'm not sure if GOG can do that. Since they are responsible to some degree. Imagine if something goes wrong with the patch. It becomes a horrible mess, and GOG would be blamed, even though they had nothing to do with it. It sounds like a potential for tons of serious problems.

About your points. Updates can be surely optional, and we should expect that GOG will not require any clients to play! That's DRM arleady, don't even mention this atrocity :) You should expect the opposite - standalone packages would be provided in addition to incremental updates through the client. The client should help the user, and not become a ball and chain. Desura does something like that. They have an updater (client) which installs / updates games, but it has nothing to do with actually playing them. Plus they have an option to get a full package/installer for backup (to enable this whole process to have a DRM free option for cases of no connectivity or the service closing down and etc.).

And about privacy and trust - that's exactly the point why it's good to make it open to begin with.

I think in the end it is already this way, by having a chain of trust to the developers ... GOG has not insight and ressources for checking code with every update, they do basic tests and mostly pointless repackaging.

A central update client will most likely remove the possiblity for separated, downloadable updates (like steam) as ressources of GOG are scarce (hint to missing linux ecosystem support). Therefpore a centalized update client will most likely introduce a update enforcement which (I think in gneral) is NOT considered DRM while I dislike it still highly.

Also, if developers are not allowed to feed directly into such client updates (but require repackagaging/review by GOG) the update cadence problem is also not solved with a client.

Beside, what do you think about cooperation with existing clients like Desurium or Tiggit?

I think clients highly depend on the service and defined protocol, as well as other important details (transactional deployment, rollbacks, repairs and etc.) so I'm not sure how useful other existing clients are, since they are tailored for their respective services.