Safari 17 की उन्नत audio fingerprinting सुरक्षा को बायपास करना

 (fingerprint.com)
1 पॉइंट द्वारा GN⁺ 2024-03-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Safari 17 प्राइवेट मोड में हर Audio API sample में random noise जोड़कर audio fingerprint को अस्थिर करता है, लेकिन FingerprintJS ने इसे कम करने वाले नए fingerprint algorithm से इसका जवाब दिया है
  • पुराना तरीका 500 audio samples के योग को identifier के रूप में इस्तेमाल करता था, इसलिए Safari के noise की रेंज browsers के बीच के अंतर से बड़ी हो गई और stability खो गई
  • नया तरीका उसी audio sample की noise copies बड़ी संख्या में बनाता है और (min+max)/2 तथा significant-figure rounding से values के उतार-चढ़ाव को कम करता है
  • square OscillatorNode, DynamicsCompressorNode, BiquadFilterNode को जोड़कर browsers के बीच अंतर बढ़ाया गया, और चुने गए browsers के 3396वें sample का न्यूनतम अंतर 0.0014% तक बढ़ाया गया
  • नया algorithm FingerprintJS 4.2.0 से पुराने audio fingerprint की जगह ले चुका है, और computation time 1.5~2 गुना बढ़ता है, लेकिन low-end devices पर भी कम समय में पूरा हो जाता है

Safari 17 audio fingerprint को कैसे अस्थिर करता है

  • Audio fingerprinting में browser के Audio API और OfflineAudioContext से audio signal render किया जाता है, फिर samples को जोड़कर एक identifier number बनाया जाता है
  • यह identifier cookies हटाने या incognito mode में जाने पर भी नहीं बदलता, इसलिए इसमें stability होती है, लेकिन बहुत से users एक ही value साझा कर सकते हैं, इसलिए uniqueness बहुत अधिक नहीं होती
  • Safari 17 की advanced fingerprinting protection डिफ़ॉल्ट रूप से private mode में चालू होती है और normal mode में बंद रहती है, और यह desktop तथा mobile दोनों पर लागू होती है
  • यह protection Screen API और Canvas API को भी प्रभावित करती है, लेकिन यहाँ केवल Audio API पर चर्चा है
  • protection चालू होने पर Safari हर audio sample पर अलग-अलग random noise multiply करता है
    • noise लागू होने के बाद sample sample*(1-magnitude) और sample*(1+magnitude) के बीच होता है
    • distribution uniform distribution है
    • Safari का development जारी है, इसलिए implementation details समय के साथ बदल सकती हैं

Audio API के वे बिंदु जहाँ noise लागू होता है

  • Safari कई interfaces पर noise लागू करता है जहाँ audio signal पढ़ा जा सकता है
  • noise हर बार लागू होने पर बदलता है, इसलिए Safari 17 private mode में audio fingerprint हर calculation पर बदल जाता है
  • M1 MacBook Air के Safari 17 में fingerprint 124.03516~124.04545 के बीच बदलता है, और अंतर लगभग 0.008% है
  • browsers के बीच पुराने audio fingerprints का सबसे छोटा अंतर 0.0000023% था, जो Safari के noise range से बहुत छोटा है
  • noise हटाने के लिए values को decimal के एक अंक स्तर तक round करना पड़ेगा, लेकिन 6 digits से कम छोड़ने पर कुछ browsers को अलग करना मुश्किल हो जाता है और uniqueness घट जाती है

नए algorithm के 3 चरण

  • FingerprintJS का नया audio fingerprint algorithm Safari द्वारा जोड़े गए noise को कम करने के लिए तीन चरणों से गुजरता है
    • noise का variance कम करना
    • browser identifier numbers के बीच distance बढ़ाना
    • बचे हुए noise को rounding से हटाना
  • पुराना audio fingerprint 500 audio samples का योग था, इसलिए हर sample में uniform-distribution noise जुड़ने पर पूरा fingerprint noise normal distribution के करीब आ जाता है
  • normal distribution का mean बहुत सारे samples के average से estimate करना पड़ता है, लेकिन uniform distribution का mean min और max से (min+max)/2 के जरिए कम samples में अधिक सटीकता से estimate किया जा सकता है
  • experiment code में समान precision condition पर normal distribution के लिए 524,288 samples चाहिए थे, जबकि uniform distribution के लिए 4,096 samples पर्याप्त थे
  • नया तरीका summed fingerprint की जगह सिर्फ एक single audio sample इकट्ठा करता है ताकि uniform-distribution noise को संभाला जा सके
  • इस बदलाव के कारण नया fingerprint पुराने fingerprint के साथ compatible नहीं है, और visitor identifier खोए बिना switch करने के लिए अलग approach चाहिए

उसी audio sample की noise copies बनाना

  • AudioBuffer instance पर getChannelData को कई बार call करने का तरीका काम नहीं करता
    • noise हर AudioBuffer instance पर सिर्फ एक बार लागू होता है
    • उसी instance का getChannelData वही signal लौटाता है
  • पूरे audio signal generation process को कई बार चलाने से बहुत सारे AudioBuffer instances बनाए जा सकते हैं, लेकिन fingerprint calculation के लिए यह बहुत धीमा है
    • 6,000 noise samples के लिए M1 MacBook पर सबसे तेज़ समय 7 seconds था
    • 60,000 पर Safari काम पूरा नहीं कर पाया
  • बेहतर तरीका यह है कि ऐसा AudioBuffer instance बनाया जाए जो उसी audio signal को repeat करे
    • पहला audio signal render किया जाता है, लेकिन getChannelData call नहीं किया जाता
    • फिर एक लंबा दूसरा OfflineAudioContext बनाया जाता है और original signal को AudioBufferSourceNode के रूप में इस्तेमाल किया जाता है
    • loop, loopStart, loopEnd से original signal के एक हिस्से को दोहराया जाता है
    • repeat होने के बाद Safari noise जोड़ता है, इसलिए उसी audio sample की अलग-अलग noise वाली copies मिलती हैं
  • इस तरीके से केवल 2 बार audio rendering करके ज़रूरी संख्या में noise copies बनाई जा सकती हैं
  • noise पूरी तरह गायब नहीं होता, लेकिन original audio sample की तुलना में variance कम हो जाता है
    • 8,192 copies: 100 runs में range 0.000387%, M1 MacBook पर 2.6ms
    • 65,536 copies: 0.0000123%, 4.1ms
    • 262,144 copies: 0%, 7.5ms

browsers के बीच audio sample का अंतर बढ़ाना

  • copies की संख्या कम करने से performance बेहतर होती है, लेकिन result variance बढ़ता है, इसलिए browsers के बीच audio sample का अंतर बढ़ाने के लिए base signal बदला गया
  • कई built-in audio nodes पर प्रयोग करने के बाद signal generation chain, जो browsers के बीच sample difference बढ़ाती है, यह रही
  • audio signal के 3396वें sample में browsers के बीच सबसे बड़ा अंतर मिला, और यह कई browsers के सभी samples की तुलना करके पाया गया
  • चुने गए browser sample set में इस नए sample का सबसे छोटा अंतर 0.0014% था
    • यह पुराने fingerprint के सबसे छोटे अंतर 0.0000023% से बड़ा है
    • इसी वजह से अधिक coarse noise removal और rounding लागू की जा सकती है

rounding से fingerprint को स्थिर करना

  • single sample का noise range छोटा होने पर भी value अब भी बदलती रहती है, इसलिए इसे final fingerprint के रूप में इस्तेमाल करने के लिए rounding ज़रूरी है
  • noise absolute value पर नहीं, बल्कि audio sample value के सापेक्ष लागू होता है, इसलिए decimal places के बजाय significant figures के आधार पर rounding की जाती है
  • चुने गए browsers को अलग करने के लिए 5 significant figures पर्याप्त थे, लेकिन सभी browsers और भविष्य के बदलावों की पुष्टि संभव नहीं है, इसलिए अधिक digits का उपयोग किया गया
  • Safari 17 private mode में rounding precision के अनुसार stabilization के लिए ज़रूरी copies की संख्या इस प्रकार है
    • 6 significant figures: 15,000, Safari 17 on M1 MacBook warm पर 3ms
    • 7 significant figures, लेकिन last digit को 5 के multiple पर round करना: 30,000, 4ms
    • 7 significant figures, लेकिन last digit को nearest even पर round करना: 70,000, 6ms
    • 7 significant figures या अधिक: 400,000, 12ms
  • अंतिम चयन 7 significant figures का है, लेकिन last digit को 0 या 5 बनाया जाता है, और stability बढ़ाने के लिए copies की संख्या 40,000 तक बढ़ाई गई
  • इस तरह round की गई संख्या Safari 17 की advanced fingerprinting protection चालू होने पर भी न बदलने वाला नया audio fingerprint बन जाती है
  • नए fingerprint का uniqueness पुराने audio fingerprint के बराबर माना गया है

performance और execution constraints

  • empty page पर warm browser में नया algorithm आम तौर पर पुराने की तुलना में धीमा है
    • MacBook Air 2020 Safari 17.3: पुराना 2ms, नया तरीका 4ms
    • MacBook Air 2020 Chrome 120: पुराना 5ms, नया तरीका 8ms
    • iPhone 13 mini Safari 17.3: पुराना 8ms, नया तरीका 12ms
    • Galaxy J7 Prime Chrome 120: पुराना 33ms, नया तरीका 45ms
    • BrowserStack Windows 11 Firefox 121: पुराना 10ms, नया तरीका 18ms
  • नए algorithm की performance पुराने की तुलना में 1.5~2 गुना खराब होती है, लेकिन low-end devices पर भी calculation time छोटा रहता है
  • browser कुछ काम OfflineAudioRender thread को सौंप देता है, इसलिए audio fingerprint calculation के अधिकतर समय page responsive रहता है
  • Web Audio API को web workers में इस्तेमाल नहीं किया जा सकता, इसलिए audio fingerprint को worker में calculate नहीं किया जा सकता
  • performance बेहतर करने के लिए user agent string से Safari 17 या उससे ऊपर की पहचान की जा सकती है, और नया algorithm केवल Safari 17+ पर इस्तेमाल किया जा सकता है, जबकि दूसरे browsers पर पुराना algorithm रखा जा सकता है

Tor और Brave का अंतर

  • Tor Web Audio API को पूरी तरह disable कर देता है, इसलिए audio fingerprinting संभव नहीं है
  • Brave, Safari 17 की तरह audio signal में noise जोड़ता है, लेकिन उसका तरीका अलग है
  • Safari हर audio sample पर अलग random value multiply करता है
  • Brave एक बार fudge factor नाम का random multiplier बनाता है और वही value सभी audio samples पर multiply करता है
    • यह value page के भीतर बनी रहती है
    • यह केवल नए normal session या incognito session में बदलती है
  • Brave में चाहे जितनी भी audio sample copies बनाई जाएँ, सभी copies पर वही noise लागू होता है, इसलिए Safari के लिए इस्तेमाल की गई mathematical noise-removal method काम नहीं करती
  • हालांकि, Brave के लिए पुरानी noise-removal method अब भी काम करती है, और browsers के बीच fingerprint difference बढ़ाने वाली नई signal-generation method error tolerance बढ़ा सकती है

FingerprintJS में लागू करना

  • नया audio fingerprint algorithm FingerprintJS में पुराने तरीके की जगह ले चुका है, और यह पहली बार 4.2.0 में जारी किया गया
  • पूरा implementation code FingerprintJS के GitHub repository में है
  • audio fingerprint open-source library द्वारा browser fingerprint बनाते समय इस्तेमाल किए जाने वाले कई signals में से एक है
  • FingerprintJS browser से मिलने वाले हर signal को बिना सोचे-समझे शामिल नहीं करता, बल्कि हर signal की stability और uniqueness का अलग विश्लेषण करके fingerprint accuracy पर उसके प्रभाव का आकलन करता है
  • audio fingerprint को uniqueness में थोड़े योगदान, लेकिन ऊँची stability के कारण, overall fingerprint accuracy को थोड़ा बढ़ाने वाले signal के रूप में आंका गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-11
Hacker News टिप्पणियाँ

  • ऑनलाइन उपयोगकर्ताओं की पहचान करने की एक और दिलचस्प तकनीक GPU fingerprinting है, जिसे 2022 में "DrawnApart" कोडनेम के साथ पेश किया गया था
    इसमें WebGL से GPU execution units की संख्या और गति गिनी जाती है, और vertex rendering पूरा होने का समय तथा stall function processing जैसी चीज़ें मापी जाती हैं

    1. https://www.bleepingcomputer.com/news/security/researchers-u...
    • ब्राउज़र को डिफ़ॉल्ट रूप से software renderer इस्तेमाल करना चाहिए, और hardware GPU render path खोलते समय साइट को माइक्रोफ़ोन या कैमरा की तरह उपयोगकर्ता से अनुमति माँगनी चाहिए

  • आजकल खासकर side-channel attacks में दिलचस्पी को देखें तो, डेटा से लीक होने वाले मानों में uniform noise जोड़ने का तरीका लगभग तय है कि काम नहीं करेगा
    क्योंकि ज़्यादा samples इकट्ठा करके noise हटाया जा सकता है। समझ नहीं आता Safari ने यह क्यों जोड़ा। यह fingerprinting को ज़्यादा झंझट वाला बना सकता है, लेकिन इस लेख की तरह आख़िरकार किसी न किसी रूप में इसे पार किया जा सकना ही लगता है

    • मुझे लगता है Apple की आजकल की काफ़ी privacy features मार्केटिंग के ज़्यादा क़रीब हैं
      तकनीकी रूप से वे प्रभावी हैं या नहीं, उससे ज़्यादा अहम यह हो गया है कि आम लोगों को एक भरोसेमंद कहानी सुनाई जा सके; यह privacy theater जैसा लगता है

  • क्या कोई समझा सकता है कि आख़िर नतीजे अलग क्यों आते हैं? उदाहरण के लिए, audio fingerprinting संभव ही क्यों है, यह जानना चाहता हूँ

    • लगता है मुख्य बात यह है कि Web Audio API में ऐसे algorithms हैं जो बहुत सारे गणितीय operations करते हैं, हर ब्राउज़र उन्हें थोड़ा अलग तरह से implement करता है, और सही output operating system और CPU पर भी निर्भर करता है
      Web Audio API से छोटा signal बनाया जाए तो सभी ब्राउज़र लगभग एक जैसा result देते हैं, लेकिन बहुत छोटे फ़र्क़ों का इस्तेमाल करके उन्हें अलग-अलग पहचाना जा सकता है
    • यह WebGL में इस्तेमाल होने वाली मिलती-जुलती तकनीक जैसा है, जहाँ PC के graphics card drivers और hardware से काफ़ी entropy निकलती है
      अफ़सोस की बात है कि इसे रोकने के लिए ब्राउज़र डेवलपर्स को audio buffer processing में noise जोड़ना पड़ता है
    • मेरे दिमाग़ में भी पहले यही सवाल आया था, और यहाँ इस पर ज़्यादा विस्तार से बात की गई है: https://fingerprint.com/blog/audio-fingerprinting/#why-the-a...
      संक्षेप में, एक ही codebase के अंदर भी अलग-अलग code paths, जैसे SIMD variants, सूक्ष्म रूप से अलग floating-point results पैदा कर सकते हैं। लगता है यह इस बात से जुड़ा है कि floating-point arithmetic, जितना लोग सोचते हैं उससे ज़्यादा, operation order जैसी चीज़ों के प्रति संवेदनशील होती है
    • इसकी वजह implementation details और compiler optimizations होने की संभावना ज़्यादा है। उदाहरण के लिए, floating-point addition में commutativity लागू नहीं होती
      इसलिए एक ही algorithm और एक ही formula को सही तरह से implement करने पर भी results थोड़ा अलग आ सकते हैं

  • अगर मैं ग़लत हूँ तो सुधारें। यहाँ fingerprinting bypass के सफल होने की वजह मुझे Web Audio API spec में OscillatorNode anti-aliasing को इस तरह खुला छोड़ने वाले फ़ैसले तक जाती दिखती है
    "ऐसी aliasing से बचने के लिए implementation कई practical approaches अपना सकते हैं। approach चाहे जो हो, ideal discrete-time digital audio signal गणितीय रूप से अच्छी तरह परिभाषित है। implementation का tradeoff CPU usage के हिसाब से implementation cost और इस ideal के कितने क़रीब पहुँचा जा सकता है, इनके बीच है। implementations से उम्मीद की जाती है कि वे इस ideal को हासिल करने के लिए कुछ हद तक सावधानी बरतेंगी, लेकिन low-end hardware पर कम quality और कम cost वाले approaches पर विचार करना भी उचित है।"
    मेरी नज़र में इसका मतलब है कि यहाँ exploit किया गया OscillatorNode output ब्राउज़रों के बीच, और शायद एक ही ब्राउज़र में अलग hardware पर भी, लगभग निश्चित रूप से deterministic नहीं है। यह non-determinism उस anti-aliasing approach पर आधारित है जिसे ब्राउज़र चुनता है, या उसी ब्राउज़र के भीतर hardware के आधार पर चुने जाने वाले अलग-अलग paths पर। इसमें उसी anti-aliasing algorithm में बदलाव या tweaks भी शामिल हैं
    समझ नहीं आता anti-aliasing को ब्राउज़र पर क्यों छोड़ा गया। high-quality audio apps या libraries तो अपने generate किए गए signal में aliasing avoidance को पूरी तरह control करना चाहेंगी और built-in oscillator का इस्तेमाल नहीं करेंगी। दूसरी तरफ, अगर कोई web app किसी भी मनमाने anti-aliasing algorithm और उससे पैदा होने वाले browser-specific differences को स्वीकार कर सकती है, तो संभव है उसे यह भी ज़्यादा फ़र्क़ न पड़े कि algorithm hardcoded SIMD instructions में है या 20MB के JavaScript Web Audio helper framework में
    1: https://webaudio.github.io/web-audio-api/#OscillatorNode
    सोचता हूँ क्या यहाँ वही समाधान लागू किया जा सकता है जो Hixie ने HTML5 parser को standardize करते समय अपनाया था। यानी किसी domain expert से काफ़ी अच्छा काम करने वाला, सटीक और deterministic anti-aliasing algorithm तय कराया जाए, और फिर सभी ब्राउज़र वही इस्तेमाल करें। मापने लायक performance loss शायद सिर्फ़ उन Web Audio API tutorials में दिखेगा जो built-in anti-aliased oscillator से signal generate करते हैं

    • high-quality anti-aliasing महँगा पड़ता है
      इसलिए implementations को यह तय करने की गुंजाइश देनी होती है कि वे उपलब्ध compute resources, battery वगैरह के हिसाब से कितना खर्च करना चाहती हैं

  • ब्राउज़र में node-graph audio API डालना बेवकूफ़ी थी। सिर्फ़ AudioWorklet होना चाहिए था

    • क्या Mozilla द्वारा प्रस्तावित audio API ज़्यादा simple नहीं था? जहाँ तक मुझे पता है, लोग ज़्यादा rich API और कम latency चाहते थे, इसलिए वह Google वाले प्रस्ताव से पीछे रह गया
      https://web.archive.org/web/20120505042746/https://developer...
    • आपको ऐसा क्यों लगता है?

  • घिनौना

    • मैं भी बिल्कुल यही सोचता हूँ। दिलचस्प है, लेकिन घिनौना।
      समझ नहीं आता कि Audio API शुरू से ही website permission के बिना क्यों इस्तेमाल की जा सकती है। लगता है इसे "यह साइट sound device का इस्तेमाल करना चाहती है" जैसे एक साधारण dialog से आसानी से ठीक किया जा सकता है
    • इससे यह सवाल उठता है कि क्या हमें मौजूदा network stack को अगले 100 साल तक इस्तेमाल करते रहना चाहिए।
      इंटरनेट के मौजूदा रूप ने personal computing के सपने को बहुत हद तक बिगाड़ दिया है। वजह यह है कि कंपनियाँ और राज्य, व्यक्तियों की तुलना में बहुत ज़्यादा असममित रूप से शक्तिशाली हैं। क्या मेरी technology को मेरी स्पष्ट मंज़ूरी के बिना server पर data भेज पाने में सक्षम होना चाहिए?
    • सही है। यकीन नहीं होता कि ये लोग इस पर गर्व करते हैं।
      दूसरी तरफ, browser cache साफ़ करके और VPN चालू करके मैंने इसे मुझे नए visitor के रूप में गलत पहचानते देखा। फिर भी business model घटिया है
    • क्योंकि यह fingerprint.com है, इसमें एक तरह की विडंबना लगी। यह कुछ वैसा है जैसे कोई वेबसाइट tax burden से बचने वाले loophole को लोकप्रिय बना दे, और फिर दुनिया घिन के साथ प्रतिक्रिया करे और उस loophole को बंद कर दे।
      चाहे इसे आशावादी नज़रिए से ही क्यों न देखें, इस तरह की research को सार्वजनिक करना और सामने लाना बहुत मूल्यवान है। अगर कोई लेख यह बताए कि किसी खास brand का हरा backpack चोरी में मदद करता है, तो मैं इस डर से ज़्यादा कि सब लोग और चोरी करेंगे, इस संभावना को ज़्यादा महत्व दूँगा कि दुकानदार उस तरीके को बेहतर पहचानने लगेंगे

  • हर sample में random value जोड़ने के बजाय, Safari शायद हर घंटे बदलने वाली key पर आधारित deterministic noise जोड़ सकता है।
    अगर इसे audio sample और key के function के रूप में बनाया जाए, तो उसी session में noise एक जैसा रहेगा, लेकिन एक घंटे बाद tracking के लिए बेकार हो जाएगा

    • अगर ऐसे 10 samples का average ले लिया जाए, तो आखिर में यह device की असली value के काफ़ी करीब पहुँच जाएगा। samples जितने ज़्यादा होंगे, उतना ही करीब पहुँचेगा।
      इसे ठीक करने के लिए information leak को ही हटाना होगा; सिर्फ random variation की layer से ढक देना काफ़ी नहीं है
    • अगर जोड़ा गया noise origin के आधार पर deterministic हो, तो क्या वह मदद नहीं करेगा? तब excessive sampling करके भी उसका average निकालकर हटाया नहीं जा सकेगा।
      उदाहरण के लिए RNG_SEED = HMAC_SHA256(PERSISTENT_SECRET,Location.origin) जैसा तरीका

  • अब मैं सचमुच JavaScript बंद करके web देखने वाला "वही आदमी" बनने के लिए तैयार हूँ

    • दिक्कत यह है कि सिर्फ ऐसा "वही आदमी" बन जाना ही पहचान के लिए 10 bits से ज़्यादा दे सकता है।
      अगर कहीं और से कुछ bits और खुरच ली जाएँ, तो uniquely identify किया जा सकता है। फिर भी मेरे हिसाब से इन लोगों को बाकी adtech industry के साथ Golgafrinchan Ark B पर बिठाकर भेज देना चाहिए
    • शुभकामनाएँ। आजकल web पर ठीक-ठाक पुराने ढंग का HTML कितना कम है, यह हैरान करने वाला है।
      हाल ही में जिस website पर गया था, उसमें markup तो था, लेकिन उसे HTML में compile करके static रूप से serve नहीं किया गया था; बल्कि client-side JavaScript से render किया गया था। WTF
    • साथ आओ, बस सच में करके देखो। uMatrix नाम का एक शानदार Firefox extension है, जिससे JavaScript को न सिर्फ site के हिसाब से बल्कि subdomain के हिसाब से भी आसानी से बंद किया जा सकता है, और जिन sites पर JavaScript के बिना चीज़ें टूट जाती हैं वहाँ फिर से चालू करना भी आसान है
    • शुभकामनाएँ। मैंने हाल ही में यह लड़ाई छोड़ दी। क्योंकि जिन लगभग सभी websites पर मैं जाता हूँ, वहाँ content देखने के लिए फिर से JavaScript चालू करनी पड़ती थी।
      सिर्फ Cloudflare जैसे DDoS checks ही नहीं, अब तो वे चीज़ें भी JavaScript से load होती हैं जो page HTML के अंदर होनी चाहिए
    • ठीक इसी वजह से Tor Browser में JavaScript बंद होनी चाहिए।
      जैसे-जैसे इंटरनेट और ज़्यादा शत्रुतापूर्ण होता जा रहा है, यह विकल्प उतना ही सही साबित होता जा रहा है

  • यह बात ठीक से समझ नहीं आती कि यह तरीका कुछ हज़ार से ज़्यादा unique combinations कैसे बना सकता है।
    browser type × browser version × operating system version × accelerator version × … और क्या है? remotely unique कहे जाने लायक variation काफ़ी नहीं लगती

    • Combinatorics बड़ी निर्मम मालकिन है

  • क्या यह तकनीक audio processing में hardware, driver, और operating system के फ़र्क के आधार पर fingerprint बनाती है, या सिर्फ browser software को देखती है?
    मुझे लगता है कि निचले graphics device के फ़र्क को उजागर करने वाली ऐसी कोई मिलती-जुलती तकनीक पहले रही है या अभी भी है

    • तरीका मिलता-जुलता है। audio algorithms अक्सर operating system functions को call करते हैं और CPU optimizations का इस्तेमाल करते हैं।
      लेख में दिया गया एक उदाहरण fast Fourier transform (FFT) है। हर operating system में इस function का एक version होता है, लेकिन समय के साथ उसे optimize किया जाता रहता है, और उपलब्ध SIMD instructions के आधार पर वह अक्सर हर CPU पर अलग तरह से काम करता है