Khi ứng dụng yêu cầu quyền, nên có tùy chọn “cung cấp dữ liệu giả”.

 (archive.md)
1 điểm bởi GN⁺ 2023-07-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi ứng dụng yêu cầu quyền, HĐH không nên chỉ cho phép câu trả lời có/không đơn giản, mà cần thêm "tùy chọn cung cấp dữ liệu giả" cho mọi nhóm quyền
  • Nếu yêu cầu danh bạ thì cung cấp danh bạ giả được tạo sẵn, nếu yêu cầu truy cập micro thì cung cấp âm thanh môi trường ngẫu nhiên, nếu yêu cầu thông tin vị trí thì cung cấp tọa độ của một hòn đảo nhỏ 5×5m
  • Nếu chặn truy cập thì ứng dụng sẽ từ chối với lý do "vậy thì không dùng được", nhưng nếu đưa dữ liệu giả thì chỉ những dịch vụ đòi dữ liệu không cần thiết mới bị trừng phạt
  • Tẩy chay đòi hỏi người dùng phải chịu hy sinh cá nhân lớn nhưng chỉ gây tác động rất nhỏ tới doanh nghiệp, nên quan điểm ở đây là tuân thủ ác ý (malicious compliance) hiệu quả hơn tẩy chay
  • Điều này dẫn tới vấn đề quyền kiểm soát của người dùng: người dùng phải có thể kiểm soát ứng dụng và phần mềm hệ thống với tư cách quản trị viên của chính thiết bị mình sở hữu

Đề xuất cốt lõi — tùy chọn dữ liệu giả theo từng quyền

  • HĐH nên cung cấp cho mọi yêu cầu quyền, ngoài có/không, thêm lựa chọn "có, nhưng cung cấp dữ liệu giả" cho mọi danh mục
    • Yêu cầu danh bạ → cung cấp danh bạ giả được tạo ngẫu nhiên
    • Yêu cầu micro → cung cấp âm thanh môi trường ngẫu nhiên (random ambiance)
    • Yêu cầu vị trí → trả lời rằng bạn đang ở trên một hòn đảo nhỏ 5×5m
  • Nếu dịch vụ đòi dữ liệu không cần thiết, có thể đưa thông tin vô dụng vào cơ sở dữ liệu của họ để tạo hiệu ứng trừng phạt
  • Khác với chặn truy cập, dữ liệu giả khiến ứng dụng không thể phản ứng bằng cách báo "không sử dụng được", đồng thời vô hiệu hóa việc thu thập dữ liệu không cần thiết

Lập luận về ưu thế so với tẩy chay

  • Tẩy chay các ứng dụng cần dùng là một giao kèo bất lợi: người dùng phải chịu hy sinh cá nhân đáng kể trong khi với các tỷ phú thì đó chỉ là cú đánh khó nhận ra
    • Cấu trúc mà bên chiến đấu mất nhiều nhất vốn dĩ bất lợi cho người dùng
  • Quan điểm cho rằng cách bơm dữ liệu giả trao cho người dùng nhiều quyền lực hơn
  • Có câu diễn đạt rằng "tuân thủ ác ý (malicious compliance)" thú vị hơn tẩy chay

Các biện pháp hiện có được nhắc đến trong thảo luận

  • Giả mạo vị trí (location spoofing)

    • Trước đây, giả mạo vị trí chỉ khả dụng dưới dạng thiết lập toàn cục (global) và khó chọn theo từng ứng dụng
    • Trong cài đặt nhà phát triển của Android, có thể chỉ định một ứng dụng cụ thể làm ứng dụng vị trí mô phỏng (mock location), rồi áp dụng ở mức toàn cục
    • Firefox có các tiện ích mở rộng để giả mạo đủ loại dữ liệu như geolocation, nhưng chạy trực tiếp trên điện thoại sẽ hữu ích hơn
    • Đã có trường hợp lạm dụng trong Pokémon GO bằng dữ liệu vị trí giả, cho thấy điều này khả thi về mặt kỹ thuật

  • XPrivacyLua

    • Trên thiết bị đã root, công cụ này từng thực hiện chính xác điều người dùng muốn, nhưng cần Magisk (chỉnh sửa hệ thống)
    • Hiện nay nó đã ở trạng thái ngừng bảo trì và không tương thích với mọi thiết bị

  • Tính năng quyền mặc định của Android

    • Android vốn đã cho phép chọn quyền truy cập thông tin theo từng ứng dụng hoặc đặt hỏi lại mỗi lần
    • Tuy nhiên đây chỉ là cách chặn, không phải cung cấp dữ liệu giả

Ý tưởng mở rộng và ví dụ

  • Làm ô nhiễm dữ liệu bằng AI

    • Có đề xuất làm vô hiệu các data miner bằng cách cung cấp đệ quy những thông tin vô nghĩa
    • Ý tưởng còn tiến xa hơn tới việc dùng dữ liệu do AI tạo ra để làm ô nhiễm cả nội dung phục vụ huấn luyện AI

  • Đối phó theo dõi quảng cáo

    • Có nhắc tới AdNauseam (một bản fork của uBlock Origin), công cụ chặn quảng cáo đồng thời nhấp vào mọi quảng cáo để làm vô hiệu dữ liệu nhắm mục tiêu
    • Có đánh giá rằng các thử nghiệm trước đây tiêu tốn nhiều tài nguyên

  • Gây nhiễu hồ sơ theo dõi trên trình duyệt

    • Có những dịch vụ dùng trình duyệt và cookie để lướt nhanh qua nhiều trang web, gây nhiễu fingerprinting và theo dõi
    • Có thể chọn kiểu ngẫu nhiên hoặc theo mẫu hồ sơ (ví dụ: "duyệt web như một hippie 70 tuổi ở Ecuador")
    • Có nhắc tới trường hợp TrackThis do Mozilla tạo ra

Những giới hạn và lo ngại được nêu ra

  • Nếu nhập ngày sinh ngẫu nhiên, bạn sẽ nhận lời chúc mừng sinh nhật vào một ngày bất kỳ, nhưng sẽ phát sinh vấn đề là không biết mình đã dùng ngày nào trong câu hỏi bảo mật
    • Có ý kiến bổ sung rằng HĐH cần có thể cho người dùng biết các giá trị dữ liệu giả của chính họ
  • Khoảng 10 năm trước, đã từng xem xét đây như một ý tưởng startup, nhưng không tìm được luật sư có thể giúp xây dựng cách bảo vệ hợp pháp
  • Dự đoán rằng Google gần như chắc chắn sẽ không triển khai điều này vì các nhà phát triển thương mại sẽ rất e ngại
  • Có chỉ trích rằng nguyên nhân gốc rễ là cả Google lẫn Apple đều không muốn người dùng có quyền kiểm soát

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-07-09
Ý kiến Hacker News

  • Tôi ủng hộ ý tưởng “dữ liệu giả”, nhưng ứng dụng cũng nên bị yêu cầu xử lý một cách tử tế ngay cả khi người dùng từ chối quyền truy cập dữ liệu thật
    Hồi trước khi phát triển iOS, chính sách của Apple là không được trừng phạt người dùng hoặc thoát ứng dụng bằng exit() chỉ vì họ từ chối quyền, và ứng dụng vẫn phải tiếp tục chạy
    Còn xa hơn nữa, ứng dụng thậm chí không được yêu cầu “tài khoản” để chạy. Tôi nhớ hơn 10 năm trước công ty tôi từng đưa yêu cầu bắt buộc có tài khoản vào và đã bị App Store từ chối hoàn toàn hợp lý. Dạo này có vẻ lập trường đó đã nới lỏng, nhìn vào số lượng ứng dụng ngày càng nhiều bắt buộc phải có tài khoản

    • Câu “ứng dụng không thể yêu cầu tài khoản để chạy” hẳn đang thiếu một điều kiện quan trọng nào đó, hoặc tôi không hiểu ý của nó
      Ứng dụng ngân hàng, game online, ứng dụng Twitter ngày nay, hay các ứng dụng như Dropbox/Nextcloud thì làm sao hoạt động được nếu không có tài khoản
      Đúng là nhiều ứng dụng yêu cầu tài khoản chỉ là chiêu trò tiếp thị, nhưng một quy tắc chung như vậy có vẻ không thể áp dụng được
    • WhatsApp vẫn “trừng phạt” người dùng nếu từ chối quyền truy cập danh bạ. Nó ẩn toàn bộ tên và chỉ hiển thị số điện thoại, kể cả khi người kia đã đặt tên trong hồ sơ của họ
      Facebook/Meta thật rác rưởi
    • Dữ liệu cá nhân giả như danh bạ hay ảnh thì ổn, nhưng đến vị trí thì bắt đầu mơ hồ hơn
      Nếu chỉ để hiển thị vị trí của tôi trên bản đồ hoặc tìm doanh nghiệp gần đó thì có thể cấp dữ liệu giả
      Nhưng nếu là ứng dụng đo tốc độ Internet để lập bản đồ tốc độ theo từng nhà mạng, hoặc ứng dụng nơi người dùng báo cáo thời tiết địa phương để cải thiện dự báo, thì tôi nghĩ ứng dụng cũng nên được phép nói rằng “hãy cho vị trí chính xác hoặc đừng cho gì cả, chúng tôi không muốn vị trí giả”
      Nền tảng sẽ phải quyết định có dành ngoại lệ cho các ứng dụng nhận dữ liệu đóng góp từ người dùng mà có ảnh hưởng đến người khác hay không
      Apple dường như đã tạo được một điểm cân bằng khá ổn ở đây. Bạn không cần cho phép ứng dụng dùng “vị trí chính xác”, và với ảnh cũng có thể chỉ cho ứng dụng thấy những ảnh mà người dùng chọn thông qua trình chọn ảnh do hệ thống cung cấp
    • Tệ nhất trên iOS là Google Photos. Nếu không cho phép truy cập toàn bộ ảnh thì thậm chí không mở được ứng dụng, và nó cũng không chấp nhận tùy chọn chỉ cho phép các ảnh đã chọn
      Ngay cả khi bạn chỉ muốn xem các ảnh đã được lưu sẵn trên đám mây cũng vậy
    • Ngay cả khi nói rằng “ứng dụng phải xử lý tử tế khi người dùng từ chối quyền truy cập dữ liệu thật”, thì sẽ thực thi thế nào nếu họ không làm
      Đây là kiểu đề xuất giải pháp tổ chức cho một vấn đề kỹ thuật nên khó vận hành, và giải pháp thực tế duy nhất là dữ liệu giả. Từ góc nhìn của ứng dụng, quyền đó phải trông như đã được cấp dù thực tế không phải vậy

  • Trên Android đã root, XPrivacy đã làm được chuyện này từ 7 năm trước, và vẫn có vài lựa chọn hiện đại hơn. Dù vậy tôi không dám đảm bảo vì đã lâu không root điện thoại: https://github.com/M66B/XPrivacy
    Tất nhiên đây không phải cách tiếp cận phổ biến, và tôi đồng ý rằng nó nên được tích hợp sẵn. Nhưng cả Android lẫn iOS đều cho phép những thứ nhảm nhí như ứng dụng giới hạn theo khu vực hay chặn chụp màn hình nội dung DRM, nên chắc sẽ không dễ

    • Dùng theo kiểu này khiến tôi trực tiếp cảm nhận được hệ thống bất lợi với người dùng đến mức nào, và từ bỏ niềm tin rằng điện thoại là máy tính
      Điện thoại là thiết bị phân phối nội dung của nhà cung cấp, còn người dùng thì bị đặt dưới sự định đoạt của họ
    • XPrivacy thực sự rất ngầu, nhưng việc root và cài Xposed trên điện thoại hiện đại đã trở nên phức tạp hơn nhiều hoặc bị chặn hẳn
      GrapheneOS không hợp lắm với ứng dụng ngân hàng, Google đã nhiều lần làm hỏng việc root bằng Magisk trong Android Beta, và đến một lúc nào đó tôi thôi không còn quan tâm nữa
      Có thể GrapheneOS hoặc các dự án tương tự sẽ làm được tính năng này
    • XPrivacy rất xuất sắc, nhưng nếu từ chối một số quyền thì ứng dụng thường xuyên bị crash. Cuối cùng có nghĩa là nó chưa cung cấp dữ liệu giả đủ tốt
      Nghiêm trọng đến mức tôi không bao giờ bấm “từ chối” ngay mà luôn bấm “từ chối tạm thời” trước. Nếu ứng dụng vẫn chạy thì mới từ chối vĩnh viễn, còn nếu crash thì phải đi tìm bộ quyền tối thiểu cần cấp
    • Tính năng này có lẽ sẽ không bao giờ vào bản image xuất xưởng hay nhánh Android chính thống, nhưng nếu nhu cầu người dùng đủ lớn thì có thể sẽ xuất hiện trong các dự án như LineageOS
    • “Ứng dụng giới hạn theo khu vực” thực ra không hẳn là vậy, mà là mỗi app store cho phép chỉ phát hành ứng dụng ở những khu vực mà họ chọn
      Đây là một tính năng quan trọng của app store vì ứng dụng có thể không mang lại trải nghiệm tốt ở mọi quốc gia, có thể chưa được bản địa hóa sang mọi ngôn ngữ, không có người kiểm duyệt nội dung cho ngôn ngữ đó, phải tuân thủ luật từng nước, hoặc giấy phép phân phối nội dung có bản quyền chỉ giới hạn ở một số quốc gia nhất định
      Việc chặn chụp màn hình nội dung DRM là tính năng mà nhà phát triển ứng dụng yêu cầu vì các ràng buộc pháp lý từ giấy phép nội dung như phim. Các hãng phim không muốn mọi người stream hay ghi lại phim, nên nền tảng ứng dụng cần có cách hiển thị an toàn cho loại nội dung đó

  • “Nếu ai đó hỏi một câu mà họ không có tư cách để hỏi, thì bạn không có nghĩa vụ phải nói sự thật với họ”
    — Leonard Schiffman
    Nguồn: “Blend me in: Privacy-Preserving Input Generalization for Personalized Online Services” https://drive.google.com/file/d/10OmoqMmHFcb7PsQtaU_GW4aCAJe...

  • Có vấn đề với lập luận rằng khi ứng dụng yêu cầu quyền, hệ điều hành nên cung cấp không chỉ tùy chọn có/không mà còn cả “có, nhưng cung cấp cho ứng dụng dữ liệu giả”
    Rất nhiều người dùng còn không biết cách chuyển tiếp email
    Hãy tưởng tượng sẽ hỗn loạn thế nào nếu những người đó dùng điều hướng Google Maps, không hiểu ý nghĩa mà vẫn chọn dữ liệu giả
    Google Maps: “Rẽ phải”
    Tài xế đang chạy trên con đường ven biển: “Được thôi”
    Xe: tõm

    • Đó hoàn toàn là vấn đề trải nghiệm người dùng
      Chỉ cần giấu sâu tính năng giả mạo dữ liệu trong phần cài đặt, giải thích thật rõ bằng ngôn ngữ dễ hiểu trước khi bật, và thông báo rõ trên màn hình rằng ứng dụng đang được cung cấp thông tin thay thế do tính năng bảo vệ quyền riêng tư mà người dùng tự bật, đồng thời có thể tắt dễ dàng
      Dù vậy vẫn sẽ có người bật nhầm, nhưng nó có thể mang lại giá trị lớn cho rất nhiều người dùng khác
    • Nghe như một cơ hội để học hỏi. Hoặc cũng có thể là cơ hội mang tính Darwin
      Dù theo cách nào thì đó cũng là vấn đề tự nó sẽ được giải quyết
    • Vậy thì cứ biến thiết lập đó thành tính năng tùy chọn cho người dùng nâng cao. Người không quen có thể không cần thấy tùy chọn đó ngay từ đầu
    • Trong trường hợp đó thì tài xế đã không quan sát đúng hướng di chuyển của mình, và đó là một vấn đề khác
      Có vẻ hệ điều hành nên cung cấp “có”, “không”, và “tùy chỉnh”. Nếu chọn “tùy chỉnh” thì có thể hiển thị cảnh báo trong menu đó khi cần, nhưng không nên ngăn người dùng điều chỉnh theo ý muốn
    • Tôi tự hỏi có nhiều người dùng Google Maps trên iOS không. Tùy chọn “cung cấp dữ liệu giả” nghe như kiểu Apple có thể làm, nhưng rất khó tin Google sẽ làm
      Apple Maps sẽ không gặp vấn đề này. Bạn có thể tải bản đồ xuống thiết bị để nó hoạt động ngoại tuyến mà không cần kết nối dữ liệu

  • Thật ngạc nhiên là ở bình luận đầu không nhắc đến việc trên iOS, bạn không thể phân biệt được ứng dụng có được cấp quyền hay không
    Ví dụ, khi ứng dụng yêu cầu quyền truy cập ảnh thì nó luôn nhận được một mảng. Nếu quyền bị từ chối thì mảng đó rỗng, nên không thể biết là thư viện của người dùng thật sự trống hay quyền truy cập đã bị từ chối. Cách này đơn giản và thanh lịch
    Tất nhiên với ảnh thì hầu như ai cũng có vài tấm nên có thể dùng heuristic. Nhưng với các loại khác như dữ liệu sức khỏe thì không rõ ràng như vậy

    • Điều đó không chính xác. Ví dụ, quyền truy cập dịch vụ vị trí có CLAuthorizationStatus: https://developer.apple.com/documentation/corelocation/claut...
      Thông báo đẩy có UNAuthorizationStatus: https://developer.apple.com/documentation/usernotifications/...
      Dữ liệu sức khỏe có HKAuthorizationStatus: https://developer.apple.com/documentation/healthkit/hkauthor...
      Danh bạ có CNAuthorizationStatus: https://developer.apple.com/documentation/contacts/cnauthori...
      Ảnh có PHAuthorizationStatus: https://developer.apple.com/documentation/photokit/phauthori...
      Ảnh là trường hợp đặc biệt vì người dùng có thể chọn từ chối truy cập, truy cập hạn chế hoặc truy cập đầy đủ. Có thể biết truy cập có bị từ chối hay không, nhưng không thể phân biệt giữa truy cập hạn chế và truy cập đầy đủ
    • Tôi thắc mắc vị trí hoạt động thế nào
      Và nếu thư mục ảnh trống thì gần như chắc chắn là không có quyền. Rất hiếm người chưa từng chụp một bức ảnh nào
    • Vậy còn những quyền khác mà trên thực tế không thể gửi một đối tượng rỗng thì sao
      Ví dụ, nếu người dùng cho phép xem vị trí thì đối tượng vị trí được gửi cho ứng dụng hiển nhiên sẽ chứa thông tin liên quan. Nếu hệ điều hành trả về một đối tượng vị trí rỗng thì chẳng phải sẽ lộ rõ là quyền đã bị từ chối sao, hay là nó được che giấu phía sau một loại lỗi nào đó
    • Điều này rõ ràng không đúng, và bạn có thể kiểm tra ở gần như mọi ứng dụng yêu cầu quyền thông báo

  • Tôi cho rằng “cung cấp dữ liệu giả” là cách làm sai. Cách tốt hơn là cung cấp dữ liệu từ nguồn thay thế, và nguồn thay thế đó nên có thể là bất kỳ chương trình nào khác
    Nguồn thay thế có thể là dữ liệu rỗng, dữ liệu ngẫu nhiên, dữ liệu giả nhưng nhất quán, dữ liệu từ tệp thay thế (ví dụ: một danh bạ riêng hoặc ảnh từ tệp thay cho camera), dữ liệu đã biến đổi (ví dụ: lật ngược ảnh từ camera), lọc, ghi log, hỏi người dùng cho từng mục dữ liệu riêng lẻ, cung cấp mã lỗi thay vì dữ liệu và cho phép người dùng chỉ định mã lỗi, v.v. — bất cứ điều gì người dùng muốn. Điều này nên bao gồm cả quyền truy cập ngày/giờ hiện tại
    Nó giúp tăng quyền kiểm soát của người dùng và cũng hữu ích cho mục đích kiểm thử và trợ năng
    Một trong những ý tưởng của tôi về thiết kế hệ điều hành là quyền proxy. Đưa quyền proxy vào bảo mật dựa trên quyền, dùng nó cho mọi đầu vào/đầu ra, có thể dùng trong shell lệnh theo cách tốt hơn UNIX pipe, và cả theo những cách khác. Bao gồm cả ngày/giờ. Ngoài Yield và Quit thì sẽ không có system call nào dùng được nếu không có khóa quyền

    • Tôi nghĩ đây là cách tiếp cận tốt nhất, và thực ra là cách tiếp cận duy nhất có thể hoạt động
      Với nhà phát triển ứng dụng, việc xử lý tốt các quyền mà họ không thể sử dụng là rất khó, và phạm vi kiểm thử sẽ lớn hơn, khó hơn rất nhiều chỉ để phục vụ một nhóm người dùng tương đối nhỏ, nên phần lớn ứng dụng thương mại nhỏ có lẽ sẽ không cố xử lý cho đúng
      Cách dễ nhất cho cả nhà phát triển lẫn người dùng là vẫn cho phép quyền nhưng cấp nguồn dữ liệu thay thế
      Tất nhiên, điều đó cũng có thể khiến gian lận dễ hơn. Ví dụ, các ngân hàng có thể sẽ dùng quy trình đăng ký thiết bị phức tạp hơn

  • Không cần phải làm khó nhau như vậy. Quy tắc đơn giản là: “không cũng là một lựa chọn, trừ khi thật sự không phải lựa chọn”
    Nếu không phải lựa chọn thì lý do phải cực kỳ rõ ràng, có lẽ phải được nêu ra trong quá trình xét duyệt ứng dụng, nếu không thì ứng dụng nên bị từ chối
    Ví dụ, nếu TikTok/Instagram yêu cầu quyền camera và micro thì cả hai đều không thiết yếu để dùng ứng dụng, nên không vẫn là một lựa chọn. Nếu vẫn có thể dùng một phần ứng dụng mà không cần một quyền nào đó, thì phía ứng dụng có trách nhiệm thiết kế để nó hoạt động như vậy. Nếu camera hoặc micro bị tắt, chỉ cần vô hiệu hóa có điều kiện những tính năng cần quyền đó
    Nói đơn giản hơn, gánh nặng thuộc về bên yêu cầu. Nếu không rõ ràng hoặc cố lách luật một cách khôn lỏi thì câu trả lời là không. Nghe có thể nghiêm khắc, nhưng nhà phát triển ứng dụng hoàn toàn có thể biến quyền đó thành tùy chọn để tránh hẳn bước bổ sung này
    Nếu tập trung vào việc thực thi điều này thì sẽ không cần đến một cuộc chạy đua vũ trang lặt vặt, và đó cũng là lựa chọn tốt hơn cho người dùng

    • Nghe có vẻ hay, nhưng sẽ thực thi bằng cách nào?
      Chủ thể duy nhất có thể ép buộc ở đây là các kho ứng dụng của Google/Apple/Microsoft. Khó mà tin rằng họ có đủ động lực để thực thi điều này một cách nhất quán và thân thiện với người dùng. Nếu có thì họ đã làm từ lâu rồi

  • Điện thoại Samsung có nút gạt truy cập camera và truy cập micro
    Khi tắt thì sẽ hiện thông báo này:

    Turn off Camera access?  
All apps will be blocked from using the camera. Apps  
will still work, but they will only be able to access an  
empty black screen. For example, you can still make  
and receive video calls, but the other person won't be  
able to see you.
    • Với quyền truy cập micro: 
      Turn off Microphone access?  
All apps will be blocked from using the microphone  
Apps will still work, but they won't be able to access  
any sounds from the microphone. For example, you  
can still make and receive calls, but the other person  
won't be able to hear you.

  • Thiết lập theo từng ứng dụng sẽ tốt hơn là “mọi danh mục đều có tùy chọn ‘có, nhưng cung cấp dữ liệu giả cho ứng dụng’”
    Bạn có thể không muốn cấp dữ liệu vị trí cho gần như mọi ứng dụng, nhưng vẫn muốn cấp cho Google Maps và ứng dụng gọi cứu hộ khẩn cấp. Danh bạ và dữ liệu cá nhân cũng vậy
    Tuy nhiên, những ứng dụng như thế sẽ vấp phải sự phản kháng mạnh mẽ từ Google và các công ty khác vốn kiếm lợi từ việc lập hồ sơ người dùng

    • Tôi đồng ý, nhưng vừa phải theo từng ứng dụng, đồng thời cũng phải theo từng nhóm quyền
      Ví dụ, trong một ứng dụng, bạn nên có thể cấp dữ liệu thật cho một quyền, cấp dữ liệu giả hoặc dữ liệu tùy chỉnh/nhập tay cho quyền khác, và từ chối quyền thứ ba
      Cũng có thể bạn muốn tạm thời đổi thiết lập cho mục đích thử nghiệm, hoặc như trường hợp ứng dụng hiển thị thời tiết theo vị trí hiện tại, khi bạn muốn xem thời tiết ở một nơi khác trong chốc lát rồi quay lại vị trí thật

  • Nếu ứng dụng cần dữ liệu của tôi để cải thiện trải nghiệm của tôi, và chỉ trải nghiệm của tôi thôi, thì khi bị cho ăn dữ liệu giả, chỉ trải nghiệm của tôi mới nên tệ đi. Nhà phát triển hay chủ sở hữu ứng dụng không nên bị ảnh hưởng gì
    Nhưng nếu mục đích là khai thác dữ liệu của tôi, như trong phần lớn trường hợp, thì dữ liệu giả sẽ rất hiệu quả trong việc cản trở điều đó
    Tất nhiên với những trường hợp như WhatsApp thì cũng chẳng giúp ích mấy. Mọi người sẵn sàng đồng bộ cả danh sách liên hệ của mình với Facebook/Meta chỉ để có trải nghiệm nhắn tin tốt hơn một chút

    • Tôi cũng đã phải làm thế và thấy cực kỳ khó chịu, nhưng đó không chỉ là kiểu “trải nghiệm tốt hơn một chút”
      Ít nhất là trên di động, ứng dụng và dịch vụ hầu như chỉ ở mức miễn cưỡng dùng được cho đến khi bạn đồng bộ danh bạ