Implement Windows Defender Auto-fix

[HannesWell]

Start-up slowdowns on Windows 10 or later due to the Windows Defender are a long standing issue in Eclipse (see Bug 548443 or microsoft/java-wdb#9) that is mentioned in the release notes for a while: https://eclipse.dev/eclipse/news/4.13/

💰 This contribution is a development issue founded by the Eclipse IDE working group to mitigate these potential startup performance problems on Windows.

This adds a start-up event handler that, if running on Windows and if the Windows Defender is active, shows a pop-up to inform the user about the potential to suffer start-up slow downs due scans by the Defender and to suggest to exclude the current installation directory from being scanned by the Windows Defender.

A user can decide to exclude the directories containing the bundles installed in the current eclipse, to skip the exclusion check for this or for all eclipse installations of the current user (the latter is persisted in the user-scope introduced with eclipse-equinox/equinox#446).

The script that is run to exclude the installation can also be shown and can be copied by the user:

This screenshot was done in an Eclipse launched from my development Eclipse, which consequently consists of bundles from many different locations (workspace, target platform with IU und Maven targets) and therefore a lot of directories would be excluded.

Additionally this extends the existing start-up preference page to allow the user to adjust settings for skipping the Windows Defender exclusion check at start-up for the current or all installations

or to run the exclusion check now by clicking on Run exclusion check now.

This PR is a draft of the current state of the work. The open points are:

• Enhance the script to consider existing exclusion and prevent addition of already existing exclusions (Windows then adds them again)
• Decide if the exclusion should be done based on directories or if the entire process should be excluded (see following comment)
• Discuss if the preference group should be moved to a more prominent location, i.e. to the General page (usually the first one that opens).
• Clean up the code and check if labels and texts need to be enhanced

This PR requires as prerequisite (as long as this is not submitted one has to check out that PR as well when reviewing this locally)

• Introduce 'user' preference scope located in <user.home>/.eclipse eclipse-equinox/equinox#446

@vogella and @merks AFAIK you are working on Windows too, are you interested in reviewing this?
@HeikoKlare are you or some of your colleges working on Windows and are interested in a review too?

Of everybody else is also invited to review this.

[HannesWell]

In general excluding directories from being scanned by the Windows Defender can be a potential security risk, which is why as few files and directories as possible should be excluded.

In order to analyze the impact of the Windows Defender on the Eclipse start-up I used the Windows Defender Performance Analyser: https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/tune-performance-defender-antivirus

This showed that basically all files touched/accessed by Eclipse are scanned by the Windows Defender, at least at the first for each process. There seem to be some short term caching but that cache didn't last long (only for a few minutes.
The scanned files include for example

• the jars/directories of the bundles installed into the Eclipse runtime (usually located in eclipse/plugins or in ~\.p2\pool\plugins in case of a shared/Oomph-ed installation)
• the resources embedded in the bundles and extracted by the OSGi runtime (usually located in eclipse\configuration\org.eclipse.osgi)
• all resources located or referenced in the workspace, but since projects can be for example imported from git repositories this can include resources in many totally different directories.
• the jars of all bundles in the PDE Target-Platform

All of this together sums up to many directories that would have to be excluded in order to fully turn off the Windows Defender for Eclipse.
Furthermore not all of the mentioned resources are relevant for all kind of Eclipse usages. For example Target-Platforms are only relevant for Plugin Developers (PDE is not even present in all Eclipse packages) and allowing other plugins to extend the list of excluded locations could also become a security risk because adding entries to the Windows Defender exclusion list requires Administrator previliges).
In order to get the greatest speed-up of the Eclipse start-up, while having as few files as possible excluded, for now I have choosen to only exclude the directories that contains the jars of all bundles installed into the running Eclipse.
They are the largest files opened during start-up and are therefore the ones that have the greatest effect, at least until the UI is up.
Furthermore excluding other locations could also make the UI more complex because users probably would like to choose if they want to exclude only the installation or only the workspace or both etc.

But if desired more (installation relative) locations can be excluded easily.

Alternatively the process of the currently running Eclipse (identified by the location of the executable usually named eclipse.exe, but it should be adapted if the product is branded) could be excluded:
https://support.microsoft.com/en-us/topic/how-to-add-a-file-type-or-process-exclusion-to-windows-security-e524cbc2-3975-63c2-f9d1-7c2eb5331e53

Add a process exclusion

Adding an exclusion for a process means that any file opened by that process will be excluded from real-time scanning.
These files will still be scanned by any on-demand or scheduled scans, unless a file or folder exclusion has also been created that exempts them.

It would be simple to configure and would have the effect that the Windows Defender does not slow down Eclipse at all.
But because Eclipse can also open files fetched from the Web, e.g. when a PR via EGit or loading bundles in a Target-Platform, this option should be chosen with great care.
On the other hand, the advantage would be that all files could still be scanned by a on-demand scan.

What is the opinion of the others on this?

[vogella]

@HannesWell I'm a enthusiast Linux (Ubuntu) user with the rare tendency to boot Windows. But AFAIK I have no Virus protection program installed on Windows

[github-actions]

Test Results

   918 files  ±0     918 suites  ±0   51m 35s ⏱️ + 3m 47s
 7 434 tests ±0   7 283 ✅  - 1  150 💤 ±0  1 ❌ +1 
23 451 runs  ±0  22 948 ✅  - 1  502 💤 ±0  1 ❌ +1 

For more details on these failures, see this check.

Results for commit 837da54. ± Comparison against base commit 1f7f07a.

♻️ This comment has been updated with latest results.

[HannesWell]

@HannesWell I'm a enthusiast Linux (Ubuntu) user with the rare tendency to boot Windows. But AFAIK I have no Virus protection program installed on Windows

Ah, sorry then I remembered that wrong. Nevertheless, if you want, your assessment is of course welcome.

[laeubi]

Alternatively the process of the currently running Eclipse (identified by the location of the executable

I wonder if one can exclude the process in general but enable it for certain file types? e.g I think it is fine to still scan dll, exe, cmd and bat files, there should not be many of them.

[BeckerWdf]

This is quit complex dialog. A lot text to read and also quite something to understand. And then one has 4 buttons one can press.
That's one of the first dialog that comes up if you start your Eclipse Installation. We should design this with care and have an eye on good user experience.

Can we improve / simplify this dialog further?

[HannesWell]

Alternatively the process of the currently running Eclipse (identified by the location of the executable

I wonder if one can exclude the process in general but enable it for certain file types? e.g I think it is fine to still scan dll, exe, cmd and bat files, there should not be many of them.

Yes, that would be a good solution, but unfortunately this seems not to be possible.
One can only configure to turn off real-time detection for all files a process opens or can exclude specific folders or files from real-time, scheduled or on demand scans:

• https://support.microsoft.com/en-us/topic/how-to-add-a-file-type-or-process-exclusion-to-windows-security-e524cbc2-3975-63c2-f9d1-7c2eb5331e53
• https://learn.microsoft.com/en-us/powershell/module/defender/add-mppreference?view=windowsserver2022-ps

With that in mind excluding the process from real-time protection has the advantage that the opened files are at least scanned during scheduled and on-demand scans.

This is quit complex dialog. A lot text to read and also quite something to understand. And then one has 4 buttons one can press. That's one of the first dialog that comes up if you start your Eclipse Installation. We should design this with care and have an eye on good user experience.

Can we improve / simplify this dialog further?

That's right, but the task is not so simple, so the users should be aware of what is done, but I agree making it simpler would be good.
Do you have specific suggestions?

[BeckerWdf]

That's right, but the task is not so simple, so the users should be aware of what is done, but I agree making it simpler would be good. Do you have specific suggestions?

I have several ideas but have to think about this in more detail. How urgent is this?

[marcushoepfner]

That's right, but the task is not so simple, so the users should be aware of what is done, but I agree making it simpler would be good. Do you have specific suggestions?

I have several ideas but have to think about this in more detail. How urgent is this?

I really think this is a great improvement, and I also think it is crucial that the dialog is easy to conceive in order to enable people to do the right decision.

One thought: is "Ignore all installations" really needed?
We have made rather bad experience with "installation overlapping preferences" during the link handler implementation. The question is, how many percent of users have multiple installations? We should not only think of contributors or power users. There are also people who download one Eclipse and install just one feature. Think there are many of them. I'm afraid it is not really clear what happens with installation that have been moved to Trash for instance.
If possible, I would skip "Ignore all installations" in order to keep it simple (we could also start without this setting and if there are complains we can add it).

[vogella]

One option would be to have a simple version, like "Exclude Eclipse from Virus Scanning scanning to improve its performance" Yes/ No with a "See detailed screen " switching to the full blown screen. Yes would then set all possible options which would make all Eclipse installations fast.

[BeckerWdf]

One option would be to have a simple version, like "Exclude Eclipse from Virus Scanning scanning to improve its performance" Yes/ No with a "See detailed screen " switching to the full blown screen. Yes would then set all possible options which would make all Eclipse installations fast.

But even then we should decide how much details the "detailed screen" needs.

[HannesWell]

That's right, but the task is not so simple, so the users should be aware of what is done, but I agree making it simpler would be good. Do you have specific suggestions?

I have several ideas but have to think about this in more detail. How urgent is this?

That would be great.
I don't think it is super urgent. Actually the term of the dev-effort ends by this year, but I have already asked to Paul to extend it and I currently see no reason that speaks against an extension. Nevertheless I would of course, as usual, be great to delay this too much. :)

One reference could also be the dialog from Intelij mentioned in the dev-effort:
https://blog.jetbrains.com/wp-content/uploads/2023/01/Windows-defender--1.png

One thought: is "Ignore all installations" really needed?
We have made rather bad experience with "installation overlapping preferences" during the link handler implementation. The question is, how many percent of users have multiple installations? We should not only think of contributors or power users. There are also people who download one Eclipse and install just one feature. Think there are many of them. I'm afraid it is not really clear what happens with installation that have been moved to Trash for instance.
If possible, I would skip "Ignore all installations" in order to keep it simple (we could also start without this setting and if there are complains we can add it).

In order to handle the Ignore all installations button/case I have opened eclipse-equinox/equinox#446 to introduce a user scope for preferences. I'm not aware of the link handler implementation, but maybe that would have helped you too? Installations moved to trash are not an issue because the user-scoped preferences are stored in <user.home>/.eclipse/.settings.
Your points regarding the necessity for a complex UI for the most common/average user are probably right, although I have no exact numbers, but the simpler it is, of course the better.

But while the first dialog should be simple and should not overwhelm novice users when they open Eclipse for the first time, at the same time power-users should not be annoyed by convoluted workflows to reach more complex goals. So I think it is a difficult balance that should be found.

With that input, what do you think about having a relatively simple dialog poping up at start up that only asks to either run the exclusion (should it also show the script?) or to open the preferences, which at the same time provide more details, or can be closed via the corner X. But I'm torn if the third button to ignore this installation should be kept too.
But in general the "Never ask again" option is something that is from my perspective a common choice in programs in general.

One option would be to have a simple version, like "Exclude Eclipse from Virus Scanning scanning to improve its performance" Yes/ No with a "See detailed screen " switching to the full blown screen. Yes would then set all possible options which would make all Eclipse installations fast.

Adding an exclusion (regardless of the kind) always requires Admin privileges, so unless Eclipse runs with such rights the user is prompted by Windows for Admin rights. That prompt should IMHO never come up out of a sudden because the user selected to automatically exclude all installations with another installation (hypothetically) created three years ago. Therefore the dialog should always come up for a new installation that has not been checked yet (with the result to exclude or ignore it).

[HannesWell]

Happy new year all together. I hope you had relaxing holidays.

With tonight's I-build all prerequisites for this should be complete and I would like to work towards completing this PR.
So what do you think about my last proposal respectively how many details do you think are necessary?

[BeckerWdf]

I would like to work towards completing this PR. So what do you think about my last proposal respectively how many details do you think are necessary?

regarding the UX discussion I will provide a update later this day.

[BeckerWdf]

I just had a MS Teams meeting with @HannesWell and Hans-Peter (the ADT UX-Expert). We discussed how the interaction an the UX of this feature can be improved.

For transparency reasons I write down the most import topics we talked about:

• The dialog comes up for a fresh installation after the workspace has been selected.

• The dialog comes up very seldom / only once

• The decision on the dialog only has effect on the next start of eclipse

• The "ignore all" option is persisted in the user's home dir.

• Pressing the "X" in the top right corner means no decision was made so the dialog comes up at the next startup again.

• "Exclude" and "Ignore" are very similar works. It's not easy what means what. We should find a question and two possible answers where this is crystal clear.

• As the dialog comes up only in rare cases the "do not ask me again" pattern is not a good fit here. The "do not ask me again" pattern is more for dialogs that would come up very frequently.

• The decision (to exclude or not to exclude) has important implications (security level of the computer might be decreased). Because of this it might be worth to change the user flow in a way that the user explicitly has to choose an option (e.g. via a drop down without default) and only after that can continue and close this dialog. This will cause that more clicks are necessary but as this is not asked often and is an important decision it might be worth it.

• We could simplify the dialog by providing an option to head over to the preference page for more details. This should be done with a textual link (not a button) inside the text on the dialog.

• We could remove the "Ignore all" and the "Show script" option from the dialog and only provide it on the preference page. The preference page can provide more explanatory text; so the dialog can get simpler and still power-uses can get the details if they want.

We did not take a final decision yet.

[HeikoKlare]

Sorry for being late in this discussion and first of all: thank you, Hannes, for this work! The Windows defender slowing down startup has also been an issue for us, in particular because we had problems with slow startups where involved colleagues did not know about potential interactions with the Windows defender, so it took us quite some time to find the reason.
So for us, I see the biggest benefit in this contribution not in terms of "fixing" Windows defender settings, but simply in terms of being notified when there is the risk of startup slowdowns because of missing exclusions in the Windows defender.

I can second everything that has already been discussed, particularly with respect to the importance of the dialog being well designed, as it is the first thing that is shown to a user. And the suggestions made so far sound very good.

Maybe this was already discussed as well, then sorry that I missed it, but otherwise I want to point out one thing: From my understanding, this functionality will be present in every RCP appcliation, and I would expect this contribution to be very valuable for all of them. Still we need to consider that RCP products may be deployed in corporate environments where the users of the application will usually not be able to do anything with most of the options in the dialog in case it pops up, since they do not have the priviledge to do any of the required configurations. So maybe we need to provide different "check modes" for the Windows Defender status that can be defined "externally", e.g., via some system property? For example, I could image that for our product it makes sense to deploy it in a mode, in which the user is informed in case of a "bad" configuration, but that no option to change the configuration is provided to him or her. Still, the information can be used to inform the IT department that configurations of the clients may need to be changed. And maybe some customers even accept bad startup performance and want to deploy the applications to their clients without this warning popping up.
Maybe there could be a configuration option for "Windows Defender Check" modes like these:

• Allow Fix: Provide the options, including the Windows Defender exclusion configuration, as proposed now
• Warn: Only show a warning on startup (that may be ignored on subsequent startups)
• Ignore: No check is performed

Even for the provision of our development IDEs for the software development colleagues, such a configuration could be reasonable (in that case we could also set according preferences via Oomph). Our computers usually have specific folders that are already excluded from virus scanners, in which we place tools or data that should not be scanned. Then it would also be good if we can configure the IDE to only report if someone installed the IDE to a folder that is not excluded from virus scan, but not to ask him or her to acquire admin priviledges and change the virus scanner settings.

[HannesWell]

Maybe there could be a configuration option for "Windows Defender Check" modes like these:

* Allow Fix: Provide the options, including the Windows Defender exclusion configuration, as proposed now

* Warn: Only show a warning on startup (that may be ignored on subsequent startups)

* Ignore: No check is performed

It is already possible to disable the startup check by setting the org.eclipse.ui/windows.defender.check.skip preference to false in any of the usual preference scopes: configuration (aka installation), the newly introduced user-scope or the default scope. The latter can be configured via the usual product's preference customization. With that this check can be disabled entirely by default for custom products. You could even disable it per workspace, but there is currently no preference UI for that (at it does not really make sense since it affects an installation).

In general the start-up check is only executed once if the user decides how to handle this installation and there are basically two options: Perform exclusion and keep the installation being scanned. And unless the user decides to cancel the dialog does not show up again.

For example, I could image that for our product it makes sense to deploy it in a mode, in which the user is informed in case of a "bad" configuration, but that no option to change the configuration is provided to him or her.

That is not possible because you need Administrator privileges even just for reading the current Windows Defender exclusions. Which actually makes sense, because otherwise malicious software could e.g. read the list of excluded folders and just copies itself to any of the excluded folders and could never be detected.

The only thing that can be done without Admin-privileges is to check if Windows-Defender is active at all.
In order to avoid subsequent start-up checks if the exclusion was selected I persist in the configuration/installation preferences the path of the just excluded configuration/installation. This way it is also detected if the installation was moved and the other is asked again.

[HannesWell]

I have now reworked the start-up check dialog and the associcated preference page as discussed with @BeckerWdf and his college. Thanks again for your input.

In general, as before, all of the following is only effective for users on Windows.

If Windows Defender is active, on first startup of a new installation, the dialog poping-up after the UI startup has completed looks as follows:

The usage of two radio buttons without a default selection is intentional to make the user aware it's a choice with two options.
The uncommon pattern to have none of the two choices selected by default is also intentional to catch the users focus and avoid a fast click through so that a informed choice can be made. Since the topic is not too easy and the dialog only pops up once for each new installation we agreed that this is important.
Depending on the resolution selected by the user the exclusion is performed (and it is persisted in the installation preferences that this installation is excluded) or the Defender configuration is left untouched. In both cases the choice is persisted and it is not asked again for this installation.
If a user chooses to cancel the dialog (by clicking cancel or ESC) the dialog pops up again on the next startup.

Clicking the link, opens the Startup and Shutdown preference page and closes the start-up dialog (as if it was canceled, i.e. no choice is persisted).

In the Startup and Shutdown preference interested users now get more detailed information about the Windows defender handling, can choose to disable the startup-check for all installations, run the exclusion check or to see the powershell script used to exclude the current installation:

Clicking Run exclusion check now opens the dialog shown above regardless of all persisted preferences. If windows defender is not active on the current computer a different info-dialog is shown to inform about that.

Clicking the Powershell script button, unfolds the code of the script:

In order to to strip down the dialog to the required minimum the option to disable the start-up check is now only presented in the preferences, while the option to skip the start-up check for the current installation was removed from the preference again. The latter was probably already chosen in the dialog shown at start-up or can be made again if Run exclusion check now is clicked.

Everybody interested, please let me know what you think.
With that I think the general structure is fine, only the the labels and texts might need some fine-tuning, but I think this can be done as last step once everything else is settled.
@BeckerWdf I hope this addresses all the discussed items?

[HannesWell]

From #1453 (comment)

Alternatively the process of the currently running Eclipse (identified by the location of the executable usually named eclipse.exe, but it should be adapted if the product is branded) could be excluded: https://support.microsoft.com/en-us/topic/how-to-add-a-file-type-or-process-exclusion-to-windows-security-e524cbc2-3975-63c2-f9d1-7c2eb5331e53

Add a process exclusion

Adding an exclusion for a process means that any file opened by that process will be excluded from real-time scanning.
These files will still be scanned by any on-demand or scheduled scans, unless a file or folder exclusion has also been created that exempts them.

It would be simple to configure and would have the effect that the Windows Defender does not slow down Eclipse at all. But because Eclipse can also open files fetched from the Web, e.g. when a PR via EGit or loading bundles in a Target-Platform, this option should be chosen with great care. On the other hand, the advantage would be that all files could still be scanned by a on-demand scan.

On this topic I now came to the conclusion that excluding the process is probably the better choice since it allows all eclipse files to be scanned in on-demand or scheduled scans and only disables real-time scanning at Eclipse execution. This also has the advantage that not only the start-up is speed up (where the jars of Eclipse are scanned) but the overall performance because files opened by Eclipse are not scanned too, regardless where they reside.
As recommended in common-exclusion-mistakes-microsoft-defender-antivirus the eclipse.exe (or a branded product) is excluded by their absolute path in order to prevent any malicious code being excluded because it uses the same executable name.

Of course this assume that a user trusts the code of Eclipse and all installed plugins and the files read by eclipse cannot make Eclipse do malicious things just by being read.

Please let me know if you think another choice should be made.

[BeckerWdf]

This looks really good now.
I have some remarks:

I am unsure if a button is the right control to show / hide (expand / collapse) the Script.
Wouldn't something like this expandable areas like e.g. used on the "Errors/Warnings" preference page:

be a better fit?

I also don't like the "Execution needs..." text being part of the button text. This makes the button very long. Can't we move this to the explanatory text above?

Shouldn't the title of the dialog be in Title Case meaning shouldn't it be "Windows Defender Exclusion Check"?

[HannesWell]

@HannesWell: We should also add a "New & Noteworthy" entry for this in platform's news section. We should also think about changing this paragraph on the top level news page:

"Windows 10 users: Windows 10 Defender significantly slows down Eclipse, reason being Windows 10 Defender scanning the JAR files. The problem has been reported to Microsoft here. Until then, a workaround to this problem is to add Eclipse root directory to Windows 10 Defender's exclusion list, detailed steps are shared here.
Note: This is not just an Eclipse issue on Windows 10."

I have just created eclipse-platform/www.eclipse.org-eclipse#123 for the N&N entry, which also just removes that paragraph. Users potentially affected will be informed through the dialog so I think it is not necessary to have a separate note about that. Please comment on the N&N PR if you think this could be handled differently.

[Phillipus]

@HannesWell Will this appear in RCP applications? It's not something that I would want to display in our RCP app.

[HannesWell]

@HannesWell Will this appear in RCP applications? It's not something that I would want to display in our RCP app.

If your product uses the org.eclipse.ui.ide.workbench then yes it will appear in your RCP app by default. But you can add a preferenceCustumization to your product to disable it. I have updated the N&N entry in eclipse-platform/www.eclipse.org-eclipse#123 to describe that as well.

[Phillipus]

If your product uses the org.eclipse.ui.ide.workbench

It doesn't at the moment, it might do one day.

I have updated the N&N entry in eclipse-platform/www.eclipse.org-eclipse#123 to describe that as well.

Creators of custom Eclipse-based products that use the org.eclipse.ui.ide.workbench application and want to suppress the new startup check for their product can disable it by adding the following entry to their product's preferenceCustomization properties file:

org.eclipse.ui/windows.defender.check.skip=true

Perfect!

[Phillipus]

I downloaded latest Eclipse SDK for Windows and clicked Yes to exclude. I checked in my Windows settings to see what had been excluded and it was the eclipse.exe file. I thought the problem came from WD scanning jar files?

[HannesWell]

I downloaded latest Eclipse SDK for Windows and clicked Yes to exclude. I checked in my Windows settings to see what had been excluded and it was the eclipse.exe file. I thought the problem came from WD scanning jar files?

Thanks for trying this out and its great that everything worked.
And yes you are right, this is about preventing WD from scanning jars, but excluding the process means that WD won't real-time scan any file opened by the excluded process (what it is currently doing). So this way the performance improvement applies to all files touched by Eclipse (e.g. project files in the workspace or jars in the target-platform or of Maven dependencies residing in the <user.home>/.m2 and not only the jars forming the Eclipse application).
At the same time it allows scheduled or on demand scans to still check all files (path exclusions are considered by all scans thus excluded paths are never ever scanned by any kind of scan).
Of course this means that everything the eclipse application is 'doing' is not scanned, but I assume that a user trusts eclipse and all installed plugins to not be malicious, if one decides to run the exclusion.
The same applies for the content of project files, I'm not a security expert but theoretically it is probably possible to pare the content for project's to make an Eclipse application doing bad things. Although this is more difficult than provides malicious plugins. But I cannot tell if Windows Defender would detect such malicious content anyways.
In general if one does not trust the installed Plug-ins or content in the workspace, it is not recommended to apply any exclusion.

I have added some more context and links in #1453 (comment)

[Phillipus]

@HannesWell Thanks for the comprehensive replies and information! 👍

[al-popa]

I am sorry if this question was already asked.

My situation: Our corporate policy forbids altering Windows Defender exclusion rules even if the user has admin permissions (and corporate security policy defined some rules for Eclipse on its own). Also we use a custom build of Eclipse for which it is desired to suppress the initial popup regarding Windows Defender with silently add skip option to installation configuration. Eclipse is built and distributed via SDC (not Oomph) if this matters.

Eclipse is configured in this way:

• <install-dir>\eclipse.ini contains the option similar to -configuration <install-dir>\configuration.
• <install-dir>\configuration contains config.ini file, .settings folder and some more per-plugin folders.
• Installation options are customized via SDC Environment Policy:
  
  This configuration lands in <install-dir>\configuration\config.ini file.
• If I configure exclusion via Window -> Preferences -> General -> Startup and Shutdown, the configuration is written to <workspace>\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.ui.prefs as:
  windows.defender.startup.check.skip=true

What works:

• Adding -dev option to <install=dir>\eclipse.ini, but it is not a solution to the problem.
• Adding windows.defender.startup.check.skip=true to <workspace>\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.ui.prefs, but <workspace> may not exist at the application startup, and anyway it is not known at the time of Eclipse installation.

What does not work:

• Adding org.eclipse.ui/windows.defender.startup.check.skip=true to <install-dir>\configuration\config.ini via SDC Environment Policy.
• Addind windows.defender.startup.check.skip=true to <install-dir>\configuration\config.ini via SDC Environment Policy.

I see some plugins specify <property name="preferenceCustomization" value="plugin_customization.ini"/> in plugin.xml and then in plugin_customization.ini put the desired configuration. Where exactly should I place this configuration to preset skipping Windows Defender scan to skip and avoid this popup?

EDIT: Found it. Need to put windows.defender.startup.check.skip=true in <install-dir>\configuration\.settings\org.eclipse.ui.prefs and it works. Now need to figure out how to do this via SDC.

EDIT2: Found SDC Console configuration. After selecting Eclipse version, in Configuration tab add an *.epf file with corresponding preferences like:

file_export_version=3.0

/configuration/org.eclipse.ui/windows.defender.startup.check.skip=true

[al-popa]

Tested the scenario above with no success.

1. Uploaded necessary *.epf file to SDC server and generated a new installer.
2. Installed Eclipse, found this *.epf file in <install-dir>\configuration\com.genuitec.pulse.client.delivery.package.runtime\current\workspace\skip-windows-defender.epf . At this time no <install-dir>\configuration\.settings folder exist.
3. Launched Eclipse. During the process and taking decisions, <install-dir>\configuration\.settings folder is created and populated with *.prefs files, including the necessary org.eclipse.ui.prefs, but only after the popup is shown and closed with no option selected (with x button at top-right corner).
4. On the next Eclipse launch the configuration is already active, but this is too late. I want to avoid popup at the very first launch.

[jukzi]

My situation: Our corporate policy forbids altering Windows Defender exclusion rules even if the user has admin permissions

@HannesWell can you please help my colleague here?

[HannesWell]

My situation: Our corporate policy forbids altering Windows Defender exclusion rules even if the user has admin permissions (and corporate security policy defined some rules for Eclipse on its own).

In this case I suggest to disable this start-up check 'user-wide' for all Eclipse based installations as described in
https://eclipse.dev/eclipse/news/4.31/platform.php#windows-defender-auto-config

If you don't want to do that through the UI or want to do it before the actual installation you adjust/create the settings file at ~\.eclipse\.settings\org.eclipse.ui.prefs at add the following content

eclipse.preferences.version=1
windows.defender.startup.check.skip=true

If this doesn't help, please create a dedicated issue for your problem.

[al-popa]

Thank you @HannesWell for suggestion. This way the problem sure can be solved, but is not applicable in case of new users: they just need to download an installer and hope the installer takes care of the situation.

Instead, I applied the solution described in https://www.genuitec.com/docs/sdc/advanced-administration/advanced-installer-customization. This way, the installation-wide setting is written as an additional step of installation process. This solution does not involve any prior user configuration and acts at the install time, not runtime.