Signed HTTP Exchanges

Kinuko Yasuda

Signed HTTP Exchange (أو "SXG") هي مجموعة فرعية من التكنولوجيا الناشئة التي تُعرف باسم Web Packages (حِزم الويب)، والتي تتيح للناشرين نقل المحتوى الخاص بهم بأمان، أي إتاحة إعادة توزيعه من قِبل جهات خارجية، مع الحفاظ على نزاهة المحتوى والإحالة. للمحتوى القابل للنقل العديد من المزايا، بدءًا من إتاحة عرض المحتوى بشكل أسرع وحتى تسهيل مشاركة المحتوى بين المستخدمين وتوفير تجارب أكثر بساطة بلا إنترنت.

إذن، كيف تعمل آليات Signed HTTP Exchange؟ تسمح هذه التكنولوجيا للناشر بتوقيع عملية تبادل واحدة عبر بروتوكول HTTP (أي زوج طلب/استجابة)، وذلك بالطريقة التي يمكن بها عرض عملية التبادل الموقَّعة من أي خادم تخزين مؤقت. عندما يحمّل المتصفّح ملف Signed Exchange هذا، يمكنه عرض عنوان URL للناشر بأمان في شريط العناوين لأنّ التوقيع في ملف التبادل هو دليل كافٍ على أنّ المحتوى مصدره هو الناشر الأصلي.

ملف Signed Exchange: الجوهر

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

  • التحميل المُسبَق الذي يحافظ على الخصوصية: على الرغم من أنّ التحميل المُسبَق للموارد (مثل، باستخدام رابط rel=prefetch) للتنقّل اللاحق يمكن أن يجعل عملية التنقّل تبدو أسرع بكثير، فإنه يتضمن أيضًا جوانب سلبية تتعلّق بالخصوصية. على سبيل المثال، سيؤدي تحميل الموارد مسبقًا لعمليات التنقّل من مصادر متعددة إلى الإفصاح للموقع الإلكتروني المقصود عن أنّه من المحتمل أن يكون المستخدِم مهتمًا بقطعة من المعلومات حتى إذا لم يكن المستخدِم قد زار الموقع الإلكتروني في نهاية المطاف. من ناحية أخرى، تسمح تقنية SXG بالتحميل المُسبَق لمختلف الموارد من مصدر مختلف من ذاكرة تخزين مؤقت سريعة بدون الوصول إلى الموقع المقصود، ما يؤدي إلى مشاركة اهتمام المستخدم فقط في حال حدوث التنقّل. نعتقد أنّ هذا الإجراء يمكن أن يكون مفيدًا للمواقع الإلكترونية التي تهدف إلى توجيه المستخدمين إلى مواقع إلكترونية أخرى. على وجه الخصوص، تخطط Google لاستخدام هذه الميزة في صفحات نتائج البحث من Google بهدف تحسين عناوين URL لصفحات AMP وتسريع النقرات على نتائج البحث.

  • مزايا شبكة توصيل المحتوى (CDN) بدون التنازل عن التحكّم في المفتاح الخاص لشهادتك: غالبًا ما يؤدي المحتوى الذي يصبح رائجًا فجأةً (مثل المحتوى المرتبط من الصفحة الأولى في reddit.com) إلى زيادة عدد الزيارات إلى الموقع الإلكتروني الذي يتم عرض المحتوى عليه، وإذا كان الموقع الإلكتروني صغيرًا نسبيًا، يميل إلى البطء أو حتى إلى عدم التوفّر مؤقتًا. يمكن تجنُّب هذا الموقف إذا تمت مشاركة المحتوى باستخدام خوادم ذاكرة التخزين المؤقت السريعة والفعّالة، ويُتيح SXG إجراء ذلك بدون مشاركة مفاتيح بروتوكول أمان طبقة النقل (TLS).

تجربة تنسيقات Signed Exchange

تتوفّر ميزة "التبادل الموقَّع" في الإصدار 73 من Chrome والإصدارات الأحدث، وكانت متوفرة في السابق كإصدار تجريبي في المصدر.

إنشاء ملف SXG

لإنشاء ملفات SXG لمصدرك (بصفتك ناشرًا)، تحتاج إلى مفتاح شهادة لتوقيع التوقيع، ويجب أن تحتوي الشهادة على إضافة"CanSignHttpExchanges" الخاصة لمعالجتها كملف SXG صالح. اعتبارًا من تشرين الثاني (نوفمبر) 2018، أصبحت DigiCert هي هيئة إصدار الشهادات الوحيدة التي تتيح استخدام هذه الإضافة، ويمكنك طلب الشهادة التي تتيح استخدام SXG من هذه الصفحة.

بعد الحصول على شهادة SXG، يمكنك إنشاء ملفات SXG باستخدام أدوات إنشاء المراجع المنشورة على GitHub.

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

اختبار الميزة على الجهاز

لإنشاء ملفات SXG لأغراض الاختبار، يمكنك إنشاء شهادة موقَّعة ذاتيًا وتفعيل chrome://flags/#allow-sxg-certs-without-extension لمعالجة Chrome لملفات SXG التي تم إنشاؤها باستخدام الشهادة بدون الإضافة الخاصة.

من المفترض أن يعمل رمز مثل ما يلي إذا تم إعداد الخادم والشهادة وملفّات SXG بشكل صحيح:

<!-- prefetch the sample.sxg -->
<link rel="prefetch" href="https://your-site.com/sample.sxg" />

<!-- clicking the link below should make Chrome navigate to the inner
     response of sample.sxg (and the prefetched SXG is used) -->
<a href="https://your-site.com/sample.sxg">Sample</a>

تجدر الإشارة إلى أنّ تنسيق SXG لا يتوفّر إلا مع علامة الربط (<a>) وlink rel=prefetch في الإصدار 73 من Chrome والإصدارات الأحدث. يُرجى العلم أيضًا أنّ صلاحية التوقيع تبلغ 7 أيام بحد أقصى وفقًا للمواصفات، لذا ستنتهي صلاحية المحتوى الموقَّع بسرعة نسبية.

تقديم الملاحظات

يهمّنا معرفة ملاحظاتك بشأن هذه التجربة على العنوان التالي: webpackage-dev@chromium.org. يمكنك أيضًا الانضمام إلى مناقشة المواصفات، أو الإبلاغ عن خطأ في Chrome للفريق. ستساعدنا ملاحظاتك كثيرًا في عملية وضع المعايير وتساعدنا أيضًا في معالجة مشاكل التنفيذ.

ملاحظات