Since you sound like a Java developer then you know that Java code can modify system level things. If an applet is malicious they take advantage of this fact to try and gain access to the client system. This sort of attack is hard to stop because by the time the applet runs, it's already to late. This native sandbox is another level of protection provided by the Windows OS that makes it so that if an applet breaks out of a browser, it shouldn't be able to do anything bad since it's inside a sandbox. If it is designed to interact with the system and it gets approved to do so even if a sandbox is set, then it will be able to since then the applet would be one allowed to do this by the Exception Site List or the run time environment's Deployment Rule Set. So you could run applets in the sandbox by default with this setting just to make sure you're extra protected until Oracle decides to turn it on for everybody, but be aware that if you do this some of the ones that need to interact with the system won't work unless they get approved or you tell it to allow them too.

Disabling it by default will allow legacy applets to update and (take advantage of/prepare for) it before it gets enabled by default if Oracle chooses to do that, or if a security over conscious user wants to use a "dangerous" applet, they can do so with confidence that it won't(hopefully) ruin their system.

Currently many applets probably aren't on the ESL or many environments aren't setup to use the DRS, so by setting it disabled by default they can make sure that it won't break anything(yet). Another reason may be that this option isn't entirely supported by Windows yet, and they have their part done and Windows just needs to catch up now or they are still ironing out the details before flipping the switch. There are still many more reasons that setting it by default right now makes sense, but we won't know until they say more. My guess is they have it set off until the ESL is large enough that they feel safe in setting it on without the people who won't read patch notes asking a flood of questions about why so and so no longer works on such and such website.

Since you sound like a Java developer then you know that Java code can modify system level things. If an applet is malicious they take advantage of this fact to try and gain access to the client system. This sort of attack is hard to stop because by the time the applet runs, it's already to late. This native sandbox is another level of protection provided by the Windows OS that makes it so that if an applet breaks out of a browser, it shouldn't be able to do anything bad since it's inside a sandbox. If it is designed to interact with the system and it gets approved to do so even if a sandbox is set, then it will be able to since then the applet would be one allowed to do this by the Exception Site List or the run time environment's Deployment Rule Set. So you could run applets in the sandbox by default with this setting just to make sure you're extra protected until Oracle decides to turn it on for everybody, but be aware that if you do this some of the ones that need to interact with the system won't work unless they get approved or you tell it to allow them too.

Disabling it by default will allow legacy applets to update and (take advantage of/prepare for) it before it gets enabled by default if Oracle chooses to do that, or if a security over conscious user wants to use a "dangerous" applet, they can do so with confidence that it won't(hopefully) ruin their system.

Currently many applets probably aren't on the ESL or many environments aren't setup to use the DRS, so by setting it disabled by default they can make sure that it won't break anything(yet). Another reason may be that this option isn't entirely supported by Windows yet, and they have their part done and Windows just needs to catch up now or they are still ironing out the details before flipping the switch. There are still many more reasons that setting it by default right now makes sense, but we won't know until they say more. My guess is they have it set off until the ESL is large enough that they feel safe in setting it on without the people who won't read patch notes asking a flood of questions about why so and so no longer works on such and such website.

Edit: After a bit more digging it turns out that the windows 10 sandbox exists already for windows store applications, info here and here, that can now be used by Java applets when correctly written and setup without problem. So it will be in the App-V sandbox used by windows store applications and newer desktop applications on Windows 10 since that seems to be the new default Windows Sandbox.

Since you sound like a Java developer then you know that Java code can modify system level things. If an applet is malicious they take advantage of this fact to try and gain access to the client system. This native sandbox is another level of protection provided by the Windows OS that makes it so that if an applet breaks out of a browser, it shouldn't be able to do anything bad since it's inside a sandbox. If it is designed to interact with the system and it gets approved to do so even if a sandbox is set, then it will be able to since then the applet would be one allowed to do this by the Exception Site List or the run time environment's Deployment Rule Set. So you could run applets in the sandbox by default with this setting just to make sure you're extra protected, but be aware that if you do this some of the ones that need to interact with the system won't work unless they get approved or you tell it to allow them to.

Since you sound like a Java developer then you know that Java code can modify system level things. If an applet is malicious they take advantage of this fact to try and gain access to the client system. This sort of attack is hard to stop because by the time the applet runs, it's already to late. This native sandbox is another level of protection provided by the Windows OS that makes it so that if an applet breaks out of a browser, it shouldn't be able to do anything bad since it's inside a sandbox. If it is designed to interact with the system and it gets approved to do so even if a sandbox is set, then it will be able to since then the applet would be one allowed to do this by the Exception Site List or the run time environment's Deployment Rule Set. So you could run applets in the sandbox by default with this setting just to make sure you're extra protected until Oracle decides to turn it on for everybody, but be aware that if you do this some of the ones that need to interact with the system won't work unless they get approved or you tell it to allow them too.

Disabling it by default will allow legacy applets to update and (take advantage of/prepare for) it before it gets enabled by default if Oracle chooses to do that, or if a security over conscious user wants to use a "dangerous" applet, they can do so with confidence that it won't(hopefully) ruin their system.

Currently many applets probably aren't on the ESL or many environments aren't setup to use the DRS, so by setting it disabled by default they can make sure that it won't break anything(yet). Another reason may be that this option isn't entirely supported by Windows yet, and they have their part done and Windows just needs to catch up now or they are still ironing out the details before flipping the switch. There are still many more reasons that setting it by default right now makes sense, but we won't know until they say more. My guess is they have it set off until the ESL is large enough that they feel safe in setting it on without the people who won't read patch notes asking a flood of questions about why so and so no longer works on such and such website.