تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

بدء استخدام الرموز المميّزة للثقة

Trust Tokens هي واجهة برمجة تطبيقات جديدة لتمكين المواقع الإلكترونية من نقل قدر محدود من المعلومات من سياق تصفُّح إلى آخر (على سبيل المثال، على مستوى المواقع الإلكترونية) للمساعدة في مكافحة الاحتيال، بدون التتبّع السلبي.

Sam Dutton

ملخّص

تتيح الرموز المميّزة الموثوق بها مصدر إصدار رموز مميّزة للتشفير لمستخدم يثق به. يتم تخزين الرموز الرموزية بواسطة متصفح المستخدم. ويمكن للمتصفّح بعد ذلك استخدام الرموز المميّزة في سياقات أخرى لتقييم أصالة المستخدِم.

تتيح واجهة برمجة التطبيقات Trust Token API نقل ثقة المستخدم في سياق معيّن إلى سياق آخر بدون تحديد هوية المستخدم أو ربط هويتَين.

يمكنك تجربة واجهة برمجة التطبيقات باستخدام الإصدار التجريبي والرموز المميّزة للفحص في علامتَي التبويب الشبكة والتطبيق ضمن "أدوات مطوري البرامج في Chrome".

لقطة شاشة تعرض الرموز المميّزة الموثوقة في علامة التبويب "شبكة أدوات مطوّري البرامج في Chrome". — الرموز المميّزة الموثوق بها في علامة التبويب **الشبكة** ضمن "أدوات مطوري البرامج في Chrome"

لقطة شاشة تعرض الرموز المميّزة الموثوق بها في علامة تبويب تطبيق "أدوات مطوري البرامج في Chrome". — الرموز المميّزة الموثوق بها في علامة التبويب **التطبيق** ضمن "أدوات مطوري البرامج في Chrome"

لماذا نحتاج إلى رموز Trust Tokens؟

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

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

مصطلح رئيسي: تتيح ميزة الملف المرجعي للمواقع الإلكترونية التعرّف على المستخدمين الفرديين وتتبُّعهم من خلال الحصول على بيانات عن أجهزتهم ونظام التشغيل وإعداد المتصفّح (مثل الإعدادات المفضّلة للغة ووكيل المستخدم والخطوط المتاحة) أو التغييرات في حالة الجهاز. ويمكن إجراء ذلك على الخادم عن طريق فحص عناوين الطلبات أو على العميل باستخدام JavaScript. تستخدم البصمات آليات لا يعرفها المستخدمون ولا يمكنهم التحكم فيها. تُظهر مواقع مثل Panopticlick وamiunique.org كيف يمكن دمج بيانات بصمات الأصابع لتحديد هويتك كفرد.

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

ماذا يتضمّن اقتراح الرموز المميّزة الموثوق بها؟

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

من شرح الاقتراح:

تقترح واجهة برمجة التطبيقات هذه مساحة تخزين جديدة لكل مصدر للرموز المميّزة للتشفير بنمط "الخصوصية Pass"، والتي يمكن الوصول إليها في سياقات تابعة لجهات خارجية. وهذه الرموز المميّزة غير مخصّصة ولا يمكن استخدامها لتتبُّع المستخدمين، بل يتم توقيعها بطريقة مشفّرة ولا يمكن تزويرها.

وعندما يكون المصدر في سياق يثق فيه بالمستخدم، يمكنه إصدار مجموعة من الرموز المميّزة التي يمكن "إنفاقها" في وقت لاحق في سياق يكون المستخدم فيه غير معروف أو غير موثوق به. والأهم من ذلك أنّه لا يمكن تمييز الرموز المميّزة عن بعضها البعض، ما يمنع المواقع الإلكترونية من تتبُّع المستخدمين من خلالها.

نقترح أيضًا آلية إضافة للمتصفّح لتوقيع الطلبات الصادرة باستخدام مفاتيح مرتبطة بتحصيل قيمة رمز مميّز معيّن.

مثال على استخدام واجهة برمجة التطبيقات

تم تعديل ما يلي من نموذج رمز في المخطط التوضيحي لواجهة برمجة التطبيقات.

لنفترض أنّ مستخدمًا يزور موقعًا إلكترونيًا إخباريًا (publisher.example) يتضمّن إعلانات من شبكة مواقع إعلانية تابعة لجهة خارجية (foo.example)، فقد سبق له استخدام موقع إلكتروني على وسائل التواصل الاجتماعي يُصدِر رموز الثقة (issuer.example).

يوضّح التسلسل أدناه طريقة عمل رموز الثقة.

1.ينتقل المستخدم إلى issuer.example وينفّذ إجراءات تؤدي إلى الاعتقاد بالموقع الإلكتروني بأنّه شخص حقيقي، مثل نشاط الحساب أو اجتياز تحدي اختبار CAPTCHA.

2.يتأكّد issuer.example من أنّ المستخدم هو مستخدم، ويشغّل رمز JavaScript التالي لإصدار رمز ثقة لمتصفّح المستخدم:

fetch('https://issuer.example/trust-token', {
  trustToken: {
    type: 'token-request',
    issuer: 'https://issuer.example'
  }
}).then(...)

3.يخزِّن متصفّح المستخدم الرمز المميّز للثقة، ويربطه بالرمز issuer.example.

4.وبعد مرور بعض الوقت، يزور المستخدم publisher.example.

5-تريد ميزة "publisher.example" معرفة ما إذا كان المستخدم شخصًا حقيقيًا. يثق publisher.example في issuer.example، لذلك يتحقّق ما إذا كان متصفّح المستخدم يحتوي على رموز مميزة صالحة من هذا المصدر:

document.hasTrustToken('https://issuer.example');

6.إذا أدى ذلك إلى عرض وعد يفي بـ "true"، هذا يعني أنّ المستخدم لديه رموز مميزة من issuer.example، وبالتالي بإمكان "publisher.example" محاولة تحصيل قيمة رمز مميّز:

fetch('https://issuer.example/trust-token', {
trustToken: {
  type: 'token-redemption',
  issuer: 'https://issuer.example',
  refreshPolicy: {none, refresh}
}
}).then(...)

باستخدام هذا الرمز:

يطلب مقدّم الخدمة publisher.example تحصيل القيمة.
إذا تم تحصيل القيمة بنجاح، تعرض جهة الإصدار issuer.example سجلّ تحصيل القيمة يشير إلى أنّها أصدرت رمزًا مميّزًا صالحًا لهذا المتصفّح في مرحلة ما.

7.بعد حلّ الوعد الذي تم إرجاعه من خلال fetch()، يمكن استخدام سجلّ تحصيل القيمة في طلبات الموارد اللاحقة:

fetch('https://foo.example/get-content', {
  trustToken: {
    type: 'send-redemption-record',
    issuers: ['https://issuer.example', ...]
  }
});

باستخدام هذا الرمز:

يتم تضمين سجلّات تحصيل القيمة على شكل عنوان الطلب Sec-Redemption-Record.
يتلقّى تطبيق "foo.example" سجلّ تحصيل القيمة ويمكنه تحليله لتحديد ما إذا كان issuer.example يعتقد أنّ هذا المستخدم هو إنسان.
وبالتالي، يردّ "foo.example" على طلبك.

كيف يمكن لموقع إلكتروني تحديد ما إذا كان موثوقًا بك؟

قد يكون لديك سجلّ تسوّق مع موقع للتجارة الإلكترونية أو عمليات تسجيل الوصول على منصة مواقع جغرافية أو سجلّ حساب في أحد المصارف. وقد تفحص جهات الإصدار أيضًا عوامل أخرى، مثل مدة امتلاكك للحساب أو تفاعلات أخرى (مثل اختبارات CAPTCHA أو إرسال النموذج)، ما يزيد من ثقة جهة الإصدار في احتمال أن تكون حقيقيًا.

إصدار الرموز المميّزة للائتمان

إذا اعتبرت جهة إصدار الرموز المميّزة الموثوق بها المستخدم موثوقًا به مثل issuer.example، يمكن لجهة الإصدار جلب رموز الثقة الخاصة بالمستخدم من خلال تقديم طلب fetch() باستخدام مَعلمة trustToken:

fetch('issuer.example/trust-token', {
  trustToken: {
    type: 'token-request'
  }
}).then(...)

يستدعي هذا امتدادًا لبروتوكول إصدار Privacy Pass باستخدام نموذج أولي جديد للتشفير:

يمكنك إنشاء مجموعة من الأرقام العشوائية الزائفة والمعروفة باسم الأرقام غير الرقمية.
يجب إخفاء الأرقام الخاصة (ترميزها حتى لا تتمكّن جهة الإصدار من الاطّلاع على محتواها) وإرفاقها بالطلب في عنوان Sec-Trust-Token.
إرسال طلب POST إلى نقطة النهاية المقدمة.

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

تحصيل قيمة الرمز المميّز للثقة

يمكن للموقع الإلكتروني للناشر (مثل publisher.example في المثال أعلاه) التحقّق مما إذا كانت هناك رموز مميّزة للثقة متاحة للمستخدم:

const userHasTokens = await document.hasTrustToken('issuer.example/trust-token');

في حال توفّر رموز مميزة، يمكن لموقع الناشر تحصيل قيمتها للحصول على سجلّ تحصيل القيمة:

fetch('issuer.example/trust-token', {
  ...
  trustToken: {
    type: 'token-redemption',
    refreshPolicy: 'none'
  }
  ...
}).then(...)

يستطيع الناشر تضمين سجلات تحصيل القيمة في الطلبات التي تتطلّب رمزًا مميّزًا للثقة، مثل نشر تعليق أو إبداء الإعجاب بصفحة أو التصويت في استطلاع، وذلك باستخدام طلب fetch() على النحو التالي:

fetch('https://foo.example/post-comment', {
  ...
  trustToken: {
    type: 'send-redemption-record',
    issuers: ['issuer.example/trust-token', ...]
  }
  ...
}).then(...);

ويتم تضمين سجلّات تحصيل القيمة على شكل عنوان طلب Sec-Redemption-Record.

اعتبارات الخصوصية

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

الاعتبارات الأمنية

استنفاد الرموز المميّزة للثقة: قد يستنفد موقع ضارّ الأموال التي يحتاجها المستخدم عمدًا من جهة إصدار معيّنة. هناك العديد من إجراءات التخفيف ضد هذا النوع من الهجمات، مثل تمكين جهات الإصدار لتوفير العديد من الرموز المميّزة في آنٍ واحد، لكي يحصل المستخدمون على المعروض الكافي لضمان تحصيل قيمة رمز مميّز واحد فقط لكل مرة عرض صفحة المستوى الأعلى.

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

آليات الطلب

قد يكون بإمكانك السماح بإرسال سجلّات تحصيل القيمة خارج fetch()، على سبيل المثال، من خلال طلبات التنقّل. قد تتمكّن المواقع الإلكترونية أيضًا من تضمين بيانات جهة الإصدار في عناوين استجابة HTTP لتفعيل تحصيل قيمة الرموز المميّزة بالتوازي مع تحميل الصفحة.

يهمّنا التأكيد على أنّ هذا الاقتراح يحتاج إلى ملاحظاتك. إذا كانت لديك تعليقات، يُرجى إنشاء مشكلة في مستودع الشرح للرمز المميّز الموثوق.

التعرف على المزيد

نشكر كل الذين ساعدوا في كتابة هذه المشاركة ومراجعتها.

صورة من تصوير ZSun Fu على UnLaunch.