Dependency on Telemetry Service about baigfe HOT 17 OPEN

Nvidia and Microsoft are acting like malware authors, that's insane.

Thanks for the changes, I'll apply them at home, see if it's not miss anything and then merge them, brb :)

from baigfe.

@Moyster Here's my crack at it.
Telemetry Service is now a separate process, but the nvnode and gfe try really hard to launch it and check for it existence. To get rid of it you need to patch both nvnode's index.js and gfe's app.js.
For both files I assume you got them beautified.

index.js: Comment this block

logger.info('Starting NvTelemetry container...');
try {
    nvUtil.StartSystemService(nvTelemetryServiceName, 30000);
}
catch (err) {
    logger.error(err);
    Shutdown();
}

and this one:

    logger.info('Waiting for NvTelemetry container to start...');
    nvUtil.WaitSystemService(nvTelemetryServiceName);
    logger.info('NvTelemetry container started');

In app.js comment this block as shown in the screenshot

                silentInstall: ["$log", "cefService", "$q", "preferencesService", "language", "nvAccountService", "GFECLIENT_CONFIG", "telemetryService", "USER_CONSENT_LEVEL", "nodeService", "localNodeInfo", "FATAL_ERRORS", function(e, t, n, r, o, i, a, s, l, c, u, d) {
                    var f = n.defer(),
                        m = e.getInstance("/main/uiRouter/main/resolve/silentInstall");
                    return m.info("requesting functional data consent"), i.getClientTelemetryConsent(a.jarvis.clientId).then(function(e) {
                        m.info("Received functional data consent: ", e);
                        var n = e.consentSettings;
                        return n.trackFunctionalData.level === l.FULL ? (m.info("consent already available"), s.setFunctionalConsentReceived(), f.resolve()) : void r.showFunctionalDataConsent().then(function() {
                            m.info("functional data consent accepted, notifying all"), s.setFunctionalConsentReceived(), n.trackFunctionalData.level = l.FULL, m.info("setting functional data consent to full"), i.setDefaultTelemetryConsent(n, "gfe").then(function() {
                                return m.info("functional data consent set successfully to full for GFE"), n.trackTechnicalData.level = l.FULL, i.setDefaultTelemetryConsent(n, "dd")
                            }).then(function() {
                                return m.info("functional and technical data consent set successfully  to full for DD"), f.resolve()
                            }).catch(function(e) {
                                return m.error("failed to update consent in nvaccounts", e), c.showErrorMessage("failed to update consent in nvaccounts", d.consentSetFail)
                            })
                        }).catch(function() {
                            return m.info("user did not accept functional data consent, closing"), t.windowClose()
                        })
                    }).catch(function(e) {
                        return m.info("failed to recieve functional data consent", e)
                    }), f.promise
                }]
            },

Then I did

1. disabled the NvTelemetryContainer service.
2. renamed\deleted C:\Program Files\NVIDIA Corporation\NvContainer\NvContainerTelemetryApi.dll
   optional step, but here's my reasoning: all of the containers try to load it, so I can't be entirely sure of it's behavior, It's not needed anyway, the service isn't there.

For me this made gfe work perfectly w/o the telemetry service(tested: gamestream, share).
Since I did some more manipulations on my installation before, I can't guarantee that's all required steps, but I'll try to find some time and test it out on a clean install.

from baigfe.

So I'm curious if any of you ran into any reliable 3rd party options to just ditch JunkForceExperience for pure driver updates? After sniffing some of this "telemetry" data they're collecting, it would seem this is way more data than I'd expect a graphics card manufacturer to collect. Not to mention the extra services running.

@JustJinxed
If you are fine with 3rd party repack of the drivers w/ crap removed look here.

If you want to repack it yourself: you unpack the driver exe w/ 7zip and remove components(folders) you are not interested in.
Documentation for each component can be found here (might not be entirely accurate e.g.: afaik the gfe won't start w/o telemetry, discussed way above)

Depending on how much you remove you might need to edit setup.cfg, here's the lines I used to remove(might be outdated) for it to work w/ minimal installation:

		<file name="${{EulaHtmlFile}}"/>
		<file name="${{FunctionalConsentFile}}"/>
		<file name="${{PrivacyPolicyFile}}"/>

You can always check the repack provided in the first link compare it with nvidia's package and find the relevant changes in setup.cfg.

At the moment I ditched the GFE myself for the minimal driver, and instead of Shield Streaming+Moonlight I found Rainway to be less obtrusive(and it's also vendor-independent) although a bit rough around the edges. Rainway's streaming protocol is less prone to desync(webrtc instead of rtmp) and latency is fine as well.

from baigfe.

Instead of NV Slimmer i suggest NV Clean Install as it has more features and even new driver check (not contacting Nvidia servers):
https://www.techpowerup.com/nvcleanstall/

The most useful and unique one imho is the "Enable MSI" option: https://www.techpowerup.com/forums/threads/feature-request-set-message-signaled-interrupts.262199/

On each driver install, Nvidia resets a registry key which disables MSI and forces devices to fall back to legacy INTx mode, presumably for compatibility reasons with their old nForce motherboards which are infamous for having a completely broken MSI implementation. INTx mode can result in longer deferred procedure calls and interrupt handling, which manifest as latency-related issues such as audio popping or unexplained dropped frames. These problems are commonly experienced in virtualized environments and on systems with overburdened PCIe lanes.

On modern motherboards and graphics cards, there is rarely ever a reason to turn off MSI.

from baigfe.

Hi, no idea pal, probably not but i could be wrong. I recently added more hosts to block :

0.0.0.0 nvidia.tt.omtrdc.net
0.0.0.0 api.commune.ly

and refreshed the old list a bit (images.xyz.com > img.xyz.com) so at least the telemetry and most of the shit that is calling outside should be blocked.

from baigfe.

If anyone has a suggestion / improvement / idea over how to "hard nullify" the telemetry containers inside nvidia's BullCrapExperience, let us know !

from baigfe.

As I discovered today NvBackend still depends on "NvTelemetry\NvTelemetryAPI64.dll", so it's not a full fix, gonna look further into it.

from baigfe.

As I discovered today NvBackend still depends on "NvTelemetry\NvTelemetryAPI64.dll", so it's not a full fix, gonna look further into it.

@Skrity Is it working "as-is" ? What about an empty stub NvTelemetryAPI64.dll ? I'm not really tempted to upload more nvidia files, so hex-editing is a nono, but an empty (prebuilt + src) stub would work just fine.

from baigfe.

re-opened in case anyone browse this rep's issues and feel like contributing

from baigfe.

NvBackend is responsible for most of the detection going on in GFE(e.g. games scans, features, driver versions, etc.). It won't run without a NvTelemetry\NvTelemetryAPI64.dll(GFE will return Error 2 on start). It's not a problem if you just disable the telemetry service and leave all files intact: GFE will work just fine. But if you for example remove NvTelemetry Folder from installer and do a clean(DDU) install and apply these fixes you'll still have to copy NvTelemetryAPI64.dll yourself to the proper program files directory.

Not sure if generic stub will suffice, didn't try.

from baigfe.

hmmm, interesting, thanks for the investigation 👍
Well if not removing files work, I guess that can be included. Would be better to have a stub to cover the "people who repacks their drivers" case but that can wait shrugs

from baigfe.

Problem with making a proxy DLL for the telemetry API is then NV can just go all out and do integrity checks on the telemetry code, making it a pain to patch elsewhere.....Plus they already have kernel access to really do some nasty shit.

from baigfe.

Problem with making a proxy DLL for the telemetry API is then NV can just go all out and do integrity checks on the telemetry code, making it a pain to patch elsewhere.....Plus they already have kernel access to really do some nasty shit.

You're probably right about how they might react to stubbing their money maker, yet so far the only actions they've taken was :

• between gfe 3.17.x & 3.18.x they would replace app.js with a clean one, every reboot. (gone now)
• make app.js licence header unobfuscated. (i'm spooked now)

Hopefully some of their engineers are not dicks and they understand nobody wants to remember a shitty login to be tracked when using the features you've paid good money for.

Oh wait no, they recently reworked login, now it tries to load a web login, and if it fails it goes for nvidia.CN login ( login.nvgs.nvidia.cn ). Don't forget to block the domain ;)

from baigfe.

Of the blocked addresses, does anyone know which is Driver Update and which is Game Optimization ? If I could only get driver update blocked, then I have a perfectly working previous version 3.13.130 which insists on getting updated unless I block everything.. but I would like to keep Game Optimization if possible.

0.0.0.0 ls.dtrace.nvidia.com
0.0.0.0 telemetry.gfe.nvidia.com
0.0.0.0 accounts.nvgs.nvidia.com
0.0.0.0 nvidia.tt.omtrdc.net
0.0.0.0 api.commune.ly
0.0.0.0 login.nvgs.nvidia.cn

from baigfe.

I realize this is a bug forum, and I know it's been a few years, but I just happened upon this, and have a question / want to thank everyone for their work. I've been trying to subvert this junk ever since they decided to add a captcha to their damn login process. Bad enough having to remember another useless password, but ... a robot check?

So I'm curious if any of you ran into any reliable 3rd party options to just ditch JunkForceExperience for pure driver updates? After sniffing some of this "telemetry" data they're collecting, it would seem this is way more data than I'd expect a graphics card manufacturer to collect. Not to mention the extra services running.

If not, I'm going to consider making a powershell script to scour their driver downloads, and something to extract / repack a basic update for windows put into orchestrate.

from baigfe.

I realize this is a bug forum, and I know it's been a few years, but I just happened upon this, and have a question / want to thank everyone for their work. I've been trying to subvert this junk ever since they decided to add a captcha to their damn login process. Bad enough having to remember another useless password, but ... a robot check?

The funny side effect of NVidia adding rewards > some poor people sees it as a way to make a bit of extra cash > bots fest > "oh no, we need some captcha and it's gonna yet again piss off our users".

So I'm curious if any of you ran into any reliable 3rd party options to just ditch JunkForceExperience for pure driver updates? After sniffing some of this "telemetry" data they're collecting, it would seem this is way more data than I'd expect a graphics card manufacturer to collect. Not to mention the extra services running.

If not, I'm going to consider making a powershell script to scour their driver downloads, and something to extract / repack a basic update for windows put into orchestrate.

Sounds like NVSlimmer, if you didn't know that Guru3D tool, it helps "clean" and make easy to redeploy installers for nvidia drivers.
The sad part of this is, getting rid of all that junk might break "random" stuff, and for those of us who wants to use ShadowReplay, or Ansel filters ingame, there's no real alternative.

from baigfe.

At the moment I ditched the GFE myself for the minimal driver, and instead of Shield Streaming+Moonlight I found Rainway to be less obtrusive(and it's also vendor-independent) although a bit rough around the edges. Rainway's streaming protocol is less prone to desync(webrtc instead of rtmp) and latency is fine as well.

Yeah, seems like that's the "way to go" now, OBS supports the ring buffer shadowplay feature, the only "missing part" is something to apply the ansel filters.
Still sad to see GFE does all that and we technically paid for it.

from baigfe.