Bromite: خداع البصمات WebGL

تم إنشاؤها على ١٧ سبتمبر ٢٠١٨  ·  16تعليقات  ·  مصدر: bromite/bromite

هل طلب الميزة الخاص بك متعلق بالخصوصية؟
يتم النظر فقط في طلبات الميزات المتعلقة بالخصوصية.

نعم

هل يوجد تصحيح متاح لهذه الميزة في مكان ما؟

ليس هذا ما اخاف منه.

صِف الحل الذي تريده
وصف واضح ومختصر لما تريد أن يحدث.

هل تعرف ما إذا كان من العملي تنفيذ آلية خداع بصمات أصابع WebGL مماثلة لتلك الخاصة ببيانات صورة Canvas؟

على وجه التحديد ، بالنسبة إلى تجزئات صور WebGL كما هو مطبق في https://browserleaks.com/webgl

صِف البدائل التي فكرت فيها
وصف واضح ومختصر لأي حلول أو ميزات بديلة فكرت فيها.

غير متاح

enhancement

التعليق الأكثر فائدة

ذات صلة: https://bugzilla.mozilla.org/show_bug.cgi؟

تحرير: لقد أضفت تجزئة صورة WebGL إلى صفحة تخفيف البصمات: https://www.bromite.org/detect

ال 16 كومينتر

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

ومع ذلك ، فهذه مجرد تكهنات ، فأنا لم أحاول فعلاً والآن من خلال النظر في النهج المستخدم هناك ، ربما يكون ذلك ممكنًا. إذا نظرنا إلى https://browserleaks.com/js/webgl.js نحو النهاية فهناك:

try{
  var j=new Uint8Array(131072);
  if (a.readPixels(0,0,256,128,a.RGBA,a.UNSIGNED_BYTE,j),i=JSON.stringify(j).replace(/,?"[0-9]+":/g,""),""==i.replace(/^{[0]+}$/g,""))

و a تم إنشاؤه على النحو التالي:

a=b.getContext("webgl2",{preserveDrawingBuffer:!0})||
b.getContext("experimental-webgl2",{preserveDrawingBuffer:!0})||
b.getContext("webgl",{preserveDrawingBuffer:!0})||
b.getContext("experimental-webgl",{preserveDrawingBuffer:!0})||
b.getContext("moz-webgl",{preserveDrawingBuffer:!0})}

لذلك إذا حصلنا على عقد readPixels على كل ما سبق (تلك المتوفرة في Chromium) ، فعندئذٍ يمكننا إعادة استخدام نفس أسلوب التوزيع العشوائي لبيانات القناة الفرعية على البيانات النقطية المستخرجة. سيكون الجزء الممل / الطويل الوحيد هو تنفيذه لجميع الأوضاع المدعومة (وليس فقط RGBA) كما فعلت في حالة SkImage ؛ من المحتمل أنه يستخدم SkImage داخليًا أيضًا ، لذلك قد يُعاد استخدام الكود.

سألقي نظرة على هذا وأبلغ هنا مرة أخرى ، شكرا لفتح هذا.

Eloston بالأمس فعلت بعض الحفر. تم تعريف الدالة readPixels في https://github.com/chromium/chromium/blob/ffd9d67094adb539dd2cfd34d3a8aaa57c77fcc7/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.h

مثال على هذا السياق (لست متأكدًا من وجود آخرين في قاعدة البيانات) هو GLES2Interface ، كما يمكنك أن ترى استخدامه في هذا الاختبار هنا: https://github.com/chromium/chromium/blob/ ffd9d67094adb539dd2cfd34d3a8aaa57c77fcc7 / cc / paint / oop_pixeltest.cc # L149

تم إيقاف ReadPixels الفعلي هنا على الرغم من: https://github.com/chromium/chromium/blob/0c92aa0f72e2dd58e8e8a86e053e79f801dce629/gpu/command_buffer/client/gles2_interface_stub_impl_autogen.h#L45

أسئلة مفتوحة:

  • هل تأتي هذه الوظيفة مباشرة من المنصة؟ على سبيل المثال مرتبطة ديناميكيًا ، بطريقة ما؟
  • هل هذا هو نفسه لنظام Android / سطح المكتب؟
  • هل يمكننا اعتراض النتيجة؟
  • هل Skia متورطة حقًا؟

ممتع ، شكرا على البحث الأولي.

ها هي أفكاري بناءً على ما وجدته:

هل يمكننا اعتراض النتيجة؟

استنادًا إلى الوثائق الموجودة على WebGLRenderingContext.readPixels () ، لاحظ أنه يجب قراءة البيانات في مصفوفة جديدة ؛ أي يتم نسخ البيانات في بيئة JavaScript من أجل الوصول إليها.

أعتقد أنه يمكننا النظر في اعتراض تعريف واجهة JavaScript لـ readPixels ؛ من هناك يمكننا تحديد كيف يمكننا معالجة البيانات التي يتم استردادها (على سبيل المثال أثناء النسخ في مصفوفة JavaScript ، أو بعد نسخها).

هل Skia متورطة حقًا؟

Skia عبارة عن مكتبة رسومات ثنائية الأبعاد تمامًا ، ويبدو أن طريقة readPixels هذه عبارة عن طبقة رقيقة حول مكالمات OpenGL. أعتقد أنه من الآمن القول أن هذا ليس هو الحال.

أعتقد أنه يمكننا النظر في اعتراض تعريف واجهة JavaScript لـ readPixels ؛ من هناك يمكننا تحديد كيف يمكننا معالجة البيانات التي يتم استردادها (على سبيل المثال أثناء النسخ في مصفوفة JavaScript ، أو بعد نسخها).

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

Skia عبارة عن مكتبة رسومات ثنائية الأبعاد تمامًا ، ويبدو أن طريقة readPixels هذه عبارة عن طبقة رقيقة حول مكالمات OpenGL. أعتقد أنه من الآمن القول أن هذا ليس هو الحال.

راجع https://github.com/chromium/chromium/blob/2ca8c5037021c9d2ecc00b787d58a31ed8fc8bcb/gpu/skia_bindings/gl_bindings_skia_cmd_buffer.h

راجع https://github.com/chromium/chromium/blob/2ca8c5037021c9d2ecc00b787d58a31ed8fc8bcb/gpu/skia_bindings/gl_bindings_skia_cmd_buffer.h

سيكون الأمر غريبًا بعض الشيء بالنسبة لي إذا قاموا بالتحويل إلى Skia أولاً ، نظرًا لأن readPixels يبدو وكأنه طبقة رقيقة حول مكالمات GL كما ذكرت سابقًا.

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

استنادًا إلى الوثائق الموجودة على WebGLRenderingContext.readPixels () ، لاحظ أنه يجب قراءة البيانات في مصفوفة جديدة ؛ أي يتم نسخ البيانات في بيئة JavaScript من أجل الوصول إليها.

أعتقد أنه يمكننا النظر في اعتراض تعريف واجهة JavaScript لـ readPixels ؛

Eloston يجب أن تكون وظائف IDL المقابلة هنا: https://github.com/chromium/chromium/blob/bf31bedf12761be9d4e56500559f2777cbcbeedd/third_party/blink/renderer/modules/webgl/webgl2_rendering_context_base.cc#

يجب أن يكون الاعتراض ممكنًا مباشرة بعد استدعاء ReadPixelsHelper ، أو أفضل داخل هذه الوظيفة لأننا لا نريد تحرير وحدات البكسل إذا لم تتم إضافة بيانات بكسل ؛ تحديدًا هنا: https://github.com/chromium/chromium/blob/53f3d30ef104e4c91ab0d7eb9683305139072ef3/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc#L4345

إذا تحققت من هذا الملف ، فستجد عدة مكالمات مثل ContextGL()->ReadPixels() ، ذلك ReadPixels مع الأحرف الكبيرة R يأتي من السياق ، كما في حالة GLES2 هنا:
https://github.com/chromium/chromium/blob/2ca8c5037021c9d2ecc00b787d58a31ed8fc8bcb/gpu/command_buffer/client/gles2_implementation.cc#L3808

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

تحقق أيضًا من بصمة الخط
https://browserleaks.com/fonts

ذات صلة: https://bugzilla.mozilla.org/show_bug.cgi؟

تحرير: لقد أضفت تجزئة صورة WebGL إلى صفحة تخفيف البصمات: https://www.bromite.org/detect

لقد اكتشفت أنه حتى إذا كان كل من WebGL و WebGL2 يستخدمان ReadPixelsHelper ، فإن WebGL2ComputeRenderingContext الموثق بشكل سيئ لا يستخدم هذه الوظيفة عند تقديم readPixels .

أنا أقول "موثق بشكل سيئ" لأنني لم أجد W3C أو أي مسودة أخرى تصفها ، فقط هذا المستند من Yunchao He (@ Intel): https://docs.google.com/document/d/1EwhDJO_lBH1mGMMwheQUXGhhFk9yoC98Ant3TPqwmmA/view

يمكنك أن ترى أن readPixels مكشوف في IDL (على الرغم من عدم توثيقه في المستند السابق):
https://github.com/chromium/chromium/blob/cf7ed613af7b01f2e64929f969d3737067e28083/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-uable.txt#L8610

تطرح تغطية هذه الطريقة أيضًا تحديات جديدة لأنها تستخدم مخزنًا مؤقتًا داخليًا ؛ قد يكون من الأسهل إزالة هذه الميزة غير الموثقة للواجهة غير القياسية.

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

في مكان ما في تطوير 7x.x ، قامت Google بتعطيل العلامة لتعطيل WebGL ، لذلك أعتقد الآن أنه يتعين علينا إعادتها.

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

في مكان ما في تطوير 7x.x ، قامت Google بتعطيل العلامة لتعطيل WebGL ، لذلك أعتقد الآن أنه يتعين علينا إعادتها.

ومع ذلك ، قد يؤدي هذا إلى زيادة في تفرد بصمة إصبعك كدعم "غير مدعوم / معطل webgl".

تمت إضافة إشارات لإيقاف تشغيل WebGL ، انظر # 411 ؛ لم يتم تعطيلها افتراضيًا في البروميت.

قد يؤدي هذا إلى زيادة في تفرد بصمة إصبعك باعتبارها "دعم webgl غير مدعوم / معطل".

PoorPocketsMcNewHold من خلال تعطيل WebGL / WebGL2 ، فأنت تقوم بتبديل عدد n بت (أيًا كانت كمية الكون التي تنقلها) بـ 1 بت ، مما يقلل التسرب بشكل فعال. ومع ذلك ، سيتم استخدام هذا البت مع جميع المصادر الأخرى ، بحيث يمكن في أفضل الأحوال تحديد المستخدمين كمستخدمي Bromite وفي أسوأ الحالات بالتفصيل كما يسمح أي متصفح Chromium (حتى بشكل فردي).

بعض الأشياء التي لاحظتها:

  • يبدو أن تعطيل WebGL في العلامات لا يفعل شيئًا للكشف و / أو أخذ بصمات الأصابع. لا يزال BrowserLeaks يكتشف عارض الأجهزة ووحدة معالجة الرسومات.
  • معرف جهاز WebRTC غير مخفي.

بعض الأسئلة:

  • أي فرصة للبروميت لنظام التشغيل Windows؟ سيكون منافسًا قويًا لـ Brave.
  • لماذا يتم تعطيل QUIC بشكل افتراضي؟ هل يشكل خطرًا على الأمان و / أو بصمة الإصبع؟
  • على أجهزة Nougat التي لا تحتوي على جذر ، يتم تعطيل Android WebView الافتراضي ويتم تعيين Chrome كعرض الويب الافتراضي. إذا تم تعطيل Chrome ، يقوم Nougat تلقائيًا بتحديد "Google Web View" (أيًا كان ذلك). إذا تم تعطيل Chrome ، وتم تثبيت Bromite WebView ، فهل يستخدم Google WebView Bromite WebView؟ Nougat خاص عندما يتعلق الأمر بشيء WebView.

بعض الأسئلة:

  • أي فرصة للبروميت لنظام التشغيل Windows؟ سيكون منافسًا قويًا لـ Brave.

اختر الكروم غير المرئي .
يأخذ البروميت بعض البقع منه.

  • لماذا يتم تعطيل QUIC بشكل افتراضي؟ هل يشكل خطرًا على الأمان و / أو بصمة الإصبع؟

https://brave.com/quic-in-the-wild
https://bugs.chromium.org/p/chromium/issues/detail؟id=715140#c11
https://bugzilla.mozilla.org/show_bug.cgi؟id=1158011
https://github.com/diracdeltas/quic-request

شكرا!
لمعلوماتك ، على Pixel + LineageOS 17.1 Nightly الأصلي (Android 10) + Magisk + Magisk Bromite Module ، يعمل Bromite WebView بشكل مثالي ، ولا يكسر أي شيء ، ويمكن تحديده في خيارات المطور. يمكن إزالة Android WebView بالكامل. رائع!

تمت إضافة إشارات لإيقاف تشغيل WebGL ، انظر # 411 ؛ لم يتم تعطيلها افتراضيًا في البروميت.

قد يؤدي هذا إلى زيادة في تفرد بصمة إصبعك باعتبارها "دعم webgl غير مدعوم / معطل".

PoorPocketsMcNewHold من خلال تعطيل WebGL / WebGL2 ، فأنت تقوم بتبديل _n_ بت (أيًا كانت كمية الكون التي تنقلها) بـ 1 بت ، مما يقلل التسرب بشكل فعال. ومع ذلك ، سيتم استخدام هذا البت مع جميع المصادر الأخرى ، بحيث يمكن في أفضل الأحوال تحديد المستخدمين كمستخدمي Bromite وفي أسوأ الحالات بالتفصيل كما يسمح أي متصفح Chromium (حتى بشكل فردي).

مرحبًا ، لم أجد علامة WebGL OFF في Bromite 85.0.4183.86
هل يمكنك توضيح المسار الدقيق لكيفية العثور عليه من فضلك؟

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات