كنت سابقًا أراجع خصوصية العقد، وكانت عيناي تظل تركز على منطقة التخزين. حقول التشفير موجودة هناك، ومن السهل أن يشعر المرء بالاطمئنان. اليوم أثناء تدقيق شروط اشتراك RUES، اثنان من المحدِّدات القيودية ثبّتاني في مكاني. يمكن لعقد @Dusk إخفاء الحالة، لكن الاشتراك لا يتم بشكل أعمى؛ فهو أولًا يتعرّف على contract_id ثم على event_name. من الواضح أن قابلية الرؤية تنقسم من هنا إلى مسارين.
قسّمت D-03 وD-37 إلى عمودين. في اليسار كتبت تشفير التخزين، وفي اليمين كتبت طبقة الأحداث. قمت بتحديد JSON header وعناصر raw event bytes في مثال الاشتراك. ستُرسل أحداث عقد $DUSK إلى المشتركين وفقًا للشروط. عندما رأيت raw event bytes يمكن قراءته كما هو، شعرت كأنني تلقيت رسالة خطأ، تقول لي ألا أضع استنتاجات طبقة التخزين فوق طبقة السجلات. حقول الاشتراك ليست مجرد شكل؛ فهي تحدد من يمكنه جمع أي شذرات من السلوك.
بعبارة واضحة: قفل خزانة الملفات لا يعني أن سجل الاستلام عند الباب أصبح مقفلًا أيضًا. الحالة مثل المواد داخل الخزانة، أمّا الأحداث فهي أقرب إلى ورقة استلام تُعلّق عند الباب. الفهرس (indexer) قد لا يتمكن من الوصول إلى حقل مُشفّر، لكنه ربما يرتّب الوقت وعمليات الاستدعاء والأسماء بجدّ واجتهاد. عندما وضعت العمودين معًا، فهمت تدريجيًا أن الخصوصية ليست زرًا واحدًا، بل هي نتيجة تُحسب على حدة لكل مستوى من مستويات القابلية للرؤية.
هنا يوجد حدّ عملي جدًا. لا يلزم أن تُكشف أصول العدد مباشرة عبر الأحداث، وإلا تتشكل مخاطر. عندما نضع نقطة الزمن وعلاقات الاستدعاء المتكررة والأسماء المرتبطة معًا، يستطيع المراقبون بالفعل إجراء استنتاجات قريبة. الاكتفاء باستعلام حالة العقد فقط سيُهمل مسار استعلام واحد. إن فصل طبقة الأحداث عن العموم ووضعها في قائمة فحص وحدها ليس تدقيقًا مبالغًا فيه، بل لتفادي اكتشاف ذلك لاحقًا بعد أن يكون شكل السلوك قد انكشف و”تكوّن“ بفعل السجلات.
لذلك لم أعد أسأل فقط هل يوجد تشفير في التخزين، بل أتابع كذلك كيف تُرسل الأحداث، ومن يمكنه الاشتراك، وما إذا كانت الحقول مُزال عنها التمييز/تمت حمايتها. أفضّل أن أصرف دقيقة إضافية في قراءة الحقول بدلًا من اعتبار الرؤية الافتراضية خصوصية افتراضية. تشفير التخزين مفيد قطعًا، لكن هذا لا يعني أن السجلات ستصبح تلقائيًا سرية. في قائمة فحص ”عقود الخصوصية“، يجب أن تحتل طبقة الأحداث سطرًا مستقلًا. كلما كان الفهرس أكثر نشاطًا، كلما لم يكن من الجيد إغفال هذا السطر. #dusk
قسّمت D-03 وD-37 إلى عمودين. في اليسار كتبت تشفير التخزين، وفي اليمين كتبت طبقة الأحداث. قمت بتحديد JSON header وعناصر raw event bytes في مثال الاشتراك. ستُرسل أحداث عقد $DUSK إلى المشتركين وفقًا للشروط. عندما رأيت raw event bytes يمكن قراءته كما هو، شعرت كأنني تلقيت رسالة خطأ، تقول لي ألا أضع استنتاجات طبقة التخزين فوق طبقة السجلات. حقول الاشتراك ليست مجرد شكل؛ فهي تحدد من يمكنه جمع أي شذرات من السلوك.
بعبارة واضحة: قفل خزانة الملفات لا يعني أن سجل الاستلام عند الباب أصبح مقفلًا أيضًا. الحالة مثل المواد داخل الخزانة، أمّا الأحداث فهي أقرب إلى ورقة استلام تُعلّق عند الباب. الفهرس (indexer) قد لا يتمكن من الوصول إلى حقل مُشفّر، لكنه ربما يرتّب الوقت وعمليات الاستدعاء والأسماء بجدّ واجتهاد. عندما وضعت العمودين معًا، فهمت تدريجيًا أن الخصوصية ليست زرًا واحدًا، بل هي نتيجة تُحسب على حدة لكل مستوى من مستويات القابلية للرؤية.
هنا يوجد حدّ عملي جدًا. لا يلزم أن تُكشف أصول العدد مباشرة عبر الأحداث، وإلا تتشكل مخاطر. عندما نضع نقطة الزمن وعلاقات الاستدعاء المتكررة والأسماء المرتبطة معًا، يستطيع المراقبون بالفعل إجراء استنتاجات قريبة. الاكتفاء باستعلام حالة العقد فقط سيُهمل مسار استعلام واحد. إن فصل طبقة الأحداث عن العموم ووضعها في قائمة فحص وحدها ليس تدقيقًا مبالغًا فيه، بل لتفادي اكتشاف ذلك لاحقًا بعد أن يكون شكل السلوك قد انكشف و”تكوّن“ بفعل السجلات.
لذلك لم أعد أسأل فقط هل يوجد تشفير في التخزين، بل أتابع كذلك كيف تُرسل الأحداث، ومن يمكنه الاشتراك، وما إذا كانت الحقول مُزال عنها التمييز/تمت حمايتها. أفضّل أن أصرف دقيقة إضافية في قراءة الحقول بدلًا من اعتبار الرؤية الافتراضية خصوصية افتراضية. تشفير التخزين مفيد قطعًا، لكن هذا لا يعني أن السجلات ستصبح تلقائيًا سرية. في قائمة فحص ”عقود الخصوصية“، يجب أن تحتل طبقة الأحداث سطرًا مستقلًا. كلما كان الفهرس أكثر نشاطًا، كلما لم يكن من الجيد إغفال هذا السطر. #dusk