needchemoteraphyfrommajor
New member
Hello,
I would like to report a problem / ask for advice regarding MajorPrivacy firewall rules and Microsoft Visual Studio Background Download.
The issue is that MajorPrivacy repeatedly shows firewall prompts for the same Visual Studio background downloader process, even though I already allow it permanently. The reason seems to be that Visual Studio launches BackgroundDownload.exe from randomly generated temporary directories, so each time the path changes, MajorPrivacy treats it as a new executable and asks again.
The process shown by MajorPrivacy is:
BackgroundDownload.exe
Visual Studio Background Download
Microsoft Corporation
The executable path is similar to this:
C:\Users\<user>\AppData\Local\Temp\<random_folder>\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
The important part is that the <random_folder> changes. Because of that, the full executable path is not stable.
For example, one time it may run from something like:
C:\Users\<user>\AppData\Local\Temp\f3uooyhj.wep\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
Another time it may run from another randomly named folder under:
C:\Users\<user>\AppData\Local\Temp\...\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
From the firewall prompt, the connections appear to be normal outbound HTTPS/TCP connections, usually to port 443. The remote addresses seem to belong to Microsoft/CDN infrastructure. I am not trying to block Visual Studio, Visual Studio Installer, Visual Studio updates, NuGet, .NET, MSBuild, or any normal development-related traffic. I want Visual Studio background update functionality to keep working normally.
The problem is only that MajorPrivacy keeps asking again and again, because the executable is launched from a different temporary folder each time.
What I have tried
I tried clicking “Permanent Allow” / “Allow forever” in the MajorPrivacy firewall prompt. This works only for the exact executable path that was shown at that moment. However, the next time Visual Studio launches BackgroundDownload.exe from a different Temp directory, MajorPrivacy shows the same prompt again.
So from the user perspective, it feels like “Permanent Allow” is not permanent for this application. It is permanent only for one temporary path, which is not enough in this case.
I also tried creating a manual firewall rule in MajorPrivacy. I opened the “Create firewall rule” window and tried to configure a rule for Visual Studio Background Download. In that window I can select a program/application from a list, or select a specific executable path. However, I do not see any visible field for a wildcard path, pattern, rule template, publisher-based rule, signature-based rule, or anything similar.
The rule creation window seems to allow only a fixed program/executable selection. Because of this, I cannot create a rule such as:
C:\Users\<user>\AppData\Local\Temp\*\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
I also do not see an obvious way to say:
Allow this executable if it is signed by Microsoft Corporation
or
Allow this specific Visual Studio Background Download application identity regardless of the Temp folder
or
Group all BackgroundDownload.exe instances from this Visual Studio Setup Service path into one application identity
This is why I am asking whether MajorPrivacy currently supports this use case, and if yes, where exactly the option is located.
Expected behavior
I would expect MajorPrivacy to provide a way to permanently allow this kind of application without creating a new rule for every random temporary path.
A good solution could be one of the following:
1. Allow by digital signature / publisher
For example:
Publisher: Microsoft Corporation
Executable name: BackgroundDownload.exe
Product / description: Visual Studio Background Download
Path contains:
resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
This would allow the real Microsoft-signed Visual Studio background downloader, without allowing every random executable from Temp.
2. Allow by internal application identity
If MajorPrivacy has its own concept of a “Program” identity that is independent of the exact full path, it would be useful to bind the rule to that identity instead of the current temporary folder.
In the popup, MajorPrivacy correctly displays:
Visual Studio Background Download
BackgroundDownload.exe
Microsoft Corporation
So it seems MajorPrivacy can identify the application in a more meaningful way than just the raw file path. I would like the firewall rule to use that identity, if possible.
3. Allow by wildcard / pattern path
For example, a path rule such as:
C:\Users\<user>\AppData\Local\Temp\*\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
or a DOS-style pattern, regular expression, or another MajorPrivacy-specific template syntax.
This would still be much safer than allowing all executables from Temp, because the path would have to match the Visual Studio Setup Service structure.
4. Allow by application group
Another possible solution would be to assign all matching BackgroundDownload.exe instances to one group, for example:
Visual Studio Installer / Visual Studio Background Services
Then I could create one outbound allow rule for that group.
Actual behavior
At the moment, clicking “Permanent Allow” creates a rule that is too specific. It appears to be tied to the exact temporary executable path. Because Visual Studio uses random Temp folders, the rule becomes useless as soon as the path changes.
The result is that MajorPrivacy keeps showing repeated firewall prompts for what is effectively the same trusted Microsoft Visual Studio component.
This is annoying because it interrupts normal work. It also makes the firewall prompt less useful, because the user ends up repeatedly approving the same Microsoft-signed component instead of focusing on genuinely suspicious network activity.
Important: I do not want to disable Visual Studio background updates
I want to be very clear about this part.
I am not looking for advice to disable Visual Studio background updates, Visual Studio Installer background tasks, scheduled tasks, update services, or anything like that.
Visual Studio background tasks should remain enabled.
The reason is simple: I want Visual Studio, Visual Studio Installer, workloads, components, SDKs, and related update mechanisms to work normally. I do not want to break my development environment just to stop firewall prompts.
The correct fix should be on the firewall rule / application identity side, not by disabling the application feature.
In other words, I do not want:
Disable Visual Studio background downloads
Disable scheduled tasks
Block Visual Studio Installer
Block BackgroundDownload.exe
Block Microsoft update/CDN servers
Block devenv.exe
Block MSBuild
Block dotnet.exe
Block NuGet
Block Node.js or other build tools
I only want MajorPrivacy to understand that this is the same Microsoft Visual Studio background downloader, even when the executable is unpacked into a different random temporary folder.
Why allowing by exact path is not enough
Normally, an application firewall rule based on the executable path makes sense. For most programs, the executable path is stable, for example:
C:\Program Files\SomeApp\SomeApp.exe
In this case, however, the executable path is not stable. Visual Studio appears to unpack or run part of its installer/update service from a temporary directory. Since the directory name changes, the path-based firewall rule does not match future launches.
So a rule for this path:
C:\Users\<user>\AppData\Local\Temp\abc123\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
will not match this path later:
C:\Users\<user>\AppData\Local\Temp\xyz789\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
Even though both are the same Visual Studio Background Download component.
That is the core of the problem.
Security considerations
I understand that allowing executables from Temp can be dangerous in general. I do not want to create a broad rule that allows everything from:
C:\Users\<user>\AppData\Local\Temp\*
That would be unsafe.
I am looking for a more precise rule. Ideally, the rule should check multiple conditions, for example:
Executable name: BackgroundDownload.exe
Publisher/signature: Microsoft Corporation
Path suffix:
resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
Direction: outbound
Protocol: TCP
Remote port: 443
Such a rule would be much safer than allowing all Temp executables, while still solving the repeated prompt problem.
A signature-based rule would probably be the safest and cleanest option, because malware could theoretically copy the same folder structure and filename, but it would not have the valid Microsoft Corporation signature.
So from a security perspective, my preferred solution would be:
Allow outbound TCP connections for Microsoft-signed Visual Studio BackgroundDownload.exe, regardless of the random temporary parent folder.
If signature-based rules are not supported, then a path pattern with a narrow suffix would still be better than nothing.
I would like to report a problem / ask for advice regarding MajorPrivacy firewall rules and Microsoft Visual Studio Background Download.
The issue is that MajorPrivacy repeatedly shows firewall prompts for the same Visual Studio background downloader process, even though I already allow it permanently. The reason seems to be that Visual Studio launches BackgroundDownload.exe from randomly generated temporary directories, so each time the path changes, MajorPrivacy treats it as a new executable and asks again.
The process shown by MajorPrivacy is:
BackgroundDownload.exe
Visual Studio Background Download
Microsoft Corporation
The executable path is similar to this:
C:\Users\<user>\AppData\Local\Temp\<random_folder>\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
The important part is that the <random_folder> changes. Because of that, the full executable path is not stable.
For example, one time it may run from something like:
C:\Users\<user>\AppData\Local\Temp\f3uooyhj.wep\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
Another time it may run from another randomly named folder under:
C:\Users\<user>\AppData\Local\Temp\...\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
From the firewall prompt, the connections appear to be normal outbound HTTPS/TCP connections, usually to port 443. The remote addresses seem to belong to Microsoft/CDN infrastructure. I am not trying to block Visual Studio, Visual Studio Installer, Visual Studio updates, NuGet, .NET, MSBuild, or any normal development-related traffic. I want Visual Studio background update functionality to keep working normally.
The problem is only that MajorPrivacy keeps asking again and again, because the executable is launched from a different temporary folder each time.
What I have tried
I tried clicking “Permanent Allow” / “Allow forever” in the MajorPrivacy firewall prompt. This works only for the exact executable path that was shown at that moment. However, the next time Visual Studio launches BackgroundDownload.exe from a different Temp directory, MajorPrivacy shows the same prompt again.
So from the user perspective, it feels like “Permanent Allow” is not permanent for this application. It is permanent only for one temporary path, which is not enough in this case.
I also tried creating a manual firewall rule in MajorPrivacy. I opened the “Create firewall rule” window and tried to configure a rule for Visual Studio Background Download. In that window I can select a program/application from a list, or select a specific executable path. However, I do not see any visible field for a wildcard path, pattern, rule template, publisher-based rule, signature-based rule, or anything similar.
The rule creation window seems to allow only a fixed program/executable selection. Because of this, I cannot create a rule such as:
C:\Users\<user>\AppData\Local\Temp\*\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
I also do not see an obvious way to say:
Allow this executable if it is signed by Microsoft Corporation
or
Allow this specific Visual Studio Background Download application identity regardless of the Temp folder
or
Group all BackgroundDownload.exe instances from this Visual Studio Setup Service path into one application identity
This is why I am asking whether MajorPrivacy currently supports this use case, and if yes, where exactly the option is located.
Expected behavior
I would expect MajorPrivacy to provide a way to permanently allow this kind of application without creating a new rule for every random temporary path.
A good solution could be one of the following:
1. Allow by digital signature / publisher
For example:
Publisher: Microsoft Corporation
Executable name: BackgroundDownload.exe
Product / description: Visual Studio Background Download
Path contains:
resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
This would allow the real Microsoft-signed Visual Studio background downloader, without allowing every random executable from Temp.
2. Allow by internal application identity
If MajorPrivacy has its own concept of a “Program” identity that is independent of the exact full path, it would be useful to bind the rule to that identity instead of the current temporary folder.
In the popup, MajorPrivacy correctly displays:
Visual Studio Background Download
BackgroundDownload.exe
Microsoft Corporation
So it seems MajorPrivacy can identify the application in a more meaningful way than just the raw file path. I would like the firewall rule to use that identity, if possible.
3. Allow by wildcard / pattern path
For example, a path rule such as:
C:\Users\<user>\AppData\Local\Temp\*\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
or a DOS-style pattern, regular expression, or another MajorPrivacy-specific template syntax.
This would still be much safer than allowing all executables from Temp, because the path would have to match the Visual Studio Setup Service structure.
4. Allow by application group
Another possible solution would be to assign all matching BackgroundDownload.exe instances to one group, for example:
Visual Studio Installer / Visual Studio Background Services
Then I could create one outbound allow rule for that group.
Actual behavior
At the moment, clicking “Permanent Allow” creates a rule that is too specific. It appears to be tied to the exact temporary executable path. Because Visual Studio uses random Temp folders, the rule becomes useless as soon as the path changes.
The result is that MajorPrivacy keeps showing repeated firewall prompts for what is effectively the same trusted Microsoft Visual Studio component.
This is annoying because it interrupts normal work. It also makes the firewall prompt less useful, because the user ends up repeatedly approving the same Microsoft-signed component instead of focusing on genuinely suspicious network activity.
Important: I do not want to disable Visual Studio background updates
I want to be very clear about this part.
I am not looking for advice to disable Visual Studio background updates, Visual Studio Installer background tasks, scheduled tasks, update services, or anything like that.
Visual Studio background tasks should remain enabled.
The reason is simple: I want Visual Studio, Visual Studio Installer, workloads, components, SDKs, and related update mechanisms to work normally. I do not want to break my development environment just to stop firewall prompts.
The correct fix should be on the firewall rule / application identity side, not by disabling the application feature.
In other words, I do not want:
Disable Visual Studio background downloads
Disable scheduled tasks
Block Visual Studio Installer
Block BackgroundDownload.exe
Block Microsoft update/CDN servers
Block devenv.exe
Block MSBuild
Block dotnet.exe
Block NuGet
Block Node.js or other build tools
I only want MajorPrivacy to understand that this is the same Microsoft Visual Studio background downloader, even when the executable is unpacked into a different random temporary folder.
Why allowing by exact path is not enough
Normally, an application firewall rule based on the executable path makes sense. For most programs, the executable path is stable, for example:
C:\Program Files\SomeApp\SomeApp.exe
In this case, however, the executable path is not stable. Visual Studio appears to unpack or run part of its installer/update service from a temporary directory. Since the directory name changes, the path-based firewall rule does not match future launches.
So a rule for this path:
C:\Users\<user>\AppData\Local\Temp\abc123\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
will not match this path later:
C:\Users\<user>\AppData\Local\Temp\xyz789\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
Even though both are the same Visual Studio Background Download component.
That is the core of the problem.
Security considerations
I understand that allowing executables from Temp can be dangerous in general. I do not want to create a broad rule that allows everything from:
C:\Users\<user>\AppData\Local\Temp\*
That would be unsafe.
I am looking for a more precise rule. Ideally, the rule should check multiple conditions, for example:
Executable name: BackgroundDownload.exe
Publisher/signature: Microsoft Corporation
Path suffix:
resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\BackgroundDownload.exe
Direction: outbound
Protocol: TCP
Remote port: 443
Such a rule would be much safer than allowing all Temp executables, while still solving the repeated prompt problem.
A signature-based rule would probably be the safest and cleanest option, because malware could theoretically copy the same folder structure and filename, but it would not have the valid Microsoft Corporation signature.
So from a security perspective, my preferred solution would be:
Allow outbound TCP connections for Microsoft-signed Visual Studio BackgroundDownload.exe, regardless of the random temporary parent folder.
If signature-based rules are not supported, then a path pattern with a narrow suffix would still be better than nothing.
