feat: Purge plaintext credential keys from RAM cache when inactivity timeout fires

[shouri123]

Description

API keys cached in sessionStorage remain accessible in RAM indefinitely while the browser is open.

Proposed Solution

Implement an automatic inactivity lock. If no action occurs for 30 minutes, clear in-memory credentials automatically.

[payalrvs3]

@shouri123 I'd like to take this on.

Here's my implementation plan

---

Root cause

The building blocks are already in place: lockCredentials() in credentials.ts correctly zeros out derivedKey and removes the plaintext keys from chrome.storage.session. The problem is the inactivity timer powering it uses a plain setTimeout that lives inside ephemeral renderer contexts (popup, options page). Those pages are destroyed the moment the user closes them, taking the timer with them. The background service worker — the only persistent context — never imports lockCredentials at all and has no timer of its own. Result: once the popup closes, the 30-minute countdown simply stops and the session keys stay in RAM indefinitely.

Plan

1. Move the inactivity alarm to background.ts using chrome.alarms.
   The alarms permission is already in manifest.json and the file already has a chrome.alarms.onAlarm listener for the retry queue. I'll register a named alarm (e.g. credential-inactivity-lock) for 30 minutes and handle it in the existing listener — when it fires, purge the credential keys from chrome.storage.session. chrome.alarms survives service-worker suspension, so this is the correct MV3-safe approach.

2. Broadcast lock state to renderer pages.
   When the alarm fires and the purge runs, background will send a credentials-locked runtime message so the popup and options page can immediately flip their UI to the locked state without waiting for user interaction.

3. Wire up activity-based reset from renderer pages.
   Popup and options page will listen for meaningful user interactions (keydown, click, focus) and send a reset-credential-timer message to background, which recreates the alarm for another 30 minutes. This extends the existing pattern — getApiCredentials() already resets the timer on API activity; this adds coverage for idle UI sessions.

4. Clean up the renderer-side setTimeout.
   resetAutoLockTimer() in credentials.ts can be simplified or removed — the chrome.alarms approach in background is the authoritative timer now. The lockCredentials() purge logic itself stays as-is since it's already correct.

5. Tests.
   Extend credentials.test.ts to explicitly assert that lockCredentials() removes keys from chrome.storage.session (not just clears derivedKey), and add a test for the message-based timer reset flow.

Happy to discuss any part of this before starting. Please assign me!

[bhavyajain0810]

Hi @shouri123,

I would like to work on this issue. I reviewed the existing credential lifecycle in src/utils/credentials.ts before requesting assignment.

I noticed that the repository already has the core groundwork for credential locking:

• A 30-minute AUTO_LOCK_TIMEOUT_MS
• An in-memory derived encryption key
• Timer reset on successful unlock and credential access
• A lockCredentials() path that clears the derived key
• Encrypted credentials retained in chrome.storage.local
• Plaintext credentials cached temporarily in chrome.storage.session

However, I would like to complete and harden this flow so the inactivity timeout has deterministic, fully tested security behaviour.

Proposed approach

1. Audit the complete plaintext credential lifecycle

   • Trace OpenAI and ElevenLabs keys from unlock/decryption through chrome.storage.session.
   • Verify every read/write path consistently updates inactivity state.
   • Ensure no secondary in-memory or session cache remains accessible after locking.

2. Centralize secure cache purging

   • Keep encrypted values in chrome.storage.local untouched.
   • Remove only plaintext credential keys from chrome.storage.session.
   • Clear the in-memory derived key immediately when the timeout fires.
   • Cancel the active timer and make repeated lock calls idempotent.
   • Handle storage removal failures safely without exposing credentials or creating unhandled promise rejections.

3. Make inactivity behaviour consistent

   • Start/reset the timer after successful unlock.
   • Reset it on legitimate credential activity such as credential retrieval and updates.
   • Avoid extending the session for unrelated extension activity.
   • Require a fresh unlock after expiry before encrypted credentials can be decrypted and repopulated.

4. Add focused security tests
   I plan to extend src/utils/credentials.test.ts to verify:

   • Plaintext session keys remain available before the 30-minute limit.
   • The timeout clears both OpenAI and ElevenLabs plaintext session keys.
   • The derived key becomes unavailable after inactivity.
   • Encrypted chrome.storage.local values are preserved.
   • Credential access resets the inactivity window.
   • Manual and automatic locking produce the same cleanup behaviour.
   • Repeated lock calls are safe.
   • A failed chrome.storage.session.remove() call is handled without an unhandled rejection.
   • Credentials cannot be rehydrated after locking until the correct passphrase is supplied again.

5. Regression validation

   • Ensure existing save, unlock, wrong-passphrase, partial-update, and restart flows remain unchanged.

   • Run:

     • npm test
     • npm run lint
     • npm run type-check
     • npm run build
     • npm run format:check if available

Expected files

Primarily:

• src/utils/credentials.ts
• src/utils/credentials.test.ts

I will only touch src/options.ts or src/background.ts if the audit shows that an activity/reset integration point is missing, and I will keep the PR scoped strictly to credential inactivity locking.

I can complete this within 1–2 days after assignment, including tests and all repository checks.

Please assign this issue to me under GSSoC 2026.

[github-actions]

Hello @bhavyajain0810! You have been assigned to this issue. 🚀

Please make sure you have read our contribution guidelines. Happy coding!

---

Please consider starring the repository ⭐ to show your support!

[bhavyajain0810]

Hi @shouri123, While reviewing the implementation for this assigned issue, I noticed that the requested production behaviour already appears to be present on the current main branch.

The existing credential flow now:

• starts a 30-minute inactivity timer,
• invokes lockCredentials() when the timer expires,
• clears the in-memory derived encryption key, and
• removes both plaintext credential keys from chrome.storage.session.

This appears to have been introduced in commit 6287b60 (security: purge plaintext session keys when credentials are locked) on June 7, before this issue was opened on June 8.

I also checked src/utils/credentials.test.ts. Although the implementation is present, there does not appear to be a focused regression test asserting that locking removes both plaintext session keys while retaining the encrypted local-storage copies.

Could you please confirm whether you would like me to:

1. add regression coverage for the session credential purge and inactivity-lock path, or
2. treat this issue as already resolved by the existing commit?

I will hold off on opening a duplicate production-code PR until the intended remaining scope is confirmed.

[bhavyajain0810]

Hi @shouri123,

While preparing to work on this issue, I synced with the latest main and found that the requested behaviour appears to have already been implemented in src/utils/credentials.ts.

The current implementation:

• uses a 30-minute AUTO_LOCK_TIMEOUT_MS,
• calls lockCredentials() when the inactivity timer fires,
• clears the in-memory derived encryption key, and
• removes openai_api_key and elevenlabs_api_key from chrome.storage.session.

Could you please confirm whether any additional scope is still expected for #654, such as dedicated auto-lock/purge test coverage, or whether the issue should now be closed/unassigned as already resolved?

[shouri123]

Hi @shouri123,

While preparing to work on this issue, I synced with the latest main and found that the requested behaviour appears to have already been implemented in src/utils/credentials.ts.

The current implementation:

• uses a 30-minute AUTO_LOCK_TIMEOUT_MS,
• calls lockCredentials() when the inactivity timer fires,
• clears the in-memory derived encryption key, and
• removes openai_api_key and elevenlabs_api_key from chrome.storage.session.

Could you please confirm whether any additional scope is still expected for #654, such as dedicated auto-lock/purge test coverage, or whether the issue should now be closed/unassigned as already resolved?

Let me see the codebase and then I can tell you just wait for sometime I will let you know

[bhavyajain0810]

@shouri123, sure, thank you. I’ll wait for your confirmation before making any changes.

[bhavyajain0810]

Hi @shouri123, just following up regarding #654, as it has been quite some time since your last message.

After reviewing the earlier discussion more carefully, I understand that the remaining concern is not simply whether lockCredentials() removes the session keys—it already does—but whether the 30-minute inactivity timer remains reliable after the popup or options page is closed.

The current setTimeout appears to run inside short-lived renderer contexts, so it may be destroyed when those pages are unloaded. The more reliable Manifest V3 approach would be to use a named chrome.alarms alarm from the background service worker, purge the plaintext session credentials when it fires, and reset the alarm through explicit credential-related activity messages.

Could you please confirm whether I should proceed with that background chrome.alarms implementation, along with focused tests for alarm expiry, credential purging, encrypted-value preservation, and timer reset behaviour?

I am still holding off on code changes until your confirmation so that the implementation matches your intended scope.