sovchen

How about you properly test your forced updates with that lenovo tool before you release them on a non-beta channel? The way you've handled this entire situation is unacceptable. This should've been rolled back the moment there was an issue and then take your sweet time while it's "looked into" not on the customer's payroll.

Not sure what you're trying to tell me. I was just commenting on the absurdity of calling it impossible to block when we have both showed how easy it is to do so.

>virtually impossible That doesn't sound right. Blocking via prompt stopped any network interaction nvdisplaycontainer tried to do, and it hasn't attempted to deploy from elsewhere either, I have verified this on my machine. I'm not sure about the other telemetry processes tho as they can be easily excluded from install using the nvslimmer tool. I've only ever had one rule for it

I disagree with the wording on the last question. I think application path should remain as default as it's been for the last ten years and add signer as the new alternative feature below it. You are changing a system that has worked fine in favor of new, untested, functionality that is already causing problems. I will not pay to be a beta tester, if this becomes the norm I cannot continue using this product.

Yes, the application path is exactly what's needed. This has been the norm up until 16.2. I'm sure you could avoid a lot of confusion if you also had it ticked by default instead of the new signed app system or at least have an option for it in the settings menu. As far as I can tell from my experience with the new update, and from the posts in this thread, the rules for signed apps don't seem to do anything when set from the interactive prompt so it might be best to just hide that.

Except it's not a problem. That post is an example of the functionality I need. A wildcard rule would be exactly what I don't want in this case.

Here is an example of my usecase: Note how I have multiple python installs working out of different locations in my filesystem. The firewall rule specifically points to the path of the executable. When the dialog appears it points directly to the application.exe path. I did not take any screenshots of how 16.2 behaves because I don't have it installed anymore as mentioned, as best I can explain it instead of assigning a path to my python.exe location it would simply treat it as a generic python signed app with no location, this is reflected in the interactive dialog as well. The rule in that case is not valid for any of my python installs. The only way to make it work is to go into the firewall rule as set by the dialog, delete the singed app nonsense and browse to the path of the executable myself, which as you can imagine invalidates the point of an interactive dialog. I might as well set the firewall to block all and manually point to everything I want unblocked. This problem gets even more tedious once you try to control service based stuff such as all the microsoft nonsense in windows I was getting prompts for these too in 16.2, I don't even know how you'd go about setting them manually. Something is clearly wrong with the way it handles these signed apps with no path through the interactive dialog at least. Please understand that having a path set directly to the executable in question, not a generic signed app, is absolutely necessary and must be a default feature in the dialog as it's been up until now else there will be no end to the problems, as others have also pointed out in this thread.

Yeah I moved back to 16.1.14 after having issues with this for a while as well. The problem is it's trying to assign some generic signed app .exe with no path making the default set rules completely pointless. You have to set the path manually now every time you add a rule through the dialog. I don't appreciate being pushed beta features to test as a paying customer. I did not select any pre-release update channel setting. Are we gonna have to disable updates and check to forums for any major problems now before updating? What if something else breaks in the next update?