Make docs more clear

Content/AdvancedTopics.md

@@ -1,5 +1,7 @@
 # Advanced Topics
 
+Some advanced topics:
+
 [Sandbox Hierarchy](SandboxHierarchy.md) discusses how Sandboxie isolates programs.
 
 [Privacy Concerns](PrivacyConcerns.md) for programs running under Sandboxie.

Content/AlertProcess.md

@@ -1,18 +1,20 @@
 # Alert Process
 
-_AlertProcess_ is a global setting in [Sandboxie Ini](SandboxieIni.md). It specifies names of programs that, if started outside the sandbox, will cause Sandboxie to issue message [SBIE1301](SBIE1301.md).
+The _AlertProcess_ setting in [Sandboxie Ini](SandboxieIni.md) is a global configuration that specifies the names of programs triggering message [SBIE1301](SBIE1301.md) when started outside the sandbox. This setting can be conveniently managed within the application interface:
 
-Usage:
-```
-   .
-   .
-   .
-   [GlobalSettings]
-   AlertProcess=iexplore.exe
-   AlertProcess=firefox.exe
+![Alert Programs](../Media/AlertPrograms.png)
+
+To utilize this setting, add program names to the [GlobalSettings] section, as demonstrated:
+
+```ini
+[GlobalSettings]
+AlertProcess=iexplore.exe
+AlertProcess=firefox.exe
 ```
 
+This example would trigger an alert if Internet Explorer or Firefox is initiated outside the sandbox.
+
+### Additional References:
 
-See also:
 * [Program Settings](ProgramSettings.md).
 * [Configure Menu > Alert Programs](ConfigureMenu.md#program-alerts).

Content/AllPages.md

@@ -1,4 +1,4 @@
-# All Pages
+# Table of Contents
 
 ### A
 

Content/AppearanceSettings.md

@@ -1,6 +1,6 @@
 # Appearance Settings
 
-Sandboxie Control > Sandbox Settings > Appearance:
+Sandbox > Sandbox Options > General Options > Box Options
 
 ![](../Media/AppearanceSettings.png)
 

Content/AutoExec.md

@@ -4,25 +4,22 @@ _AutoExec_ is a sandbox setting in [Sandboxie Ini](SandboxieIni.md). It specifie
 
 Examples:
 
-```
-   .
-   .
-   .
-   [DefaultBox]
-   AutoExec=regedit /s c:\defaultbox.reg
-   AutoExec=cmd /c del /f "%windir%\system32\someExploitableDLL.dll"
+```ini
+[DefaultBox]
+AutoExec=regedit /s c:\defaultbox.reg
+AutoExec=cmd /c del /f "%windir%\system32\someExploitableDLL.dll"
 ```
 
-The first example shows using _AutoExec_ to populate the sandboxed registry in some way. The second example shows using _AutoExec_ to delete an undesirable DLL file. In both cases the customization takes place only within the sandbox.
+The first example shows using _AutoExec_ to populate the sandboxed registry in some way. The second example shows using _AutoExec_ to delete an undesirable DLL file. In both cases, the customization takes place only within the sandbox.
 
-Multiple _AutoExec_ settings may be specified for a single sandbox. The commands listed are executed one by one. The commands (whether one or any number of them) are executed _once_ in the life-time of a particular sandbox. To get Sandboxie to execute these commands again, the sandbox must be deleted.
+Multiple _AutoExec_ settings may be specified for a single sandbox. The commands listed are executed one by one. The commands (whether one or any number of them) are executed _once_ in the lifetime of a particular sandbox. To get Sandboxie to execute these commands again, the sandbox must be deleted.
 
-This is true even if the command execution fails -- it will not be executed again, unless the sandbox is deleted.
+This is true even if the command execution fails -- it will not be executed again unless the sandbox is deleted.
 
 At this time, there is no corresponding [Sandboxie Control](SandboxieControl.md) configuration for this setting.
 
 **Technical Details**
 
 Each _AutoExec_ command, as it is executed by Sandboxie, is recorded in the registry of that sandbox, in the key _HKEY_CURRENT_USER\Software\SandboxieAutoExec_.
 
-The command will not be executed if it was already recorded in the sandboxed registry. Thus, deleting the sandbox clears all recorded _AutoExec_ commands, so they are executed again the next time any sandboxed program starts in that sandbox. But it is also possible to get them to execute again, by manually deleting the command from that sandboxed registry key.
+The command will not be executed if it was already recorded in the sandboxed registry. Thus, deleting the sandbox clears all recorded _AutoExec_ commands, so they are executed again the next time any sandboxed program starts in that sandbox. But it is also possible to get them to execute again by manually deleting the command from that sandboxed registry key.

Content/AutoRecover.md

@@ -1,15 +1,12 @@
 # Auto Recover
 
-_AutoRecover_ is a sandbox setting in [Sandboxie Ini](SandboxieIni.md). It is typically specified as _AutoRecover=y_, and enables the Immediate Recovery extension of [Quick Recovery](QuickRecovery.md).
+_AutoRecover_ is a sandbox setting in [Sandboxie Ini](SandboxieIni.md). Typically specified as _AutoRecover=y_, it enables the Immediate Recovery extension of [Quick Recovery](QuickRecovery.md).
 
 Usage:
 
-```
-   .
-   .
-   .
-   [DefaultBox]
-   AutoRecover=y
+```ini
+[DefaultBox]
+AutoRecover=y
 ```
 
 Related [Sandboxie Control](SandboxieControl.md) setting: [Sandbox Settings > Recovery > Immediate Recovery](RecoverySettings.md#immediate-recovery)

Content/BoxRootFolder.md

@@ -1,6 +1,6 @@
 # Box Root Folder
 
-**This setting is deprecated. Please use [FileRootPath](FileRootPath.md) instead.**
+**This setting is deprecated and may be removed in the future. To prevent Sandboxie from breaking in the future, please use [FileRootPath](FileRootPath.md) instead.**
 
 _BoxRootFolder_ is a global setting in [Sandboxie Ini](SandboxieIni.md). It specifies the folder containing all sandboxes. One sub-folder is created within the container folder for each sandbox in active use.
 

Content/ClosedClsid.md

@@ -1,18 +1,16 @@
 # Closed Clsid
 
-_ClosedClsid_ is a sandbox setting in [Sandboxie Ini](SandboxieIni.md) available since v0.5.3a / 5.45.2. It specifies the COM class identifiers for unsandboxed COM objects that should not be accessible by a sandboxed program.
+The _ClosedClsid_ setting in [Sandboxie Ini](SandboxieIni.md) (available since v0.5.3a / 5.45.2) is employed to specify COM class identifiers for unsandboxed COM objects that should be restricted from access by sandboxed programs.
 
-Usage:
-```
-   .
-   .
-   .
-   [DefaultBox]
-   ClosedClsid={8BC3F05E-D86B-11D0-A075-00C04FB68820}
+To utilize this setting, you can include it in the [DefaultBox] section, as shown below:
+
+```ini
+[DefaultBox]
+ClosedClsid={8BC3F05E-D86B-11D0-A075-00C04FB68820}
 ```
 
-This example makes the _Windows Management and Instrumentation_ not accessible to sandboxed programs.
+In this example, the _Windows Management and Instrumentation_ is designated as not accessible to sandboxed programs.
 
-Related Sandboxie Plus setting:
+Additionally, it is related to the Sandboxie Plus setting found under:
 
 Sandbox Options > Resource Access > COM

Content/Description.md

@@ -1,20 +1,17 @@
 # Description
 
-_Description_ is a sandbox settings in [Sandboxie Ini](SandboxieIni.md). It specifies free text, which can explain, for example, the purpose of the sandbox.
+The _Description_ setting in [Sandboxie Ini](SandboxieIni.md) allows you to provide explanatory text about the purpose of a specific sandbox. This information is displayed in a balloon pop-up within the _Run Sandboxed_ sandbox selection dialog box.
 
-```
-   .
-   .
-   .
-   [DefaultBox]
-   Description=Example<BR>text.
-   .
-   .
-   .
-   [PrivateBox]
-   Description=Access denied to sensitive file locations
-   ClosedFilePath=%Personal%
-   ClosedFilePath=D:\MyDocs
+To set the description, include it in the sandbox section, such as [DefaultBox] or [PrivateBox], and add the desired free text. You can use the `<BR>` sequence for line breaks, as illustrated below:
+
+```ini
+[DefaultBox]
+Description=Example<BR>text.
+
+[PrivateBox]
+Description=Access denied to sensitive file locations
+ClosedFilePath=%Personal%
+ClosedFilePath=D:\MyDocs
 ```
 
-The `<BR>` sequence in the text is used to indicate a line break. The free text is displayed in a balloon pop-up in the _Run Sandboxed_ sandbox selection dialog box.
+In this example, the text "Example text" will be displayed for the [DefaultBox] sandbox, and for the [PrivateBox] sandbox, it informs about access denial to specific file locations with the associated closed file paths.

Content/DetectingKeyLoggers.md

@@ -1,94 +1,52 @@
 # Detecting Key Loggers
 
-Go to [Help Topics](HelpTopics.md), [Usage Tips](UsageTips.md).
+For more detailed information, please refer to [Help Topics](HelpTopics.md) and [Usage Tips](UsageTips.md).
 
-* * *
+---
 
-### Overview
+## Overview
 
-It is very difficult to reliably detect all classes of key-loggers. This section first explains why this is so, and concludes by offering a possible defense against them.
-
-First, a distinction must be made between several classes of key-loggers:
-
-*   external key-loggers
-*   rootkit key-loggers
-*   windows hook key-loggers
-*   windows message key-loggers
-*   scripted key-loggers
+Detecting all classes of key-loggers poses a significant challenge. This section categorizes key-loggers into various classes and explores potential defenses against them.
 
 ### External Key-Loggers
 
-External (or hardware) key-loggers are devices that connect to your computer in some way. Two examples are a small device plugged between the keyboard and the computer, or a device that snoops on radio signals transmitted by a wireless keyboard.
-
-The common principle of key-loggers in this class is that they are _external_ to the Windows system on which they are spying. Software running within Windows cannot detect, remove or protect against external key-loggers.
-
-The other classes of key-loggers described here are software key-loggers which do operate within Windows.
+External (hardware) key-loggers, such as devices connected to the computer, are beyond the reach of software running within Windows. Sandboxie cannot detect or protect against these devices.
 
 ### Rootkit Key-Loggers
 
-Rootkit key-loggers record keystrokes at the lowest software level, typically by positioning themselves as a second keyboard hardware driver (a _filter_ driver, in Windows terminology).
-
-Once installed, this class of key-loggers may provide the best logging facilities, and may be difficult to get rid of. But to be installed in the first place, this key-logger needs the explicit help of the operating system, and so is easily blocked by Sandboxie.
-
-~~If such a key-logger attempts to install, Sandboxie should report an informational message [SBIE2103](SBIE2103.md), unless the [BlockDrivers](BlockDrivers.md) setting (see also [Sandbox Settings > Restrictions > Low-Level Access](RestrictionsSettings.md#low-level-access--removed)) was explicitly used to disable this protection.~~
+Rootkit key-loggers operate at a low software level, often as secondary keyboard hardware drivers. Sandboxie effectively blocks their installation, as they require explicit help from the operating system.
 
 ### Windows Hook Key-Loggers
 
-These key-loggers don't masquerade as hardware drivers, but they still have to ask the operating system to load them (or _hook them_) into every program executing on the desktop.
-
-It is not uncommon for applications to install such hooks as part of normal operation, and blocking all of them would prevent some programs from running successfully inside the sandbox.
-
-~~**Removed From Sandboxie - Block Hooks Command**~~
-
-~~The approach Sandboxie takes is to honor the hook request partially, by applying the hook only to applications in the same sandbox as the requesting application.~~
-
-~~The [BlockWinHooks](BlockWinHooks.md) setting (see also [Sandbox Settings > Restrictions > Low-Level Access](RestrictionsSettings.md#low-level-access--removed)) may be used to explicitly disable this protection.~~
+These key-loggers request the operating system to load or "hook" them into every program executing on the desktop. Sandboxie partially honors these requests, applying the hook only to applications in the same sandbox.
 
 ### Windows Message Key-Loggers
 
-This class of key-loggers doesn't need any assistance from the operating system, and can only reliably record activity within one program. However, from the point of view of a supervisory program like Sandboxie, they don't do anything suspicious, and so cannot be stopped.
-
-In order for a program running on the desktop to actually process the keyboard input, the operating system sends that program a message describing the input. The message key-logger, which is likely running in the same process space as the program being logged, can snoop on these messages in a variety of ways, which don't raise suspicion.
-
-Typically this key-logger will be a secret Web browser plugin (or a secret component of a plugin), so it can easily record keyboard activity related to the Web browser.
+Operating within the same process space as the logged program, these key-loggers intercept keyboard input messages sent by the operating system to the program. Detecting them is challenging for a supervisory program like Sandboxie.
 
 ### Scripted Key-Loggers
 
-This class of key-loggers target and compromise the Web site you will be visiting. This is in contrast to the three other forms of key-loggers discussed here, which target and compromise your own computer.
-
-The JavaScript and VBScript languages offer facilities for a Web page to react to keystrokes. Legitimate uses of these facilities enable the creation of sophisticated Web pages. For example, consider how Google and Yahoo! searches react to the keys you type in order to suggest a possible search string.
-
-Exploiting security weaknesses in a Web site, a spy embeds a scripted key-logger into one of the pages in the site. These key-logger are practically indistinguishable from other scripts on the same site, and can use the same script facilities to react to your keystrokes, record them or transmit them to a third-party site.
-
-### Defending Against Key-Logger
-
-Sandboxie is not designed to detect or disable key-loggers, but it is designed to make sure that sandboxed software stays in the sandbox, that such software can't integrate into Windows, and that it can be completely discarded when you delete the sandbox.
-
-This means that if you take care to carry out all untrusted activity in the sandbox, you can always delete the sandbox to undo the effects of that activity, and restore your computer to a trusted state.
-
-The first step is to make sure your system is not infected by malicious key-loggers, prior to using Sandboxie. A system scan by an anti-virus or anti-malware tool should help here.
-
-Then carry out all untrusted activity -- such as browsing the Web, reading email, and testing unknown programs -- only in the restricted area of the sandbox. This doesn't mean you won't be infected by key-loggers, but it does mean you can get rid of them:
-
-*   You can make sure you stop all of them, by telling Sandboxie to stop all activity in all sandboxes.
-    *   See also the **Terminate All Programs** command in the [File Menu](FileMenu.md#terminate-all-programs) and the [Tray Icon Menu](TrayIconMenu.md#terminate-all-programs).
-*   Once stopped, you can discard the traces of their program code, by deleting the contents of the sandbox.
-    *   See also [Delete Sandbox](DeleteSandbox.md).
-
-Once discarded, they can no longer record your keyboard activity, and you are safe to browse to trusted sites and enter your passwords.
+Scripted key-loggers target and compromise websites, reacting to keystrokes using languages like JavaScript or VBScript. They are challenging to distinguish from legitimate scripts on the site.
 
-Note that if you don't like to regularly delete your sandbox, you can set aside one sandbox for trusted browsing, and delete just that sandbox before carrying out the trusted activity. But it is still important to first stop all sandboxed activity in all sandboxes, for maximum protection.
+## Defending Against Key-Loggers
 
-* * *
+Sandboxie is not designed to detect or disable key-loggers but ensures sandboxed software stays within the sandbox. By confining untrusted activities to the sandbox, users can delete the sandbox to undo any potential effects and restore their system to a trusted state.
 
-Another protection measure against a key-logger is to configure Sandboxie to deny access to the Internet for anything other than your Web browser, in an attempt to prevent the key-logger from sending out the recorded information. See the setting for "the only program that can access the Internet" in [Program Settings](ProgramSettings.md#internet).
+1. **Pre-Sandboxie Steps:**
+   - Scan your system with an anti-virus or anti-malware tool to ensure it's not infected by key-loggers.
 
-Note two caveats:
+2. **Sandboxed Activity:**
+   - Perform untrusted activities (e.g., browsing, email, testing unknown programs) only in the sandbox.
 
-*   The Internet access feature is neither a replacement for a proper firewall, nor was it designed as a mechanism to counter or hinder key-loggers.
+3. **Termination and Deletion:**
+   - Stop all sandboxed activity using the **Terminate All Programs** command.
+   - Delete the sandbox to discard traces of key-loggers' program code.
 
-*   Some key-loggers could possibly circumvent the Internet access restriction by hijacking the Web browser to be used as a vehicle through which to send out the recorded information.
+4. **Internet Access Restriction:**
+   - Configure Sandboxie to deny internet access for anything other than your web browser. This aims to prevent key-loggers from sending out recorded information.
 
-* * *
+**Important Notes:**
+- Internet access restriction is not a replacement for a firewall and was not designed as a primary defense against key-loggers.
+- Some key-loggers may attempt to bypass internet access restrictions by exploiting the web browser to transmit recorded information.
 
-Go to [Help Topics](HelpTopics.md), [Usage Tips](UsageTips.md).
+For additional details, refer to [Help Topics](HelpTopics.md) and [Usage Tips](UsageTips.md).