វិធីសាស្ត្រពិសោធន៍សម្រាប់រកឃើញកម្មវិធីរុករកស្នាមម្រាមដៃ៖ ពីការប្រកាសកំណែទៅការផ្ទៀងផ្ទាត់ឥរិយាបថ

មានការអះអាងជាច្រើនអំពីថាតើ browser fingerprint អាចត្រូវបានរកឃើញឬអត់ ហើយភាគច្រើនបញ្ចប់ត្រឹមសេចក្តីសន្និដ្ឋាន។ ជំនួសឱ្យជជែកថាតើអ្នកណាឈ្នះ ឬចាញ់ វាមានប្រយោជន៍ជាងក្នុងការមើលថា អ្នកស្រាវជ្រាវបានបម្លែងសំណួរនេះទៅជាការពិសោធន៍ដែលអាចធ្វើឡើងវិញបានយ៉ាងដូចម្តេច និងប្រើសូចនាករអ្វីដើម្បីវាយតម្លៃ។

ការសិក្សាឈ្មោះ Browser Polygraph ដែលត្រូវបានបោះពុម្ពនៅ ACM Internet Measurement Conference (IMC) 2024 ត្រូវបានធ្វើឡើងដោយអ្នកស្រាវជ្រាវពី Arizona State University, Boston University និង Amazon ហើយមាន DOI 10.1145/3646547.3688455។ ជំនួសឱ្យប្រើទិន្នន័យ simulated នៅមន្ទីរពិសោធន៍ ប្រព័ន្ធត្រូវបានដាក់ប្រើក្នុង production environment ពិតរបស់ក្រុមហ៊ុនហិរញ្ញវត្ថុធំមួយរយៈពេល 4.5 ខែ និងគ្របដណ្តប់ 205,000 user sessions ពិត។ ដំណោះស្រាយ environment masking ទូទៅចំនួន 10 ត្រូវបានសាកល្បង ហើយ traffic ធម្មតារបស់អ្នកប្រើត្រូវបានប្រើជាក្រុម control។

របៀបរៀបចំការពិសោធន៍

ជម្រើសរចនាបីធ្វើឱ្យអាចដាក់ detection លើ traffic ទាំងមូលដោយមិនប៉ះពាល់ដល់អាជីវកម្ម។

Features ត្រូវមានតម្លៃប្រតិបត្តិទាប។ Detection អានតែ properties មួយក្រុមដែលកំណត់ទុក ហើយ overhead ក្នុងមួយ run ស្ថិតក្នុងកម្រិត milliseconds និង KB។ ដូច្នេះវាអាចរត់លើ traffic ទាំងអស់ដោយមិនចាំបាច់ sampling ហើយអ្នកប្រើស្ទើរមិនមានអារម្មណ៍ថាមានផលប៉ះពាល់។

Features ត្រូវមានស្ថេរភាព។ ការសិក្សាមិនជ្រើស parameters ដែលអ្នកប្រើអាចកែបានទេ ប៉ុន្តែជ្រើស underlying structures ដែល browser កំណត់ដោយខ្លួនឯង។ Browser version នីមួយៗមាន JavaScript engine ខុសគ្នា ហើយចំនួន API និង properties ដែលភ្ជាប់នឹង object នីមួយៗមានភាពខុសគ្នាបន្តិចតាម version។ ការសិក្សាប្រើចន្លោះ Chrome 110 ដល់ Chrome 114 សម្រាប់ប្រៀបធៀប៖ ប្រព័ន្ធរាប់ properties របស់ objects សំខាន់ 28 ហើយប្រៀបធៀបលទ្ធផលជាមួយ version ដែល browser ប្រកាស។ បើមិនត្រូវគ្នា មានន័យថាការប្រកាស និងឥរិយាបថពិត មិនមកពី technical stack ដូចគ្នា។

Labels ត្រូវអាចទុកចិត្តបាន។ Environment ដែលសាកល្បងនីមួយៗត្រូវបានភ្ជាប់ទៅ production traffic ដូចគ្នា និងវាយតម្លៃដោយ rules ដូចគ្នា ខណៈក្រុម control គឺឥរិយាបថធម្មតារបស់អ្នកប្រើពិត។ ដូច្នេះលទ្ធផលមិនមែនជាការវាយតម្លៃផ្អែកលើអារម្មណ៍ថា “មើលទៅពិត” ឬអត់ទេ ប៉ុន្តែថាតើ traffic នោះអាចត្រូវបានបំបែកក្រោម rules ដូចគ្នាឬអត់។

សូចនាករសម្រាប់វាយតម្លៃថាការសម្ដែងមានភាពពិតកម្រិតណា

ការវាស់វែងក្នុងការសិក្សាអាចបែងចែកជាបួនប្រភេទ។

• ភាពស្របគ្នា៖ version ដែល browser ប្រកាស ត្រូវគ្នាជាមួយរចនាសម្ព័ន្ធ underlying objects ឬអត់? នេះជាសូចនាករស្នូល និងពិបាកក្លែងបន្លំជាងគេ ព្រោះការកែ string មួយមិនអាចប្តូរចំនួន objects និង properties ក្នុង engine ទៅជាមួយគ្នាបានទេ។
• អត្រារកឃើញ៖ ការសិក្សាបានធ្វើតេស្តលម្អិតលើដំណោះស្រាយ 4 ហើយអត្រារកឃើញស្ថិតពី 67% ដល់ 84%។
• គម្លាតពីឧបករណ៍ពិត៖ ក្រោម decision rules ដូចគ្នា browser ធម្មតាមាន risk score 0 ខណៈដំណោះស្រាយដែលសាកល្បងមានមធ្យមពី 8.85 ដល់ 11.66។ Score នេះបង្ហាញចម្ងាយពី real distribution មិនមែនជាអារម្មណ៍ផ្ទាល់ខ្លួនថាស្រដៀងប៉ុណ្ណានោះទេ។
• លទ្ធភាពបំបែក៖ តើអាចបំបែក tested traffic ចេញពី normal traffic បានឬអត់? ប្រភេទដែលមិនអាចបំបែកបាន បង្ហាញថាក្រោមវិធីសាស្ត្រនេះ មិនឃើញ behavioral gap ជាមួយ browser ពិត។

ក្នុងចំណោមសូចនាករបួន សូចនាករទីមួយគឺជាមូលហេតុ ហើយបីសូចនាករបន្ទាប់គឺជាលទ្ធផលរបស់វា។

ប្រភេទលទ្ធផលទាំងបួនខុសគ្នាត្រង់ណា

ការសិក្សាបែងចែកដំណោះស្រាយដែលបានសាកល្បងជាបួនប្រភេទ ដោយផ្អែកលើ underlying implementation។

ប្រភេទទីមួយ low-level features មិនត្រូវគ្នាជាមួយ browser version ពិតដែលគេស្គាល់ណាមួយទេ ដូច្នេះមិនមាន engine ពិតដែលត្រូវគ្នា។ ការស្កេនសាមញ្ញអាចបង្ហាញ mismatch បានភ្លាម។

ប្រភេទទីពីរ environment មាន fingerprint features ពិត ប៉ុន្តែពេលប្តូរ identity មានតែ surface-level declaration ប្តូរ ខណៈ underlying engine នៅដដែល។ នេះជារូបមន្តដែលជួបញឹកញាប់បំផុតក្នុងការសិក្សា។ អាចប្រៀបបានថានាមប័ណ្ណសរសេរថា version ថ្មី ប៉ុន្តែសំឡេងនៅតែដូច version ចាស់។ បញ្ហាមិនមែនថា parameter នីមួយៗត្រូវបាន tune ល្អប៉ុណ្ណាទេ ប៉ុន្តែជាគម្លាតរវាង declaration និង behavior ហើយការរកឃើញជាច្រើនកើតចេញពីគម្លាតនេះ។

ប្រភេទទីបី underlying engine ប្តូរជាមួយ identity។ Environment ប្រកាស version ណា ក៏ដំណើរការ engine ដែលត្រូវនឹង version នោះ ដូច្នេះ consistency នៅតែមាន ហើយ detector នេះមិនអាចបំបែក traffic បាន។ Paper ក៏បញ្ជាក់ថា ការរកឃើញប្រភេទនេះត្រូវការវិធី detection ស្មុគស្មាញជាងនេះ។

ប្រភេទទីបួនមិនកែ browser ទេ។ Browser ពិតត្រូវបានដំណើរការនៅក្នុង virtual machine ហើយបន្ទាប់មក load target configuration។ ដោយសារ browser ពិតជារបស់ពិត detector មិនអាចបំបែកបាន ប៉ុន្តែ operational cost ខ្ពស់ និងពិបាក scale។

ភាពខុសគ្នារវាងប្រភេទទាំងបួនមិនស្ថិតនៅចំនួន parameters ទេ ប៉ុន្តែស្ថិតនៅថា declaration និង behavior មកពី technical base ដូចគ្នាឬអត់។

គន្លឹះអនុវត្តសម្រាប់ជ្រើស environment solution

ចំណុចផ្តោតរបស់ detection បានផ្លាស់ពីការអាន declaration ទៅការផ្ទៀងផ្ទាត់ behavior ដូច្នេះ surface-level parameters ដែលអាចកែបាន ផ្តល់អត្ថប្រយោជន៍កាន់តែតិច។ ក្នុងការវាយតម្លៃជាក់ស្តែង៖

• សួរអំពី underlying layer មិនមែនតែ parameter list។ ពេលប្តូរ declared version តើ layer ខាងក្រោមប្តូរតាមដែរឬទេ? Fingerprints ត្រូវបានបង្កើតស្វ័យប្រវត្តិជាការរួមបញ្ចូលពិត ឬត្រូវបានប្រមូល values ដោយដៃ?
• ប្រៀបធៀប environments ជាមួយគ្នា។ បើ environments ជាច្រើនត្រឡប់ low-level features ស្រដៀងគ្នាខ្លាំង នោះ isolation មិនទាន់ពេញលេញ។
• ដាក់ consistency មុន differentiation។ Features ដែលផ្ទុយគ្នាខាងក្នុងកាន់តែច្រើនត្រូវបាន tune នោះ exposure surface កាន់តែធំ។
• ការឆ្លងកាត់ generic detection page មិនមានន័យថា platform នឹងទទួលស្គាល់ environment ទេ។ ការផ្ទៀងផ្ទាត់ចុងក្រោយគួរប្រើ traffic ពិតបរិមាណតិចសម្រាប់សាកល្បងដោយខ្លួនឯង។

បញ្ហាស្នូលរបស់ environment isolation គឺធ្វើឱ្យ environment នីមួយៗឯករាជ្យ និងស្របគ្នាខាងក្នុង។ នេះហើយជាអ្វីដែល PurpleMark កំពុងដោះស្រាយ។ ទាំង detection និង anti-detection គួរត្រូវបានប្រើក្នុងព្រំដែន compliance ដែលសមស្រប; តម្លៃពិតរបស់ការសិក្សានេះគឺផ្តល់មូលដ្ឋានមានភស្តុតាងសម្រាប់ការវាយតម្លៃ មិនមែនធ្វើចំណាត់ថ្នាក់ថាផលិតផលណាល្អ ឬអាក្រក់នោះទេ។