#dusk $DUSK @Dusk
عدتُ إلى ملاحظات أمان محفظة Dusk وإلى سجل التغييرات v0.3.0 بافتراض بسيط: يعني أمان المحفظة حماية عبارة الاسترداد وتعيين كلمة مرور قوية.
لكن تصميم الإضافة أكثر تشغيلية. يتم تشفير عبارة الاسترداد أثناء السكون باستخدام PBKDF2 و AES-GCM-256، إلا أن عبارة الاسترداد غير المقفلة ما تزال موجودة في ذاكرة JavaScript ولا يمكن ضمان مسحها بالكامل (zeroization). يتم تشغيل القفل التلقائي عبر تنبيهات/منبّهات المتصفح (alarms)؛ وقد أصلح v0.3.0 طابع وقت النشاط الذي كان يستمر رغم إعادة تشغيل عامل الخلفية (background-worker restarts) كما حافظ على أحداث الحالة المقفلة للتطبيقات اللامركزية المرتبطة (connected dApps). كذلك يقوم المُزوِّد (provider) بفحص طول المُذكرة (memo) ويرفض المذكرات في استدعاءات العقود لأن الحمولة يمكن أن تكون مُذكرة أو نداءً (call)، وليست كلاهما. تُمسح سجلات الخزائن القديمة غير المدعومة، وتستلزم إعادة استيراد عبارة الاسترداد بدل قبولها بصمت.
هذا جعلني أنظر إليها بشكل مختلف.
تفسيري: يمكن أن تفشل الخصوصية عند حدود الجلسة والحالة المحلية حتى عندما تكون تشفيرات المعاملات المحمية (shielded transaction) سليمة.
أما عدم يقيني فهو مفاضلة الاسترداد. هل يؤدي رفض صيغة خزنة قديمة إلى حماية المستخدمين من السجلات المُعبث بها أو الضعيفة، أم يخلق مخاطرة تشغيلية جديدة عندما لا يتمكن المستخدم من العثور على عبارة الاسترداد؟ وهل تعزز عمليات القفل التلقائي المتكررة الاستخدام الحقيقي، أم تدرب الناس على الموافقة على المطالبات دون قراءتها؟
أريد أن أراقب هذا أثناء التطبيق.
عدتُ إلى ملاحظات أمان محفظة Dusk وإلى سجل التغييرات v0.3.0 بافتراض بسيط: يعني أمان المحفظة حماية عبارة الاسترداد وتعيين كلمة مرور قوية.
لكن تصميم الإضافة أكثر تشغيلية. يتم تشفير عبارة الاسترداد أثناء السكون باستخدام PBKDF2 و AES-GCM-256، إلا أن عبارة الاسترداد غير المقفلة ما تزال موجودة في ذاكرة JavaScript ولا يمكن ضمان مسحها بالكامل (zeroization). يتم تشغيل القفل التلقائي عبر تنبيهات/منبّهات المتصفح (alarms)؛ وقد أصلح v0.3.0 طابع وقت النشاط الذي كان يستمر رغم إعادة تشغيل عامل الخلفية (background-worker restarts) كما حافظ على أحداث الحالة المقفلة للتطبيقات اللامركزية المرتبطة (connected dApps). كذلك يقوم المُزوِّد (provider) بفحص طول المُذكرة (memo) ويرفض المذكرات في استدعاءات العقود لأن الحمولة يمكن أن تكون مُذكرة أو نداءً (call)، وليست كلاهما. تُمسح سجلات الخزائن القديمة غير المدعومة، وتستلزم إعادة استيراد عبارة الاسترداد بدل قبولها بصمت.
هذا جعلني أنظر إليها بشكل مختلف.
تفسيري: يمكن أن تفشل الخصوصية عند حدود الجلسة والحالة المحلية حتى عندما تكون تشفيرات المعاملات المحمية (shielded transaction) سليمة.
أما عدم يقيني فهو مفاضلة الاسترداد. هل يؤدي رفض صيغة خزنة قديمة إلى حماية المستخدمين من السجلات المُعبث بها أو الضعيفة، أم يخلق مخاطرة تشغيلية جديدة عندما لا يتمكن المستخدم من العثور على عبارة الاسترداد؟ وهل تعزز عمليات القفل التلقائي المتكررة الاستخدام الحقيقي، أم تدرب الناس على الموافقة على المطالبات دون قراءتها؟
أريد أن أراقب هذا أثناء التطبيق.
