عندما أقرأ Citadel 2 توقفت عند جملة واحدة قبل أن أكمل. الجملة ليست طويلة: عقد السلسلة لا يقوم إلا بالتحقق من صحة التحقق التشفيري لكلمة مرور session—أما السماح لك بالدخول من عدمه، فبيد Service Provider.🤔
يبذل المستخدم جهداً كبيراً لإنشاء إثبات صالح، وما زالت القصة لم تنتهِ، بل يمكن القول إنها بدأت للتو.
يمكنك أن تثبت أنك تملك ترخيصاً صالحاً صادراً عن License Provider ما، ولا حاجة لرفع البيانات إلى السلسلة، فحماية الخصوصية محكمة للغاية. لكن على جهة الخدمة أن تحسم بنفسها مجموعة من الأسئلة: هل أثق بهذا الـ LP؟ ما السمات التي أقبلها؟ هل انتهت صلاحية session؟ هل تم إلغاؤه؟ وهل يمكن استخدام هذه الـ cookie مرة ثانية؟
تمت حماية الخصوصية، لكن السياسات الخاصة بالعمل لا تُقرِّر مكانك.
كيف تبدو الحالة السيئة؟
ينجح المستخدم في إنشاء الـ proof، وتظهر على الصفحة عبارة واحدة: "غير مصرح بالوصول."
أربع كلمات فقط. انتهى.🥶
يبدأ المستخدم في التخمين: هل فشل الـ proof؟ أم أن جهة الخدمة لا تثق بجهة الإصدار؟ أم أن السمات لا تطابق القواعد؟ تخمينات عديدة بلا أي فكرة واضحة.
الخصوصية لم تُسرب فعلاً، لكن الوقت يُستهلك في حل لغز. بالنسبة للمستخدم، تُحفظ الخصوصية، لكن التجربة تنهار.
أما بالنسبة لجهة الخدمة، فإن جميع حالات الرفض تختبئ خلف رمز خطأ واحد، ولا يمكن حتى شرح حدود الامتثال بوضوح.
هذا التقيّد هو في الواقع وعي
قيمة Citadel 2 تكمن هنا: فهي تثبت أنك تملك بيانات اعتماد مناسبة، لكنها لا تتظاهر أبداً بأنك "يجب" أن تقدم الخدمة لي.
الإثبات لك، وقرار الخدمة بيد جهة الخدمة. هذان الأمران منفصلان بوضوح.
$DUSK يطمح نظامه البيئي لاستخدامه في onboarding واقعي، و@Dusk ينبغي أن يدفع التطبيق إلى إخبار المستخدم بوضوح عند فصل valid للـ proof عن policy denied.
هل لم ينجح الإثبات؟ أم أن الإثبات صحيح لكن السياسة رفضته؟ وضعهما في رمز خطأ واحد يوفر الوقت، أما وضعهما في رمزين فيحترم قدرة المستخدم على الحكم.
عندما يعرف المستخدم في أي طبقة يتعثر الأمر، تصبح تجربة الخصوصية الخاصة بـ #dusk كاملة.
وإلا، حتى لو كانت حماية الخصوصية ممتازة، فلن يتذكر المستخدم سوى تلك الكلمات الأربع فقط.🤷♂️
يبذل المستخدم جهداً كبيراً لإنشاء إثبات صالح، وما زالت القصة لم تنتهِ، بل يمكن القول إنها بدأت للتو.
يمكنك أن تثبت أنك تملك ترخيصاً صالحاً صادراً عن License Provider ما، ولا حاجة لرفع البيانات إلى السلسلة، فحماية الخصوصية محكمة للغاية. لكن على جهة الخدمة أن تحسم بنفسها مجموعة من الأسئلة: هل أثق بهذا الـ LP؟ ما السمات التي أقبلها؟ هل انتهت صلاحية session؟ هل تم إلغاؤه؟ وهل يمكن استخدام هذه الـ cookie مرة ثانية؟
تمت حماية الخصوصية، لكن السياسات الخاصة بالعمل لا تُقرِّر مكانك.
كيف تبدو الحالة السيئة؟
ينجح المستخدم في إنشاء الـ proof، وتظهر على الصفحة عبارة واحدة: "غير مصرح بالوصول."
أربع كلمات فقط. انتهى.🥶
يبدأ المستخدم في التخمين: هل فشل الـ proof؟ أم أن جهة الخدمة لا تثق بجهة الإصدار؟ أم أن السمات لا تطابق القواعد؟ تخمينات عديدة بلا أي فكرة واضحة.
الخصوصية لم تُسرب فعلاً، لكن الوقت يُستهلك في حل لغز. بالنسبة للمستخدم، تُحفظ الخصوصية، لكن التجربة تنهار.
أما بالنسبة لجهة الخدمة، فإن جميع حالات الرفض تختبئ خلف رمز خطأ واحد، ولا يمكن حتى شرح حدود الامتثال بوضوح.
هذا التقيّد هو في الواقع وعي
قيمة Citadel 2 تكمن هنا: فهي تثبت أنك تملك بيانات اعتماد مناسبة، لكنها لا تتظاهر أبداً بأنك "يجب" أن تقدم الخدمة لي.
الإثبات لك، وقرار الخدمة بيد جهة الخدمة. هذان الأمران منفصلان بوضوح.
$DUSK يطمح نظامه البيئي لاستخدامه في onboarding واقعي، و@Dusk ينبغي أن يدفع التطبيق إلى إخبار المستخدم بوضوح عند فصل valid للـ proof عن policy denied.
هل لم ينجح الإثبات؟ أم أن الإثبات صحيح لكن السياسة رفضته؟ وضعهما في رمز خطأ واحد يوفر الوقت، أما وضعهما في رمزين فيحترم قدرة المستخدم على الحكم.
عندما يعرف المستخدم في أي طبقة يتعثر الأمر، تصبح تجربة الخصوصية الخاصة بـ #dusk كاملة.
وإلا، حتى لو كانت حماية الخصوصية ممتازة، فلن يتذكر المستخدم سوى تلك الكلمات الأربع فقط.🤷♂️
