Vượt qua cơ chế bảo vệ chống nhận dạng vân tay âm thanh nâng cao của Safari 17

 (fingerprint.com)
1 điểm bởi GN⁺ 2024-03-11 | 1 bình luận | Chia sẻ qua WhatsApp
  • Safari 17 làm nhiễu vân tay âm thanh trong chế độ riêng tư bằng cách thêm nhiễu ngẫu nhiên vào từng mẫu Audio API, nhưng FingerprintJS đã đáp lại bằng một thuật toán vân tay mới để giảm tác động này
  • Cách cũ dùng tổng của 500 mẫu âm thanh làm mã định danh, nên biên độ nhiễu của Safari lớn hơn khác biệt giữa các trình duyệt và làm mất tính ổn định
  • Cách mới tạo hàng loạt bản sao có nhiễu của cùng một mẫu âm thanh và giảm dao động giá trị bằng (min+max)/2 cùng làm tròn theo chữ số có nghĩa
  • Bằng cách nối square OscillatorNode, DynamicsCompressorNode, BiquadFilterNode, nhóm đã tăng khác biệt giữa các trình duyệt và nâng chênh lệch tối thiểu ở mẫu thứ 3396 của các trình duyệt được chọn lên 0.0014%
  • Thuật toán mới đã thay thế vân tay âm thanh cũ từ FingerprintJS 4.2.0, và dù thời gian tính toán tăng 1.5~2 lần, nó vẫn hoàn tất nhanh ngay cả trên thiết bị cấu hình thấp

Cách Safari 17 làm nhiễu vân tay âm thanh

  • Nhận dạng vân tay âm thanh là cách dùng Audio API và OfflineAudioContext của trình duyệt để render tín hiệu âm thanh, rồi cộng các mẫu lại thành một số định danh duy nhất
  • Mã định danh này có tính ổn định vì không thay đổi dù xóa cookie hay chuyển sang chế độ ẩn danh, nhưng độ độc nhất không cao vì nhiều người dùng có thể cùng chia sẻ một giá trị
  • Cơ chế bảo vệ nhận dạng vân tay nâng cao của Safari 17 được bật mặc định trong chế độ riêng tư và tắt trong chế độ thường, áp dụng cho cả desktop lẫn mobile
  • Cơ chế bảo vệ này cũng ảnh hưởng đến Screen API và Canvas API, nhưng ở đây chỉ đề cập Audio API
  • Khi cơ chế bảo vệ được bật, Safari sẽ nhân từng mẫu âm thanh với nhiễu ngẫu nhiên riêng
    • Mẫu đã áp nhiễu sẽ nằm giữa sample*(1-magnitude) và sample*(1+magnitude)
    • Phân bố là phân bố đều
    • Do Safari vẫn đang tiếp tục phát triển, chi tiết triển khai có thể thay đổi theo thời gian

Những điểm trong Audio API được áp nhiễu

  • Safari áp nhiễu ở nhiều giao diện có thể đọc tín hiệu âm thanh
  • Vì nhiễu thay đổi mỗi lần áp dụng, nên trong chế độ riêng tư của Safari 17, vân tay âm thanh sẽ khác đi mỗi lần tính toán
  • Trên Safari 17 của M1 MacBook Air, vân tay dao động trong khoảng 124.03516~124.04545, chênh lệch khoảng 0.008%
  • Chênh lệch nhỏ nhất giữa các vân tay âm thanh cũ theo từng trình duyệt là 0.0000023%, nhỏ hơn rất nhiều so với biên độ nhiễu của Safari
  • Để loại bỏ nhiễu phải làm tròn ở mức một chữ số thập phân, nhưng nếu giữ lại ít hơn 6 chữ số thì sẽ khó phân biệt một số trình duyệt, làm giảm độ độc nhất

3 bước của thuật toán mới

  • Thuật toán vân tay âm thanh mới của FingerprintJS đi qua ba bước để giảm nhiễu do Safari thêm vào
    • Giảm phương sai của nhiễu
    • Tăng khoảng cách giữa các số định danh trình duyệt
    • Loại bỏ phần nhiễu còn lại bằng làm tròn
  • Vân tay âm thanh cũ là tổng của 500 mẫu âm thanh, nên khi mỗi mẫu được cộng nhiễu phân bố đều, nhiễu của toàn bộ vân tay sẽ gần với phân bố chuẩn
  • Trung bình của phân bố chuẩn phải được ước lượng bằng trung bình của nhiều mẫu, nhưng trung bình của phân bố đều có thể được ước lượng chính xác với ít mẫu hơn bằng (min+max)/2 dùng min và max
  • Trong mã thử nghiệm, với cùng điều kiện độ chính xác, phân bố chuẩn cần 524,288 mẫu còn phân bố đều chỉ cần 4,096 mẫu
  • Cách mới bỏ vân tay dạng tổng hợp và chỉ thu thập một mẫu âm thanh đơn lẻ để xử lý nhiễu phân bố đều
  • Vì thay đổi này, vân tay mới không tương thích với vân tay cũ, và muốn chuyển đổi mà không mất mã định danh khách truy cập thì cần cách tiếp cận riêng

Tạo các bản sao có nhiễu của cùng một mẫu âm thanh

  • Cách gọi getChannelData nhiều lần trên một thực thể AudioBuffer không hoạt động
    • Nhiễu chỉ được áp một lần cho mỗi thực thể AudioBuffer
    • getChannelData trên cùng một thực thể sẽ trả về cùng một tín hiệu
  • Có thể tạo nhiều thực thể AudioBuffer bằng cách chạy toàn bộ quá trình sinh tín hiệu âm thanh nhiều lần, nhưng cách này quá chậm để tính vân tay
    • 6,000 mẫu nhiễu mất nhanh nhất 7 giây trên M1 MacBook
    • Với 60,000 mẫu thì Safari không thể hoàn thành tác vụ
  • Cách tốt hơn là tạo một thực thể AudioBuffer lặp lại cùng tín hiệu âm thanh
    • Render tín hiệu âm thanh đầu tiên nhưng không gọi getChannelData
    • Tạo OfflineAudioContext thứ hai dài hơn và dùng tín hiệu gốc làm AudioBufferSourceNode
    • Dùng loop, loopStart, loopEnd để lặp lại một phần của tín hiệu gốc
    • Sau khi lặp, Safari mới thêm nhiễu nên có thể thu được các bản sao của cùng một mẫu âm thanh nhưng với nhiễu khác nhau
  • Cách này tạo ra số lượng bản sao nhiễu cần thiết chỉ với 2 lần render âm thanh
  • Nhiễu không biến mất hoàn toàn, nhưng phương sai nhỏ hơn mẫu âm thanh gốc
    • 8,192 bản sao: phạm vi 0.000387% sau 100 lần chạy, 2.6ms trên M1 MacBook
    • 65,536 bản sao: 0.0000123%, 4.1ms
    • 262,144 bản sao: 0%, 7.5ms

Tăng khác biệt mẫu âm thanh giữa các trình duyệt

  • Nếu giảm số bản sao thì hiệu năng tốt hơn nhưng phương sai kết quả tăng, vì vậy nhóm đã thay đổi tín hiệu cơ sở để làm tăng khác biệt mẫu âm thanh giữa các trình duyệt
  • Sau khi thử nhiều audio node tích hợp, chuỗi sinh tín hiệu làm chênh lệch mẫu giữa các trình duyệt lớn hơn là
  • Mẫu thứ 3396 của tín hiệu âm thanh có khác biệt lớn nhất giữa các trình duyệt; đây là giá trị được tìm ra bằng cách so sánh mọi mẫu trên nhiều trình duyệt
  • Trong tập mẫu trình duyệt được chọn, chênh lệch nhỏ nhất của mẫu mới này là 0.0014%
    • Lớn hơn chênh lệch nhỏ nhất 0.0000023% của vân tay cũ
    • Nhờ đó có thể áp dụng khử nhiễu và làm tròn thô hơn

Ổn định hóa vân tay bằng làm tròn

  • Dù biên độ nhiễu của một mẫu đơn lẻ đã nhỏ đi, giá trị vẫn còn dao động, nên cần làm tròn để dùng làm vân tay cuối cùng
  • Vì nhiễu được áp tương đối theo giá trị mẫu âm thanh chứ không phải giá trị tuyệt đối, nên việc làm tròn dựa trên chữ số có nghĩa thay vì số chữ số thập phân
  • 5 chữ số có nghĩa là đủ để phân biệt các trình duyệt được chọn, nhưng vì không thể kiểm tra toàn bộ trình duyệt và mọi thay đổi trong tương lai, nhóm dùng nhiều chữ số hơn
  • Trong chế độ riêng tư của Safari 17, số bản sao cần để ổn định theo từng mức làm tròn là
    • 6 chữ số có nghĩa: 15,000, khoảng 3ms trên Safari 17 chạy warm trên M1 MacBook
    • 7 chữ số có nghĩa nhưng làm tròn chữ số cuối về bội số của 5: 30,000, 4ms
    • 7 chữ số có nghĩa nhưng làm tròn chữ số cuối về số chẵn gần nhất: 70,000, 6ms
    • Từ 7 chữ số có nghĩa trở lên: 400,000, 12ms
  • Lựa chọn cuối cùng là 7 chữ số có nghĩa nhưng ép chữ số cuối thành 0 hoặc 5, đồng thời tăng số bản sao lên 40,000 để cải thiện độ ổn định
  • Con số sau khi làm tròn này trở thành vân tay âm thanh mới, không thay đổi ngay cả khi bật cơ chế bảo vệ nhận dạng vân tay nâng cao của Safari 17
  • Vân tay mới được đánh giá là có độ độc nhất tương đương vân tay âm thanh cũ

Hiệu năng và các ràng buộc khi chạy

  • Trên trình duyệt warm với một trang trống, thuật toán mới nhìn chung chậm hơn cách cũ
    • MacBook Air 2020 Safari 17.3: cách cũ 2ms, cách mới 4ms
    • MacBook Air 2020 Chrome 120: cách cũ 5ms, cách mới 8ms
    • iPhone 13 mini Safari 17.3: cách cũ 8ms, cách mới 12ms
    • Galaxy J7 Prime Chrome 120: cách cũ 33ms, cách mới 45ms
    • BrowserStack Windows 11 Firefox 121: cách cũ 10ms, cách mới 18ms
  • Hiệu năng của thuật toán mới kém hơn 1.5~2 lần so với trước, nhưng thời gian tính toán vẫn ngắn ngay cả trên thiết bị cấu hình thấp
  • Do trình duyệt giao một phần công việc cho luồng OfflineAudioRender, trang vẫn giữ được độ phản hồi trong phần lớn thời gian tính vân tay âm thanh
  • Web Audio API không dùng được trong web workers, nên không thể tính vân tay âm thanh trong worker
  • Để cải thiện hiệu năng, có thể kiểm tra chuỗi user agent để xác định Safari 17 trở lên, chỉ dùng thuật toán mới trên Safari 17+ và giữ thuật toán cũ cho các trình duyệt khác

Khác biệt với Tor và Brave

  • Tor vô hiệu hóa hoàn toàn Web Audio API nên không thể nhận dạng vân tay âm thanh
  • Brave cũng thêm nhiễu vào tín hiệu âm thanh như Safari 17, nhưng cách làm khác
  • Safari nhân từng mẫu âm thanh với một giá trị ngẫu nhiên riêng biệt
  • Brave tạo một hệ số ngẫu nhiên gọi là fudge factor một lần rồi nhân cùng giá trị đó cho mọi mẫu âm thanh
    • Giá trị này được giữ nguyên trong cùng một trang
    • Chỉ thay đổi khi bắt đầu phiên thường mới hoặc phiên riêng tư mới
  • Trên Brave, dù tạo bao nhiêu bản sao mẫu âm thanh thì tất cả vẫn nhận cùng một nhiễu, nên phương pháp khử nhiễu toán học dành cho Safari không hoạt động
  • Tuy vậy, cách khử nhiễu Brave trước đây vẫn tiếp tục hoạt động, và phương pháp sinh tín hiệu mới để tăng khác biệt vân tay giữa các trình duyệt có thể mở rộng biên độ sai số chấp nhận được

Áp dụng trong FingerprintJS

  • Thuật toán vân tay âm thanh mới đã thay thế cách cũ trong FingerprintJS và được công bố lần đầu ở 4.2.0
  • Toàn bộ mã triển khai có trong kho GitHub của FingerprintJS
  • Vân tay âm thanh là một trong nhiều tín hiệu mà thư viện mã nguồn mở dùng để tạo vân tay trình duyệt
  • FingerprintJS không đưa vào mọi tín hiệu có thể lấy được từ trình duyệt một cách vô điều kiện, mà phân tích riêng độ ổn định và độ độc nhất của từng tín hiệu để đánh giá tác động của nó đến độ chính xác của vân tay
  • Vân tay âm thanh được xem là tín hiệu chỉ đóng góp ít vào độ độc nhất nhưng có độ ổn định cao, nên giúp cải thiện nhẹ độ chính xác của toàn bộ vân tay

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-11
Các ý kiến trên Hacker News

  • Một kỹ thuật thú vị khác để nhận diện người dùng trên mạng là lấy dấu vân tay GPU, được giới thiệu năm 2022 với tên mã "DrawnApart"
    Cách này dùng WebGL để đếm số lượng và tốc độ của các đơn vị thực thi GPU, đo thời gian hoàn tất render đỉnh và xử lý các hàm stall, v.v.

    1. https://www.bleepingcomputer.com/news/security/researchers-u...
    • Về cơ bản, trình duyệt nên dùng trình render phần mềm, và khi mở đường render bằng GPU phần cứng thì trang web phải yêu cầu quyền của người dùng như với micro hay camera

  • Dạo này, nhất là nhìn vào mức độ quan tâm dành cho tấn công kênh kề, tôi cho rằng cách thêm nhiễu đồng đều vào giá trị làm rò rỉ dữ liệu gần như chắc chắn không hiệu quả
    Vì chỉ cần thu thập thêm nhiều mẫu là có thể loại bỏ nhiễu. Không hiểu vì sao Safari lại đưa cách này vào. Nó có thể khiến việc lấy dấu vân tay phiền phức hơn, nhưng như bài viết này cho thấy, rốt cuộc nhìn chung vẫn có thể bị vượt qua dưới một hình thức nào đó

    • Tôi cho rằng khá nhiều tính năng quyền riêng tư gần đây của Apple gần với marketing hơn
      Nó có cảm giác như một kiểu sân khấu hóa quyền riêng tư, nơi việc có một câu chuyện nghe hợp lý để kể với công chúng trở nên quan trọng hơn hiệu quả kỹ thuật thực sự

  • Ngay từ đầu, có ai giải thích được vì sao kết quả lại khác nhau không? Chẳng hạn tôi thắc mắc vì sao lấy dấu vân tay âm thanh lại khả thi

    • Điểm cốt lõi dường như là trong Web Audio API có các thuật toán thực hiện nhiều phép toán, cách triển khai ở mỗi trình duyệt hơi khác nhau, và kết quả chính xác còn phụ thuộc vào hệ điều hành và CPU
      Khi tạo một tín hiệu nhỏ bằng Web Audio API, mọi trình duyệt cho kết quả gần như giống nhau, nhưng có thể tận dụng những khác biệt rất nhỏ để phân biệt chúng
    • Tương tự các kỹ thuật dùng trong WebGL, tôi nghĩ nó giống việc có rất nhiều entropy đến từ driver card đồ họa của PC và chính phần cứng
      Thật đáng tiếc khi các nhà phát triển trình duyệt phải thêm nhiễu vào xử lý bộ đệm âm thanh để ngăn chuyện này
    • Đó cũng là điều đầu tiên tôi nghĩ tới, và phần này nói chi tiết hơn: https://fingerprint.com/blog/audio-fingerprinting/#why-the-a...
      Tóm lại, ngay cả trong cùng một codebase cũng có các đường mã khác nhau, ví dụ các biến thể SIMD, có thể tạo ra kết quả dấu phẩy động khác nhau rất tinh vi. Có vẻ điều này liên quan đến việc phép toán dấu phẩy động nhạy cảm hơn tưởng tượng với thứ tự thực hiện phép toán, v.v.
    • Rất có thể là do chi tiết triển khai và tối ưu hóa của compiler. Ví dụ phép cộng dấu phẩy động không có tính giao hoán
      Ngay cả khi triển khai đúng cùng một thuật toán và cùng một công thức, kết quả vẫn có thể khác nhau đôi chút

  • Nếu tôi sai thì xin sửa giúp. Lý do việc vượt qua bảo vệ lấy dấu vân tay ở đây thành công có vẻ quy về lựa chọn trong đặc tả Web Audio API khi để ngỏ cách xử lý anti-aliasing của OscillatorNode như thế này
    "Có nhiều cách tiếp cận thực tế mà một implementation có thể thực hiện để tránh aliasing này. Bất kể cách tiếp cận nào, tín hiệu âm thanh số thời gian rời rạc lý tưởng đều được định nghĩa rõ ràng về mặt toán học. Các đánh đổi trong triển khai nằm ở chi phí triển khai xét theo mức dùng CPU và mức độ trung thành với lý tưởng đó. Dù kỳ vọng implementation sẽ chú ý ở một mức nào đó để đạt được lý tưởng này, nhưng trên phần cứng cấp thấp thì việc cân nhắc các cách tiếp cận có chất lượng thấp hơn và chi phí thấp hơn là hợp lý."
    Theo tôi, điều này có nghĩa là output của OscillatorNode bị khai thác ở đây gần như chắc chắn không mang tính quyết định giữa các trình duyệt, thậm chí trong cùng một trình duyệt nhưng trên phần cứng khác nhau. Tính không quyết định dựa trên phương pháp anti-aliasing mà trình duyệt chọn, hoặc các đường xử lý khác nhau được chọn trong cùng trình duyệt tùy phần cứng. Cũng bao gồm cả các thay đổi hay chỉnh sửa đối với cùng một thuật toán anti-aliasing
    Tôi không rõ vì sao anti-aliasing lại được giao cho trình duyệt. Các ứng dụng hay thư viện âm thanh chất lượng cao sẽ muốn kiểm soát hoàn toàn cách tránh aliasing của tín hiệu do chúng tạo ra và sẽ không dùng oscillator mặc định. Ngược lại, nếu một web app chấp nhận một thuật toán anti-aliasing tùy ý cùng các khác biệt theo từng trình duyệt kéo theo, thì rất có khả năng nó cũng không quá quan tâm thuật toán đó là lệnh SIMD được hard-code hay một framework trợ giúp JavaScript Web Audio nặng 20MB
    1: https://webaudio.github.io/web-audio-api/#OscillatorNode
    Tôi cũng tự hỏi liệu có thể áp dụng ở đây giải pháp giống cách Hixie đã dùng khi chuẩn hóa parser HTML5 không: để một chuyên gia trong lĩnh vực chỉ định một thuật toán anti-aliasing chính xác, mang tính quyết định và hoạt động đủ tốt, rồi sau đó tất cả trình duyệt dùng thuật toán đó. Có lẽ suy giảm hiệu năng có thể đo được chỉ xuất hiện ở mức các tutorial Web Audio API tạo tín hiệu bằng oscillator anti-aliasing mặc định

    • Anti-aliasing chất lượng cao rất tốn kém
      Vì vậy họ muốn để implementation quyết định sẽ dùng bao nhiêu tài nguyên tính toán tùy theo tài nguyên sẵn có, pin, v.v.

  • Việc đưa API âm thanh dạng đồ thị node vào trình duyệt là một quyết định ngu ngốc. Đáng ra chỉ nên có AudioWorklet

    • API âm thanh mà Mozilla từng đề xuất không đơn giản hơn sao? Theo tôi biết thì mọi người muốn một API phong phú hơn và độ trễ thấp hơn, nên đề xuất phía Google đã thắng thế
      https://web.archive.org/web/20120505042746/https://developer...
    • Vì sao bạn nghĩ vậy?

  • Thật kinh tởm

    • Tôi cũng nghĩ đúng như vậy. Thú vị nhưng kinh tởm
      Ngay từ đầu tôi không hiểu tại sao API âm thanh lại có thể được dùng mà không cần quyền của website. Có vẻ có thể dễ dàng sửa bằng một hộp thoại đơn giản kiểu “Trang này muốn sử dụng thiết bị âm thanh”
    • Khiến tôi tự hỏi liệu chúng ta có thể tiếp tục dùng network stack hiện nay trong 100 năm tới không
      Internet ở dạng hiện tại đã phá hỏng rất nhiều giấc mơ về điện toán cá nhân. Vì doanh nghiệp và nhà nước quá mạnh một cách bất đối xứng so với cá nhân. Công nghệ của tôi có nên được phép gửi dữ liệu lên server mà không có sự chấp thuận rõ ràng không?
    • Đúng vậy. Không thể tin nổi là những người này lại tự hào về chuyện này
      Mặt khác, sau khi tôi xóa cache trình duyệt và bật VPN, nó đã nhận nhầm tôi là khách truy cập mới. Dù vậy, business model vẫn hèn hạ
    • Vì là fingerprint.com nên tôi nghĩ cũng có chút mỉa mai. Nó giống như xuất hiện một website phổ biến hóa một lỗ hổng để né gánh nặng thuế, khiến cả thế giới thấy kinh tởm và đóng lỗ hổng đó lại
      Ngay cả nếu hiểu theo hướng lạc quan, việc công bố và đưa những nghiên cứu như thế này ra ánh sáng có giá trị rất lớn. Thay vì lo rằng mọi người sẽ trộm nhiều hơn chỉ vì có bài viết nói một mẫu ba lô xanh của một thương hiệu nào đó giúp ích cho việc trộm cắp, tôi nghiêng về khả năng các cửa hàng sẽ nhận ra thủ đoạn đó tốt hơn

  • Thay vì cộng một giá trị ngẫu nhiên vào từng mẫu, Safari có lẽ có thể cộng nhiễu xác định dựa trên một khóa thay đổi mỗi giờ
    Nếu biến nó thành hàm của mẫu âm thanh và khóa, nhiễu sẽ giống nhau trong cùng một phiên, nhưng trở nên vô dụng cho việc theo dõi sau một giờ

    • Nếu lấy trung bình 10 mẫu như vậy, cuối cùng nó sẽ tiến gần đến giá trị thực của thiết bị. Càng nhiều mẫu thì càng gần hơn
      Muốn sửa chuyện này thì phải loại bỏ chính việc rò rỉ thông tin, chứ chỉ che bằng một lớp sai lệch ngẫu nhiên là không đủ
    • Nếu nhiễu được thêm vào mang tính xác định theo origin thì chẳng phải sẽ có ích sao? Như vậy dù lấy mẫu quá mức rồi tính trung bình cũng không thể loại bỏ được
      Ví dụ như RNG_SEED = HMAC_SHA256(PERSISTENT_SECRET,Location.origin)

  • Giờ tôi thật sự đã sẵn sàng trở thành “người đó”, người tắt JavaScript để duyệt web

    • Vấn đề là chỉ riêng việc trở thành “người đó” như vậy cũng có khả năng trao hơn 10 bit cho việc định danh
      Chỉ cần moi thêm vài bit ở chỗ khác là có thể bị định danh duy nhất. Dù vậy, theo tiêu chuẩn của tôi thì có thể tống những người này cùng phần còn lại của ngành adtech lên Golgafrinchan Ark B
    • Chúc may mắn. Thật đáng ngạc nhiên là ngày nay trên web còn ít HTML cũ tử tế đến mức nào
      Một website tôi ghé gần đây có dùng markup, nhưng không biên dịch nó thành HTML rồi phục vụ tĩnh, mà render bằng JavaScript phía client. WTF
    • Cùng làm đi, thực sự làm được đấy. Có một extension Firefox rất hay tên là uMatrix, cho phép dễ dàng tắt JavaScript không chỉ theo từng site mà còn theo từng subdomain, và cũng dễ bật lại ở những site bị hỏng nếu không có JavaScript
    • Chúc may mắn. Gần đây tôi đã bỏ cuộc trong trận chiến này. Vì trên hầu hết mọi website tôi truy cập, tôi đều phải bật lại JavaScript để xem nội dung
      Không chỉ các bước kiểm tra DDoS kiểu Cloudflare, mà giờ ngay cả những thứ đáng lẽ phải nằm trong HTML của trang cũng được load bằng JavaScript
    • Chính vì lý do này mà Tor Browser nên tắt JavaScript
      Internet càng ngày càng trở nên thù địch, lựa chọn này càng ngày càng đúng hướng

  • Tôi không hiểu lắm vì sao cách này có thể tạo ra hơn vài nghìn tổ hợp duy nhất
    Loại trình duyệt × phiên bản trình duyệt × phiên bản hệ điều hành × phiên bản bộ tăng tốc × … còn gì nữa? Có vẻ không đủ biến thể để gọi là duy nhất từ xa

    • Tổ hợp học là một bà chủ khắc nghiệt

  • Kỹ thuật này lấy dấu vân tay dựa trên khác biệt về phần cứng, driver, hệ điều hành trong xử lý âm thanh, hay chỉ nhìn vào phần mềm trình duyệt?
    Tôi nghĩ từng có, hoặc vẫn còn, các kỹ thuật tương tự làm lộ khác biệt của thiết bị đồ họa cấp thấp

    • Cách làm tương tự. Các thuật toán âm thanh thường gọi hàm hệ điều hành và tận dụng tối ưu hóa CPU
      Một trong những ví dụ trong bài là biến đổi Fourier nhanh (FFT). Mọi hệ điều hành đều có phiên bản của hàm này, nhưng chúng thường được tối ưu hóa theo thời gian, và trong nhiều trường hợp hoạt động khác nhau tùy CPU dựa trên các lệnh SIMD khả dụng