pr_comments_round3.json

{"data":{"repository":{"pullRequest":{"reviews":{"nodes":[{"author":{"login":"copilot-pull-request-reviewer"},"comments":{"nodes":[{"path":"shared/src/components/DownloadButton.ts","line":null,"body":"The global TypeScript declarations for the File System Access API are defined within the DownloadButton component file, which couples API type definitions to a specific component. Consider moving these declarations to a separate type definition file (e.g., types/file-system-access.d.ts) or to a shared types location for better reusability and organization.\n```suggestion\n\n```","createdAt":"2025-12-22T15:26:02Z"},{"path":"tools/encryption-decryption/src/page.ts","line":null,"body":"The text detection heuristic has a potential issue with byte value 128 and higher. The condition `byte >= 128` on line 956 assumes that all bytes >= 128 are printable UTF-8 characters, but this is not always true. Invalid UTF-8 sequences or binary data can contain these values. This could lead to misclassification of binary files as text, resulting in corrupted output when decoded. Consider using a more robust UTF-8 validation approach or removing the `|| byte >= 128` condition to be more conservative.\n```suggestion\n            if ((byte >= 32 && byte <= 126) || byte === 10 || byte === 13 || byte === 9) {\n```","createdAt":"2025-12-22T15:26:03Z"},{"path":"tools/encryption-decryption/src/page.ts","line":null,"body":"The function getMimeType returns 'application/octet-stream' as a fallback for unknown extensions. However, when encrypting a file without a recognized extension, this generic MIME type will be stored. On decryption, if the original file had a more specific MIME type (from file.type), that information is lost. Consider preserving the original file.type value when available, rather than always deriving from the extension.","createdAt":"2025-12-22T15:26:03Z"},{"path":"tools/encryption-decryption/src/tool.ts","line":null,"body":"The 'supported' property is hardcoded to true for ChaCha20-Poly1305 in the ENCRYPTION_OPTIONS constant, but the actual support is determined asynchronously by isChaCha20Supported(). This creates an inconsistency where the static list shows ChaCha20 as supported even if it's not available in the browser. This could confuse users or cause runtime errors if they select an unsupported algorithm. Consider either removing ChaCha20 from the static list or adding a comment explaining that runtime validation is required.\n```suggestion\n// Static list for immediate access.\n// Note: For accurate ChaCha20-Poly1305 support, use getEncryptionOptions() which performs runtime detection.\nexport const ENCRYPTION_OPTIONS: EncryptionOption[] = [\n    { id: 'AES-256-GCM', name: 'AES-256-GCM', description: 'Strongest AES encryption (256-bit key)', keyLength: 256, supported: true },\n    { id: 'AES-192-GCM', name: 'AES-192-GCM', description: 'Strong AES encryption (192-bit key)', keyLength: 192, supported: true },\n    { id: 'AES-128-GCM', name: 'AES-128-GCM', description: 'Fast AES encryption (128-bit key)', keyLength: 128, supported: true },\n    { id: 'ChaCha20-Poly1305', name: 'ChaCha20-Poly1305', description: 'Modern stream cipher (256-bit key, runtime support may vary)', keyLength: 256, supported: false },\n```","createdAt":"2025-12-22T15:26:03Z"},{"path":"shared/src/components/DownloadButton.ts","line":null,"body":"Memory leak potential: the URL created with URL.createObjectURL on line 128 is only revoked after a 500ms timeout on line 138. If the component is unmounted or the download is cancelled before this timeout completes, the URL will never be revoked, leading to a memory leak. Consider storing the URL reference and implementing cleanup in a disconnectedCallback lifecycle method, or reducing the timeout duration.\n```suggestion\n    }, 0);\n```","createdAt":"2025-12-22T15:26:04Z"},{"path":"tools/encryption-decryption/src/page.ts","line":781,"body":"Security concern: The cleanup function secureCleanup() clears input fields and variables but doesn't securely wipe the memory. In a security-sensitive encryption tool, password strings and decrypted data may remain in memory even after being set to empty strings or null. JavaScript doesn't provide direct memory wiping capabilities, but consider documenting this limitation or exploring techniques like overwriting with random data before clearing.\n```suggestion\n  // Best-effort helpers to overwrite sensitive data before clearing.\n  // Note: JavaScript cannot guarantee secure memory wiping. These functions\n  // reduce, but do not eliminate, the risk of sensitive data lingering.\n  const secureRandomString = (length: number): string => {\n    if (length <= 0) return '';\n    const charset = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';\n    const charsetLen = charset.length;\n    let result = '';\n\n    const globalAny = globalThis as any;\n    const cryptoObj: Crypto | undefined =\n      (typeof globalThis !== 'undefined' &&\n        (globalAny.crypto || globalAny.msCrypto)) as Crypto | undefined;\n\n    if (cryptoObj && typeof cryptoObj.getRandomValues === 'function') {\n      const randomValues = new Uint32Array(length);\n      cryptoObj.getRandomValues(randomValues);\n      for (let i = 0; i < length; i++) {\n        result += charset[randomValues[i] % charsetLen];\n      }\n    } else {\n      // Fallback to Math.random if crypto is not available.\n      for (let i = 0; i < length; i++) {\n        const idx = Math.floor(Math.random() * charsetLen);\n        result += charset[idx];\n      }\n    }\n\n    return result;\n  };\n\n  const scrubValueElement = (el: { value: string } | null | undefined): void => {\n    if (!el) return;\n    const len = el.value ? el.value.length : 0;\n    if (len > 0) {\n      // Overwrite with random data before clearing.\n      el.value = secureRandomString(len);\n    }\n    el.value = '';\n  };\n\n  // Populate algorithm options with feature detection\n  populateAlgorithmSelect(algorithm);\n\n  // Cleanup hook\n  cleanupHook = () => {\n    // Best-effort scrubbing of sensitive text fields.\n    scrubValueElement(inputText);\n    scrubValueElement(password);\n    scrubValueElement(confirmPassword);\n    scrubValueElement(outputText);\n\n    // copyOutputBtn is not expected to hold sensitive data, so a simple clear is used.\n    if (copyOutputBtn) copyOutputBtn.value = '';\n\n    selectedFile = null;\n\n    // Best-effort scrubbing of in-memory file data.\n    if (fileData) {\n      const globalAny = globalThis as any;\n      const cryptoObj: Crypto | undefined =\n        (typeof globalThis !== 'undefined' &&\n          (globalAny.crypto || globalAny.msCrypto)) as Crypto | undefined;\n      if (cryptoObj && typeof cryptoObj.getRandomValues === 'function') {\n        cryptoObj.getRandomValues(fileData);\n      }\n      // Overwrite again with zeros to reduce residual data.\n      fileData.fill(0);\n    }\n```","createdAt":"2025-12-22T15:26:04Z"},{"path":"tools/encryption-decryption/src/tool.ts","line":null,"body":"Performance issue: The bytesToBase64 function uses string concatenation in a loop, which creates a new string object on each iteration. For large data (like the 1MB test case), this is inefficient and could cause performance degradation. Consider using an array to collect characters and joining at the end, or using alternative methods like TextDecoder with base64 encoding libraries.\n```suggestion\n    const chars = new Array<string>(bytes.length);\n    for (let i = 0; i < bytes.length; i++) {\n        chars[i] = String.fromCharCode(bytes[i]);\n    }\n    const binary = chars.join('');\n```","createdAt":"2025-12-22T15:26:04Z"},{"path":"shared/src/components/DownloadButton.ts","line":null,"body":"Type casting to ArrayBuffer may cause issues with detached or incompatible ArrayBuffers. The Uint8Array.buffer property returns an ArrayBuffer, but when the Uint8Array is a view of a larger buffer (e.g., from a slice), the buffer may contain data beyond what the view represents. Consider using content.slice() or constructing the blob directly from the Uint8Array without accessing .buffer.\n```suggestion\n      : [content];\n```","createdAt":"2025-12-22T15:26:05Z"},{"path":"tools/encryption-decryption/src/page.ts","line":null,"body":"The MIME type fallback logic may not preserve the original MIME type correctly. When a file is decrypted, if originalMimeType is undefined, the code falls back to getMimeType(ext), which derives the MIME type from the file extension. This means that if a file was encrypted with a specific MIME type that doesn't match its extension, the wrong MIME type will be used on decryption. Consider prioritizing originalMimeType over the extension-based lookup.\n```suggestion\n          let mimeType = originalMimeType;\n          if (!mimeType) {\n            const ext = originalFilename?.split('.').pop()?.toLowerCase() || '';\n            mimeType = getMimeType(ext) || 'application/octet-stream';\n          }\n          downloadBtn.mimeType = mimeType;\n```","createdAt":"2025-12-22T15:26:05Z"},{"path":"tools/encryption-decryption/src/tool.ts","line":432,"body":"Maintainability issue: The decryptWithMetadata method parses the encrypted payload twice - once in lines 385-388 to extract metadata, and again when calling this.decrypt() on line 391, which parses it again internally. This is inefficient and duplicates parsing logic. Consider refactoring to parse once and reuse the parsed payload, or have decrypt() optionally return metadata.","createdAt":"2025-12-22T15:26:05Z"},{"path":"shared/src/components/DownloadButton.ts","line":null,"body":"Unexpected any. Specify a different type.\n```suggestion\n        if (err instanceof Error && err.name === 'AbortError') return;\n```","createdAt":"2025-12-22T15:26:05Z"},{"path":"tools/encryption-decryption/src/page.ts","line":null,"body":"'EncryptionOption' is defined but never used.\n```suggestion\nimport type { EncryptionAlgorithm, AdvancedOptions } from './tool';\n```","createdAt":"2025-12-22T15:26:06Z"},{"path":"tools/encryption-decryption/tests/tool.unit.test.ts","line":null,"body":"Unexpected any. Specify a different type.\n```suggestion\n            const info = EncryptorTool.getAlgorithmInfo('INVALID' as unknown as EncryptionAlgorithm);\n```","createdAt":"2025-12-22T15:26:06Z"}]}},{"author":{"login":"copilot-pull-request-reviewer"},"comments":{"nodes":[{"path":"tools/encryption-decryption/src/tool.ts","line":null,"body":"Potential race condition with cached support detection. The '_chacha20Supported' cache variable is checked at the start of 'isChaCha20Supported()' and set at the end, but if multiple concurrent calls occur before the first completes, they will all bypass the cache check and attempt to generate keys, potentially causing redundant operations and race conditions. Consider using a promise-based cache or mutex pattern to ensure only one detection attempt runs at a time.\n```suggestion\nlet _chacha20SupportPromise: Promise<boolean> | null = null;\n\n/**\n * Check if ChaCha20-Poly1305 is supported in this browser\n */\nexport async function isChaCha20Supported(): Promise<boolean> {\n    // Fast path: support has already been determined\n    if (_chacha20Supported !== null) {\n        return _chacha20Supported;\n    }\n\n    // If a detection is already in progress, reuse its promise\n    if (_chacha20SupportPromise) {\n        return _chacha20SupportPromise;\n    }\n\n    // Start a new detection and cache the in-flight promise\n    _chacha20SupportPromise = (async () => {\n        try {\n            // Try to generate a ChaCha20-Poly1305 key\n            await crypto.subtle.generateKey(\n                { name: 'ChaCha20-Poly1305', length: 256 } as Algorithm,\n                false,\n                ['encrypt', 'decrypt']\n            );\n            _chacha20Supported = true;\n        } catch {\n            _chacha20Supported = false;\n        }\n        return _chacha20Supported;\n    })();\n\n    return _chacha20SupportPromise;\n```","createdAt":"2025-12-22T16:05:41Z"},{"path":"tools/encryption-decryption/src/tool.ts","line":null,"body":"Error handling loses original error information. When decryption fails, the catch block on line 338 throws a generic error message without preserving the original error. This makes debugging difficult and could hide useful information about what went wrong (e.g., authentication tag verification failure vs. other crypto errors). Consider logging the original error or including more specific error details in the message.\n```suggestion\n        } catch (error: unknown) {\n            if (error instanceof Error) {\n                throw new Error(\n                    `Decryption failed: incorrect password or corrupted data. Details: ${error.message}`,\n                    { cause: error }\n                );\n            }\n```","createdAt":"2025-12-22T16:05:41Z"},{"path":"tools/encryption-decryption/src/tool.ts","line":null,"body":"Inconsistent error message format. The error message 'Decryption failed: incorrect password or corrupted data' uses a colon and lowercase format, while other error messages in the same file use plain format without colons (e.g., 'Password is required', 'No data to encrypt'). Consider standardizing error message formatting for consistency.\n```suggestion\n            throw new Error('Decryption failed due to incorrect password or corrupted data');\n```","createdAt":"2025-12-22T16:05:41Z"},{"path":"shared/src/components/DownloadButton.ts","line":null,"body":"The type assertion 'as any' bypasses TypeScript's type safety when creating blob content. On line 85, 'content as any' is used which could mask type errors. Consider explicitly handling the Uint8Array type or using a more specific type assertion that maintains type safety while accommodating the Blob constructor's requirements.\n```suggestion\n    const blobContent: BlobPart[] = typeof content === 'string'\n      ? [content]\n      : [content as BlobPart];\n```","createdAt":"2025-12-22T16:05:42Z"},{"path":"tools/encryption-decryption/src/page.ts","line":null,"body":"The PBKDF2 iteration minimum of 10,000 is below current OWASP recommendations. The advanced options allow users to set iterations as low as 10,000 (line 657), while OWASP recommends at least 210,000 iterations for PBKDF2-SHA256 as of 2023. Although the default is 100,000 which is reasonable, allowing users to set it lower could result in weaker key derivation. Consider increasing the minimum to at least 100,000 or adding a warning when users select low values.\n```suggestion\n            <input type=\"number\" class=\"advanced-input\" id=\"iterations\" value=\"${DEFAULT_PBKDF2_ITERATIONS}\" min=\"100000\" max=\"1000000\">\n```","createdAt":"2025-12-22T16:05:42Z"},{"path":"tools/encryption-decryption/src/page.ts","line":1065,"body":"Sensitive data in memory might not be cleared properly in error scenarios. When encryption or decryption fails (line 1057), the catch block doesn't ensure that sensitive variables like 'pwd' are cleared from memory before the error is shown. While the cleanup hook exists, it only runs on page navigation. Consider explicitly clearing sensitive variables in the finally block or on error.","createdAt":"2025-12-22T16:05:42Z"},{"path":"tools/encryption-decryption/src/page.ts","line":1052,"body":"Variable 'ext' is declared but its value is not used. The variable 'ext' is assigned on line 1043, then reassigned on line 1046 without using the first value. Consider removing line 1044 or using a different variable name for line 1046 to avoid confusion.\n```suggestion\n\n```","createdAt":"2025-12-22T16:05:42Z"},{"path":"tools/encryption-decryption/tests/tool.unit.test.ts","line":null,"body":"The copyright year in the user-visible test string is '2024', which may need updating. Consider using the current year or making this a dynamic value if this test is meant to be maintained long-term.","createdAt":"2025-12-22T16:05:43Z"},{"path":"shared/src/components/DownloadButton.ts","line":null,"body":"Do not use a triple slash reference for ../types.d.ts, use `import` style instead.\n```suggestion\nimport '../types.d.ts';\n```","createdAt":"2025-12-22T16:05:43Z"},{"path":"tools/encryption-decryption/src/page.ts","line":null,"body":"Unexpected any. Specify a different type.\n```suggestion\n  type GlobalWithCrypto = typeof globalThis & { crypto?: Crypto; msCrypto?: Crypto };\n  const globalWithCrypto = globalThis as GlobalWithCrypto;\n  const cryptoObj: Crypto | undefined =\n    (typeof globalThis !== 'undefined' &&\n      (globalWithCrypto.crypto || globalWithCrypto.msCrypto)) as Crypto | undefined;\n```","createdAt":"2025-12-22T16:05:43Z"},{"path":"tools/encryption-decryption/src/page.ts","line":null,"body":"Unexpected any. Specify a different type.\n```suggestion\n      const globalWithCrypto = globalThis as typeof globalThis & {\n        crypto?: Crypto;\n        msCrypto?: Crypto;\n      };\n      const cryptoObj: Crypto | undefined =\n        typeof globalThis !== 'undefined'\n          ? (globalWithCrypto.crypto ?? globalWithCrypto.msCrypto)\n          : undefined;\n```","createdAt":"2025-12-22T16:05:43Z"}]}},{"author":{"login":"copilot-pull-request-reviewer"},"comments":{"nodes":[{"path":"tools/encryption-decryption/src/page.ts","line":57,"body":"The password scrubbing implementation using Math.random() as a fallback is not cryptographically secure and defeats the purpose of secure memory wiping. While the comment acknowledges JavaScript's limitations in secure memory wiping, using Math.random() in a security-sensitive context sends mixed signals. Consider either removing the fallback entirely (since crypto should be available in modern browsers where this tool runs) or documenting more clearly that the fallback is insecure and only present for extreme edge cases.\n```suggestion\n    // In environments without Web Crypto, fall back to a fixed pattern instead\n    // of Math.random(). This does not provide cryptographic security and is\n    // only a best-effort overwrite before clearing the value.\n    const fillChar = '0';\n    for (let i = 0; i < length; i++) {\n      result += fillChar;\n```","createdAt":"2025-12-22T16:18:03Z"},{"path":"shared/src/components/DownloadButton.ts","line":15,"body":"The comment says \"Types are now in shared/src/types.d.ts\" but this comment doesn't explain what types it's referring to or provide context about why they were moved. This comment would be more helpful if it explained that the File System Access API types have been moved to a shared types file for reuse across components, or it could be removed entirely if it's not adding value.\n```suggestion\n// File System Access API type definitions are centralized in shared/src/types.d.ts for reuse across components.\n```","createdAt":"2025-12-22T16:18:03Z"},{"path":"shared/src/components/DownloadButton.ts","line":106,"body":"The error handling here catches all exceptions and rethrows them generically. This could mask important errors. Consider catching only specific expected exceptions (like DOMException for AbortError) and letting other errors propagate naturally. Additionally, when the File System Access API fails for reasons other than user cancellation, the fallback to the legacy download method may not be the desired behavior for all error types.\n```suggestion\n      } catch (err: unknown) {\n        if (err && typeof err === 'object') {\n          const anyErr = err as { name?: string };\n          if (anyErr.name === 'AbortError') {\n            // User canceled the save dialog; treat as a no-op.\n            return;\n          }\n        }\n        // Propagate unexpected errors so they are not masked and do not fall back silently.\n        throw err;\n```","createdAt":"2025-12-22T16:18:04Z"},{"path":"tools/encryption-decryption/src/page.ts","line":1034,"body":"The heuristic for detecting text vs binary data (checking if >90% of bytes are printable ASCII) is too simplistic and may produce false positives/negatives. For example, UTF-8 encoded text with many non-ASCII characters (like Chinese, Arabic, or emoji-heavy content) could be incorrectly classified as binary. Additionally, some binary formats might have large text headers that could be misclassified as text. Consider using a more robust detection method or allowing users to manually specify the content type during decryption.\n```suggestion\n        // Try to detect whether the decrypted data is text by attempting UTF-8 decoding\n        let decodedText: string | null = null;\n        const isLikelyText = (() => {\n          try {\n            // Use fatal decoding so invalid UTF-8 sequences cause an error\n            const decoder = new TextDecoder('utf-8', { fatal: true });\n            decodedText = decoder.decode(decrypted);\n          } catch {\n            decodedText = null;\n            return false;\n          }\n\n          if (!decodedText) {\n            return false;\n          }\n\n          // Analyze a sample of the decoded text for control characters\n          const sample = decodedText.slice(0, 2048);\n          let controlCount = 0;\n          for (let i = 0; i < sample.length; i++) {\n            const code = sample.charCodeAt(i);\n            // Reject if we see any NUL bytes\n            if (code === 0) {\n              return false;\n            }\n            // Count non-whitespace control characters\n            if (code < 32 && code !== 9 && code !== 10 && code !== 13) {\n              controlCount++;\n            }\n          }\n\n          // If less than 5% of characters are non-whitespace control chars, treat as text\n          return sample.length === 0 ? false : (controlCount / sample.length) < 0.05;\n        })();\n\n        if (isLikelyText && decodedText !== null) {\n          // Text data\n          result = decodedText;\n```","createdAt":"2025-12-22T16:18:04Z"},{"path":"shared/src/components/DownloadButton.ts","line":179,"body":"The new LuDownloadButton component lacks test coverage. Other shared components like LuCopyToClipboard should have corresponding tests (if they exist), and this new component should follow the same pattern. Consider adding unit tests to verify the component's behavior, especially the File System Access API integration and fallback logic.","createdAt":"2025-12-22T16:18:04Z"},{"path":"shared/src/components/DownloadButton.ts","line":86,"body":"The variable name 'blobContent' is misleading since it's not the blob itself but rather the array of parts that will be used to construct the blob. Consider renaming to 'blobParts' or 'contentParts' for clarity.\n```suggestion\n    const blobParts = typeof content === 'string'\n      ? [content]\n      : [content as unknown as BlobPart];\n    const blob = new Blob(blobParts, { type: mimeType });\n```","createdAt":"2025-12-22T16:18:04Z"},{"path":"shared/src/components/DownloadButton.ts","line":121,"body":"The fallback download implementation doesn't handle potential errors from createObjectURL or other DOM operations. Consider wrapping this in a try-catch block to handle edge cases where blob creation or download might fail.\n```suggestion\n    let url: string | undefined;\n    let a: HTMLAnchorElement | null = null;\n    try {\n      url = URL.createObjectURL(blob);\n      a = document.createElement('a');\n      a.href = url;\n      a.download = filename;\n      a.style.display = 'none';\n      if (document.body) {\n        document.body.appendChild(a);\n        a.click();\n      }\n    } catch (error) {\n      // Swallow or log the error to avoid breaking the page if download fails\n      // eslint-disable-next-line no-console\n      console.error('LuDownloadButton: fallback download failed', error);\n    } finally {\n      if (url && a) {\n        setTimeout(() => {\n          if (a && a.parentNode) {\n            a.parentNode.removeChild(a);\n          }\n          URL.revokeObjectURL(url as string);\n        }, 0);\n      }\n    }\n```","createdAt":"2025-12-22T16:18:05Z"},{"path":"tools/encryption-decryption/src/page.ts","line":122,"body":"The MIME type inference from file extension is incomplete and could lead to incorrect file type detection. The getMimeType function is missing common file extensions like '.ts', '.py', '.java', '.c', '.cpp', '.go', '.rs', and many others. More importantly, for security-sensitive encryption operations, relying solely on file extension for MIME type is risky. Consider using the File API's type property as the primary source (which you do on line 974), and only fall back to extension-based detection when the File object doesn't provide a type.\n```suggestion\n    // Text / Source code\n    txt: 'text/plain',\n    html: 'text/html',\n    css: 'text/css',\n    js: 'text/javascript',\n    mjs: 'text/javascript',\n    jsx: 'text/jsx',\n    ts: 'application/typescript',\n    tsx: 'text/tsx',\n    json: 'application/json',\n    xml: 'application/xml',\n    csv: 'text/csv',\n    md: 'text/markdown',\n    py: 'text/x-python',\n    java: 'text/x-java-source',\n    c: 'text/x-c',\n    h: 'text/x-c',\n    cpp: 'text/x-c++',\n    hpp: 'text/x-c++',\n    cs: 'text/x-csharp',\n    go: 'text/x-go',\n    rs: 'text/rust',\n    php: 'text/x-php',\n    rb: 'text/x-ruby',\n    sh: 'text/x-shellscript',\n```","createdAt":"2025-12-22T16:18:05Z"},{"path":"tools/encryption-decryption/src/page.ts","line":883,"body":"Reading the entire file into memory with arrayBuffer() could cause performance issues or memory problems with very large files. Consider implementing streaming or chunked encryption for large files, or at minimum, adding a file size check with a warning to users about memory constraints before processing extremely large files.","createdAt":"2025-12-22T16:18:05Z"},{"path":"tools/encryption-decryption/src/tool.ts","line":354,"body":"The error message format is inconsistent with other error messages in the codebase. This error includes implementation details (the original error message) which may expose internal information. Consider using a simpler, user-friendly message like \"Decryption failed due to incorrect password or corrupted data\" without the technical details in the main message. Technical details could be logged separately for debugging purposes.\n```suggestion\n                    'Decryption failed due to incorrect password or corrupted data',\n```","createdAt":"2025-12-22T16:18:06Z"},{"path":"shared/src/components/DownloadButton.ts","line":94,"body":"The type cast 'as any' bypasses TypeScript's type checking. While the File System Access API types are defined in types.d.ts, using 'any' here defeats the purpose. Consider using 'window.showSaveFilePicker' directly since it's defined in the Window interface in types.d.ts, or use a proper type assertion like '(window as Window).showSaveFilePicker'.\n```suggestion\n        const handle = await window.showSaveFilePicker({\n```","createdAt":"2025-12-22T16:18:06Z"},{"path":"shared/src/components/DownloadButton.ts","line":12,"body":"Using innerHTML to escape HTML is a clever technique, but it's generally considered an anti-pattern for security reasons. While it works correctly here, it's better to use textContent assignment and then read it back, or use a proper escaping library. The current implementation could be confusing to other developers and might be flagged by security scanners.\n```suggestion\n  return text.replace(/[&<>\"']/g, (ch) => {\n    switch (ch) {\n      case '&':\n        return '&amp;';\n      case '<':\n        return '&lt;';\n      case '>':\n        return '&gt;';\n      case '\"':\n        return '&quot;';\n      case \"'\":\n        return '&#39;';\n      default:\n        return ch;\n    }\n  });\n```","createdAt":"2025-12-22T16:18:06Z"},{"path":"tools/encryption-decryption/src/page.ts","line":1071,"body":"The password scrubbing logic after each operation (lines 1069-1070) only scrubs the password inputs but doesn't scrub the passwords already read into the 'pwd' variable (line 933) that's still in scope in the event handler closure. While JavaScript's garbage collector will eventually reclaim this memory, the sensitive password data remains in the 'pwd' variable until the handler function completes. Consider explicitly nullifying or overwriting the 'pwd' variable in the finally block as well.","createdAt":"2025-12-22T16:18:06Z"}]}}]}}}}}