كشفت دراسة أمنية عن طريقة غير معتادة استخدمها Meta Pixel على Android لربط نشاط المستخدم داخل مواقع الويب بهويته داخل تطبيقَي Facebook وInstagram. وبدل الاعتماد فقط على ملفات تعريف الارتباط أو تسجيل دخول المستخدم إلى Facebook داخل المتصفح، استُخدمت قناة اتصال محلية عبر localhost وWebRTC لتمرير معرّف من المتصفح إلى تطبيق Meta الموجود على الهاتف نفسه.
كانت النتيجة أن معرّف الويب _fbp يمكن أن يصل إلى تطبيق Facebook أو Instagram الذي يعرف أصلًا الحساب المسجل داخله، ما يسمح بربط تصفح الويب بهوية أكثر ثباتًا. وعندما نشر الباحثون النتائج علنًا في 3 يونيو 2025، رصدوا توقف Meta Pixel عن إرسال البيانات إلى localhost وإزالة معظم الشيفرة المسؤولة عن هذه القناة.
القصة لم تنتهِ عند ذلك الحد. فمنذ الكشف، أضافت المتصفحات ونظام Android طبقات حماية جديدة حول الوصول إلى الشبكة المحلية وLoopback، وأصبح Chrome يميز لاحقًا بين الوصول إلى أجهزة الشبكة المحلية والوصول إلى خدمات تعمل على الجهاز نفسه.
ماذا اكتشف الباحثون؟
وثّق باحثون من KU Leuven وIMDEA Networks وRadboud University طريقة لتبادل المعرّفات بين صفحات الويب والتطبيقات الأصلية عبر localhost. نُشرت النتائج أولًا ضمن مشروع LocalMess، ثم تحولت الدراسة إلى البحث المحكّم Bridges to Self: Silent Web-to-App Tracking on Mobile via Localhost ضمن USENIX Security 2026.
الفكرة الأساسية كانت وجود طرفين على الهاتف يستطيعان الوصول إلى واجهة Loopback نفسها:
- شيفرة Meta Pixel تعمل داخل صفحة ويب في المتصفح.
- تطبيق Facebook أو Instagram يعمل كتطبيق أصلي على Android ويستمع إلى منافذ محلية.
هذه القناة أتاحت نقل معرّف من سياق الويب إلى سياق التطبيق دون الحاجة إلى إرسال الاتصال من المتصفح إلى جهاز آخر على الإنترنت.
ما هو localhost ولماذا كان مهمًا؟
localhost يشير إلى الجهاز نفسه، ويرتبط عادةً بعنوان Loopback مثل 127.0.0.1 في IPv4. فعندما يرسل برنامج بيانات إلى هذا العنوان، لا تغادر البيانات الهاتف إلى خادم خارجي، بل يتم توجيهها إلى خدمة أخرى تعمل على الجهاز نفسه.
هذا الاستخدام مشروع وشائع في البرمجة والتطوير، والمشكلة ليست في localhost بحد ذاته. ما كشفه البحث هو إمكانية تحويله إلى جسر بين صفحة ويب وتطبيق أصلي بطريقة لا يتوقعها المستخدم.
ولفهم الفرق بين الاتصال داخل الجهاز والشبكة المحلية والإنترنت بصورة أوسع، يمكنك الرجوع إلى دليل أساسيات الشبكات من الصفر خطوة بخطوة.
في البيئة التي درسها الباحثون، كان بإمكان تطبيق Android يملك صلاحية الإنترنت فتح Socket يستمع على واجهة Loopback، بينما تستطيع بعض تقنيات الويب إنشاء اتصالات إلى العنوان المحلي. وبذلك أصبحت localhost نقطة يلتقي عندها سياق الويب مع التطبيق الأصلي.
كيف ربط Meta Pixel تصفح الويب بحساب Facebook أو Instagram؟
لفهم المشكلة، يجب أولًا معرفة أن Meta Pixel يستخدم معرّفًا يسمى _fbp. وهو ملف تعريف ارتباط First-Party يمكن استخدامه للتعرف على المتصفح لأغراض القياس والإعلانات.
وفقًا للباحثين، كان المسار يعمل تقريبًا كالتالي:
- يكون تطبيق Facebook أو Instagram مثبتًا على هاتف Android، ويكون المستخدم مسجل الدخول إلى حسابه داخل التطبيق.
- يشغّل التطبيق خدمة في الخلفية تستمع إلى منافذ محلية على الهاتف.
- يفتح المستخدم موقعًا يحتوي على Meta Pixel من متصفح Android.
- تقرأ شيفرة Pixel معرّف
_fbpالخاص بالموقع. - تستخدم الشيفرة WebRTC لإرسال هذا المعرّف إلى خدمة Meta التي تستمع على localhost.
- يتلقى تطبيق Facebook أو Instagram قيمة
_fbp. - يستطيع التطبيق إرسال القيمة إلى بنية Meta الخلفية بجانب معرّفات مرتبطة بالمستخدم المسجل داخل التطبيق.
وهنا تظهر أهمية التقنية: معرّف كان موجودًا داخل سياق تصفح الويب أصبح قابلًا للربط بهوية مستخدم معروفة داخل التطبيق الأصلي.
هل كان يجب تسجيل الدخول إلى Facebook داخل المتصفح؟
لا. وهذه من أهم النقاط في البحث.
السيناريو الذي وثقه الباحثون لم يكن يحتاج إلى أن يكون المستخدم مسجل الدخول إلى Facebook.com أو Instagram.com داخل Chrome. الشرط المهم كان وجود تطبيق Facebook أو Instagram الأصلي على الهاتف وتسجيل المستخدم إلى حسابه داخل التطبيق.
بمعنى آخر، المتصفح نفسه لم يكن بحاجة إلى امتلاك جلسة Facebook مسجلة. تطبيق الهاتف كان الطرف الذي يستطيع أخذ معرّف الويب وربطه بمعرّفات مرتبطة بالحساب.
كيف استُخدم WebRTC لنقل معرّف _fbp؟
WebRTC مجموعة تقنيات ويب صُممت أساسًا للاتصالات في الوقت الحقيقي، مثل مكالمات الصوت والفيديو ونقل البيانات مباشرة بين الأطراف.
لكن WebRTC يحتوي أيضًا على آليات شبكية لاكتشاف المسارات والعناوين اللازمة لإنشاء الاتصال. واستفادت طريقة Meta التي وثقها الباحثون من هذه الآليات لإرسال بيانات إلى عنوان Loopback داخل الهاتف.
وجد الفريق أن Meta Pixel استخدم STUN Binding Requests المرسلة عبر UDP إلى منافذ في النطاق من 12580 إلى 12585.
وكانت تطبيقات Facebook وInstagram التي اختبرها الباحثون تستمع إلى أحد هذه المنافذ.
ما علاقة SDP Munging بالأمر؟
في إحدى نسخ التقنية، وضعت شيفرة Meta Pixel قيمة _fbp داخل الحقل ice-ufrag المستخدم ضمن بيانات WebRTC من خلال أسلوب يعرف باسم SDP Munging.
بعد ذلك تنتقل القيمة ضمن رسالة STUN إلى منفذ UDP المحلي الذي يستمع إليه تطبيق Meta.
ومن النقاط التقنية المهمة أن الباحثين أشاروا إلى أن هذا التدفق لم يكن يظهر بالطريقة المعتادة في أدوات Chrome DevTools التي يستخدمها مطورو المواقع لمراقبة طلبات HTTP التقليدية، لأن جزءًا من الاتصال كان يحدث عبر WebRTC.
ماذا كان يحدث للبيانات بعد وصولها إلى التطبيق؟
لم تكن قيمة _fbp تُرسل إلى التطبيق فقط. ففي الوقت نفسه كان Meta Pixel يرسل أحداث القياس العادية إلى Meta، والتي قد تتضمن — حسب إعداد الموقع — عنوان الصفحة وبيانات المتصفح ونوع الحدث مثل:
PageViewAddToCartPurchase- أحداث قياس أخرى يحددها الموقع.
ووفق تحليل الباحثين، كان تطبيق Facebook أو Instagram يستطيع بدوره إرسال _fbp إلى Meta مع معرّفات مستخدم أكثر ثباتًا.
وهكذا تتكون حلقة الربط: الموقع يعرف نشاط التصفح، وPixel يعرف _fbp، والتطبيق الأصلي يعرف الحساب، ثم يصبح من الممكن ربط هذه السياقات ببعضها.
لماذا كانت First-Party Cookies وحدها لا تمنع الربط؟
من المفترض أن تكون قيمة _fbp الخاصة بموقع ما منفصلة عن القيمة الموجودة في موقع آخر، لأن كل موقع يعمل ضمن نطاقه الخاص.
لكن إذا استطاع تطبيق موجود خارج كلا الموقعين استقبال معرّفات المواقع المختلفة وربطها بالهوية نفسها، فإن الفصل بين ملفات تعريف الارتباط داخل المواقع يفقد جزءًا من فائدته.
لهذا وصف الباحثون التقنية بأنها Web-to-App ID Bridging: جسر ينقل الهوية بين عالم الويب وعالم التطبيق الأصلي.
هل كان Incognito يمنع هذه الطريقة؟
بحسب اختبارات الباحثين، لم يكن Incognito Mode كافيًا لمنع نموذج التتبع الذي درسوه.
التصفح الخفي يمنع المتصفح أساسًا من الاحتفاظ ببعض البيانات المحلية بعد إنهاء الجلسة، لكنه لا يعني أن صفحة الويب معزولة عن كل خدمة أخرى تعمل على الهاتف.
إذا استطاعت الشيفرة أثناء الجلسة إرسال معرّف إلى تطبيق أصلي عبر localhost، فإن عدم الاحتفاظ بالكوكيز بعد إغلاق النافذة لا يمحو بالضرورة عملية الربط التي حدثت أثناء التصفح.
وماذا عن مسح Cookies؟
المشكلة مشابهة. مسح ملفات تعريف الارتباط يمنح المتصفح حالة جديدة، لكنه لا يغير حقيقة أن التطبيق الأصلي ما زال يعرف حساب المستخدم.
إذا حصل الموقع لاحقًا على _fbp جديد ثم نُقل هذا المعرّف إلى التطبيق نفسه، يمكن نظريًا ربط المعرّف الجديد بالهوية الدائمة مرة أخرى.
ولهذا خلص البحث إلى أن الطريقة التي وثقها يمكن أن تتجاوز بعض الحماية التي تعتمد فقط على حذف الحالة الموجودة داخل المتصفح.
هل استخدام VPN كان يمنع التتبع؟
ليس بالضرورة.
السبب أن الاتصال إلى 127.0.0.1 هو اتصال بالجهاز نفسه، وليس اتصالًا بخادم بعيد يجب أن يمر عبر الإنترنت بالطريقة التقليدية.
لذلك لا ينبغي اعتبار VPN حلًا عامًا لأي عملية تبادل بيانات يمكن أن تحدث محليًا بين تطبيقين أو بين متصفح وتطبيق على الهاتف نفسه.
هل كانت العملية تحدث قبل موافقة المستخدم على Cookies؟
أجرى فريق البحث عمليات زحف آلية لمواقع ويب من الولايات المتحدة وأوروبا لدراسة مدى انتشار السلوك.
ووجد الباحثون Meta Pixel يرسل معرّف _fbp إلى localhost على 17,223 موقعًا في الاختبارات المنفذة من الولايات المتحدة و15,677 موقعًا في الاختبارات الأوروبية.
ثم أجروا اختبارًا آخر دون الضغط على زر قبول ملفات تعريف الارتباط.
في هذه الحالة رصدوا الاتصال على:
- 13,468 موقعًا من أصل المواقع المرصودة في الاختبارات الأمريكية، أي نحو 78.2%.
- 11,890 موقعًا في الاختبارات الأوروبية، أي نحو 75.8%.
هذه الأرقام لا تعني أن كل موقع يستخدم Meta Pixel فعل ذلك، كما أن الباحثين أنفسهم أوضحوا أن عملية الزحف لم تكن مسحًا شاملًا لكل مواقع الإنترنت.
لكن النتائج مهمة من منظور السياسة الرقمية لأنها تطرح سؤالًا مباشرًا حول معنى الموافقة إذا بدأت بعض قنوات القياس قبل اتخاذ المستخدم قرارًا بشأن التتبع.
هل كان أصحاب المواقع يعرفون بوجود هذه القناة؟
قال الباحثون إنهم لم يجدوا توثيقًا تقنيًا عامًا من Meta يشرح طريقة الاتصال المحددة بين Meta Pixel وتطبيقات Facebook أو Instagram عبر localhost.
كما عثروا على أسئلة سابقة من مطورين لاحظوا أن شيفرة Pixel تحاول الاتصال بـlocalhost ولم يفهموا سبب ذلك.
وهذه نقطة مهمة لأصحاب المواقع: إضافة أداة تحليلات أو إعلانات خارجية تعني تشغيل شيفرة يمكن أن يتغير سلوكها بمرور الوقت. لذلك لا يكفي النظر إلى اسم المزود فقط، بل يجب أيضًا الانتباه إلى البيانات التي ترسلها الأدوات الخارجية وموعد تشغيلها بالنسبة لاختيار المستخدم.
كيف تطورت تقنية Meta قبل الكشف؟
استطاع الباحثون استخدام بيانات تاريخية لإعادة بناء تطور الطريقة خلال عدة أشهر:
- سبتمبر 2024: ظهر اتصال HTTP إلى منفذ محلي.
- أكتوبر 2024: كانت آخر مشاهدات الباحثين لطريقة HTTP المستخدمة بواسطة Pixel.
- نوفمبر 2024: ظهر استخدام WebSocket.
- نوفمبر 2024: بدأ أيضًا استخدام WebRTC وSTUN مع منافذ UDP من 12580 إلى 12585.
- مايو 2025: أضيف مسار آخر مبني على WebRTC TURN يستخدم منافذ مختلفة ولا يعتمد على SDP Munging بالطريقة نفسها.
- 3 يونيو 2025: توقف الباحثون عن رؤية Meta Pixel يرسل الحزم أو الطلبات إلى localhost.
ماذا تغير في 3 يونيو 2025؟
في يوم النشر العلني للبحث، أعلن الفريق تحديثًا مهمًا: Meta/Facebook Pixel لم يعد يرسل أي حزم أو طلبات إلى localhost في مراقبتهم، كما أشاروا إلى أن الشيفرة المسؤولة عن إرسال _fbp بهذه الطريقة أزيلت تقريبًا.
لذلك لا يصح في 2026 وصف طريقة localhost التي كشفها البحث وكأنها ما زالت تعمل دون تغيير.
الصياغة الأدق هي أن Meta استخدمت هذه القناة في الفترة التي درسها الباحثون، ثم توقفت القناة التي وثقوها بعد الكشف.
كيف استجاب Chrome؟
لم تبدأ استجابة Chrome فقط بعد النشر الإعلامي. فقد أجرى الباحثون إفصاحًا مسؤولًا لمزودي المتصفحات قبل الإعلان، وبدأت عدة متصفحات تطوير إجراءات مضادة.
وفق نتائج الفريق، تضمن Chrome 137 إجراءات لتعطيل الشكل المحدد من SDP Munging الذي استُخدم في الطريقة وحظر منافذ استُغلت في الاتصالات المكتشفة.
لكن هذه المعالجة كانت دفاعًا ضد الأنماط المعروفة، وليست حلًا معماريًا شاملًا لكل اتصال محتمل بين مواقع الإنترنت والخدمات المحلية.
ما هو Local Network Access في Chrome؟
ذهبت Google لاحقًا إلى نموذج أوسع يسمى Local Network Access أو LNA.
توضح Google في توثيق Local Network Access الرسمي أن الهدف هو تقييد قدرة المواقع العامة على إرسال طلبات إلى موارد داخل الشبكة المحلية للمستخدم أو إلى برامج تعمل محليًا على جهازه دون إذن.
بدأ طرح نافذة الإذن بصورة عامة مع Chrome 142.
ولا تتعلق الحماية بقضية Meta وحدها. فمن الممكن نظريًا لموقع ويب أن يحاول الاتصال براوتر أو كاميرا أو جهاز ذكي أو برنامج محلي، لذلك يمثل الوصول إلى LAN سطحًا أمنيًا يحتاج إلى حدود واضحة.
ولهذا يرتبط الموضوع أيضًا بمفهوم أمن أجهزة إنترنت الأشياء IoT وحماية الأجهزة المتصلة بالشبكة، حيث لا ينبغي افتراض أن كل خدمة داخل الشبكة المحلية آمنة لمجرد أنها غير متاحة مباشرة من الإنترنت.
ماذا أضاف Chrome 145؟
في Chrome 145، الذي وصل إلى القناة المستقرة في فبراير 2026، أصبحت أذونات Local Network Access أكثر دقة.
فبدل الاعتماد على إذن واحد فقط، فصل Chrome بين:
local-network: للوصول إلى عناوين داخل مساحة الشبكة المحلية.loopback-network: للوصول إلى عناوين Loopback على الجهاز نفسه.
يمكن مراجعة التغيير في ملاحظات إصدار Chrome 145 الرسمية.
هذا الفصل منطقي أمنيًا: موقع يحتاج إلى التواصل مع جهاز موجود على شبكة Wi-Fi المحلية لا ينبغي أن يحصل تلقائيًا على الصلاحية نفسها للتواصل مع برنامج يستمع على localhost داخل الكمبيوتر أو الهاتف.
هل حل Chrome مشكلة WebRTC بالكامل؟
ليس بعد بصورة يمكن وصفها بأنها نهائية.
عند طرح Local Network Access، أوضحت Google أن بعض أنواع الاتصال، ومنها WebRTC، لم تكن في البداية مشمولة بالكامل بمطالبة الإذن نفسها.
ومنذ ذلك الوقت أضاف Chromium تغييرات مرتبطة بدمج LNA مع WebRTC وSTUN وTURN، لكن تذكرة Chromium الخاصة بتطبيق Local Network Access على اتصالات WebRTC ما زالت مدرجة بحالة In Progress حتى أغسطس 2026.
يمكن متابعة الحالة التقنية مباشرة عبر تذكرة Chromium الخاصة بـWebRTC وLocal Network Access.
ولهذا لا ينبغي اختصار الأمر بعبارة «Chrome منع localhost نهائيًا». الواقع أكثر دقة: المتصفح أضاف قيودًا وإجراءات قوية، وأصبح نموذج الأذونات أكثر صرامة، بينما ما زال توحيد الحماية عبر جميع مسارات الاتصال عملية مستمرة.
وما الذي تغير في Android؟
Google شددت أيضًا نموذج الوصول إلى الشبكة المحلية على مستوى نظام التشغيل.
في Android 17، أصبحت التطبيقات التي تستهدف API level 37 أو أحدث بحاجة إلى إذن Runtime جديد يسمى:
ACCESS_LOCAL_NETWORK
وذلك عند حاجتها إلى وصول واسع إلى أجهزة الشبكة المحلية.
توضح Google في توثيق Local Network Permission في Android أن التطبيقات الحديثة تصبح محجوبة عن الوصول المحلي افتراضيًا ما لم تستخدم آليات النظام المخصصة أو تحصل على الإذن المناسب.
وتذكر Google صراحة أن من أهداف الحماية الحد من إساءة استخدام الوصول غير المقيد إلى الشبكة المحلية في التتبع الخفي وبناء البصمات Fingerprinting.
هل ACCESS_LOCAL_NETWORK يمنع كل اتصال localhost؟
لا ينبغي تفسير التغيير بهذه البساطة.
هناك فرق بين شبكة LAN التي تحتوي على أجهزة أخرى، وبين Loopback الذي يشير إلى الجهاز نفسه، كما توجد اختلافات بين التطبيقات القديمة والجديدة وطريقة استهدافها لإصدارات Android.
كما أضاف Android 17 قيودًا خاصة على حركة Loopback بين ملفات العمل والملفات الشخصية في البيئات المُدارة.
الرسالة الأوسع هي أن Android وChrome أصبحا يعاملان الاتصال المحلي باعتباره جزءًا من حدود الخصوصية والأمان، بدل ترك جميع هذه الاتصالات متاحة ضمن افتراضات قديمة.
هل ما زال Meta Pixel يستخدم localhost بهذه الطريقة في 2026؟
لا توجد في نتائج فريق LocalMess المنشورة أدلة على استمرار قناة Meta Pixel المحددة التي كشفوها بعد توقفها في 3 يونيو 2025.
ويجب هنا الفصل بين أمرين مختلفين:
- Meta Pixel ما زال أداة للإعلانات والقياس والتحويلات على الويب.
- قناة Web-to-App عبر localhost التي وثقتها الدراسة هي التي توقفت.
لذلك فإن القول إن «Meta Pixel توقف عن التتبع» غير صحيح، كما أن القول إن «طريقة localhost المكتشفة ما زالت تعمل كما كانت» لا تدعمه الأدلة المنشورة.
لماذا تعد هذه القضية مهمة للخصوصية؟
تكمن أهمية القضية في أنها أظهرت حدودًا غير متوقعة في نموذج العزل الذي يعتمد عليه المستخدم.
المتصفح يفصل المواقع عن بعضها بواسطة آليات مثل Same-Origin Policy وعزل بيانات المواقع، بينما يعزل Android التطبيقات باستخدام Application Sandbox.
لكن إذا تمكنت صفحة ويب وتطبيق أصلي من استخدام نقطة اتصال مشتركة على localhost، يمكن إنشاء قناة تعبر بين هذين العالمين.
وعندما تكون البيانات المنقولة مجرد معرف مؤقت غير مرتبط بالشخص، قد تبدو قيمته محدودة. لكن عندما يصل المعرّف إلى تطبيق يعرف الحساب الحقيقي للمستخدم، تتغير طبيعة البيانات تمامًا.
وهذا هو ما جعل الدراسة تتحدث عن ربط pseudonymous web identifiers بهويات أصلية أطول عمرًا.
ما علاقة القضية بالسياسة الرقمية والموافقة على التتبع؟
القضية ليست مشكلة تقنية فقط؛ فهي مرتبطة مباشرة بمفهوم الموافقة والتحكم في البيانات.
عندما يرى المستخدم نافذة Cookies ويختار قبول أو رفض أدوات معينة، يتوقع أن يكون لهذا القرار تأثير فعلي على ما يحدث بعد ذلك.
لكن إذا بدأت أداة خارجية في نقل معرفات عبر قناة مختلفة قبل إعطاء الموافقة، تظهر مشكلة أكبر من مجرد طريقة تخزين Cookie.
لهذا يجب على أصحاب المواقع عدم الاكتفاء بعرض Consent Banner شكلي، بل التأكد من أن أدوات الإعلانات والتحليلات التي تتطلب موافقة لا تبدأ معالجة البيانات قبل تطبيق اختيار المستخدم فعليًا، وفق القواعد القانونية التي تنطبق على الموقع وزواره.
ماذا تعلمنا من قضية Meta Pixel وlocalhost؟
أهم درس هو أن الخصوصية لا يمكن اختزالها في Cookies فقط.
هناك طبقات متعددة يمكن أن تُستخدم لربط النشاط:
- ملفات تعريف الارتباط.
- معرفات التطبيقات.
- حسابات المستخدم.
- Fingerprinting.
- واجهات المتصفح.
- قنوات الاتصال المحلية بين الويب والتطبيقات.
كما أن Incognito أو VPN أو مسح Cookies يعالج كل منها جزءًا معينًا من المشكلة، وليس كل طرق الربط الممكنة بين التطبيقات والويب.
أما على مستوى المنصات، فقد أظهر البحث أن localhost ليس مجرد أداة تطوير داخلية، بل حد أمني يجب أن يخضع لضوابط واضحة عندما تحاول صفحات الإنترنت الوصول إليه.
الخلاصة
استخدمت الطريقة التي كشفها الباحثون Meta Pixel وWebRTC لإنشاء جسر بين صفحات الويب وتطبيقَي Facebook وInstagram على Android. كانت شيفرة Pixel ترسل معرّف _fbp عبر localhost إلى تطبيق Meta الموجود على الهاتف، ما أتاح ربط معرف المتصفح بمعرفات مرتبطة بالحساب المسجل داخل التطبيق.
لم يكن المستخدم بحاجة إلى تسجيل الدخول إلى Facebook داخل المتصفح، كما أظهرت الدراسة أن بعض الحماية التقليدية مثل Incognito ومسح Cookies وVPN لم تكن كافية لمنع نموذج الربط الذي اختبره الباحثون.
في 3 يونيو 2025، توقف الفريق عن رؤية Meta Pixel يرسل البيانات إلى localhost، ثم استمرت المتصفحات والمنصات في تشديد هذا النوع من الاتصال. أطلق Chrome قيود Local Network Access، وفصل في Chrome 145 بين إذن الشبكة المحلية وإذن Loopback، بينما جعل Android 17 الوصول إلى الشبكات المحلية أكثر خضوعًا للتحكم على مستوى النظام.
لكن أهم نتيجة تتجاوز Meta نفسها: عندما يستطيع تطبيق أصلي وصفحة ويب الوصول إلى قناة مشتركة داخل الجهاز، يمكن أن تتحول وظيفة شبكية مشروعة إلى وسيلة لربط هويات كان المستخدم يتوقع أن تبقى منفصلة. ولهذا أصبحت حدود localhost والشبكة المحلية جزءًا مهمًا من تصميم الخصوصية والأمان الحديث.