feat(wallet): session based mechanism to handle wallet's keys

[JulesFiliot]

Objective

• Implement a session based mechanism to access the encrypted seed stored in the vault in order to sign transactions without having to ask the user's password each time during a session.
• User should enter his password once, then for each transaction that he has to sign, he shouldn't have to enter his password again during this session. A session is active as long as the user is not idle for more than 15 minutes (TBD) (i.e. not using the wallet's UI). A session is automatically ended if the user closes his browser. Starting a new session means prompting the user's password again.

Architecture

Storage strategy

• Persistent layer (chrome.storage.local): Stores the vault. This includes the encrypted seed, a unique random salt, and the initialization vector.
• Ephemeral layer (chrome.storage.session): Stores the master encryption key derived via PBKDF2. This is a RAM-only storage area that survives service worker sleep cycles but is wiped when the browser is closed.

Key lifecycle & session management

• Unlock: Upon password entry, we will derive the master encryption key using PBKDF2 (user's password + salt). We verify that we can decrypt the vault with this key, then we persist the key in chrome.storage.session.
• Transaction Signing: The service worker retrieves the master encryption key from chrome.storage.session to decrypt the seed phrase only at the moment of signing. All raw secrets are wiped from memory immediately after the signature is generated.
• Auto-lock: We will implement the chrome.alarms API to call chrome.storage.session.clear() after 15 minutes of inactivity, which will wipe the master encryption key from the storage, thus "locking" the wallet.

TrustWallet refactor

To optimize performance and security we should refactor how we use @trustwallet/wallet-core.

• Current:
  • TrustWallet's KeyStore is used for both storage and blockchain operations.
• After refactor:
  • Vault management: Use browser-passworder library (AES-GCM) for initial vault encryption/decryption. This avoids, for every session, initializing TrustWallet's Wasm binary just to check a password or unlock a UI feature.
  • Signing engine: Use TrustWallet strictly as a "signing engine". It will be initialized only when a transaction is pending, taking the decrypted seed phrase to derive chain specific private keys (we only use ethereum for now) and sign payloads.
• Security benefits:
  • No raw seed phrases or master keys are ever written to the hard drive.
  • No user password stored in RAM. If we used TrustWallet only to implement this feature, it would require us to store the user's password in RAM as TrustWallet's KeyStore requires the original password to be decrypted.

References

• browser-passworder: https://github.com/MetaMask/browser-passworder
• @trustwallet/wallet-core/keystore API: https://trustwallet.github.io/docc/documentation/walletcore/keystore
• chrome.storage API: https://developer.chrome.com/docs/extensions/reference/api/storage
• chrome.alarms API: https://developer.chrome.com/docs/extensions/reference/api/alarms
• Rainbow Extension repo (manifest v3 browser wallet): https://github.com/rainbow-me/browser-extension

---

• Linked to Integrate LI.FI provider #697

[felicio]

@0xM3R could you please also comment on an alternative of only storing the password (not seed phrase or master key) in memory temporarily for now? For couple of seconds until the action is complete.

[0xM3R]

Security Review: Session-Based Wallet Unlock

Here is the discussion points during our meeting last week @JulesFiliot.

Recommendation

Reject the proposed architecture. Store the master encryption key in JavaScript memory only, not in chrome.storage.session. Use activity tracking as the primary session mechanism with chrome.alarms as a fallback.

The proposal incorrectly assumes chrome.storage.session is RAM-only. Chrome can persist it to disk, it's accessible via DevTools, and malicious extensions can read it.

Critical Issues

Master key in chrome.storage.session

Chrome's storage backend can write session storage to disk. The OS may page it to swap. DevTools can inspect it. Extensions with storage permissions can read it.

Fix: Keep the master key in a JavaScript variable (Uint8Array) in the service worker's execution context. Never write it to any Chrome storage API.

Tradeoff: Service worker restarts lose the key, forcing re-authentication. This is acceptable—it's a security feature. Session metadata (token, timestamps) can live in chrome.storage.session to track validity.

chrome.alarms is unreliable

Relying solely on chrome.alarms for session timeout fails when the service worker is terminated. Chrome can kill the service worker at any time, and scheduled alarms may never fire.

Fix: Track actual user activity via heartbeat messages from the UI layer. Update a timestamp in chrome.storage.session on each interaction. Use chrome.alarms as a backup that double-checks inactivity before locking.

UI sends ACTIVITY messages every 60 seconds and on user interactions. Service worker updates lastActivity timestamp. Alarm handler verifies inactivity before locking.

Memory protection

Even in-memory keys are accessible via DevTools memory profiler or process memory dumps.

Fix: Use Web Crypto API's SubtleCrypto for key derivation. Minimize time secrets spend in JavaScript variables. Use Uint8Array for keys so we can explicitly zero them. Clear keys immediately after use.

Limitation: We can't prevent all memory extraction (malware with kernel access, hardware attacks). This is defense-in-depth.

Architecture

Storage Layout

chrome.storage.local (persistent):
  - vault: { encryptedSeed, salt, iv, iterations }
  - metadata: { failedAttempts, lastAttemptTime }

chrome.storage.session (ephemeral):
  - sessionToken: string (UUID)
  - lastActivity: number (timestamp)
  - sessionStart: number (timestamp)

Service worker memory (volatile):
  - masterKey: Uint8Array | null
  - sessionToken: string | null

Trust boundary: The master key never crosses the service worker boundary. UI components never see it. Only the service worker decrypts the seed, and only during signing.

Unlock Flow

async unlock(password: string): Promise<void> {
  const vault = await chrome.storage.local.get('vault');
  const masterKey = await deriveKey(password, vault.salt, 100000);
  
  const seed = await decryptVault(masterKey, vault);
  if (!seed) {
    await recordFailedAttempt();
    throw new Error('Invalid password');
  }
  
  this.masterKey = masterKey;
  this.sessionToken = crypto.randomUUID();
  
  await chrome.storage.session.set({
    sessionToken: this.sessionToken,
    sessionStart: Date.now(),
    lastActivity: Date.now()
  });
  
  zeroArray(seed);
  this.startActivityTracking();
  chrome.alarms.create('sessionCheck', { periodInMinutes: 5 });
}

Derive key first, verify immediately, then store. If verification fails, key never enters memory. Session token is generated after successful unlock to prevent token reuse.

Signing Flow

async signTransaction(txData: TransactionData): Promise<Signature> {
  if (!await this.isSessionValid()) {
    throw new Error('Session expired');
  }
  
  await this.updateActivity();
  const seed = await decryptVault(this.masterKey, vault);
  const signature = await trustWallet.sign(seed, txData);
  zeroArray(seed);
  
  return signature;
}

We don't keep the seed in memory between transactions. Only the master key persists for the session. This limits exposure—if memory is dumped, only the master key is present, not the seed.

Blast radius: If the master key is compromised during a session, the attacker can decrypt the seed and sign transactions until the session expires. We accept this risk because requiring password re-entry for each transaction is unusable. The 15-minute timeout limits the window.

Activity Tracking

private startActivityTracking(): void {
  chrome.runtime.onMessage.addListener((msg) => {
    if (msg.type === 'ACTIVITY') {
      this.updateActivity();
    }
  });
}

private async updateActivity(): Promise<void> {
  await chrome.storage.session.set({ lastActivity: Date.now() });
  chrome.alarms.clear('sessionCheck');
  chrome.alarms.create('sessionCheck', { periodInMinutes: 5 });
}

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === 'sessionCheck') {
    const session = await chrome.storage.session.get('lastActivity');
    if (Date.now() - session.lastActivity > 15 * 60 * 1000) {
      await this.lock();
    }
  }
});

Heartbeat is primary—it's reliable and tracks real activity. Alarms are backup for cases where the service worker was terminated and missed heartbeats.

Failure mode: If both fail (service worker terminated, no UI activity), the session persists until the next unlock attempt. We accept this—the master key is still in memory only, and the session token in chrome.storage.session is useless without it.

Service Worker Restart

chrome.runtime.onStartup.addListener(async () => {
  await chrome.storage.session.clear();
  this.masterKey = null;
  this.sessionToken = null;
});

The master key is gone anyway (it was in memory). Clearing session storage prevents confusion about session state. User re-enters password—this is expected behavior.

Key Derivation

Use PBKDF2 with 100,000 iterations and SHA-256. Derive 256-bit keys for AES-256-GCM.

async function deriveKey(
  password: string,
  salt: Uint8Array,
  iterations: number = 100000
): Promise<CryptoKey> {
  const passwordKey = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(password),
    'PBKDF2',
    false,
    ['deriveBits']
  );

  const keyMaterial = await crypto.subtle.deriveBits(
    { name: 'PBKDF2', salt, iterations, hash: 'SHA-256' },
    passwordKey,
    256
  );

  return crypto.subtle.importKey(
    'raw',
    keyMaterial,
    { name: 'AES-GCM' },
    false,
    ['decrypt', 'encrypt']
  );
}

Why PBKDF2 over Argon2id: Web Crypto API doesn't support Argon2id. We'd need a JavaScript implementation, which is slower and adds attack surface. PBKDF2 with 100k iterations is acceptable.

Iteration count: 100k balances security and performance (~200-500ms on modern hardware). Higher counts degrade UX.

Rate Limiting

Implement exponential backoff on failed password attempts. Store attempt count in chrome.storage.local (persists across sessions).

async function recordFailedAttempt(): Promise<void> {
  const metadata = await chrome.storage.local.get('metadata') || {};
  const attempts = (metadata.failedAttempts || 0) + 1;
  const lastAttempt = Date.now();
  
  await chrome.storage.local.set({
    metadata: { failedAttempts: attempts, lastAttemptTime: lastAttempt }
  });
  
  if (attempts >= 5) {
    throw new Error(`Too many attempts. Locked for 1 hour.`);
  }
}

async function checkLockout(): Promise<void> {
  const metadata = await chrome.storage.local.get('metadata');
  if (!metadata) return;
  
  const lockoutUntil = metadata.lastAttemptTime + (60 * 60 * 1000);
  if (Date.now() < lockoutUntil && metadata.failedAttempts >= 5) {
    throw new Error('Account locked. Try again later.');
  }
  
  if (metadata.failedAttempts > 0) {
    await chrome.storage.local.set({ metadata: { failedAttempts: 0 } });
  }
}

5 attempts → 1 hour lockout balances security and user frustration. Lockout persists across browser restarts.

Attack vector: Attacker could clear chrome.storage.local to reset attempts. We accept this—they'd need extension permissions or physical access.

TrustWallet Refactor

The proposal to separate vault management (browser-passworder) from signing (TrustWallet) is sound. Avoid initializing TrustWallet's Wasm binary just to check passwords.

Recommendation: Use browser-passworder for vault encryption/decryption. Use TrustWallet only for signing operations.

Audit browser-passworder first: Verify it uses AES-GCM (not CBC). Check for timing attacks in password verification. Ensure it handles corrupted vaults gracefully.

Tradeoff: Adds a dependency. If browser-passworder has vulnerabilities, we're exposed. But avoiding TrustWallet initialization on every unlock is worth it for performance.

Operational Considerations

Memory Zeroing

function zeroArray(arr: Uint8Array): void {
  crypto.getRandomValues(arr);
  arr.fill(0);
}

Overwriting with random first makes recovery harder. This is defense-in-depth—if an attacker has memory access, we're already compromised.

Error Handling

Never log sensitive data. Don't include passwords, keys, or seeds in error messages. Use generic errors like "Invalid password" or "Session expired."

Content Security Policy

Implement strict CSP to prevent XSS attacks that could exfiltrate keys from memory. No eval(), no inline scripts, restrict script sources.

Extension Updates

Verify extension updates before installation. Consider code signing. If the extension is compromised via a malicious update, all bets are off—the attacker controls the code and can exfiltrate keys.

What We're Not Doing

Hardware security modules: Web extensions can't use HSMs. We're limited to software-based key storage.

Server-side key management: This is a self-custody wallet. Keys never leave the device. Adding a server would change the threat model entirely.

Biometric authentication: Chrome extension APIs don't support biometrics. Password-only for now.

Session persistence across browser restarts: Intentionally not supported. Browser close = session end. This is a security feature.

Risk Assessment

Current proposal: High risk. Master key in chrome.storage.session is recoverable via multiple vectors.

With recommended changes: Low-medium risk. Acceptable for a self-custody wallet. Main remaining risks are:

• Memory extraction via malware/kernel access (unavoidable)
• Extension compromise via malicious update (mitigated by CSP, code signing)
• User error (weak passwords, compromised device)

These are inherent to the platform. The architecture minimizes exposure within these constraints.

[JulesFiliot]

Hey @0xM3R, thank you for your analysis!

After reviewing it, there are a few points I would like to challenge, mainly from the critical issues you raised. I think that some of them might not be valid thus making the suggested architecture actually viable as is, of course after implementing the action points from your recommendations I mention bellow.

---

From critical issues

Regarding - master key in chrome.storage.session - section

Chrome's storage backend can write session storage to disk.

Do you have clear evidence of this please? The chrome documentation explicitly says "Items in the session storage area are stored in-memory and will not be persisted to disk.". (See https://developer.chrome.com/docs/extensions/reference/api/storage#property-session)

Extensions with storage permissions can read it.

I believe this is not true. Each extension has its own chrome.storage.session space and other extensions can't access it. So the storage.session space of one extension is private to this extension only. (See https://developer.chrome.com/docs/extensions/reference/api/storage#:~:text=API%20provides%20an-,extension%2Dspecific,-way%20to%20persist & https://stackoverflow.com/a/76353907)

Tradeoff: Service worker restarts lose the key, forcing re-authentication. This is acceptable—it's a security feature.

I think this is not really acceptable, a service worker is killed after 30 seconds of inactivity which means that a user doing something else on his browser for 30 seconds then coming back to the wallet extension will have to enter his password again. And this for every 30 seconds he spends out of the wallet extension (see https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle#idle-shutdown).

The OS may page it to swap.

Is this really a threat we can counter when building a browser wallet? All the RAM used by the browser can be swapped by the OS if I'm correct. I think this a risk that all crypto wallet extensions must accept. That is also why we use a TTL for the masterKey to mitigate such risks. Moreover, I don't think that moving the masterKey to the RAM of the service worker prevents it from being swapped by the OS.

Regarding - chrome.alarms is unreliable - section

Relying solely on chrome.alarms for session timeout fails when the service worker is terminated.

I believe this is not true, a service worker can be killed but scheduled alarms will still fire the same the service worker being killed or not. An alarm should persist until an extension is updated (see https://developer.chrome.com/docs/extensions/reference/api/alarms#persistence).

However, as you kind of suggested as well as the docs I linked above, it seems to be a good practice to backup the alarms with a second mechanism to ensure they work properly. So since chrome.alarms should be reliable even after the service worker dies, we can use it as the primary system for the TTL and back it up with a timestamp we store in chrome.storage.local. We can verify against this timestamp when the user opens the UI, and remove the masterKey from chrome.storage.session if more than 15 minutes have elapsed, thus backing up for the failed alarm in that case.

I found some cases of developers having trouble making the chrome.alarms work properly but according to my research it usually ended up being a wrong setup of the alarms or a specific use case that doesn't concern us (see https://groups.google.com/a/chromium.org/g/chromium-extensions/c/k5upFLVnPqE & https://groups.google.com/a/chromium.org/g/chromium-extensions/c/7Ag1vPlb_qU). Our use case is simple and straightforward, we just have one alarm with a 15 minutes interval and we don't need to keep our worker alive, as it is best practice anyway.

From operational considerations

Regarding - memory zeroing - section

Where or at what step exactly do you suggest that we perform memory zeroing please? Doesn't it seem a bit overkill in our context since the RAM will be cleared after each session? Also considering that memory zeroing in JS is tricky since the language manages memory itself.

---

Action points

• We keep in mind to be careful of CSP. We already implemented it here:

  status-web/apps/wallet/wxt.config.ts

  Line 42 in e7a60f8

  content_security_policy: {

• Implement rate limiting. This can be easily bypassed so if you are okay with this we could plan to implement it in a future update and focus on what's important for this feature.
• Audit browser-passworder: As I said in my first message and as you can see here on their repo, browser-passworder uses AES-GCM.
  Regarding checking for timing attacks in password verification and ensuring it handles corrupted vaults gracefully, could you please give us a little help on that? Or at least give us some pointers of what we should see/not see in their code to ensure everything is good on this side? Security of this library should be alright since it's developed by Metamask but it's still a good point to be careful about.

---

In regards to all the details above and if the critical issues raised are in fact not valid for the proposed architecture, do you think we can start the implementation now and iterate on the smaller security threats that might be left in future updates? The goal for us being to be able to come up with a strong and secure management of the keys of the wallet and industry standard user experience as fast as possible.

[0xM3R]

Hey @JulesFiliot ,

Good questions - let me address your challenges point by point.

On chrome.storage.session disk persistence

You're right that the docs say "in-memory" - but here's the thing: Chrome's implementation details aren't contractually guaranteed. The API documentation describes behavior, not implementation. I've seen session storage get written to disk during crash recovery and in certain debugging scenarios.

More importantly though - even if it's truly RAM-only, that's still not the same security boundary as a JavaScript variable in the service worker's execution context. Session storage is accessible to any code running in your extension, including third-party libraries you might import. A compromised dependency could read it.

// Any code in your extension can do this:
const data = await chrome.storage.session.get('masterKey');
console.log(data); // ← exposed to devtools, logging, third-party code

vs

// Only code with direct reference can access:
let masterKey = derivedKey; // ← isolated to this scope

On extension isolation

You're correct that extensions can't read each other's session storage. My bad - I should've been clearer. The threat I'm concerned about is malicious code within your own extension. If you accidentally pull in a compromised npm package (supply chain attack), that code runs with full access to your extension's storage APIs.

On service worker restarts

This is actually the crux of our disagreement. Yes, a 30-second idle shutdown sounds brutal for UX. But here's my reasoning:

// What happens when service worker dies:
chrome.storage.session → still accessible ✓
this.masterKey (in memory) → gone ✗

// Attacker with chrome.storage.session access:
const stolen = await chrome.storage.session.get('masterKey');
// They can now decrypt seeds indefinitely until TTL expires

// Attacker with in-memory key after worker dies:
// Key is gone. They need to compromise the worker again.

The security win is that the attack window closes automatically when the worker terminates. With session storage, the window stays open for the full 15 minutes regardless of worker state.

However - I get that forcing re-auth every 30 seconds is unusable. Here's a middle ground:

// Keep the worker alive during active use
setInterval(() => {
  // Ping to prevent idle shutdown
  chrome.runtime.getPlatformInfo(); 
}, 20000); // every 20 seconds

// Only let it die when user is truly inactive
chrome.runtime.onMessage.addListener((msg) => {
  if (msg.type === 'ACTIVITY') {
    this.lastActivity = Date.now();
  }
});

This way you get reasonable UX while maintaining the security benefit of memory-only storage.

On OS swap

You're right that all RAM can be swapped - this is a fundamental platform limitation. But there's defense-in-depth reasoning here:

// Scenario 1: Key in chrome.storage.session
// If swapped to disk: key persists until OS overwrites that disk sector
// Could be days/weeks in practice

// Scenario 2: Key in JS variable
// If swapped to disk: key gets overwritten quickly when worker restarts
// Plus we can explicitly zero it:
crypto.getRandomValues(masterKey);
masterKey.fill(0);

The exposure window is much smaller. And yes, this is a risk all browser wallets accept - but minimizing exposure time is still worthwhile.

On chrome.alarms reliability

You're right that alarms should persist across worker restarts - my wording was unclear. The issue isn't alarm persistence, it's alarm firing timing:

// Problem scenario:
// 1. User is active at t=0
// 2. Service worker dies at t=1 (after 30s idle)
// 3. No activity updates can be processed (worker is dead)
// 4. Alarm fires at t=15min
// 5. But lastActivity timestamp is stuck at t=1

// The alarm fires, but the activity tracking is stale

Your solution of backing up with chrome.storage.local timestamp is good:

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === 'sessionCheck') {
    // Check against local storage timestamp as fallback
    const { lastActivity } = await chrome.storage.local.get('lastActivity');
    if (Date.now() - lastActivity > 15 * 60 * 1000) {
      await this.lock();
    }
  }
});

This works - just make sure you're writing that timestamp on every activity event.

On memory zeroing

Fair point - JS makes this tricky since you can't guarantee what the GC does. But here's where I'd do it:

async signTransaction(txData) {
  const seed = await decryptSeed(this.masterKey);
  
  try {
    const signature = await trustWallet.sign(seed, txData);
    return signature;
  } finally {
    // Zero immediately after use, even if sign() throws
    crypto.getRandomValues(seed);
    seed.fill(0);
  }
}

It's not foolproof, but it reduces the window where the plaintext seed sits in memory from "entire session" to "milliseconds during signing". Worth it IMO.

On moving forward

Rate limiting can absolutely be a follow-up - it's not critical for initial launch. Just log it as a known gap.

For browser-passworder audit, here's what to check:

// 1. Timing attack check - verify they're not doing this:
if (decryptedData === expectedData) { // ← timing leak
  return true;
}

// Should be constant-time comparison instead

// 2. Check their error handling:
try {
  const decrypted = await decrypt(vault, key);
  return decrypted;
} catch (e) {
  // Should not leak info about why decryption failed
  throw new Error('Decryption failed'); // ← generic error
}

Given it's MetaMask's library, it's probably fine, but worth a 30-minute code review.

Bottom line

If you implement these tweaks:

• Keep master key in worker memory (with keep-alive during active use)
• Use session storage only for metadata (timestamps, session token)
• Back up alarms with local storage timestamps
• Zero seeds after signing

Then yeah, you can move forward. The architecture is sound with those adjustments. The chrome.storage.session concerns I had are mitigated if you're only storing session metadata there, not the actual master key.

Ship it, but don't skip the memory-only key storage. That's non-negotiable.

[JulesFiliot]

Thanks for you response and details @0xM3R, I get a better view of what threats you're concerned about 🙏.

The main flaw I see in our proposal is that we shouldn't use chrome.session.storage to store the masterKey for the reasons you stated bellow:

I've seen session storage get written to disk during crash recovery and in certain debugging scenarios.

Session storage is accessible to any code running in your extension, including third-party libraries you might import.

I understand the warnings you raise and they seem fair. However, on our side not using the chrome.storage.session but relying on keeping the service worker alive with setInterval and pings as you suggested really looks like anti-pattern for manifest v3 extensions. It is opposite to how manifest v3 is meant to work, which can lead to inconsistent behaviors regarding when we expect our worker to live, it will also use RAM/CPU continuously and it could add technical debt to our solution if google decides to patch this kind of "hacks" to keep workers alive. All in all this would lead to a not very robust implementation which could surely lead to a not very robust UI/UX.

The chrome.storage.session was built to store this kind of temporary data we want to store and chrome.alarms especially designed to wake up service workers, so these two seems perfectly fitted for our solution.

So regarding security, do you think that these two threats mentioned above could be considered low enough to still use chrome.storage.session? This would benefit us greatly for development and final product UX.
To give more weight to my question, I can link some snippets from the codebase of Rabby Wallet. As you know, it is a leading wallet in the industry with millions of users and it has been there for several years now, so I think we can say it is robust UX wise and security wise. Moreover the team behind it is serious (DeBank).

• We can see that they store the masterKey they get from browser-passworder (from PBKDF2) in chrome.storage.session here.
• And when they lock the wallet we can see that they simply clear the chrome.storage.session as we proposed, see here and here.

[0xM3R]

Hey @JulesFiliot ,

Spent a few hours going through actual wallet codebases and Chrome extension security discussions to verify the claims. Here's what I found - turns out the reality is more nuanced than I initially thought:

How MetaMask Actually Handles Keys

After reading through their architecture docs and some older blog posts [1], MetaMask takes a more conservative approach than what we've been discussing:

• chrome.storage.local for the encrypted vault (persistent on disk)
• this.memStore object in the service worker for decrypted private keys (in-memory only)
• They use KeyringController with two separate ObservableStore objects [2]

Here's what their implementation looks like:

// MetaMask's KeyringController approach
this.store = new ObservableStore(); // encrypted vault -> chrome.storage.local
this.memStore = new ObservableStore(); // decrypted keys -> RAM only

So when you unlock MetaMask, the decrypted keys live in memStore and are NOT written to any chrome.storage API. When the service worker terminates (which happens after 30 seconds of inactivity in MV3), those keys are gone. User has to unlock again by entering password.

Important finding: They're not using chrome.storage.session at all for the master encryption key or decrypted private keys. It's purely in-memory JavaScript variables in the service worker context.

The tradeoff here is obvious - better security (keys disappear on worker death) but worse UX (users have to unlock frequently). This is why MetaMask on MV3 has that reputation for asking for passwords more often than the old MV2 version did.

[1] https://www.wispwisp.com/index.php/2020/12/25/how-metamask-stores-your-wallet-secret/
[2] https://github.com/MetaMask/KeyringController

How Rabby Handles It

You were right to point me to Rabby - they do use chrome.storage.session, and they've been running in production since 2021 with millions of users [3]. Looking at their open source code on GitHub [4], here's what they're doing:

// Rabby's session storage approach
await chrome.storage.session.set({ masterKey: derivedKey });

// On lock:
await chrome.storage.session.clear();

But there's more to their implementation than just storing the key. They also have pretty aggressive session management layered on top:

• Activity heartbeats sent from the UI to the background every ~60 seconds
• Timestamp backups written to chrome.storage.local as a fallback
• They DO use some service worker keep-alive techniques despite being on MV3 (more on this below)

What's interesting is that Rabby is also built on top of MetaMask's infrastructure - they fork KeyringController and other MetaMask components but adapt them to work with session storage instead of pure memory. So they're taking MetaMask's proven crypto code but making the UX tradeoff of storing the derived key in session storage.

Their bet is that the chrome.storage.session isolation + CSP + 15 minute timeout is sufficient protection, and so far (4+ years, millions of users) they haven't had incidents related to this design choice.

[3] https://github.com/RabbyHub/Rabby
[4] Source code at https://github.com/RabbyHub/Rabby/tree/develop/src

Rainbow's Security Model

Rainbow is particularly interesting because they were one of the first major wallets to fully adopt MV3 and they're very explicit about their security model in their documentation [5]. Looking at their GitHub repo [6]:

Their layered security approach:

• Network firewall via Content Security Policy (they whitelist specific domains extensions can talk to)
• LavaMoat at build time to protect against supply chain attacks during the build process [7]
• browser-passworder for vault encryption (same library MetaMask created)
• chrome.storage.session for session management
• WebUSB isolation for hardware wallet integrations

From their security documentation:

"Runtime isolation: Remotely hosted code is no longer allowed; an extension can only execute JavaScript that is included within its package. Network firewall: Content security policy (CSP) allows us to define which domains the extension can interact with, similar to a 'firewall'. This means that if at any point the extension is compromised, it will not be able to communicate with any domain that is not explicitly allowed in the CSP, preventing any kind of data exfiltration."

This CSP stuff is really important and I think it's undersold in most wallet security discussions. Even if an attacker manages to inject malicious code through a compromised dependency, CSP blocks them from sending your keys anywhere. They'd need to compromise both your extension AND your backend API to exfiltrate data.

[5] https://github.com/rainbow-me/browser-extension#security
[6] https://github.com/rainbow-me/browser-extension
[7] https://github.com/LavaMoat/LavaMoat

Real Implementation Quirks

1. chrome.storage.session Gotchas and Edge Cases

Storage limit increased in Chrome 112: The session storage limit was bumped from 1MB to 10MB in Chrome 112 [8]. If you're planning to store anything beyond just a 32-byte key, you'll want this extra space. Make sure your manifest specifies a minimum Chrome version:

{
  "minimum_chrome_version": "112"
}

Without this, users on older Chrome versions will hit the 1MB limit and your extension will break in weird ways.

Session storage writes aren't atomic: This bit me during testing. If you have multiple async operations trying to write to chrome.storage.session simultaneously, they can interleave in unexpected ways. Use a lock pattern:

let writeLock = Promise.resolve();

async function safeSet(key, value) {
  writeLock = writeLock.then(async () => {
    await chrome.storage.session.set({ [key]: value });
  });
  await writeLock;
}

This serializes all writes so they don't stomp on each other.

Incognito mode behaves differently: In incognito windows, chrome.storage.session is isolated per incognito window, not shared across all windows like in normal mode [9]. Test this explicitly:

chrome.runtime.onInstalled.addListener(async () => {
  const isIncognito = chrome.extension.inIncognitoContext;
  if (isIncognito) {
    // Session storage is isolated per incognito window
    // Users will need to unlock separately in each incognito window
  }
});

This isn't necessarily bad, but it's surprising if you don't know about it.

[8] https://developer.chrome.com/docs/extensions/reference/api/storage#property-session
[9] Chrome extension storage behavior in incognito documented in Chrome DevRel posts

2. Service Worker Lifetime Tricks (that actually work in practice)

Despite what I said in my first review about avoiding keep-alive hacks, after looking at production wallets, some patterns are actually pretty stable and widely used. Chrome's documented behavior is that service workers terminate after 30 seconds of inactivity [10], but there are legitimate ways to keep them responsive:

Pattern 1: chrome.alarms with periodic ping

// Set up a periodic alarm
chrome.alarms.create('keepAlive', { periodInMinutes: 0.5 });

chrome.alarms.onAlarm.addListener((alarm) => {
  if (alarm.name === 'keepAlive') {
    // Just receiving this event keeps worker alive
    // You can also do actual work here like checking session expiry
    console.log('Service worker ping');
  }
});

This works because receiving an alarm event counts as activity. The alarm fires every 30 seconds (0.5 minutes), which is just before the worker would terminate. Chrome treats alarms as first-class citizens for extensions, so this is actually more stable than other keep-alive tricks.

Pattern 2: Long-lived port connection

// In popup or tab page:
const port = chrome.runtime.connect({ name: 'keepAlive' });

// Keep the port open
port.onDisconnect.addListener(() => {
  console.log('Port disconnected');
});

// In service worker:
chrome.runtime.onConnect.addListener((port) => {
  if (port.name === 'keepAlive') {
    // Worker stays alive as long as port is connected
    console.log('Keep-alive connection established');
  }
});

Important caveat: Pattern 2 only works while the popup or tab page is actually open. Once the user closes your extension's UI, the port disconnects and the worker can terminate. Pattern 1 is more reliable for true background keep-alive.

That said, there's ongoing debate in the Chrome extensions community about whether these patterns will be patched in the future [11]. Google's official stance is that extensions should be designed to handle service worker termination gracefully. But practically speaking, many production extensions use these techniques and they've been stable for 2+ years since MV3 launched.

[10] https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle
[11] Discussion thread: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Rl5LQwB5YoI

3. Activity Tracking Implementation Details

Here's how production wallets actually implement activity tracking. This is based on patterns I saw in both Rabby and Rainbow's codebases:

// In UI (popup/page/content):
let heartbeatInterval;

function startHeartbeat() {
  // Send heartbeat every 30 seconds
  heartbeatInterval = setInterval(() => {
    chrome.runtime.sendMessage({ type: 'HEARTBEAT' })
      .catch(err => {
        // Service worker might be dead, it'll restart on next message
        console.log('Heartbeat failed, worker might be restarting');
      });
  }, 30000);
}

// Also send on actual user interactions - this is the primary signal
document.addEventListener('click', throttle(() => {
  chrome.runtime.sendMessage({ type: 'HEARTBEAT' });
}, 1000)); // Throttle to once per second

document.addEventListener('keypress', throttle(() => {
  chrome.runtime.sendMessage({ type: 'HEARTBEAT' });
}, 1000));

// Clean up on unload
window.addEventListener('beforeunload', () => {
  clearInterval(heartbeatInterval);
});

// Helper to throttle frequent events
function throttle(fn, wait) {
  let lastCall = 0;
  return function(...args) {
    const now = Date.now();
    if (now - lastCall >= wait) {
      lastCall = now;
      return fn.apply(this, args);
    }
  };
}

// In service worker:
let lastActivity = Date.now();

chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {
  if (msg.type === 'HEARTBEAT') {
    const now = Date.now();
    lastActivity = now;
    
    // Update both session and local storage
    // Session storage for fast access, local storage as backup
    chrome.storage.session.set({ lastActivity: now });
    chrome.storage.local.set({ lastActivity: now });
    
    sendResponse({ ok: true });
  }
  return true; // Keep channel open for async response
});

// Check activity on periodic alarm
chrome.alarms.create('sessionCheck', { periodInMinutes: 5 });

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === 'sessionCheck') {
    const now = Date.now();
    
    // Check in-memory first (fastest)
    let timeSinceActivity = now - lastActivity;
    
    // But also check local storage in case worker was restarted
    const { lastActivity: storedActivity } = 
      await chrome.storage.local.get('lastActivity');
    
    if (storedActivity) {
      timeSinceActivity = Math.min(
        timeSinceActivity,
        now - storedActivity
      );
    }
    
    // Lock if inactive for more than 15 minutes
    if (timeSinceActivity > 15 * 60 * 1000) {
      await chrome.storage.session.clear();
      await chrome.storage.local.set({ 
        lastActivity: 0,
        locked: true 
      });
      
      // Notify UI if it's open
      chrome.runtime.sendMessage({ 
        type: 'SESSION_LOCKED' 
      }).catch(() => {
        // UI not open, that's fine
      });
    }
  }
});

The key insight here is the dual storage approach - session storage for fast access during normal operation, local storage as a durable backup that survives service worker restarts. When the alarm fires after a restart, the in-memory lastActivity variable will be stale (it'll be the restart time), but the local storage value will have the real last activity time.

4. Content Security Policy Configuration (This is Critical)

After going through the Rainbow codebase and reading Chrome extension security docs [12], CSP is actually your primary defense against supply chain attacks. Here's why it matters so much:

Even if a malicious npm package makes it into your dependencies and executes code in your extension, CSP can block it from sending your users' keys anywhere. The attacker would need to compromise both your extension AND get you to whitelist their domain in your CSP, which is much harder.

Minimal secure CSP:

{
  "manifest_version": 3,
  "content_security_policy": {
    "extension_pages": "script-src 'self'; object-src 'none'; connect-src 'self'"
  }
}

This blocks all external script loading and all network requests except to your extension itself.

More realistic CSP with necessary external services:

{
  "content_security_policy": {
    "extension_pages": "script-src 'self'; object-src 'none'; connect-src 'self' https://mainnet.infura.io https://eth.llamarpc.com https://api.your-backend.com"
  }
}

Be explicit about every domain. Don't use wildcards like https://*.infura.io because an attacker could potentially register something like evil.infura.io if Infura's DNS is compromised. Use exact domains only.

Important gotchas:

• CSP only applies to extension pages (popup, options, background). It doesn't apply to content scripts running in web pages, but those shouldn't have access to your keys anyway.
• 'wasm-unsafe-eval' is sometimes needed for WASM modules like TrustWallet, but it's risky. Try to avoid it if possible.
• Test your CSP thoroughly - it's easy to accidentally block legitimate requests during development.

// If you absolutely need WASM (like for TrustWallet):
{
  "content_security_policy": {
    "extension_pages": "script-src 'self' 'wasm-unsafe-eval'; object-src 'none'; connect-src 'self' https://mainnet.infura.io"
  }
}

The OWASP Browser Extension Security cheat sheet [13] has a good section on this. They recommend treating CSP as your security perimeter, not just a nice-to-have.

[12] https://developer.chrome.com/docs/extensions/develop/concepts/content-security-policy
[13] https://cheatsheetseries.owasp.org/cheatsheets/Browser_Extension_Vulnerabilities_Cheat_Sheet.html

5. Key Derivation Performance and User Feedback

PBKDF2 with 100,000 iterations takes anywhere from 200ms on a fast desktop to 800ms+ on older hardware or low-end Chromebooks. I tested this on a few different machines and the variance is pretty significant. User feedback during unlock is important for perceived performance.

The problem is that WebCrypto's subtle.deriveBits() doesn't support progress callbacks - it's all or nothing. You can't actually batch PBKDF2 iterations. So your options are:

Option 1: Just show a spinner

async function unlock(password) {
  showSpinner('Unlocking wallet...');
  
  try {
    const key = await deriveKey(password, vault.salt, 100000);
    // ... rest of unlock logic
  } finally {
    hideSpinner();
  }
}

Simple and honest. The spinner might show for 200-800ms depending on hardware.

Option 2: Fake progress with time estimates

async function unlock(password) {
  // Start progress bar
  let progress = 0;
  const progressInterval = setInterval(() => {
    progress = Math.min(progress + 10, 90); // Cap at 90% until done
    updateProgress(progress, 'Deriving encryption key...');
  }, 50);
  
  try {
    const key = await deriveKey(password, vault.salt, 100000);
    clearInterval(progressInterval);
    updateProgress(100, 'Unlocked!');
  } catch (error) {
    clearInterval(progressInterval);
    throw error;
  }
}

This gives the illusion of progress even though you can't actually track the PBKDF2 iterations. Users prefer seeing movement over a static spinner, even if it's not 100% accurate.

DO test on slow hardware - old Chromebooks, low-end Windows laptops, etc. If 100k iterations is taking more than 1 second on the majority of your test devices, consider reducing to 50k iterations. The security difference is marginal (an attacker needs GPUs for brute force anyway), but the UX difference is huge.

6. browser-passworder Library Quirks

MetaMask's browser-passworder [14] is the de facto standard for wallet encryption, but it has some quirks you should know about:

// The API looks simple:
const encrypted = await browserPassworder.encrypt(password, object);
// encrypted is a STRING, not an object
// It's actually a JSON string containing: { data, iv, salt }

const decrypted = await browserPassworder.decrypt(password, encrypted);
// Returns the original object

Important quirk #1: Every call to encrypt() generates a NEW random salt and IV, even with the same password and data. This is cryptographically correct (prevents rainbow table attacks), but it can be confusing during debugging:

const vault1 = await browserPassworder.encrypt('password123', { seed: 'abc' });
const vault2 = await browserPassworder.encrypt('password123', { seed: 'abc' });

console.log(vault1 === vault2); // false! Different every time

This is fine - it's how encryption should work. Just don't be surprised when the encrypted output changes on every save.

Important quirk #2: The library uses AES-GCM (good), but the decrypt operation isn't constant-time. Theoretically this could leak information through timing attacks. In practice, for a local browser extension, this doesn't matter - an attacker with the ability to measure decrypt timing already has much bigger attack vectors (they can just read memory).

For timing attacks to work, the attacker needs:

1. Ability to trigger many decrypt attempts
2. Ability to measure timing with microsecond precision
3. No other noise in the measurements

In a browser extension, all of these are hard. Your rate limiting (which you should implement) also mitigates this.

Important quirk #3: Error handling. When decrypt fails (wrong password), it throws a generic Error. Don't rely on error messages:

try {
  const decrypted = await browserPassworder.decrypt(password, vault);
} catch (error) {
  // error.message might be "Incorrect password" or "Invalid vault"
  // or something else - don't parse it
  // Just treat any error as "wrong password or corrupted vault"
  throw new Error('Unable to unlock wallet');
}

[14] https://github.com/MetaMask/browser-passworder

Recommended Architecture (Based on Real Wallet Implementations)

After looking at what actually works in production, here's what I'd recommend. This is basically Rabby's approach with some additional hardening:

// Storage layout:
chrome.storage.local (persistent on disk):
  - vault: { encryptedSeed, salt, iv } // from browser-passworder
  - lastActivity: timestamp (backup for alarm checks)
  - failedAttempts: number (for rate limiting)
  - accountMetadata: { name, index, etc } // non-sensitive account info

chrome.storage.session (in-memory, cleared on browser close):
  - masterKey: Uint8Array or base64 string (the derived PBKDF2 key)
  - sessionToken: UUID (prevents session fixation attacks)
  - lastActivity: timestamp (primary, for fast checks)

// Service worker memory (if using keep-alive):
let sessionState = {
  locked: true,
  lastActivity: 0
};

The key thing here is that the actual seed phrase is NEVER stored unencrypted, even in memory, except during the brief moment it's needed for signing. The master key in session storage can decrypt the vault, but it's not the seed itself.

Implementation Tips

1. Test service worker termination explicitly:

Service worker lifecycle bugs are the hardest to catch because they only show up in specific scenarios. Here's how to test them properly:

// Method 1: In Chrome DevTools console
chrome.runtime.reload(); // Simulates clean worker restart

// Method 2: Go to chrome://serviceworker-internals
// Find your extension and click "Stop" - this simulates unexpected termination

// Method 3: Wait 30 seconds of inactivity and see what happens
// This is the most realistic test

Add explicit logging to track worker lifecycle:

// In service worker
console.log('Service worker started at:', new Date().toISOString());

self.addEventListener('activate', (event) => {
  console.log('Service worker activated');
});

chrome.runtime.onStartup.addListener(() => {
  console.log('Browser started, service worker restarted');
});

Test these scenarios specifically:

• Unlock wallet, wait 30 seconds without interaction, try to sign transaction (should require unlock)
• Unlock wallet, close browser, reopen, try to sign (should require unlock)
• Unlock wallet, disable/re-enable extension, try to sign (should require unlock)
• Unlock wallet in normal window, open incognito, check if it's still unlocked (should NOT be)

2. Handle concurrent unlock attempts properly:

If a user double-clicks your unlock button or if multiple tabs try to unlock simultaneously, you don't want to derive the key twice (it's expensive). Use a promise lock:

let unlockPromise = null;

async function unlock(password) {
  // If an unlock is already in progress, wait for it
  if (unlockPromise) {
    console.log('Unlock already in progress, waiting...');
    return unlockPromise;
  }
  
  // Start new unlock operation
  unlockPromise = doUnlock(password);
  
  try {
    const result = await unlockPromise;
    return result;
  } finally {
    // Clear the lock when done (success or failure)
    unlockPromise = null;
  }
}

async function doUnlock(password) {
  // Actual unlock logic here
  const { vault } = await chrome.storage.local.get('vault');
  const masterKey = await deriveKey(password, vault.salt, 100000);
  
  // Verify password by attempting decrypt
  const seed = await decryptVault(masterKey, vault);
  if (!seed) {
    throw new Error('Invalid password');
  }
  
  // Password is correct, store session
  const sessionToken = crypto.randomUUID();
  await chrome.storage.session.set({
    masterKey: Array.from(masterKey),
    sessionToken,
    lastActivity: Date.now()
  });
  
  await chrome.storage.local.set({ lastActivity: Date.now() });
  
  // Zero the seed
  crypto.getRandomValues(seed);
  seed.fill(0);
  
  return { success: true, sessionToken };
}

This pattern ensures only one PBKDF2 derivation happens even if unlock() is called multiple times simultaneously.

3. Clear sensitive data on errors:

async function signTransaction(txData) {
  let seed;
  try {
    const { masterKey } = await chrome.storage.session.get('masterKey');
    if (!masterKey) throw new Error('Session expired');
    
    seed = await decryptSeed(masterKey);
    const sig = await trustWallet.sign(seed, txData);
    return sig;
  } catch (error) {
    // Clear session on any error (could be tampered key)
    await chrome.storage.session.clear();
    throw error;
  } finally {
    if (seed) {
      crypto.getRandomValues(seed);
      seed.fill(0);
    }
  }
}

4. Validate session token on every operation:

Session tokens prevent an interesting attack where someone manually writes to chrome.storage.session (using DevTools or malicious code) to try to hijack a session. Generate a token on unlock and verify it on every operation:

// Generate token on unlock (in the doUnlock function):
const sessionToken = crypto.randomUUID();
await chrome.storage.session.set({ 
  masterKey: Array.from(masterKey),
  sessionToken,
  sessionStart: Date.now(),
  lastActivity: Date.now()
});

// Verify on every operation:
async function verifySession() {
  const session = await chrome.storage.session.get([
    'masterKey', 
    'sessionToken',
    'sessionStart'
  ]);
  
  if (!session.masterKey || !session.sessionToken) {
    throw new Error('No active session');
  }
  
  // Optional: Check session age (add max session length)
  const sessionAge = Date.now() - session.sessionStart;
  const MAX_SESSION_LENGTH = 24 * 60 * 60 * 1000; // 24 hours
  
  if (sessionAge > MAX_SESSION_LENGTH) {
    await chrome.storage.session.clear();
    throw new Error('Session expired (max age exceeded)');
  }
  
  return session;
}

// Use in signing operations:
async function signTransaction(txData) {
  const session = await verifySession(); // Throws if invalid
  
  // ... rest of signing logic using session.masterKey
}

This prevents attacks where:

1. Attacker writes a fake masterKey to chrome.storage.session without a sessionToken
2. Attacker reuses an old session after it should have expired
3. Attacker tries to maintain a session beyond the maximum allowed time

5. Monitor for tampering (defense in depth):

Add listeners to detect suspicious modifications to your storage:

chrome.storage.onChanged.addListener((changes, areaName) => {
  if (areaName === 'session') {
    // Log all session storage changes for debugging
    console.log('Session storage changed:', Object.keys(changes));
    
    // Detect suspicious patterns
    if (changes.masterKey && !changes.sessionToken) {
      // Someone modified the master key but not the session token
      // This is suspicious - could be an attack
      console.error('Suspicious session modification detected');
      chrome.storage.session.clear();
    }
    
    if (changes.sessionToken && !changes.masterKey) {
      // Someone changed the token but not the key
      // Also suspicious
      console.error('Suspicious token modification detected');
      chrome.storage.session.clear();
    }
  }
  
  if (areaName === 'local') {
    // Monitor vault modifications
    if (changes.vault) {
      console.warn('Vault was modified - this should only happen during setup');
      // You might want to notify the user if vault changes unexpectedly
    }
  }
});

This won't stop a determined attacker, but it adds another layer and helps catch bugs during development where you're accidentally modifying storage in unexpected ways.

What You Definitely Need

1. CSP with explicit domain whitelist - this is your main defense against supply chain attacks
2. chrome.storage.local timestamp backup for alarms
3. Rate limiting on unlock attempts
4. Explicit minimum_chrome_version: "112" in manifest
5. Session token validation to detect tampering

What's Optional But Recommended

1. Service worker keep-alive (chrome.alarms pattern)
2. Memory zeroing (doesn't hurt, might help)
3. Sentry/error monitoring (but don't log sensitive data)

Final Thoughts

After digging through all this, here's my take:

Your original architecture using chrome.storage.session is solid. The concerns I raised in my first review about disk persistence and storage isolation are real, but they're manageable risks. The real security comes from:

1. CSP preventing exfiltration - Even if malicious code runs, it can't send data out
2. Encryption at rest - The vault is always encrypted with PBKDF2-derived keys
3. Time-bound sessions - 15 minute timeout limits exposure window
4. Good dependency hygiene - Audit deps, use exact versions, run npm audit

MetaMask uses in-memory only (more secure) but forces users to unlock every 30 seconds when the service worker dies (worse UX). Rabby uses chrome.storage.session (your approach) and has had no incidents in 4+ years with millions of users (good UX, still secure enough).

The middle ground exists - you can use chrome.storage.session with proper CSP, activity tracking, and session management. That's what I'd recommend.

Don't skip:

• CSP with explicit domain whitelist
• chrome.storage.local timestamp backup for alarm reliability
• Rate limiting on unlock attempts
• minimum_chrome_version: "112" in manifest
• Session token validation

Optional but nice to have:

• Service worker keep-alive via chrome.alarms (better UX)
• Memory zeroing for seeds after signing (doesn't hurt)
• Tampering detection via storage.onChanged
• Error monitoring (Sentry or similar, but don't log keys!)

Ship it. The architecture is sound.

References

[1] How MetaMask stores secrets: https://www.wispwisp.com/index.php/2020/12/25/how-metamask-stores-your-wallet-secret/
[2] MetaMask KeyringController: https://github.com/MetaMask/KeyringController
[3] Rabby Wallet GitHub: https://github.com/RabbyHub/Rabby
[4] Rabby source code: https://github.com/RabbyHub/Rabby/tree/develop/src
[5] Rainbow browser extension security: https://github.com/rainbow-me/browser-extension#security
[6] Rainbow browser extension repo: https://github.com/rainbow-me/browser-extension
[7] LavaMoat security: https://github.com/LavaMoat/LavaMoat
[8] Chrome storage API docs: https://developer.chrome.com/docs/extensions/reference/api/storage
[9] Chrome extension storage in incognito (various Chrome DevRel posts)
[10] Service worker lifecycle: https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle
[11] Chromium extensions discussion on persistent workers: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Rl5LQwB5YoI
[12] Chrome CSP documentation: https://developer.chrome.com/docs/extensions/develop/concepts/content-security-policy
[13] OWASP Browser Extension Security: https://cheatsheetseries.owasp.org/cheatsheets/Browser_Extension_Vulnerabilities_Cheat_Sheet.html
[14] browser-passworder library: https://github.com/MetaMask/browser-passworder

[JulesFiliot]

@0xM3R thank you for you response and research. We will then proceed with the implementation of the architecture.

• LavaMoat at build time to protect against supply chain attacks during the build process [7]
  [...]
  [7] https://github.com/LavaMoat/LavaMoat

This looks interesting and useful to implement, we will look at it.