الـ Privacy والـ Data Retention: consent و export و erasure و crypto shredding

أهلًا بيك. النهارده الـ privacy. موضوع ناس كتير بتفتكره مسؤولية المحامين، وهو في الحقيقة مسؤولية الـ backend. بص على users dot naive dot js. middleware بيكتب كل request في الـ log، و route للـ analytics events، و route بيحفّظ الرقم القومي، و route لمسح الـ user. الـ log بيكتب الـ body كله: الـ passwords والـ emails والأرقام القومية في ملفات بتتنسخ في كل حتة، ومحدش بيمسحها. الـ events بتتسجل لكل الناس من غير موافقة، والـ IP كامل، ومفيش أي حاجة بتتمسح أبدًا. الرقم القومي متخزّن plaintext، فأي حد معاه backup أو read replica شايفه. المسح: delete عادي بيقع لأن الـ user عنده orders. والـ cascade كان هيمسح الفواتير، والقانون بيقولك خلّيها سنين. والـ backups والـ events لسه فيها كل حاجة. ومفيش export: الـ user من حقه يعرف إحنا عارفين عنه إيه.

ليه ده شغلك؟ فيه قوانين: الـ GDPR في أوروبا، وبيطبّق على أي حد بيخدم users أوروبيين حتى لو الـ company في مصر. وفي مصر قانون حماية البيانات الشخصية رقم مِيّة واحد وخمسين لسنة ألفين وعشرين. وفي أمريكا الـ CCPA. والغرامات ممكن توصل نسبة من الـ revenue. بس الأهم: كل data متخزّنة هي خطر. أي leak، اللي اتسرق هو اللي كان عندك. فالـ data اللي ما خزّنتهاش ما تتسرقش. الحقوق اللي هتشوفها في كل القوانين دي تقريبًا: حق إنك تعرف، وحق إنك تاخد نسخة، وحق إنك تصحّح، وحق إنك تتمسح، وحق إنك ترفض الـ marketing والـ tracking.

أول خطوة: تعرف عندك إيه. ده اسمه data map. لكل table ولكل column: ده PII ولا لأ؟ حساس ولا عادي؟ ليه بنجمعه، يعني الـ purpose؟ بنخلّيه قد إيه؟ مين يقدر يشوفه؟ وبيتنسخ فين، زي الـ replicas والـ warehouse والـ logs والـ third parties؟ PII يعني أي حاجة توصل للشخص: الاسم والـ email والتليفون والعنوان والـ IP والـ device id. والحساس: الرقم القومي، والصحة، والدين، والـ location الدقيق، والـ biometrics. ده بيحتاج حماية أكتر، زي التشفير على مستوى الـ field. والـ data map مش document بيتكتب مرة. اعمله في الـ code: comment أو tag على كل column، و check في الـ CI بيرفض أي migration بتضيف column من غير تصنيف.

الـ data minimization: ما تجمعش حاجة مش محتاجها. محتاج تعرف إن الـ user فوق تمنتاشر؟ خزّن verified بـ true، مش تاريخ الميلاد. محتاج المدينة للشحن؟ ما تخزّنش الـ GPS. والـ IP في الـ analytics، شيل آخر جزء منه، أو ما تخزّنهوش خالص. والـ consent: لكل purpose لوحده. analytics حاجة، و marketing حاجة، و personalization حاجة. والـ default لا. مش checkbox متعلّم من الأول. وخزّن إمتى وافق، وعلى أنهي نسخة من الـ policy، عشان يبقى معاك دليل. ولو سحب الموافقة، الـ tracking يقف على طول. وفيه حاجات مش محتاجة consent، زي إنك تخزّن العنوان عشان تشحن الـ order، لأنها لازمة للخدمة نفسها. ده اسمه legal basis، وكل purpose ليه واحد. الحساس يتشفّر. الـ disk encryption بتاع الـ cloud بيحميك لو حد سرق الـ hard disk بس. أي حد عنده access للـ database، أو لـ backup، أو لـ replica، بيشوف كل حاجة. فالحاجات الحساسة، زي الرقم القومي، تتشفّر في الـ app قبل ما تنزل الـ database، بـ AES-GCM. والأحسن: key لكل user. وده بيدّيك حاجة مهمة قوي هنشوفها كمان شوية في المسح. وفي الـ production، الـ keys دي ما تتخزّنش plaintext في نفس الـ database. بتتشفّر هي كمان بـ master key في KMS، وده اسمه envelope encryption. النهارده هنخزّنها في table عشان نركّز على الفكرة.

حق الـ access. الـ user يقولك ابعتلي كل حاجة عندكم عني. والقانون بيدّيك وقت محدّد، في الـ GDPR شهر. الصح: function واحدة اسمها export، بتلف على كل table في الـ data map، وتطلّع JSON واحد: الـ profile، والـ orders، والـ consents، والـ events، وبتفك تشفير الحساس. وبتشتغل كـ background job، لأنها ممكن تبقى تقيلة، والنتيجة تتبعت كـ link بـ expiry قصير، بعد ما تتأكد من هوية اللي طالب. وأي table جديدة فيها PII لازم تدخل في الـ export. ده تاني سبب للـ data map في الـ code.

حق المسح، وده أصعب حاجة. مش delete. الـ user مربوط بـ orders و payments و audit logs. والقانون بيقولك خلّي الفواتير خمس سنين أو أكتر للضرايب. فالحق في المسح ليه حدود: أي حاجة القانون مجبرك تخلّيها. فالخطوات: أول ما يطلب، soft delete. الـ account يقف على طول، والـ sessions تتمسح، والـ consents تبقى لا. وبعدين فترة سماح، زي تلاتين يوم. ناس كتير بتطلب المسح وهي متضايقة وبترجع. وكمان بتحميك لو حد سرق الـ account وعمل request للمسح. وبعد فترة السماح، job بيعمل الـ erasure الحقيقي. الـ erasure الحقيقي بيعمل إيه؟ الـ user row بيفضل، عشان الـ foreign keys، بس الـ email يبقى حاجة زي erased و الـ id و at invalid، والاسم والتليفون null. ده اسمه anonymization. الـ orders بتفضل، بالمبلغ والتاريخ، عشان الضرايب والتقارير. بس العنوان يتمسح. الـ events: الـ user id والـ IP يبقوا null، فالأرقام في الـ dashboards ما تتغيّرش، بس محدش يعرف مين. والـ consents والـ sessions تتمسح. وفيه حالة مهمة: الـ legal hold. لو فيه قضية أو تحقيق، الـ lawyers بيقولولك ما تمسحش أي حاجة تخص الـ user ده. فالـ job بيشوف الـ flag ده، والـ request يبقى held، والـ data تفضل لحد ما الـ hold يتشال.

طب والـ backups؟ عندك backups كل يوم بقالها تلاتين يوم، و snapshots، وكلها فيها الـ data القديمة. ما تقدرش تفتح كل backup وتعدّل فيه. الحل اسمه crypto shredding. فاكر الـ key لكل user؟ في الـ erasure، بتمسح الـ key ده. الـ data المتشفّرة في الـ backups لسه موجودة، بس من غير key مالهاش أي معنى، random bytes. وده بيشتغل كمان مع أي حتة تانية البيانات اتنسخت فيها وأنت مش قادر توصلها، زي الـ data warehouse أو الـ event streams. بس خلي بالك: ده بيحمي الحاجات المتشفّرة بس. الـ email في الـ backup لسه plaintext، فالـ backups لازم يبقى ليها retention هي كمان، وأي restore لازم يعيد تشغيل الـ erasure requests اللي حصلت بعد الـ backup.

الـ retention. لكل نوع data مدة. الـ sessions تلاتين يوم، والـ events الخام تسعين يوم، والـ logs أسبوعين، والـ orders خمس سنين وبعدين anonymize. والمدة دي تشتغل بـ job، مش بـ نيّة حلوة. والـ job ما يعملش delete لمليون row مرة واحدة. ده بيمسك locks كتير، ويكبّر الـ WAL، ويبطّأ الـ replicas. الصح batches، ألف row في كل مرة، و transaction صغيرة. ولو الـ table ضخمة قوي وكل الـ data بتتمسح بالتاريخ، استخدم partitioning بالشهر، والـ retention يبقى drop partition، وده تقريبًا ببلاش. والـ logs: الـ log system نفسه ليه retention، اضبطه، ما تسيبوش الـ default. الـ pseudonymization. الـ analytics team عايزة تعرف نفس الـ user عمل إيه على مدار أسبوع، من غير ما تعرف هو مين. بدل الـ user id، ابعتلهم HMAC للـ id بـ secret. نفس الـ user، نفس القيمة، فيقدروا يعملوا joins. ومن غير الـ secret ما يقدروش يرجعوا للـ id. وده مختلف عن الـ anonymization: الـ pseudonymous data لسه بتعتبر PII في الـ GDPR، لأن اللي معاه الـ secret يقدر يرجع. بس الخطر أقل بكتير. ولو غيّرت الـ secret، الـ pseudonyms كلها بتتغيّر، ودي طريقة تقطع الربط القديم.

الـ logs. أكتر مكان الـ PII بتتسرّب فيه، لأنها بتتكتب من غير تفكير، وبتتبعت لـ third party، وبيشوفها كل الـ engineers. ما تكتبش الـ body كله أبدًا. اعمل redaction في الـ logger نفسه، مش في كل مكان: أي field اسمه password أو token أو email أو card يبقى REDACTED. و pino عنده option اسمه redact لده بالضبط. والـ strings الحرة، زي error messages فيها email، تتعمل بـ regex كمان. ومش هتمسك كل حاجة، فالأساس إنك ما تحطش PII في الـ messages من الأول. وآخر حاجة: الـ data residency. بعض القوانين بتقول data المواطنين لازم تفضل في البلد، أو ما تطلعش برّه منطقة معيّنة من غير شروط. ده بيفرق في أنهي region تختاره، وأنهي third parties تبعتلهم. التحدي. عندك lab dot js بيحكي قصة مُنى، اللي عايزة تعرف إحنا عارفين عنها إيه وبعدين تتمسح، و test dot js. والمطلوب privacy dot js. كل التفاصيل في الكومنت: migrate بتمان tables، والـ consent، والتشفير بـ key لكل user، و exportUserData، و requestErasure و cancelErasure، و processErasures بالـ anonymization والـ crypto shredding والـ legal hold و skip locked، و applyRetention بالـ batches، و pseudonym، و redact. اقرا الكومنت كويس، ونشغّل test dot js لحد ما تبقى أربعتاشر من أربعتاشر.

الحل. كل الـ timestamps جاية من now، فالـ tests تقدر تقدّم الساعة تلاتين يوم في سطر واحد. requestErasure: الـ on conflict بيعمل update بس لو الـ request القديم cancelled، فالضغطة التانية ما بتأخّرش الـ due. processErasures: request واحد في كل transaction، بـ skip locked، فلو وقع في النص، اللي خلص خلص، والباقي يكمّل المرة الجاية. والـ anonymize والـ key والـ orders والـ events كلهم في نفس الـ transaction. والـ retention: delete where id in select limit، لحد ما الـ rowCount يبقى صفر. نشغّل lab dot js.

// privacy.js: الـ consent، والـ export، والـ erasure بفترة سماح و legal hold و crypto shredding، والـ retention بالـ batches، والـ redaction
// lab.js و test.js بيعملوا import من هنا: PrivacyError و migrate و createPrivacy و redact
import { randomBytes, createCipheriv, createDecipheriv, createHmac } from "node:crypto";

export class PrivacyError extends Error {
  constructor(code, extra = {}) {
    super(code);
    this.code = code;
    Object.assign(this, extra);
  }
}

export async function migrate(db) {
  await db.query(`
    create table if not exists users (
      id serial primary key, email text unique not null, name text, phone text,
      legal_hold boolean not null default false, created_at timestamptz not null default now(),
      deleted_at timestamptz, erased_at timestamptz);
    create table if not exists user_keys (user_id int primary key references users, key bytea not null);
    create table if not exists profiles (user_id int primary key references users, national_id_enc bytea);
    create table if not exists orders (
      id serial primary key, user_id int references users, total_cents int not null,
      shipping_address text, created_at timestamptz not null default now());
    create table if not exists sessions (id serial primary key, user_id int not null references users, created_at timestamptz not null default now());
    create table if not exists consents (
      user_id int not null references users, purpose text not null, granted boolean not null,
      updated_at timestamptz not null, primary key (user_id, purpose));
    create table if not exists events (id serial primary key, user_id int references users, kind text not null, ip text, created_at timestamptz not null default now());
    create table if not exists erasure_requests (
      user_id int primary key references users, requested_at timestamptz not null, due_at timestamptz not null,
      status text not null, done_at timestamptz);
  `);
}

const DAY = 86400000;

export function createPrivacy({ pool, now = () => new Date(), graceDays = 30, pseudonymSecret }) {
  async function tx(fn) {
    const c = await pool.connect();
    try {
      await c.query("begin");
      const r = await fn(c);
      await c.query("commit");
      return r;
    } catch (e) {
      await c.query("rollback");
      throw e;
    } finally {
      c.release();
    }
  }

  async function liveUser(db, userId, lock = false) {
    const { rows } = await db.query(`select * from users where id = $1${lock ? " for update" : ""}`, [userId]);
    if (!rows[0]) throw new PrivacyError("NOT_FOUND");
    if (rows[0].erased_at) throw new PrivacyError("ERASED");
    return rows[0];
  }

  async function setConsent(userId, purpose, granted) {
    await liveUser(pool, userId);
    await pool.query(
      `insert into consents (user_id, purpose, granted, updated_at) values ($1, $2, $3, $4)
       on conflict (user_id, purpose) do update set granted = excluded.granted, updated_at = excluded.updated_at`
…

$ node lab.js
① الـ consent:
   event من غير موافقة اتسجل؟ false
   بعد الموافقة؟ true

② الرقم القومي متشفّر بـ key خاص بمنى:
   في الـ database: ff1501705ee9673b64b098a428814f07f05209e5… | مقري: 29801011234567

③ منى طلبت الـ data بتاعتها (export):
   {"user":"[email protected]","nationalId":"29801011234567","orders":1,"consents":{"analytics":true},"events":1}

④ منى طلبت تتمسح:
   status: pending | due: 2026-03-31T09:00:00.000Z | sessions: 0
   بعد عشر أيام processErasures: {"erased":[],"held":[]}
   بعد واحد وتلاتين يوم: {"erased":[1],"held":[]}
   الـ user: {"email":"erased-1@invalid","name":null,"phone":null}
   الـ order: {"total_cents":19950,"shipping_address":null}
   نسخة الرقم القومي اللي في الـ backup ← KEY_SHREDDED

⑤ كريم عليه legal hold:
   {"erased":[],"held":[2]} | email لسه: [email protected]

⑥ الـ retention والـ logs:
   {"sessions":2500,"events":0,"orders":0,"batches":3}
   pseudonym لكريم: 8171b73842e32608
   {"path":"/login","body":{"email":"[REDACTED]","password":"[REDACTED]"},"note":"card [CARD]"}

الأول: الـ event من غير موافقة ما اتسجلش، وبعد الموافقة اتسجل. التاني: الرقم القومي في الـ database bytes مش مفهومة. التالت: الـ export طلّع كل حاجة. الرابع: الـ sessions اتمسحت على طول، وبعد عشر أيام الـ job ما عملش حاجة، وبعد واحد وتلاتين يوم مُنى اتمسحت. الـ order فاضل بالمبلغ من غير العنوان، والنسخة اللي في الـ backup بقت KEY_SHREDDED. الخامس: كريم عليه legal hold، فالـ request بقى held. والسادس: ألفين وخمسمية session اتمسحوا في تلات batches، والـ password والـ email والـ card number اختفوا من الـ log. ونشغّل test dot js.

$ node test.js
✅ 1 migrate مرتين، والتمان tables موجودة ["consents","erasure_requests","events","orders","profiles","sessions","user_keys","users"]
✅ 2 الـ consent: الـ default لا، والـ event ما يتسجلش من غيره {"before":[false,false],"after":[true,true,false],"ev2":[{"n":1}]}
✅ 3 الرقم القومي متشفّر في الـ database ومقري صح 42
✅ 4 exportUserData: كل حاجة عن الـ user في JSON واحد {"user":{"id":1,"email":"[email protected]","name":"Mona","phone":"+201111111111","createdAt":"2026-01-01T10:00:00.000Z"},"nationalId":"29801011234567","orders":
✅ 5 requestErasure: soft delete على طول، والـ sessions اتمسحت، و due بعد تلاتين يوم، ومرة تانية نفس الـ due {"r5":{"userId":1,"status":"pending","dueAt":"2026-01-31T10:00:00.000Z"},"r5b":{"userId":1,"status":"pending","dueAt":"2026-01-31T10:00:00.000Z"}}
✅ 6 cancelErasure جوّه فترة السماح بيرجّع الـ user، والمرة التانية NOT_CANCELLABLE {"c6":{"userId":2,"status":"cancelled"},"again":"NOT_CANCELLABLE","none":"NOT_CANCELLABLE"}
✅ 7 processErasures: قبل الـ due مفيش حاجة، وبعده الـ user اتمسح {"early":{"erased":[],"held":[]},"late":{"erased":[1],"held":[]}}
✅ 8 بعد الـ erasure: الـ PII راحت، والـ orders فاضلة للضرايب من غير عنوان، والـ events من غير us
…

كله نجح. كل قرار عملناه النهارده، تلاتين يوم سماح، وخمس سنين للـ orders، و key لكل user، محتاج يتكتب في حتة، عشان اللي ييجي بعدك يعرف ليه. الدرس الجاي: الـ ADRs والـ feature flags. إزاي تكتب القرارات، وإزاي تنزّل feature لخمسة في المِيّة من الـ users وترجع فيها على طول.

// users.naive.js: كل حاجة متخزّنة للأبد، والمسح يا بيكسر يا بيمسح الغلط
import express from "express";
import pg from "pg";
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });
const app = express();
app.use(express.json());

app.use((req, res, next) => {
  console.log(new Date().toISOString(), req.method, req.url, JSON.stringify(req.body)); // الـ passwords والـ emails في الـ logs
  next();
});

app.post("/events", async (req, res) => {
  // analytics لكل الناس، من غير consent، والـ IP كامل، وما بيتمسحش أبدًا
  await pool.query("insert into events (user_id, kind, ip) values ($1, $2, $3)", [req.body.userId, req.body.kind, req.ip]);
  res.sendStatus(204);
});

app.post("/users/:id/national-id", async (req, res) => {
  await pool.query("update users set national_id = $2 where id = $1", [req.params.id, req.body.nationalId]); // plaintext
  res.sendStatus(204);
});

app.delete("/users/:id", async (req, res) => {
  try {
    await pool.query("delete from users where id = $1", [req.params.id]); // foreign key error لو عنده orders
  } catch {
    await pool.query("delete from users where id = $1 cascade", [req.params.id]); // مش SQL أصلًا، ولو اشتغلت هتمسح فواتير لازم تتحفظ
  }
  res.sendStatus(204); // والـ backups والـ events والـ logs لسه فيها كل حاجة
});

// export؟ مفيش. الـ user يبعت email، وحد يعمل queries بإيده بعد شهر
app.listen(3000);