Privacy Statnive Live · Parhum Khoshbakht

DSAR بدون درامة: حق الوصول والمحو في أداة القياس

المادتان 15 و17 لا تتوقفان لأجل التحليلات. هذه هي طريقة هندسة نقاط نهاية حق الوصول والمحو دون كسر التجميعات — وما الذي شحنّاه.

هذا بحث في الخصوصية وليس استشارة قانونية. راجعوا التذييل للاطلاع على إخلاء المسؤولية الكامل.

الخلاصة

  • المادتان 15 و17 تنطبقان على تحليلات الويب — المعرّفات المستعارة مثل عناوين IP المُجزّأة ومعرّفات Cookies وتوقيعات الزوار BLAKE3-HMAC تبقى بيانات شخصية وفق خط Breyer وIAB Europe وحكم محكمة الاستئناف في بروكسل بتاريخ 14 مايو 2025.
  • ثلاث نقاط نهاية تم شحنها — POST /api/privacy/opt-out و GET /api/privacy/access و POST /api/privacy/erase — جميعها محمية من CSRF ومحدودة المعدل وموثقة في سجل التدقيق.
  • جداول التجميع تبقى بعد المحو لأنها جُمّعت بالفعل إلى ما بعد نقطة قابلية التعرف — مخططات HyperLogLog uniqCombined64 هي أعداد، وليست سجلات، ولا يمكن عكس مساهمة فرد بعينه.
  • 8 أحداث تدقيق للخصوصية تُصدر دليل المساءلة المنظّم وفق المادة 28(3)(h) — يغطي إلغاء الاشتراك والوصول والمحو ومنح الموافقة وسحبها وعرض الصفحات القانونية.
  • تركيز إنفاذ EDPB لعام 2025 كان حق المحو ضمن الإطار المنسّق؛ وتركيز EDPB لعام 2026 ينتقل إلى التزامات الشفافية. كلاهما يتوافق مع البنية الموضحة في هذا المنشور.

لماذا تحليلات الويب هي السطح الأكثر نسياناً لـ DSAR

معظم تدفقات طلبات الوصول إلى البيانات الشخصية وفق GDPR مبنية حول الأنظمة التي توجد فيها البيانات الشخصية بشكل واضح — CRM، تذاكر مكتب المساعدة، تاريخ الطلبات، قوائم التسويق عبر البريد الإلكتروني. مكدّس تحليلات الويب يكون عادةً فكرةً لاحقة، وعندما يُذكر، فإن أول حدس للمشغّل غالباً ما يكون «لا توجد بيانات شخصية هناك، فقد جزّأنا عناوين IP». هذا الحدس خاطئ قانونياً وبشكل متزايد خاطئ معمارياً.

مسودة إرشادات EDPB رقم 01/2025 بشأن الترميز المستعار — التي اعتُمدت كمسودة في الجلسة العامة 101 بتاريخ 16 يناير 2025، والمفتوحة للتشاور العام حتى 28 فبراير 2025، والتي لا تزال قيد التطوير حتى مايو 2026 — توضح أن البيانات المُرمَّزة بشكل مستعار، بما في ذلك عناوين IP المُجزّأة ومعرّفات Cookies وتوقيعات زوار BLAKE3/HMAC وسلاسل TC، تبقى بيانات شخصية عندما تكون إعادة التعرف محتملة بشكل معقول عبر وسائل متاحة للمسؤول عن المعالجة أو أي طرف ثالث. حكم محكمة العدل الأوروبية في قضية IAB Europe (C-604/22، 7 مارس 2024)، الذي أكّده حكم محكمة الاستئناف في بروكسل بتاريخ 14 مايو 2025 (القضية 2022/AR/292)، يمتد إلى ما هو أبعد من سلاسل TC ليشمل أي معرّف مقترن بعنوان IP. Breyer (C-582/14، 19 أكتوبر 2016) حسم مسألة عنوان IP بالنسبة للمشغّل قبل ذلك بكثير.

عملياً، هذا يعني: تحليلات الويب التي تعالج عناوين IP أو Cookies المُجزّأة أو توقيعات زوار BLAKE3-HMAC أو أي معرّف لكل زائر هي معالجة بيانات شخصية ضمن مفهوم GDPR. تنطبق المادتان 15 (حق الوصول) و17 (حق المحو). تقتضي المادة 28(3)(e) من المعالج — إن وُجد — مساعدة المسؤول عن المعالجة في هذه الطلبات. وتشمل ساعة الإخطار بالاختراق وفق المادة 33 الاختراقات التي تؤثر على هذه المعرّفات.

ما يلي هو دليل المشغّل العملي. تشريح DSAR التحليلات، ونقاط النهاية الثلاث التي يشحنها Statnive Live، ومسار التدقيق المطلوب، وكيف تبقى التجميعات بعد المحو، ودليل DSAR ودود للمطوّر، وعينة كود عاملة.

تشريح DSAR للتحليلات

طلب DSAR ضد مكدّس تحليلات الويب لا يشبه طلب DSAR ضد CRM. لا يوجد عنوان بريد إلكتروني، ولا اسم عميل، ولا مفتاح أساسي واضح. صاحب البيانات يتواصل ويقول، في جوهر الأمر: «أزور موقعكم أحياناً. ماذا لديكم عني، ويرجى حذفه.»

ما الذي يمتلكه المشغّل فعلاً؟

بالنسبة لمكدّس تحليلات الطرف الأول بدون Cookies مثل Statnive Live في وضع consent-free، الإجابة هي: توقيع مستعار محدود باليوم مشتق من عنوان IP الزائر و User-Agent ونطاق الموقع وملح يدور يومياً يُتلف في نهاية اليوم. البنية موصوفة بالتفصيل في دليل تحليلات الاتحاد الأوروبي بدون موافقة لعام 2026. توقيع اليوم يوجد في جدول الأحداث الخام حتى يتم تدوير الملح في الساعة 00:00 UTC التالية؛ وبعد التدوير، يصبح التوقيع غير قابل للعكس فعلياً لأن الملح الذي أنتجه قد اختفى. التجميعات تُجمّع ذلك التوقيع إلى أعداد قبل تدوير الملح، لذا فإن معرّف كل زائر ليس موجوداً في جداول التجميع على الإطلاق — فقط أعداد الزوار الفريدين لكل يوم أو صفحة أو مصدر.

بالنسبة لنشر consent-required أو hybrid من Statnive Live مع منح الموافقة، يُصدَر إضافةً إلى ذلك معرّف Cookie إلى المتصفح (UUID خام). يُخزّن الخادم SHA-256(master_secret || site_id || cookieID) ببادئة h: كمفتاح الاستمرار. استمرارية الزائر عبر الأيام تُحفظ بمعرّف Cookie المُجزّأ بدلاً من الملح اليومي الدوّار.

ثلاثة أمور تتبع من هذا:

  • وصول المادة 15. يمكن لصاحب البيانات أن يعطي المشغّل شيئاً للبحث عنه — عادةً معرّف Cookie من متصفحه (إن كان موجوداً في جلسته الحالية) أو وصفاً لزيارته (التاريخ، الصفحة، الوقت التقريبي، IP من شبكة معروفة). يمكن للمشغّل إرجاع الأحداث المطابقة.
  • محو المادة 17. يمكن للمشغّل تحديد موقع نفس الأحداث وحذفها. السجلات التي يستطيع المشغّل التعرف عليها هي السجلات التي يستطيع المشغّل محوها.
  • ما لا يمكن التعرف عليه لا يمكن محوه — ولا يمكن الاحتفاظ به أيضاً. إتلاف الملح اليومي في الساعة 00:00 UTC هو محو متزامن وتلقائي لقدرة إعادة التعرف عبر الأيام. توقيع جلسة اليوم 1 للزائر يصبح غير مرتبط بشكل دائم بتوقيع جلسة اليوم 2 بمجرد إتلاف ملح اليوم 1؛ طلب المادة 17 الذي يصل إلى المشغّل في اليوم 2 لا يستطيع المطالبة بحذف سجلات اليوم 1 لأنه لا يمكن تحديد موقعها، لكن هذا أيضاً مقبول لأنها لم تعد قابلة لإعادة التعرف.

البنية مصمَّمة بحيث يكون احتفاظ الحالة المستقرة بالبيانات القابلة للتعرف صغيراً. تدوير الملح يقوم بمعظم عمل المادة 5(1)(c) من GDPR لتقليل البيانات مجاناً. طلبات DSAR ضد مكدّس تحليلات مُصمَّم بهذه الطريقة منخفضة الحجم بطبيعتها مقارنة بطلبات DSAR ضد CRM — معظم الزوار لا يتركون أي سجل لكل زائر بمجرد أن يدور الملح.

نقاط النهاية الثلاث

Statnive Live يشحن ثلاث نقاط نهاية للخصوصية افتراضياً. جميعها الثلاث محمية من CSRF ومحدودة المعدل وتُصدر أحداث تدقيق منظّمة.

POST /api/privacy/opt-out

نقطة نهاية حق الاعتراض وفق المادة 21. يستدعي الزائر هذا من زر في سياسة الخصوصية للمشغّل. يسجّل الخادم إلغاء الاشتراك كملف Cookie ضروري بشكل صارم يعبّر عن اختيار المستخدم (مسموح به وفق ePrivacy § 25(2)(ii) / TDDDG / التطبيقات الوطنية المكافئة لأنه ينفّذ تفضيل الخدمة الذي طلبه المستخدم صراحةً). طلبات الاستيعاب اللاحقة من نفس المتصفح تُسقَط في طبقة الاستيعاب قبل حساب توقيع الزائر.

بدلاً من ذلك، يمكن استمرار إلغاء الاشتراك على جانب الخادم عبر قائمة قمع مفتاحها توقيع الزائر المُجزّأ مع TTL مناسب — الخيار قابل للتكوين من قبل المشغّل.

تُصدر نقطة النهاية حدث التدقيق privacy.opt_out_received مع الطابع الزمني ومعرّف الموقع وتجزئة توقيع الزائر للإسناد المرجعي مع سجل التدقيق.

GET /api/privacy/access

نقطة نهاية حق الوصول وفق المادة 15. يقدّم الزائر:

  • معرّف Cookie المخزّن حالياً في متصفحه (إن وُجد)، أو
  • معرّفاً موقّعاً مُعدّاً مسبقاً (للمشغّلين الذين يدمجون مع بوابة DSAR الخاصة بهم)، أو
  • وصفاً لزيارته ضيّقاً بما يكفي ليتمكن المشغّل من تحديد موقعها (التاريخ، الصفحة، الوقت التقريبي، شبكة المصدر).

تُعيد نقطة النهاية الأحداث المسجلة. الاستجابة هي كائن JSON يحتوي على الأحداث الخام التي تطابق البحث، بالإضافة إلى البيانات الوصفية المشتقة من التجميع التي تتعلق بالزائر (إلى أي دلاء التجميع ساهمت زيارته، دون الإفصاح عن الزوار الآخرين في نفس الدلو). حدث التدقيق: privacy.dsar_access_requested.

POST /api/privacy/erase

نقطة نهاية حق المحو وفق المادة 17. البحث هو نفسه كما في المادة 15. تُعدّد نقطة النهاية جداول الواجهة الخلفية للتخزين ديناميكياً — عبر الفحص الاستبطاني لـ system.tables على ClickHouse — وتحذف الصفوف المطابقة من كل جدول لديه عمود visitor_signature أو cookie_id_hash. التعداد الديناميكي مقصود: جدول مستقبلي يُضاف إلى المخطط يفشل بشكل مغلق إن كان يحمل معرّف زائر لكنه لم يُضَف إلى مسار المحو، لأن اختبار التكامل الذي يؤكد التعداد الديناميكي يغطي كل جدول يعرفه المخطط.

التجميعات الإجمالية لا تُحذف. السبب — وهو السبب الصحيح وفق GDPR — في القسم التالي. حدث التدقيق: privacy.dsar_erase_requested.

جميع نقاط النهاية الثلاث ترفض الطلبات غير الموقّعة عبر الأصول، وتتطلب رمز CSRF مشتقاً من جلسة المشغّل، وتحدّ المعدل لكل IP ولكل ثلاثية (IP, site_id) لمنع الإساءة. سجل التدقيق منفصل عن قاعدة بيانات التحليلات ويُحتفظ به وفق سياسة احتفاظ سجل التدقيق للمشغّل — عادةً أطول من نافذة التجميع التحليلي البالغة 25 شهراً.

لماذا تبقى التجميعات بعد المحو — ولماذا هذا صحيح

الجزء الأكثر إثارة للحدس المعاكس في تصميم DSAR للتحليلات هو بقاء جداول التجميع الإجمالية عبر طلب محو وفق المادة 17. ردة الفعل الأولى عادةً: إن أراد المستخدم أن يُحذف، فبالتأكيد يجب أن تذهب جميع البيانات المتعلقة به، بما في ذلك الأعداد التي ساهم فيها؟

الإجابة تتوقف على ما يحتويه جدول التجميع فعلاً. صف في hourly_visitors يسجّل، على سبيل المثال: site_id=X, hour=Y, unique_visitors=4271. الصف لا يحتوي على توقيع الزائر، ولا عنوان IP الخاص به، ولا أي معرّف لكل زائر. يحتوي على مخطط uniqCombined64 HyperLogLog — بنية بيانات احتمالية تنتج تقديرات أعداد دقيقة دون تخزين القيم الفردية. مخطط uniqCombined64 هو عدد، وليس سجلاً لمن. مساهمة الزائر في العدد لا يمكن عكسها من المخطط.

هذا هو الموقف القياسي لـ EDPB بشأن البيانات المُجمَّعة: بمجرد أن تُجمَّع البيانات إلى ما بعد نقطة قابلية التعرف — بعد النقطة التي يمكن فيها إعادة بناء أي مساهمة فردية — فإنها لم تعد بيانات شخصية. توصية CNIL Sheet 16 بالتجميع إلى أقرب 10 تستند إلى نفس المبدأ. تحليل عدم تحديد الهوية للهيئة الإيطالية Garante في قرار Caffeina Media يتوقف على ما إذا كانت إعادة التعرف محتملة بشكل معقول؛ بالنسبة لعدد إجمالي مشتق من مخطط HyperLogLog، فهي ليست كذلك.

التأثير العملي: طلب محو وفق المادة 17 يحذف صفوف الأحداث الخام (التي تحمل توقيع كل زائر، والموقع الجغرافي المشتق من IP، والمرجع المحدود بالمضيف، والصفحة) لكن يترك جداول التجميع سليمة. لوحات تحكم المشغّل تستمر في عرض حركة المرور التاريخية إلى الصفحة، لكن لا يمكن تتبّع أي صف في لوحة التحكم إلى صاحب البيانات الذي طلب المحو.

يوصف هذا في سياسة خصوصية المشغّل بـ: «مُجمَّعة إلى ما بعد نقطة قابلية التعرف.» تلك هي الصياغة الصحيحة — لا ادعاء مبالغ فيه بـ «مجهولة» ولا ادعاء أقل بـ «لا تزال بيانات شخصية». التجميعات هي الحالة المستقرة الصحيحة وفق GDPR للاحتفاظ بالتحليلات.

سقف 25 شهراً على TTL للتجميع (750 يوماً، عبر ترحيل 011_rollup_ttl.sql) ينطبق بصرف النظر. حتى الأعداد الإجمالية تنتهي صلاحيتها تلقائياً وفق الجدول الزمني لـ CNIL Sheet 16.

مسار التدقيق — 8 أحداث خصوصية

Statnive Live يُصدر 8 أحداث تدقيق منظّمة تغطي سطح الخصوصية والقانون. الأحداث هي دليل المساءلة وفق المادة 28(3)(h) لتدقيق من قبل DPO المشغّل، أو مدقق المسؤول عن المعالجة، أو سلطة حماية البيانات:

الحدثالمحفّزالغرض
privacy.opt_out_receivedPOST /api/privacy/opt-outاعتراض المادة 21 مسجّل
privacy.dsar_access_requestedGET /api/privacy/accessطلب المادة 15 مُبتدأ
privacy.dsar_erase_requestedPOST /api/privacy/eraseطلب المادة 17 مُبتدأ
privacy.consent_givenstatnive.acceptConsent()منحت الموافقة في وضع consent-required / hybrid
privacy.consent_withdrawnstatnive.withdrawConsent()سُحبت الموافقة
legal.lia_viewedGET /legal/liaصفحة LIA للمشغّل قُدِّمت
legal.dpa_viewedGET /legal/dpaصفحة DPA وفق المادة 28 قُدِّمت
legal.privacy_policy_viewedGET /legal/privacy-policy/{lang}صفحة سياسة الخصوصية قُدِّمت

كل حدث هو JSON منظّم مع طابع زمني ومعرّف الموقع ومعرّف الطلب والبصمة ذات الصلة. سجل التدقيق منفصل عن قاعدة بيانات التحليلات — لا يُجمَّع، ولا تنتهي صلاحيته وفق TTL التحليلي البالغ 25 شهراً، ويُحتفظ به وفق سياسة سجل التدقيق للمشغّل (عادةً أطول، وغالباً إلى أجل غير مسمى كدليل امتثال).

مسار التدقيق هو ما يسلّمه المشغّل إلى المنظّم عند التفتيش. سياسة الخصوصية هي الموقف العام؛ أحداث التدقيق هي الدليل المتزامن على أن الموقف قد نُفّذ فعلاً. حزمة استجابة تفتيش CNIL عادةً تشمل (أ) LIA، (ب) سياسة الخصوصية، (ج) سجل التدقيق لنافذة التفتيش، و(د) ناتج نقطة نهاية تدقيق الأحداث (فحص سقف الأحداث الثلاثة للنشر الفرنسي). Statnive Live ينتج الأربعة جاهزة من العلبة.

دليل DSAR للمشغّلين

دليل عمل لمعالجة DSAR ضد نشر Statnive Live:

الخطوة 1: حدّد الطلب. صاحب البيانات يتواصل، عادةً عبر البريد الإلكتروني إلى عنوان DSAR المنشور للمسؤول عن المعالجة. يجب أن يكون الطلب محدّداً بما يكفي ليتمكن المشغّل من تحديد موقع البيانات — عادةً يعني ذلك معرّف Cookie الموجود حالياً في متصفح الزائر (الذي يمكن للزائر فحصه عبر DevTools) أو وصفاً للزيارة ضيّقاً بما يكفي لتحديد نافذة الحدث.

الخطوة 2: تحقّق من هوية مقدّم الطلب. المادة 12(6) من GDPR تسمح للمسؤول عن المعالجة بطلب تحديد هوية إضافي حيث يكون ذلك ضرورياً بشكل معقول للتحقق من هوية صاحب البيانات. لطلبات التحليلات، يميل الإثبات إلى أن يكون: السيطرة على معرّف Cookie (يرسل الزائر لقطة شاشة من DevTools تظهر Cookie)، أو السيطرة على عنوان IP الذي زار منه الزائر (تسجيل دخول موثّق من نفس IP، أو تحدّي رد اتصال). يجب على المشغّل ألا يطلب تحديد هوية أكثر مما هو ضروري للتحقق من الطلب.

الخطوة 3: شغّل استعلام الوصول. يستدعي المشغّل GET /api/privacy/access بمعرّف البحث. الاستجابة هي الأحداث المطابقة. إن كان الطلب طلب وصول وفق المادة 15، فهذه هي الاستجابة المرسلة إلى صاحب البيانات — مُهيّأة كـ CSV أو JSON أو PDF، حسب ما تفضّل بوابة DSAR للمشغّل.

الخطوة 4: شغّل المحو (إن طُلب). يستدعي المشغّل POST /api/privacy/erase بنفس معرّف البحث. تحذف نقطة النهاية الصفوف المطابقة من كل جدول يحمل معرّف زائر؛ جداول التجميع تبقى سليمة (وفق القسم السابق). تُعيد نقطة النهاية عدد الصفوف المحذوفة لكل جدول.

الخطوة 5: أكّد لصاحب البيانات. المادة 12(3) من GDPR تسمح بحتى شهر واحد للرد، قابل للتمديد بشهرين إضافيين للطلبات المعقّدة. استجابة المشغّل يجب أن:

  • تؤكد تحديد موقع البيانات و(إن طُلب المحو) حذفها.
  • تصف ما تم الاحتفاظ به — تجميعات التجميع — ولماذا ليست بيانات شخصية.
  • تشير إلى احتفاظ سجل التدقيق للمشغّل (حقيقة أن طلب DSAR نفسه سُجِّل).

الخطوة 6: سجّل الاستجابة في التدقيق. أحداث تدقيق Statnive Live أُصدرت تلقائياً عندما استدعى المشغّل نقاط نهاية API. يجب على المشغّل أيضاً تسجيل الاستجابة المرسلة إلى صاحب البيانات في نظامه الأوسع لمعالجة DSAR (عادةً مكتب المساعدة أو DPMS).

الدليل بأكمله يتسع في قائمة فحص نصف صفحة. معظم المشغّلين الذين يطبّقونه لأول مرة يقلقون من أن DSAR التحليلات سيكون صعباً؛ عملياً، البنية مصمَّمة بحيث توجد البيانات إما في نافذة صغيرة محدّدة جيداً أو لا توجد على الإطلاق. الحجم منخفض، والاستعلامات محدودة، وشكل الاستجابة موحَّد.

عينة تكامل عاملة

للمشغّلين الذين يدمجون بوابة DSAR الخاصة بهم مع Statnive Live، النمط التالي يعمل من البداية إلى النهاية:

// Triggered from a DSAR portal after identity verification
async function handleAccessRequest(verifiedRequest) {
  const response = await fetch(
    `https://app.statnive.live/api/privacy/access?site_id=${SITE_ID}&cookie_id=${verifiedRequest.cookieId}`,
    {
      method: 'GET',
      headers: {
        'X-Statnive-CSRF': await getCsrfToken(),
        'X-Statnive-Operator-Key': OPERATOR_API_KEY,
      },
    }
  );
  if (!response.ok) {
    throw new Error(`DSAR access failed: ${response.status}`);
  }
  const { events, rollup_metadata } = await response.json();
  return { events, rollup_metadata };
}

async function handleErasureRequest(verifiedRequest) {
  const response = await fetch(
    `https://app.statnive.live/api/privacy/erase`,
    {
      method: 'POST',
      headers: {
        'X-Statnive-CSRF': await getCsrfToken(),
        'X-Statnive-Operator-Key': OPERATOR_API_KEY,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        site_id: SITE_ID,
        cookie_id: verifiedRequest.cookieId,
      }),
    }
  );
  if (!response.ok) {
    throw new Error(`DSAR erasure failed: ${response.status}`);
  }
  const { rows_deleted_by_table } = await response.json();
  return { rows_deleted_by_table };
}

مفتاح المشغّل يُدوَّر وفق سياسة تدوير الأسرار للمشغّل. رمز CSRF مشتق من جلسة المشغّل كجزء من تدفق مصادقة Statnive Live الإداري القياسي.

ما الذي يغيّره النشر بالاستضافة الذاتية

للمشغّلين الذين يديرون Statnive Live كنشر باستضافة ذاتية — الثنائي الذي يعمل على بنية المشغّل التحتية الخاصة — يتغيّر تحليل المسؤول/المعالج. Statnive ليس معالجاً لبيانات تحليلات المشغّل على الإطلاق؛ المشغّل هو المسؤول الوحيد عن المعالجة. لا توجد DPA بين Statnive والمشغّل لتوقيعها لأنه لا يوجد شيء ليكون Statnive معالجاً له.

نقاط نهاية DSAR تعمل بشكل مماثل على ثنائي مستضاف ذاتياً كما تعمل على نشر Statnive Live SaaS مستضاف. أحداث التدقيق تُصدر إلى وعاء السجل الذي اختاره المشغّل (stdout / stderr في النشر بالحاويات، syslog على المضيفين التقليديين، أو جدول تدقيق مخصّص في إعدادات الاستضافة الذاتية). عينة التكامل أعلاه تعمل بنفس الطريقة ضد نقطة نهاية المشغّل الخاصة.

ما يختلف: استجابة المسؤول عن المعالجة لطلب وفق المادة 15 من صاحب بيانات طرف ثالث هي استجابة المسؤول وحده. لا يوجد معالج فرعي Statnive للمساعدة؛ فريق تكنولوجيا المعلومات للمشغّل هو المستجيب لـ DSAR الخاص بالمشغّل.

هذا أحد المقايضات المُغطّاة في منشور الاستضافة الذاتية مقابل EU SaaS الخاص. للمشغّلين الذين لديهم مواقف صارمة بعدم لمس أي طرف ثالث للبيانات (الصناعات المنظّمة، البيئات المعزولة عن الشبكة)، شكل الاستضافة الذاتية هو الإجابة النظيفة؛ للمشغّلين الذين لديهم مواقف صارمة باتفاقية معالج موقّعة (استبيانات بائعي ISO 27001، المشتريات الكبيرة)، شكل SaaS مع DPA وفق المادة 28 هو الإجابة النظيفة. بنية DSAR تعمل بنفس الطريقة في كليهما.

ما الذي يمنحه هذا للمشغّل

النتيجة العملية:

  • حزمة استجابة DSAR نظيفة جاهزة لأي طلب وفق المادة 15 / 17 ضد طبقة التحليلات. ثلاث نقاط نهاية، ثمانية أحداث تدقيق، دليل، وعينة تكامل.
  • إجابة قابلة للدفاع عن بقاء التجميع. صياغة «مُجمَّعة إلى ما بعد نقطة قابلية التعرف» هي الموقف المتوافق مع EDPB؛ سقف TTL البالغ 25 شهراً للتجميع ينطبق بصرف النظر.
  • مسار مساءلة يربط بمساعدة تدقيق المادة 28(3)(h) لعلاقات المعالج ومبدأ المساءلة الأوسع للمادة 5(2) لسجلات المسؤول عن المعالجة الخاصة.
  • توافق مستقبلي مع توقعات حقوق صاحب البيانات للمادة 88a من Digital Omnibus. النص الحالي لا يغيّر التزامات المادتين 15 و17 الجوهرية؛ نقاط نهاية DSAR تعمل دون تغيير.

ما لا يمنحه: طريقة للاحتفاظ ببيانات خام لكل زائر بعد نافذة التجميع البالغة 25 شهراً، لأن إتلاف الملح يجعل ذلك مستحيلاً. طريقة لـ «التراجع» عن طلب حذف، لأن عمليات الحذف لا رجعة فيها. طريقة لتخطي سجل التدقيق للطلبات «الداخلية»، لأنه لا توجد طلبات داخلية — كل استدعاء لنقاط النهاية الثلاث يُصدر حدثاً.

ما تفعلونه، وما تتجنّبونه

افعلواتجنّبوا
تعاملوا مع معرّفات الزوار المُجزّأة كبيانات شخصية منخفضة المخاطر؛ احترموا المواد 15 و17 و21 ضدها.تسويق المعرّفات المُجزّأة على أنها «مجهولة» — مستعارة هي الكلمة القانونية الصحيحة؛ محكمة بروكسل في 14 مايو 2025 أكّدت ذلك.
اربطوا نقاط نهاية الخصوصية الثلاث (/api/privacy/opt-out, /api/privacy/access, /api/privacy/erase) مع حماية CSRF وتحديد المعدل وتسجيل التدقيق.بناء معالج DSAR لمرة واحدة يتجاوز سجلات التدقيق — مساءلة المادة 28(3)(h) هي حزمة الأدلة التي تحتاجونها عند التفتيش.
صفوا بقاء جدول التجميع وفق المادة 17 بـ «مُجمَّعة إلى ما بعد نقطة قابلية التعرف» — لا ادعاء مبالغ فيه بـ «مجهولة» ولا ادعاء أقل بـ «بيانات شخصية».حذف صفوف جدول التجميع رداً على طلب المادة 17 — هي أعداد إجمالية، وليست سجلات لكل زائر، وستفقدون رؤية حركة المرور التاريخية دون أي فائدة من GDPR.
تحقّقوا من هوية مقدّم الطلب وفق المادة 12(6) من GDPR — عادةً بالسيطرة على معرّف Cookie أو تحدّي رد اتصال — قبل تشغيل استعلام الوصول / المحو.طلب تحديد هوية أكثر مما هو ضروري؛ إرشادات EDPB 01/2022 بشأن حق الوصول صريحة بأن التجاوز يهزم الحق.
وثّقوا الدليل + سجّلوا كل حدث تدقيق خصوصية — تركيز إنفاذ EDPB CEF 2025 كان حق المحو، تركيز EDPB CEF 2026 هو الشفافية.معاملة معالجة DSAR كعمل تشغيلي لمرة واحدة — الإنفاذ المنسّق لـ DPA نشط، ومسار التدقيق المتزامن هو الإجابة الصحيحة.

الخلاصة النهائية

حق الوصول وحق المحو وفق المادتين 15 و17 من GDPR ينطبقان على تحليلات الويب. إرشادات EDPB 01/2025 وأحكام محكمة العدل الأوروبية في Breyer وIAB Europe وموقف المنظّمين الوطنيين المتسق كلها تقول ذلك. القرار المعماري هو ما يجب فعله حياله — والإجابة هي جعل نافذة بيانات كل زائر صغيرة (تدوير الملح اليومي)، وجعل نافذة التجميع محدودة (TTL لـ 25 شهراً)، وكشف ثلاث نقاط نهاية (إلغاء الاشتراك، الوصول، المحو)، وإصدار ثمانية أحداث تدقيق، وتوثيق الموقف في سياسة الخصوصية.

Statnive Live يشحن هذا السطح افتراضياً. المشغّلون يدمجون ضده؛ سجل التدقيق يلتقط الدليل المتزامن؛ جداول التجميع تبقى بعد المحو لأنها قد جُمِّعت بالفعل إلى ما بعد قابلية التعرف. درامة DSAR، عندما تصل، إجرائية — ساعة شهر، خطوة تحقق، استدعاء API، بريد إلكتروني للتأكيد — وليست معمارية.

للإطار الأوسع للخصوصية، راجعوا دليل تحليلات الاتحاد الأوروبي بدون موافقة لعام 2026. لمعرفة لماذا يجعل الملح اليومي الدوّار البنية ضئيلة بطبيعتها، راجعوا الخريطة قطراً بقطر. لمعرفة كيف تشغّل نفس أحداث التدقيق تكامل GPC والوضع الهجين، راجعوا المنشور المرتبط. سطح DSAR هو النسيج الضام عبر الأربعة جميعاً.

هذا بحث في الخصوصية وليس استشارة قانونية. نقاط نهاية DSAR الموضّحة هي ميزات إتاحة تقنية. الصحة القانونية لأي استجابة لطلب وفق المادة 15 / 17 / 21 هي مسؤولية المسؤول عن المعالجة وفق المادة 12 من GDPR والتشريعات الوطنية ذات الصلة. كل عميل Statnive يبقى المسؤول عن البيانات ويتحمّل مسؤولية تكوينه وDPIA الخاصة به. اعتمدوا على مستشار قانوني مؤهّل في ولايتكم القضائية قبل النشر.

حالة المراجع التنظيمية حتى 13 مايو 2026: المواد 12 و15 و17 و21 و28(3)(e) و28(3)(h) و33 من GDPR؛ إرشادات EDPB 01/2022 بشأن حق الوصول (النسخة النهائية اعتُمدت في مارس 2023)؛ حكم محكمة العدل الأوروبية C-582/14 Breyer بتاريخ 19 أكتوبر 2016 (ECLI:EU:C:2016:779)؛ حكم محكمة العدل الأوروبية C-604/22 IAB Europe بتاريخ 7 مارس 2024؛ حكم محكمة الاستئناف في بروكسل بتاريخ 14 مايو 2025 في القضية 2022/AR/292 (يؤكد خط IAB Europe / TC String)؛ مسودة إرشادات EDPB 01/2025 بشأن الترميز المستعار (اعتُمدت كمسودة في الجلسة العامة 101 بتاريخ 16 يناير 2025؛ التشاور العام حتى 28 فبراير 2025؛ النهائي لم يُنشر بعد حتى مايو 2026؛ فريق سبرنت EDPB يستهدف إكمالها في صيف 2026)؛ إرشادات EDPB 1/2024 بشأن المصلحة المشروعة بتاريخ 8 أكتوبر 2024؛ تركيز إطار الإنفاذ المنسّق لـ EDPB لعام 2025: حق المحو (المادة 17)؛ تركيز إطار الإنفاذ المنسّق لـ EDPB لعام 2026: التزامات الشفافية والمعلومات (المادتان 13/14)؛ توجيه ePrivacy 2002/58/EC (ساري) وتطبيقاته من قبل الدول الأعضاء بما في ذلك § 25 TDDDG (ألمانيا) والمادة 82 من Loi 78-17 (فرنسا).

Get Statnive Free