Because of this restriction, I need to store the data locally using something like chrome.storage or IndexedDB. However, storing the data in plain text is not acceptable from a security perspective.

My current approach is to encrypt the data before storing it locally and decrypt it when needed.

For encryption I am using the Web Crypto API with AES-GCM, and deriving the key from a user password using PBKDF2.

Here is a simplified version of the encryption logic I am currently using:

Copyconst ALGO = 'AES-GCM';
const KEY_LENGTH = 256;
const IV_LENGTH = 12;

export async function deriveKey(password, salt) {
  const enc = new TextEncoder();

  const keyMaterial = await crypto.subtle.importKey(
    'raw',
    enc.encode(password),
    'PBKDF2',
    false,
    ['deriveKey']
  );

  return crypto.subtle.deriveKey(
    {
      name: 'PBKDF2',
      salt,
      iterations: 100000,
      hash: 'SHA-256'
    },
    keyMaterial,
    {
      name: ALGO,
      length: KEY_LENGTH
    },
    false,
    ['encrypt', 'decrypt']
  );
}

export async function encryptData(data, masterPassword) {
  const enc = new TextEncoder();
  const iv = crypto.getRandomValues(new Uint8Array(IV_LENGTH));
  const salt = crypto.getRandomValues(new Uint8Array(16));

  const key = await deriveKey(masterPassword, salt);

  const encryptedBuffer = await crypto.subtle.encrypt(
    { name: ALGO, iv },
    key,
    enc.encode(JSON.stringify(data))
  );

  return {
    cipher: bufferToBase64(encryptedBuffer),
    iv: bufferToBase64(iv),
    salt: bufferToBase64(salt)
  };
}

export async function decryptData(encryptedPayload, masterPassword) {
  const { cipher, iv, salt } = encryptedPayload;

  const key = await deriveKey(masterPassword, base64ToBuffer(salt));

  const decryptedBuffer = await crypto.subtle.decrypt(
    { name: ALGO, iv: base64ToBuffer(iv) },
    key,
    base64ToBuffer(cipher)
  );

  const dec = new TextDecoder();
  return JSON.parse(dec.decode(decryptedBuffer));
}

function bufferToBase64(buffer) {
  return btoa(String.fromCharCode(...new Uint8Array(buffer)));
}

function base64ToBuffer(base64) {
  return Uint8Array.from(atob(base64), c => c.charCodeAt(0));
}

Example usage:

Copyconst password = '1234';
const encrypted = await encryptData(plainTab, password);

My main concern is key management.

Since this is a browser extension without a backend, I cannot store a secret key on a server. At the same time, if a key is hardcoded or stored directly in the extension code, it can be extracted by inspecting the extension.

So my questions are:

1. What is the recommended approach for encrypting sensitive data locally in a Chrome extension?

2. How should the encryption key be generated and managed securely if everything runs on the client side?

3. Is deriving the key from a user-provided master password (using PBKDF2 or similar) considered a good practice in this scenario?

4. Are there established patterns used by password managers or other privacy-focused extensions for this problem?

I am trying to design something similar to how password managers encrypt vault data locally before storing it.

Environment:

• Chrome Extension (Manifest V3)

• JavaScript

• Web Crypto API

• Storage via chrome.storage or IndexedDB

Have you solved a similar problem in a Chrome extension or another client-only application?
If you have any ideas, better approaches, or security recommendations, please leave a reply or reach out to me via email codeguyakash[at]gmail[dot]com. I’d love to learn from your experience.

Node.js has built a reputation for its speed and efficiency in handling web requests. However, if you’ve worked with Node.js you know that its core execution operates on a single thread. This means it generally handles one task at a time. So, what happens when you have tasks that take a lot of time to compute, like image processing or complex math? That’s where the ‘worker threads’ module comes to the rescue.

Understanding Single-Threaded Node.js

• The Event Loop: Node.js uses the famous event loop, a super-efficient manager. Think of it like a tireless receptionist. The event loop constantly checks if any tasks are waiting. If there are, it grabs one and starts processing it.

• Non-Blocking I/O: When Node.js needs to do things that take time (like reading a file or making a network call), it cleverly offloads these tasks to the operating system. Then, it moves on to other tasks. When the operating system finishes, it sends a message back to the event loop saying, “Hey, I’m done!” The event loop then picks up the completed task.

This approach is excellent for most web applications, but what if you need raw processing power?

Enter Worker Threads

Worker threads allow you to create additional threads of execution within your Node.js process. It’s like adding extra workers to your team! These threads can handle CPU-heavy tasks in parallel with your main Node.js thread.

Key Advantages of Worker Threads

1. Improved Performance: Break up long calculations or data manipulation into smaller jobs that can run simultaneously.

2. Offloading Intensive Tasks: Don’t let heavy processing clog up your main thread’s ability to respond to web requests. Shift the workload to worker threads.

3. Shared Memory: Worker threads can share data with the main thread for fast and easy communication.

Example: Let’s Calculate Some Primes

Let’s say we want to find a bunch of prime numbers:

JavaScript

// main.js
const { Worker } = require('worker_threads');

function findPrimes(start, range) {
  let primes = [];
  for (let i = start; i < start + range; i++) {
    if (isPrime(i)) primes.push(i); 
  }
  return primes;
}
const worker = new Worker('./worker.js');

worker.on('message', (result) => {
  console.log(result); 
});

worker.postMessage({ start: 1000000, range: 2000000 });

JavaScript

// worker.js
const { parentPort, workerData } = require('worker_threads');
const primes = findPrimes(workerData.start, workerData.range);
parentPort.postMessage(primes);

Explanation

• main.js: Creates a worker thread, sends it a task to find prime numbers, and waits for results.

• worker.js: Calculates prime numbers, and sends them back to the main thread.

Notice we don’t use typical Node.js modules like http or fs inside a worker thread, but they're fantastic for heavy calculations!

When Should You Use Worker Threads?

• CPU-Intensive Tasks: Think complex math, data analysis, compression, or image/video processing.

• Avoiding Main Thread Blocking: Keep your main thread free to handle incoming web requests.

Let me know if you’d like more advanced use cases or deeper explanations. I’m happy to tailor the article further for your blog!