21 điểm bởi GN⁺ 2025-06-04 | 11 bình luận | Chia sẻ qua WhatsApp
  • Đã bị phanh phui rằng các ứng dụng lớn như Meta (Facebook), Yandex đã sử dụng cổng cục bộ (127.0.0.1) trên Android để bí mật chia sẻ định danh và cookie giữa trình duyệt web và ứng dụng native
  • Các script Facebook Pixel, Yandex Metrica được nhúng trong website đã trực tiếp truyền phiên duyệt web và định danh từ trình duyệt Android sang ứng dụng native (Facebook, Instagram, các ứng dụng thuộc hệ Yandex), khiến việc nhận diện người dùngkhử ẩn danh trở nên khả thi
  • Cách làm này vượt qua toàn bộ các biện pháp bảo vệ quyền riêng tư hiện có như xóa cookie, chế độ ẩn danh, thiết lập quyền, đặt lại ID quảng cáo, và nếu ứng dụng độc hại chỉ cần lắng nghe đúng cổng thì còn có thể thu thập lịch sử truy cập trình duyệt
  • Sau khi được công bố ngày 3/6/2025, phía Facebook đã gỡ bỏ phần lớn đoạn mã liên quan, nhưng kỹ thuật này đã được sử dụng trong nhiều năm trên hàng trăm triệu thiết bị Android trên toàn thế giới. Yandex vẫn liên tục dùng phương thức tương tự từ năm 2017
  • Các trình duyệt lớn như Chrome, Firefox, Brave đã đưa vào biện pháp chặn khẩn cấp, nhưng do giới hạn mang tính cấu trúc của nền tảng nên vẫn thiếu giải pháp gốc rễ hoàn chỉnh, làm nổi bật nhu cầu tăng cường bảo mật Android IPC và mạng cục bộ

Disclosure: Kỹ thuật theo dõi web-ứng dụng bí mật thông qua Localhost

  • Nhóm nghiên cứu phát hiện Meta và Yandex đã nhắm tới hàng tỷ người dùng Android, bằng cách để ứng dụng native mở sẵn các cổng cục bộ cố định (ví dụ: 12580~12585, 29009~30103) trong nền và giao tiếp với JavaScript chạy trên web
  • Nhờ vậy, cookie, metadata và lịch sử sử dụng từ trình duyệt web được truyền sang ứng dụng native, sau đó kết hợp với thông tin tài khoản ứng dụng và Android Advertising ID để liên kết danh tính người dùng với các lượt truy cập web

How does this work?

Lạm dụng cổng cục bộ trên Android

  • Trên Android OS, mọi ứng dụng chỉ cần quyền INTERNET là có thể mở socket trên 127.0.0.1 (loopback)
  • Trình duyệt cũng có thể truy cập giao diện này mà không cần sự đồng ý riêng từ người dùng
  • JavaScript được nhúng trong website có thể gửi và nhận dữ liệu giữa trình duyệt và ứng dụng native bằng Web API tiêu chuẩn

Cách Meta/Facebook Pixel liên kết web-ứng dụng

  • Khi JavaScript Meta Pixel được tải trong trình duyệt Android, giá trị cookie _fbp sẽ được gửi tới ứng dụng native qua gói STUN của WebRTC (UDP cổng 12580–12585)
  • Các ứng dụng Facebook, Instagram trên thiết bị (tùy phiên bản như 515.0.0.23.90/382.0.0.43.84) lắng nghe tại các cổng đó, nhận giá trị _fbp từ trình duyệt rồi gửi tiếp lên máy chủ riêng bằng GraphQL
  • _fbp là cookie quan trọng được cài trên khoảng 25% trong top một triệu website; trước đây nó tách biệt theo từng website nên khó theo dõi chéo, nhưng với cách này có thể ghép nhiều _fbp của một người dùng vào cùng một tài khoản
  • Sau tháng 5/2025, script còn bổ sung phương thức WebRTC TURN để né kỹ thuật SDP Munging
  • Cookie _fbp có thời hạn 90 ngày và cực kỳ phổ biến, được dùng trên khoảng 25% các website hàng đầu
  • Sau khi các trình duyệt lớn như Chrome phản ứng, đoạn mã đã bị gỡ ngày 3/6

Cách Yandex Metrica liên kết web-ứng dụng

  • Script Yandex Metrica từ năm 2017 đã gửi request qua HTTP(S) tới các cổng cục bộ (29009, 29010, 30102, 30103, v.v.)
  • Các ứng dụng Yandex (Yandex Maps, Navigator, Browser, Search, v.v.) mở sẵn các cổng này và phản hồi bằng dữ liệu chứa Android Advertising ID (AAID) được mã hóa Base64 cùng các định danh thiết bị khác, UUID, v.v.
  • Script trong trình duyệt thu thập thông tin này rồi gửi ngược về máy chủ Yandex, hoàn tất việc liên kết định danh giữa trình duyệt, ứng dụng và máy chủ
  • Tên miền yandexmetrica.com được phân giải về 127.0.0.1 để né phát hiện và che giấu luồng thu thập
  • Do sử dụng HTTP localhost, nếu một ứng dụng khác đang lắng nghe cùng cổng thì còn có nguy cơ làm lộ lịch sử truy cập website của người dùng

Rủi ro thực tế: rò rỉ lịch sử truy cập trình duyệt

  • Khi dùng giao tiếp cục bộ dựa trên HTTP, bất kỳ ứng dụng Android nào chỉ cần lắng nghe đúng cổng cũng có thể lấy được URL truy cập và lịch sử duyệt web
  • Nhóm nghiên cứu đã phát triển ứng dụng Proof-of-Concept và thử nghiệm trên Chrome, Firefox, Edge, qua đó chứng minh rằng private browsing và chế độ ẩn danh đều dễ bị ảnh hưởng
  • Chỉ một số trình duyệt như Brave, DuckDuckGo có thể phòng vệ nhờ danh sách chặn riêng và cơ chế yêu cầu người dùng đồng ý

Affected Sites

  • Meta Pixel: được dùng trên 5,8 triệu website; kết quả crawling thực tế quan sát thấy chia sẻ ID cục bộ tại 15 nghìn website ở EU và 17 nghìn website ở Mỹ trong top 100 nghìn website
  • Yandex Metrica: được dùng trên 3 triệu website; với cùng cách thức, xác nhận có giao tiếp cổng cục bộ tại 1.260 website ở EU và 1.312 website ở Mỹ
  • Trong số đó, phần lớn website còn tự động chạy theo dõi ngay cả khi không có quy trình xin đồng ý cookie

History

  • Yandex: bắt đầu dùng cổng HTTP/HTTPS từ năm 2017
  • Meta: chuyển dần từ HTTP vào tháng 9/2024, WebSocket vào tháng 11/2024, WebRTC STUN trong năm 2025 và TURN vào tháng 5

Abuse Vectors

  • Nguyên nhân chính là Android không có hạn chế truy cập socket localhost và chính sách sandbox còn thiếu chặt chẽ
  • Mọi biện pháp bảo vệ hiện có như thiết lập quyền, chế độ ẩn danh của trình duyệt, đặt lại ID quảng cáo đều bị vượt qua
  • Dù khó phân biệt với mục đích hợp pháp trong phát triển web, đây vẫn là một trường hợp đã được chứng minh về theo dõi trên diện rộng
  • Các trình duyệt như Chrome, Firefox, DuckDuckGo, Brave đang triển khai bản vá khẩn cấp, nhưng về căn bản vẫn cần tăng cường quyền hạn, cảnh báo, sandbox và chính sách IPC ở cấp độ nền tảng

Disclosure

  • Đã yêu cầu công bố có trách nhiệm và hợp tác với các nhà cung cấp trình duyệt như Chrome, Firefox, DuckDuckGo, Brave
  • Chrome (phiên bản 137), Firefox (phiên bản 138), Brave, v.v. đã áp dụng các biện pháp ngắn hạn như chặn cổng dễ bị khai thác, chặn SDP Munging
  • Về dài hạn, cần nhấn mạnh sự cần thiết của các cải tiến mang tính cấu trúc như kiểm soát truy cập mạng cục bộ, tăng cường sandbox, hướng dẫn người dùng
Trình duyệt Phiên bản Yandex Facebook Tình trạng ứng phó/chặn
Chrome 136.0+ Bị ảnh hưởng Bị ảnh hưởng Từ 137 chặn cổng và SDP munging, đang triển khai dần
Edge 136.0+ Bị ảnh hưởng Bị ảnh hưởng Chưa rõ (dựa trên Chromium)
Firefox 138.0.2 Bị ảnh hưởng Không bị ảnh hưởng(1) Chặn SDP munging, UDP sẽ được chặn sau
DuckDuckGo 5.233.0 Bị ảnh hưởng một phần(2,3) Không bị ảnh hưởng(2,3) Chặn dựa trên blocklist
Brave 1.78.102 Không bị ảnh hưởng(3,4) Không bị ảnh hưởng(3,4) Từ năm 2022 yêu cầu người dùng đồng ý với request localhost, áp dụng blocklist
  • 1: Chặn SDP Munging, cổng TURN vẫn chưa bị chặn (dự kiến áp dụng sau)
  • 2,3,4: Có nhiều lớp phòng vệ như blocklist, chặn cổng, yêu cầu người dùng đồng ý

Tình trạng nhận thức của người dùng và nhà vận hành

Nhà vận hành website

  • Tài liệu chính thức của Meta và Yandex chưa từng công khai phương thức này
  • Từ tháng 9/2024, trên diễn đàn nhà phát triển Facebook đã liên tục xuất hiện câu hỏi như "vì sao script Pixel lại truy cập localhost", nhưng không có phản hồi chính thức nào
  • Phần lớn nhà vận hành website và người dùng cuối đều không hề hay biết. Người dùng vẫn có thể bị theo dõi cả khi chưa đăng nhập, ở chế độ ẩn danh, hoặc đã xóa cookie

Người dùng phổ thông

  • Việc theo dõi hoạt động không phụ thuộc vào trạng thái đăng nhập
  • Chế độ ẩn danh, xóa cookie và các biện pháp bảo vệ khác đều bị vô hiệu hóa
  • Có nhiều trường hợp vẫn hoạt động cả trên website không có quy trình xin đồng ý cookie

Tóm tắt FAQ

  • Q: Vì sao Meta dừng phương thức này ngay sau khi bị công bố?
    A: Không có phản hồi chính thức; sau khi bị công bố, đã xác nhận việc gửi packet tới người dùng Android đã dừng lại
  • Q: Nghiên cứu đã được peer review chưa?
    A: Đã được một số tổ chức xác minh nhưng chưa qua phản biện học thuật; do quy mô lạm dụng nên quyết định công bố sớm
  • Q: Có được công khai trong tài liệu chính thức của Meta/Yandex không?
    A: Không có tài liệu kỹ thuật chính thức, chỉ có các câu hỏi trên diễn đàn nhà phát triển
  • Q: iOS hay nền tảng khác có bị ảnh hưởng không?
    A: Tính đến hiện tại mới xác nhận trên Android, nhưng về mặt kỹ thuật thì iOS/desktop/smart TV cũng có thể tiềm ẩn rủi ro

11 bình luận

 
dhy0613 2025-06-05

Thấy pin hao bất thường nên trước đây tôi đã xóa hết các ứng dụng bên Meta, hóa ra là có chuyện như thế này... Có lẽ tôi cũng phải dùng adb để xóa nốt các ứng dụng hệ thống được cài sẵn trên mấy máy Galaxy còn lại.

 
savvykang 2025-06-05

Tôi cũng không thể tin tưởng ứng dụng Meta nên không dùng, thay vào đó chỉ sử dụng bằng Chrome trong Thư mục bảo mật.

 
iolothebard 2025-06-05

Các loại framework được gọi là ứng dụng web lai, phần lớn đều chạy webserver localhost (dù mục đích thì khác nhau). Những thứ không giải quyết được qua thiết lập thư viện trình duyệt nhúng (WebKit...) hay tùy biến (phần web) sẽ được xử lý ở phía webserver chạy trên localhost (phần native). Hóa ra cũng có thể bị tận dụng theo cách này... tiếc thật.

 
jeiea 2025-06-05

Theo tôi, trong ứng dụng hybrid, cách giao tiếp thông thường giữa web và app là thông qua các API do hệ điều hành và phía trình duyệt cung cấp, còn gọi là bridge. Tôi cho rằng máy chủ web cục bộ không phải là thứ bắt buộc.
Lý do việc dùng máy chủ web cục bộ ở đó trở thành vấn đề, theo tôi, là vì nó có thể dẫn tới những lỗ hổng như việc truy cập vào cổng localhost từ Chrome ở chế độ ẩn danh để phá vỡ tính ẩn danh của người dùng. Nếu kỹ thuật này là bắt buộc trong ứng dụng hybrid thì... ứng dụng hybrid nên biến mất.

 
nemorize 2025-06-06

Việc mở và dùng một máy chủ web bên trong ứng dụng để xử lý các tính năng bắt buộc phải có tên miền, localStorage và những thứ tương tự nhìn chung là cách làm phổ biến.

 
ethanhur 2025-06-04

Nếu không trả tiền cho dịch vụ thì bản thân tôi chính là sản phẩm. Những nỗ lực theo dõi cá nhân thông qua ngày càng nhiều dữ liệu rồi sẽ chỉ tăng lên, và có vẻ như không thể đảo ngược xu hướng này. Chúng ta cần những lựa chọn thay thế tốt hơn, nhưng dưới chủ nghĩa tư bản thì thật khó nghĩ ra lựa chọn nào tốt hơn.

 
savvykang 2025-06-04

Tôi tò mò không biết liệu quyền truy cập localhost từ bên trong và bên ngoài Thư mục bảo mật trên Galaxy có được cô lập hay không

 
savvykang 2025-06-04

Không được cách ly nhỉ. Chạy Python http.server bằng Termux bên ngoài Thư mục bảo mật rồi truy cập bằng Chrome ở bên trong thì vẫn vào được.

 
forgotdonkey456 2025-06-05

Cái này chẳng phải là lỗ hổng bảo mật sao -_-??

 
jjpark78 2025-06-04

Có vẻ như đáp án đúng là không dùng SNS..

 
GN⁺ 2025-06-04
Ý kiến Hacker News
  • Nếu tóm tắt toàn bộ quy trình theo dõi mà Meta đang dùng theo cách tôi hiểu, nội dung tham khảo từ blog Localmess

    1. Khi người dùng đang đăng nhập vào ứng dụng Facebook hoặc Instagram, ứng dụng đó sẽ lắng nghe lưu lượng đi vào trên một cổng cụ thể ở chế độ nền
    2. Khi người dùng truy cập một trang web bằng trình duyệt trên điện thoại (ví dụ: something-embarassing.com), trang đó thường có nhúng Meta Pixel (theo bài viết, đã được cài trên hơn 5,8 triệu website)
      Ngay cả ở chế độ ẩn danh vẫn có thể bị theo dõi
    3. Tùy theo vị trí, website có thể yêu cầu sự đồng ý của người dùng; bài viết không giải thích chi tiết nhưng có lẽ là các “cookie banner” mà nhiều người bấm đồng ý theo quán tính
    4. Script Meta Pixel gửi cookie _fbp (chứa thông tin duyệt web) sang ứng dụng Instagram hoặc Facebook bằng kỹ thuật WebRTC (STUN) SDP Munging
      Phần này cũng không hiển thị trong công cụ dành cho nhà phát triển của trình duyệt
    5. Nếu ứng dụng đã ở trạng thái đăng nhập, Meta có thể liên kết hoạt động duyệt web “ẩn danh” với thông tin người dùng đã đăng nhập
      Ứng dụng sẽ gửi thông tin _fbp và ID người dùng lên máy chủ của Meta
      Ngoài ra còn có vài điểm đáng chú ý,
    • Cách chia sẻ ID từ web sang app này vượt qua các biện pháp bảo vệ quyền riêng tư thông thường như xóa cookie, chế độ ẩn danh, hay kiểm soát quyền trên Android

    • Thậm chí còn mở ra khả năng cho ứng dụng độc hại theo dõi hoạt động web của người dùng

    • Từ giữa tháng 5, script Meta Pixel cũng bắt đầu gửi cookie _fbp bằng cơ chế WebRTC TURN; cách này được đưa vào sau khi đội ngũ Chrome chặn SDP Munging

    • Tính đến ngày 2/6/2025, chưa quan sát thấy ứng dụng Facebook/Instagram thực sự nhận dữ liệu qua cổng mới đó

    • Nếu trường hợp sử dụng chính của WebRTC là lấy thông tin như IP nội bộ của người dùng để phá ẩn danh, thì tôi không hiểu vì sao tính năng như vậy lại có thể chạy mà không cần xin quyền riêng biệt

    • Ở một số quốc gia, việc truy cập các trang như something-embarassing.com có thể dẫn đến hậu quả nghiêm trọng hơn nhiều chứ không chỉ là xấu hổ

    • Tôi chưa hoàn toàn hiểu rõ, nhưng tự hỏi liệu chuyện này có bao gồm cả việc lợi dụng thông báo xin đồng ý cookie theo GDPR để theo dõi người dùng một cách bí mật hay không

  • Tôi chỉ muốn cấm hẳn quảng cáo và theo dõi trên internet
    Chính vì những thứ này mà quá nhiều thứ vô nghĩa bị đẩy ra đời
    Theo tôi thì tất cả chỉ là để các CEO mua thêm một chiếc du thuyền nữa

    • Reddit cũng thu thập fingerprint thiết bị khá nhiều
      Họ còn bán dữ liệu này để huấn luyện mô hình AI
      Tôi đoán rồi sẽ đến ngày họ tích cực bán cả dữ liệu riêng tư chỉ dùng được trong ứng dụng premium

    • Vấn đề còn lại là làm sao cấm được chuyện này, và làm sao chứng minh được ai đã vi phạm luật đó

    • Việc loại bỏ cookie bên thứ ba khỏi trình duyệt thực tế là bước đầu tiên khả thi nhất
      Nhưng Google đã dùng thế thống trị của Chrome để làm trật bánh việc này vào năm ngoái
      Có thể không trái luật, nhưng đó là hành vi thao túng thị trường phi đạo đức lẽ ra phải khiến người tiêu dùng nổi giận
      Có vẻ ban lãnh đạo Google lúc đầu tin rằng vẫn có thể giữ doanh thu mà không cần cookie; thực tế có thể là họ hoàn toàn không hiểu ý nghĩa của cookie, hoặc ngay từ đầu chưa từng có ý định loại bỏ chúng

    • Kiểu hành vi này đơn thuần là lòng tham
      Những nhà quản lý truyền thống thành công suốt hàng thế kỷ thường tránh sự ám ảnh quá mức với lợi ích cá nhân như vậy
      Ngay cả những lãnh đạo tạm ổn cũng thường có thể vượt lên trên kiểu hành xử thấp kém này để điều hành công ty tốt hơn
      Nhưng trong một thế giới chỉ còn lòng tham, có lẽ chỉ biết cười cho qua
      Thật tốt nếu có nhiều CEO vừa giỏi vừa trung thực hơn

    • Nói thêm về câu đùa “du thuyền của CEO”, thực ra đa số người tiêu dùng chọn mô hình quảng cáo vì họ thích dịch vụ/sản phẩm miễn phí
      Trên thực tế nếu có cả bản trả phí và bản có quảng cáo, bản có quảng cáo thường được chuộng hơn theo tỷ lệ 10:1
      Việc chặn quảng cáo lại còn làm tình hình tệ hơn — sự phản kháng thực sự nên là tẩy chay dịch vụ hoặc trả tiền trực tiếp cho phương án thay thế
      Tôi nghĩ các mô hình như BAT (Brave Attention Token), phân phối vi thanh toán trực tiếp cho website, hợp lý hơn
      Về lý thuyết, đó là cấu trúc: tôi trả tiền đúng theo mức sử dụng, và tôi là khách hàng thật sự chứ không phải nhà quảng cáo

  • Báo cáo sự cố thực tế: blog Localmess
    Google nói đang điều tra các trường hợp lạm dụng, nhưng trớ trêu là bản thân Google cũng đang theo dõi mọi người bằng nhiều side channel như tên Wi-Fi AP
    Các công ty ứng dụng lớn vẫn tiếp tục thu thập dữ liệu bằng những cách tương tự để né các giới hạn của hệ điều hành

  • Thêm một lý do nữa để không cài ứng dụng của Big Tech nếu có thể, và chỉ dùng website khi thật sự cần
    Website tuy chậm và bất tiện hơn, nhưng được sandbox nên an toàn hơn nhiều

    • Không rõ ứng dụng Meta nào đang mở cổng
      Ví dụ, điện thoại Samsung có nhiều ứng dụng Meta được cài sẵn, và kể cả khi xóa ứng dụng Facebook thì các dịch vụ ẩn như com.facebook.services vẫn có thể còn lại
      Những dịch vụ này chỉ có thể gỡ bằng công cụ cho nhà phát triển (ADB/UAD)
      Hoặc có thể chọn iPhone hoặc điện thoại Pixel
  • Thông tin kỹ thuật liên quan đến script Meta Pixel:
    Meta Pixel đã gửi dữ liệu qua HTTP cho tới tháng 10/2024, và ứng dụng Facebook/Instagram hiện vẫn đang chờ nhận trên cổng đó
    Chúng cũng đang chờ trên cổng 12388 mới, nhưng chưa phát hiện script nào gửi dữ liệu đến cổng này
    Vì vậy, có một sự tò mò mang tính khoa học(?) là liệu ứng dụng khác có thể gửi thông điệp giả đến cổng đó hay không

    • Tôi nghĩ có hai cách để làm nhiễu các tracker này
      Một là không gửi gì cả, hai là gửi thật nhiều dữ liệu giả
      Tôi cũng muốn có một thiết bị chia sẻ cookie theo dõi quảng cáo kiểu P2P
  • Tôi tự hỏi liệu việc theo dõi này có thể vượt qua giữa các profile hay không
    Nếu có thì đây là một vấn đề bảo mật cực lớn với doanh nghiệp
    Tôi đã thử chạy một server trên cổng 8080 bằng ứng dụng userland và thấy cả hai profile đều truy cập được
    Điều đó có nghĩa là ứng dụng bị nhiễm ở một profile có thể trao đổi dữ liệu với website được truy cập ở profile khác

    • Tuy nhiên, câu hỏi đặt ra là liệu chuyện này chỉ xảy ra khi website chủ động giao tiếp rõ ràng với một dịch vụ đang bind vào cổng local không có xác thực hay không
  • Tôi tự hỏi nếu cá nhân thu thập thông tin từ máy tính của người khác bằng cách này thì có thể bị xử theo CFAA (Computer Fraud and Abuse Act) hay không

    • Cách này đòi hỏi kiểm soát mã nguồn ở cả một phía (website đang truy cập) lẫn phía bên kia (ứng dụng đang chạy trên điện thoại)
      Nó không phải kiểu kỹ thuật hack ma thuật có thể tự động đánh cắp lịch sử trình duyệt bất kỳ
      Vì vậy khó mà coi đây là hack theo nghĩa rõ ràng, và kể cả khi Google/Meta theo dõi không có sự đồng ý thì cũng không thuộc CFAA

    • Thực ra dưới CFAA từng có người bị truy tố chỉ vì đơn giản dùng “xem mã nguồn trang” trong trình duyệt
      Có vẻ không phải hành vi phạm tội tự thân quan trọng bằng việc bạn đụng đến ai, và mối quan hệ mạng lưới xung quanh nó

    • Có thể bị xử phạt

  • Hệ thống ID này quá dễ bị lạm dụng, và tôi đoán Google cũng biết điều đó, biết rằng họ bắt buộc phải đặt ra quy định ngăn lạm dụng
    Đây là chuyện có thể dẫn tới án phạt nặng (cấm vĩnh viễn trên Play Store, hành động pháp lý, thậm chí truy tố hình sự)
    Nhưng trên thực tế, với công ty quá lớn như Meta thì gần như không thể áp đặt chế tài thực chất
    (Và ngay cả nếu không phải Meta, cũng có thể những động thái mờ ám như vậy đang được cơ quan tình báo hoặc thực thi pháp luật ngầm chấp thuận — rất khó để ngăn lại, thậm chí nói ra cũng không dễ)

    • Google và Apple sở hữu toàn bộ hệ điều hành
      Họ có hơn 50 cách tự theo dõi người dùng
      Các công ty khác cũng kiếm được rất nhiều tiền bằng cách đàm phán lại điều khoản chia sẻ dữ liệu người dùng với các tập đoàn lớn
      Các thỏa thuận đã được chốt, quyền cũng đã được cấp, chỉ là có một số người dùng đang làm ầm lên vì chuyện này mà thôi
  • Trên Firefox có thể chặn WebRTC bằng cách đổi tùy chọn media.peerconnection.enabled trong about:config thành false
    Kết hợp Netguard và Nebulo ở chế độ non-VPN có thể chặn các kết nối không cần thiết tới máy chủ Meta

  • Tôi nghĩ Liên minh châu Âu (EU) nên áp các mức phạt kỷ lục với những vấn đề như thế này
    Cũng nên có một loại thuế tăng lũy tiến thêm 1~X% mỗi lần tái phạm
    Và cần có cả một website để nhìn nhanh các vụ vi phạm của từng công ty

    • Meta dù mỗi năm đều nộp phạt vẫn ghi nhận khoảng 70 tỷ USD lợi nhuận ròng

    • Không chỉ phạt tiền, mà trong một số trường hợp còn cần biện pháp mạnh hơn, vì đã có những cá nhân bị bỏ tù vì các vi phạm nhẹ hơn nhiều