كنت أنظر في أحد الأيام إلى ملف قوائم سوداء قديم، فخطر لي خاطر غير مريح: يمكن أن تبقى القاعدة كما هي تمامًا، لكن العالم خلف تلك القاعدة قد يتغير بين عشية وضحاها.
قد يكون اسم لم يكن موجودًا في القائمة بالأمس موجودًا اليوم. منطق السياسة لا يتحرك، لكن الواقع الذي تقرؤه قد تغيّر بالفعل.
وهذا ما جعلني ألاحظ تفصيلًا صغيرًا في "Newton Protocol’s Privacy Flows":
أحدث إصدار.
في البداية، بدا التصنيف بالإصدارات وكأنه إدارة بيانات عادية. ينشر موفّر قائمة جزاءات أو قائمة سوداء أو جدول مخاطر أو مجموعة بيانات امتثال؛ في كل مرة يُستدعى publishData، يُنشأ إصدار جديد، ويقوم المشغّلون بحلّ أحدث بيانات سرّية عندما يحتاج عميلٌ مُخوَّلٌ إليها.
يبدو ذلك منطقيًا.
لا ينبغي تجميد بيانات الامتثال عبر الزمن. إذا تغيّرت قائمة سوداء، يجب أن ترى السياسة التحديث، وإذا تغيّر جدول المخاطر، ينبغي أن يتفاعل تدفق الترخيص مع الواقع الجديد بدلًا من فرض وجهة نظر الأمس للعالم.
لكن كلما فكرت أكثر، شعرت بأن "أحدث" ليست مجرد إحساس بالحداثة، بل هي أقرب إلى الصلاحية.
في @NewtonProtocol ، لا يثبّت العملاء المُخوَّلون أنفسهم إلى إصدارٍ صريح واحد. إنهم يقرؤون أحدث البيانات، وهذا يعني أن نفس PolicyClient، ونفس منطق Rego، ونفس المستخدم قد يُنتج قرارًا مختلفًا غدًا لأن مجموعة البيانات السرّية الكامنة تحت السياسة تغيّرت اليوم.
قد يُرفض طلب المستخدم ليس لأن محفظته تغيّرت، بل لأن مجموعة البيانات خلف السياسة تغيّرت.
هذه هي الحدود.
المزوّد لا يقوم فقط بتزويد البيانات. يصبح المزوّد جزءًا من حدود الإنفاذ، لأن أحدث إصداره يساعد في تحديد ما تراه السياسة.
إتاحة الوصول عبر أحدث إصدار تُبقي السياسة قريبة من العالم الحقيقي، لكنها تمنح أيضًا أحدث مجموعة بيانات القدرة على إعادة تشكيل الإنفاذ قبل أن يفهم المستخدمون بالكامل ما الذي تغيّر.
ربما لا تكون أحدث البيانات تلقائيًا هي الأكثر أمانًا.
وربما هي ببساطة البيانات المسموح بها حاليًا لتحديد القرار.
$LAB $NEWT #Newt