صلاحيات تطبيقات الأطفال: كيف ندير الكاميرا والميكروفون والصور والجهات بأقل وصول؟

طلب صلاحية في الهاتف يبدو بسيطًا: الكاميرا، الميكروفون، الصور، الموقع، جهات الاتصال، Bluetooth أو الشبكة المحلية. لكن كل صلاحية تفتح سطح بيانات مختلفًا، وقد تكون أوسع بكثير من المهمة التي يريد الطفل تنفيذها. إذا كان التطبيق يحتاج صورة واحدة لإضافتها إلى الواجب، فلا يحتاج مكتبة الصور كلها. وإذا كان يحتاج ميكروفونًا لمكالمة، فلا يحتاج تسجيلًا في الخلفية. الحوكمة الجيدة تبدأ من capability محددة، تطلب أقل scope وفي اللحظة التي يفهم فيها المستخدم السبب، ثم تتوقف عند انتهاء الحاجة. بالنسبة للأطفال، يجب أيضًا مراعاة العمر والشفافية والguardian controls وعدم استخدام permission كشرط لوظيفة لا تحتاجها.

Permission ليس Consent لكل غرض

موافقة نظام التشغيل تسمح تقنيًا بالوصول، لكنها لا تمنح الخدمة حق استخدام البيانات لأي غرض. إذا سمح الطفل بالكاميرا لالتقاط avatar، لا تستخدم الصور لتحسين face model أو الإعلان. افصل technical permission عن legal/purpose basis وprivacy notice. كل feature يحدد ما يأخذه وما يحتفظ به وما يرسله للخادم.

Just-in-time أفضل من طلب كل الصلاحيات عند التسجيل

لا تطلب contacts وcamera وmic وphotos وBluetooth في أول شاشة قبل أن يعرف الطفل لماذا. اطلب permission عندما يضغط feature يحتاجها، مع شرح قصير وواضح. إذا رفض، لا تعاقبه خارج الوظيفة المرتبطة. التسجيل الأساسي يجب أن ينجح بأقل permissions ممكنة.

الكاميرا: Capture لا يعني Continuous Access

استخدم system picker أو camera intent عندما يكفي بدل access دائم. بعد التقاط الصورة، لا تترك preview أو camera stream مفتوحًا في الخلفية. أظهر indicator النظامي، ولا تحاول إخفاءه. إذا كانت الخدمة تستخدم camera للواقع المعزز، وضح هل frames تغادر الجهاز أم تعالج محليًا.

الميكروفون: Live Call يختلف عن Recording

الصوت في مكالمة يحتاج mic أثناء الجلسة، بينما حفظ التسجيل غرض آخر. لا تسجل افتراضيًا لأن permission موجود. إذا كانت feature voice command، استخدم push-to-talk أو listening محددًا بدل hot mic دائم. وضح cloud processing وretention. عند خروج الطفل من screen، أوقف capture ما لم تكن الوظيفة واضحة ومشروعة في الخلفية.

الصور: Selected Photos أفضل من Full Library عندما يكفي

أنظمة التشغيل توفر في حالات كثيرة اختيار صور محددة. استخدم photo picker بدل إذن مكتبة كامل. لا تحاول إقناع الطفل بتغيير limited access إلى full لمجرد convenience. إذا احتاج إنشاء album أو backup حقيقيًا، اشرح. لا تقرأ metadata أو faces أو albums خارج الصور التي اختارها المستخدم.

جهات الاتصال تكشف أشخاصًا لم يوافقوا

رفع دفتر contacts لا يخص الطفل وحده؛ يكشف أسماء وهواتف الآخرين. لا تستخدمه افتراضيًا لبناء friend suggestions. قدم username أو QR أو رابط دعوة كبديل. إذا اختار المستخدم contact matching، استخدم hashing أو processing يقلل البيانات حيث مناسب، وحدد retention واحذف raw address book بعد المطابقة إذا لم تعد حاجة.

الموقع: Precise وApproximate ليسا شيئًا واحدًا

إذا feature تحتاج مدينة أو طقسًا محليًا، لا تطلب precise GPS. اطلب approximate أو مدينة يدويًا. background location أعلى حساسية ويحتاج ضرورة قوية. لا تجعل رفض location يمنع تطبيقًا لا يعتمد عليه. اربط permission بصفحة location governance وguardian visibility.

Bluetooth: Pairing لا يعني Scanning دائمًا

تطبيق لعبة أو wearable قد يحتاج Bluetooth لاكتشاف جهاز. بعد pairing، قلل scanning. لا تبنِ proximity graph من الأجهزة القريبة. اشرح أسماء الأجهزة التي سيتصل بها التطبيق، ولا تستخدم Bluetooth identifiers للإعلانات أو تتبع الأماكن.

Local Network قد يكشف المنزل الرقمي

الوصول للشبكة المحلية قد يرى TVs وspeakers وأجهزة منزلية. لا تطلبه إلا لو feature تحتاج discovery أو casting. بعد العثور على جهاز، لا تحفظ inventory كاملًا. في حساب طفل، لا تعرض أسماء أجهزة قد تكشف اسم الأسرة أو الغرفة في واجهة عامة.

Notifications ليست صلاحية منخفضة الأثر دائمًا

push قد يكشف رسائل أو اسم خدمة حساسة على شاشة مشتركة، وقد يدفع engagement. اسأل permission بعد شرح نوع الإشعارات. استخدم preview privacy، quiet hours، ولا تجعل refusal يفقد رسائل أمنية حيوية إذا يمكن توفيرها داخل التطبيق أو قناة منفصلة.

Calendar وReminders

إذا يحتاج التطبيق إضافة حدث واحد، استخدم event intent بدل قراءة calendar كاملًا. لا تستنتج المدرسة أو العلاج من events. عند write-only capability إن كانت متاحة، فضلها على read/write. لا تستخدم مواعيد الطفل لبناء advertising profile.

Motion and Fitness قد يكشف الروتين

بيانات الحركة والخطوات والتمرين تبدو غير حساسة لكنها تكشف أوقات النوم والرياضة والتنقل. لا تطلبها لتخصيص badge بسيط إذا يمكن إدخالها يدويًا. إذا التطبيق صحي أو رياضي، افصل analytics وsharing، وامنح delete/export.

Nearby Devices وUWB

تقنيات القرب الدقيقة قد تحدد جهازًا قريبًا أو اتجاهه. استخدمها فقط feature واضح مثل العثور على device، ولا تحتفظ بتاريخ proximity. لا تسمح لمستخدم آخر بمعرفة أن جهاز طفل قريب بلا mutual flow أو حماية.

Background Access يحتاج بوابة ثانية

حتى لو وافق الطفل أثناء feature نشط، background access يتجاوز التوقع. اطلبه منفصلًا واشرح ماذا يحدث عندما app مغلق. راجع دوريًا إذا ما زال مستخدمًا. إذا توقف feature، اطلب من النظام أو المستخدم إزالة permission.

Foreground Service ليس عذرًا لإبقاء Sensor دائمًا

بعض الأنظمة تتطلب indicator إذا app يستخدم mic/location في الخلفية. لا تستغل foreground service لتبرير capture دائم. اجعل notification واضحة ويمكن إيقاف المهمة. لا تحاول إخفاء الخدمة أو تغيير اسمها كي لا يفهم الطفل.

الرفض يجب أن يفتح بديلًا لا حلقة ضغط

إذا رفض الطفل contacts، لا تعرض prompt كل مرة يفتح التطبيق. قدم إضافة صديق بالusername. إذا رفض camera، اسمح avatar جاهزًا. repeated prompts يمكن أن تصبح dark pattern. سجل refusal محليًا بقدر يسمح بعدم الإزعاج، مع option من settings لتغيير القرار.

Guardian Approval لا يغير Scope المطلوب

قد يوافق ولي على app، لكن ذلك لا يجعل كل permission ضرورية. product يجب أن يظل minimal. في family account، أخبر الطفل أيضًا بما سيُستخدم. لا تجعل guardian dashboard يعرض raw mic/photos/contacts لمجرد أن ولي سمح للتطبيق.

School-managed Device لا يعني Unlimited Permissions

MDM قد يمنح المدرسة controls أوسع، لكن app تعليمي يظل يحتاج غرضًا. لا تفرض camera/mic على كل الطلاب إذا activity اختيارية. وثق permissions عبر vendor procurement، وراجعها عند تحديث التطبيق. لا تسمح للمورد بإضافة permission جديد صامتًا بعد اعتماد النسخة.

App Update قد يضيف صلاحية جديدة

راجع diff في permissions عند release. إذا أضاف SDK advertising contacts أو Bluetooth، توقف. لا تعتمد على OS prompt فقط؛ اشرح feature الجديدة. في app store، راقب privacy labels لكن تحقق من data flow فعليًا.

SDK قد يطلب Permission باسم التطبيق

مكتبة analytics أو ads تعمل داخل process التطبيق وقد تصل إلى البيانات التي يملكها app. لا تقل نحن لا نستخدم contacts إذا SDK يقرأها. راجع permissions وAPIs والnetwork calls لكل dependency. اعزل SDK أو أزلها إذا لا تستطيع منع وصول غير لازم.

Clipboard وPaste

لا تقرأ clipboard في الخلفية. الطفل قد ينسخ password أو رسالة خاصة. استخدم paste action عند اختيار المستخدم، واعتمد APIs التي تظهر intent. لا تخزن clipboard contents في analytics أو crash reports.

Files and Documents

استخدم document picker للوصول إلى ملف محدد بدل filesystem واسع. لا scan كل Downloads. إذا يرفع الطفل واجبًا، انسخ فقط الملف المختار ثم احذف local temp بعد upload. لا تجعل parser يرسل الملف إلى vendor إضافي دون disclosure.

Biometric Authentication عبر OS أفضل من جمع Biometric بنفسك

إذا الغرض login، استخدم platform authenticator الذي يعيد success/failure ولا يشارك template. لا تطلب face image لبناء نظام خاص. هذا يقلل البيانات والأمن المطلوب. إذا biometric feature نفسها هي المنتج، تدخل قواعد biometrics المتخصصة.

Permission Dashboard داخل التطبيق

اعرض ما يستخدمه app فعليًا ولماذا، مع link إلى OS settings. لا تدّعِ القدرة على تغيير permission إذا OS وحده يملكها. فرّق بين granted وused recently. المستخدم يحتاج رؤية أن camera مسموحة لكنها لم تُستخدم منذ أشهر، فيستطيع إزالةها.

Unused Permission Review

راجع permissions التي لم تُستخدم 30 أو 90 يومًا واقترح إزالتها أو اعتمد auto-reset النظامي. لا تعيد الطلب فورًا. إذا feature تعود لاحقًا، اطلبها عند الحاجة من جديد. هذا يقلل attack surface.

Incident: Permission Misuse

إذا اكتشفت أن app أو SDK وصل إلى mic/photos بلا غرض، أوقف code path، حدّث التطبيق، قيّم data sent، احذف غير الضروري، وأخطر وفق القانون إذا كان breach. لا تقل OS سمح بذلك. technical grant لا يبرر misuse.

اختبار قبل الإصدار

1. Fresh install بلا permissions.
2. Refuse كل permission واختبر الوظائف البديلة.
3. Grant selected photos فقط.
4. Mic أثناء call ثم بعد الخروج.
5. Location approximate مقابل precise.
6. Bluetooth بعد pairing.
7. Local network discovery.
8. School MDM profile.
9. SDK network calls بعد permission.
10. App update يضيف permission جديد.
11. Age transition وguardian role.
12. Delete account وrevoke tokens.

مقاييس

قِس permission request rate، grant/refuse، feature success without grant، unused permissions، background access minutes، SDK access، permission-related complaints، app-update scope changes، وtime-to-revoke بعد delete. لا تجعل grant rate KPI؛ ارتفاعه قد يعني pressure UX.

خطة 90 يومًا

30 يومًا: inventory لكل permission وpurpose/code owner. 31–60: system pickers، selected scopes، just-in-time prompts، SDK review. 61–90: dashboard، unused reset، school profile tests، age/guardian tests وrelease permission diff. أزل permission لا تستطيع ربطها بfeature حقيقية.

نموذج روافد المفاهيمي: طلب واحد، غرض واحد، مدة واحدة

تقترح روافد أن كل permission يمر بثلاثة أسئلة: ما الوظيفة الحالية، ما أقل scope، ومتى تنتهي الحاجة. يضاف العمر والجهة التي ترى البيانات. النموذج conceptual وغير متحقق. يقاس بانخفاض full-library/background grants وارتفاع نجاح البدائل والحذف.

أسئلة شائعة

المصادر والمنهجية

تعتمد الصفحة على Children’s Code لدى ICO، وإرشادات Android/Google Play وApple حول privacy والpermissions وتطبيقات الأطفال، وFTC COPPA، وeSafety Safety by Design، وUNICEF online privacy وCRC General Comment 25. تم فصل OS permission عن الغرض القانوني/التصميمي، وتحويل كل capability إلى lifecycle واضح.

حوّل كل إذن إلى حاجة وظيفية محددة

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

اطلب الإذن في اللحظة التي يفهم فيها الطفل السبب

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

لا تنس وصول SDK والمكتبات الطرفية

قد يطلب التطبيق إذنًا لغرض مشروع ثم تتمكن مكتبة Analytics أو Chat أو Crash من رؤية البيانات الناتجة. لذلك تربط حوكمة Permission بين إذن نظام التشغيل ومسار البيانات داخل التطبيق، وتحدد أي SDK يستطيع استدعاء الواجهة أو استقبال الملف. يُراجع Manifest والاعتمادات عند كل إصدار، وتُمنع المكتبة من الوصول إذا لم تكن جزءًا من الغرض الذي شرحه المستخدم. إضافة SDK جديد يجب أن تعيد فتح مراجعة الأذونات حتى لو لم تتغير شاشة الطلب.

افصل وضع الطفل عن وضع البالغ أو المعلم

قد تحتاج أداة مدرسية أو حساب بالغ خصائص أوسع من حساب الطفل. لا ينبغي أن تتحول هذه الحاجة إلى Permission افتراضي لكل المستخدمين. يمكن تصميم Scopes أو Feature flags تجعل الوصول الأوسع مرتبطًا بدور موثق وسياق واضح، مع منع الانتقال الصامت بين الأوضاع. في الأجهزة المُدارة مدرسيًا يجب توضيح ما يفرضه MDM وما يطلبه التطبيق نفسه، لأن المستخدم قد لا يستطيع تغيير بعض القيم. هذا الفرق مهم للشفافية ولمنع نسبة قرار المؤسسة إلى اختيار الطفل.

اختبر Permission Diff في كل إصدار

قبل النشر يقارن خط CI الأذونات والتصريحات والحساسيات بالإصدار السابق. أي Permission جديد أو توسع من foreground إلى background أو من ملف محدد إلى مكتبة كاملة يحتاج مراجعة مبررة. كما تُختبر الأجهزة التي رفض المستخدم عليها الإذن سابقًا للتأكد من أن التحديث لا يعيد الطلب بصورة مضللة. ويشمل الفحص Android وiOS ونسخ الويب أو سطح المكتب عندما تختلف قدرات النظام. الهدف هو جعل توسع الوصول حدثًا ظاهرًا لا أثرًا جانبيًا لتغيير مكتبة.

مقاييس تقلل Permission Creep

راقب عدد الأذونات الحساسة لكل ميزة، ونسبة المستخدمين الذين يرفضون ثم يستطيعون إكمال المهمة، ومعدل الأذونات التي لم تستخدم خلال فترة، وعدد إصدارات التطبيق التي أضافت وصولًا دون إزالة قديم، وحوادث وصول SDK إلى بيانات أوسع من غرضه. يمكن أيضًا قياس نسبة الطلبات التي تظهر بعد فعل واضح من المستخدم بدل شاشة البدء. انخفاض عدد الأذونات مع بقاء الوظيفة مؤشر أفضل من مجرد ارتفاع نسبة الموافقة.

سيناريو مراجعة: ميزة جديدة تطلب وصولًا أوسع

افترض أن فريق المنتج أضاف ميزة تسمح للطفل بتسجيل مقطع قصير وإرساله إلى صديق. قبل التنفيذ كان التطبيق يحتاج الصور فقط، والآن يقترح المطور إذن الكاميرا والميكروفون والمكتبة كاملة والوصول في الخلفية لتسهيل التجربة. المراجعة لا تسأل فقط هل يستطيع نظام التشغيل منح هذه الأذونات؛ تفكك المهمة إلى أقل وصول ممكن: كاميرا وميكروفون عند فتح شاشة التسجيل، دون خلفية، وحفظ محلي مؤقت، ومنتقي ملف محدود إذا اختار المستخدم مادة موجودة. ثم تُراجع مكتبات الطرف الثالث التي تعمل في الشاشة نفسها، وما إذا كان الملف يمر عبر Analytics أو Crash logs. تُختبر حالات الرفض، والإذن لمرة واحدة، وإلغاء الإذن أثناء الجلسة، وحساب طفل على جهاز مُدار، وجهاز قديم لا يدعم الخيار الأدق. إذا لم تعمل الميزة دون مكتبة الصور كاملة، يُعامل ذلك كقرار تصميم يحتاج تبريرًا لا كسبب تلقائي لتوسيع الوصول.

قائمة مراجعة قبل كل Release

قبل كل إصدار يُقارن Manifest وEntitlements والإعلانات الخاصة بالخصوصية بالإصدار السابق، ثم يُربط كل تغيير بقصة منتج ومالك واضح. تُراجع الأذونات غير المستخدمة، والأذونات التي يمكن استبدالها بواجهات أقل صلاحية، والميزات التي ما زالت تعمل بعد الرفض. ويُختبر أن شاشة الشرح تسبق الطلب وأن النص يصف الغرض الحالي بدل عبارة عامة تصلح لكل شيء. كما يُفحص سلوك الحساب بعد خفض العمر أو الانتقال إلى وضع طفل، لأن Permission مُنح سابقًا لحساب بالغ قد يبقى في نظام التشغيل. عند وجود هذا الانتقال يجب أن يقلل التطبيق استخدام البيانات فعليًا حتى لو ظل الإذن التقني موجودًا، وأن يطلب إجراءً جديدًا فقط عندما يكون ضروريًا ومفهومًا.

متى نعتبر الإذن زائدًا؟

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

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

وتُراجع النتيجة بعد الإطلاق دوريًا.

سجل صلاحيات قابل للمراجعة على مستوى الميزة

اربط كل صلاحية بمهمة مستخدم محددة

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

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

اختبار الرفض والسحب وليس الموافقة فقط

المنتج الجيد يعمل عندما يقول الطفل لا

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

كما تُختبر الحسابات المشتركة والأجهزة المدرسية؛ فقد يعطي بالغ صلاحية على جهاز ثم يستخدمه طفل آخر، أو تفرض إدارة الجهاز إعدادًا لا يستطيع المستخدم تغييره. في هذه الحالات لا تُعامل موافقة النظام وحدها كدليل كافٍ على مناسبة الاستخدام. يجب أن يعرف التطبيق سياق الحساب والعمر المتوقع وأن يقلل جمع البيانات عندما تكون هوية المستخدم أو ملكية الجهاز غير مؤكدة.

مراجعة دورية للوصول غير المستخدم

قلل الامتيازات مع تغير المنتج

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

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

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