Những câu hỏi khó chịu về chứng thực nhà phát triển Android
(commonsware.com)- Chương trình chứng thực nhà phát triển Android mà Google triển khai từ năm 2026 yêu cầu mọi nhà phát triển ứng dụng phải xác minh danh tính, làm dấy lên tranh cãi về sự cân bằng giữa quyền riêng tư và bảo mật
- Trường hợp ICEBlock cho thấy với những nhà phát triển cần ẩn danh, việc tiết lộ danh tính có thể gây ra thiệt hại cá nhân và nghề nghiệp
- Chính sách quyền riêng tư của Google nêu rõ rằng thông tin nhà phát triển có thể được chia sẻ với bên thứ ba mà không có giới hạn rõ ràng, làm dấy lên lo ngại về độ tin cậy và tính minh bạch
- Nếu sau năm 2027, debug keystore và việc sử dụng tên gói trùng lặp bị hạn chế, khả năng phát triển và kiểm thử ứng dụng trong môi trường giáo dục có thể trở nên khó khăn hơn
- Chương trình này nhằm ngăn chặn ứng dụng độc hại, nhưng cần có thêm thảo luận về tính ẩn danh, khả năng tiếp cận trong giáo dục và sự thiếu hợp tác với các tổ chức dân sự
Bối cảnh và vấn đề được nêu ra
- Từ năm 2026, Google sẽ yêu cầu tất cả nhà phát triển ứng dụng Android hoàn tất xác minh danh tính, và chỉ cho phép cài đặt các ứng dụng từ những nhà phát triển đã được chứng thực
- Chính sách này cũng áp dụng với các ứng dụng được phân phối ngoài Google Play (sideloading)
- Quyền truy cập sớm bắt đầu vào tháng 10/2025, mở cho mọi nhà phát triển vào tháng 3/2026, và được áp dụng tại Brazil, Indonesia, Singapore, Thái Lan vào tháng 9/2026
- Trường hợp ứng dụng ICEBlock nhấn mạnh tầm quan trọng của tính ẩn danh
- ICEBlock là một nền tảng cho phép người dùng ẩn danh báo cáo hoạt động của ICE (Immigration and Customs Enforcement); sau khi nhà phát triển công khai danh tính, họ đã phải chịu đe dọa pháp lý và cả việc vợ/chồng bị sa thải
- Nhà phát triển một ứng dụng tương tự trên Android (tạm gọi là “ICE Scream”) có thể phải đối mặt với rủi ro tương tự nếu tiết lộ danh tính
Câu hỏi 1: Cân nhắc về tính ẩn danh
- Chưa rõ Google định hỗ trợ thế nào đối với những nhà phát triển cần duy trì tính ẩn danh vì các lý do hợp pháp
- Nhà phát triển của các ứng dụng như ICE Scream có thể lo ngại về đe dọa an toàn hoặc bị trả đũa pháp lý do lộ danh tính
- Google chưa công bố biện pháp cụ thể hay chính sách ngoại lệ cho các kịch bản như vậy
Câu hỏi 2: Hợp tác với các tổ chức dân sự
- Chưa xác nhận liệu Google có hợp tác với các tổ chức dân sự như EFF hay AccessNow để thảo luận về sự cân bằng giữa quyền riêng tư và bảo mật trong chương trình chứng thực hay không
- Những tổ chức này có nhiều kinh nghiệm lâu năm trong việc xử lý cân bằng giữa quyền riêng tư và bảo mật
- Thiếu thông tin về việc Google có tận dụng chuyên môn của họ hay không, và nếu có thì kết quả là gì
Câu hỏi 3: Sự mơ hồ trong chính sách quyền riêng tư
- Chính sách quyền riêng tư của Google nêu rằng dữ liệu cá nhân của nhà phát triển có thể được chia sẻ với “các công ty hoặc cá nhân đáng tin cậy”
- Không có giải thích rõ ràng về tiêu chí thế nào là “đáng tin cậy”, cũng như giới hạn sử dụng đối với thông tin được chia sẻ
- Điều này khiến những người như nhà phát triển ICE Scream khó có thể tin tưởng vào cách Google xử lý thông tin của họ
Câu hỏi 4: Debug keystore và môi trường phát triển
- Việc phát triển ứng dụng Android sử dụng debug keystore, vốn mang tính tạm thời và thường xuyên được thay thế
- Sau năm 2027, nếu debug keystore không được đưa vào chương trình chứng thực, việc kiểm thử ứng dụng trên phần cứng đã được Google chứng thực có thể trở nên bất khả thi
- Trong môi trường giáo dục (ví dụ: lớp học, máy chủ CI), yêu cầu đăng ký keystore có thể làm tăng rào cản học tập
Câu hỏi 5: Vấn đề tên gói trùng lặp
- Trong môi trường giáo dục, việc sử dụng tên gói trùng lặp là khá phổ biến, như trong các dự án mẫu của Google
- Chương trình chứng thực cấm tên gói trùng lặp, điều này có thể khiến nhà phát triển mới không thể chạy mã mẫu
- Ví dụ: tác giả một cuốn sách về phát triển ứng dụng Android lo ngại độc giả sẽ không còn chạy được các ví dụ mẫu
- Google chưa đưa ra phương án giải quyết cho vấn đề này
Thảo luận bổ sung và phản hồi
- Google cung cấp biểu mẫu trực tuyến để nhận phản hồi từ nhà phát triển; có thể gửi câu hỏi và mối quan ngại
- Liên kết biểu mẫu: https://docs.google.com/forms/d/…
- Các tổ chức dân sự hoặc những người quan tâm có thể liên hệ qua dev.verification@commonsware.com
- Nếu chính Google cũng muốn thảo luận, có thể liên hệ qua did.you.really.need.a.written.invitation@commonsware.com
Hàm ý
- Chương trình chứng thực nhà phát triển Android có mục tiêu tăng cường bảo mật cho người dùng, nhưng dường như chưa cân nhắc đầy đủ tác động của việc hạn chế tính ẩn danh đối với các nhà phát triển
- Nó có thể làm suy giảm khả năng tiếp cận trong giáo dục và bảo vệ quyền riêng tư, do đó cần Google giải thích chính sách minh bạch hơn và hợp tác với các tổ chức dân sự
- Chính sách này đặt ra thách thức trong việc cân bằng giữa ngăn chặn ứng dụng độc hại và duy trì một hệ sinh thái mở, vì vậy đối thoại với cộng đồng nhà phát triển là điều quan trọng
2 bình luận
Nếu là ứng dụng mà chính nhà phát triển tự phân phối file apk thì hãy cài bằng Obtainium khi có thể. Với các nền tảng phân phối phổ biến như GitHub, GitLab, chỉ cần thao tác một hai lần là có thể cài đặt và cũng có cập nhật tự động.
Không bao gồm cả mã liên quan đến Google nên mọi mặt đều tốt.
Nếu bạn không thể tin tưởng nhà phát triển thì ngay từ đầu cũng không nên cài ứng dụng.
Ý kiến trên Hacker News
Đây không chỉ là mức đặt câu hỏi đơn thuần mà phải thể hiện lập trường phản đối hoàn toàn
Chỉ cần nhượng bộ dù rất nhỏ cũng có thể dẫn tới việc mọi quyền hạn bị tước mất trong chớp mắt
Tôi cứ nhớ mãi lời cảnh báo của Stallman trong The Right to Read năm 1997: “vào năm 2047, debugger sẽ được đánh số và chỉ phân phối cho các lập trình viên đã được chứng nhận chính thức”
Tôi không hiểu tại sao việc có được một mobile OS mã nguồn mở tử tế lại phức tạp đến vậy
Tôi chỉ dùng PC Linux (laptop, server) cho cả việc cá nhân lẫn công việc
Công việc có cần MS365, Google Workspace, Zoom v.v., nhưng ít nhất vẫn có thể truy cập qua trình duyệt nên tôi thấy ổn vì còn ngăn được hệ sinh thái đóng
Bên mảng di động thì có PostmarketOS, Phosh, Ubuntu Touch, nhưng tôi chưa từng thực sự dùng chúng trong đời sống hằng ngày
Tôi cũng tự hỏi có phải đây là trách nhiệm của mình không, nhưng ngay cả chính phủ nước tôi cũng chỉ hỗ trợ ứng dụng xác minh danh tính trên iOS/Android
Đúng ra nên cố bám vào web thôi, nhưng vì tiện lợi nên cuối cùng tôi vẫn dùng app, cảm giác như bản thân quá yếu lòng
Nếu có Ubuntu Touch cùng với iPad thì có lẽ đó sẽ là những thiết bị mà tôi còn kiểm soát được phần nào quyền riêng tư của mình
Rốt cuộc tôi cần một “nền tảng điện toán cá nhân” thực sự có thể mang theo mà không cần túi xách
Thật buồn khi ngay cả tương lai của GrapheneOS cũng phụ thuộc vào tay một kẻ đối địch khổng lồ (công ty đó, thứ ghét việc người dùng kiểm soát)
Tôi kỳ vọng rằng trong tương lai gần, smartphone và tablet đóng sẽ còn nhiều hơn desktop/laptop phổ thông
Phần lớn mọi người thậm chí sẽ không còn cơ hội sở hữu một thiết bị thực sự mở
Và chuyện cả laptop cũng bị khóa lại hoàn toàn là điều có thể xảy ra
Hiện tại vẫn có thể mua chip RISC-V hoàn toàn mở và debug tùy ý
x86 cũng gần như hoàn toàn mở rồi (ngoại trừ vài nỗ lực đóng như XBox, PS5)
Vì vậy tôi cho rằng câu chuyện “quyền được đọc” của Stallman hiện vẫn là một sự cường điệu hơi sớm
Lỗ hổng logic trong lập luận của Stallman là giả định rằng mọi hệ thống đều hoàn hảo, tuyệt đối không thể bị phá, và mọi người đều có hiểu biết hoàn hảo về phần mềm cũng như hệ thống, dù thích hay không
Nếu debugger bị hạn chế, cuối cùng ai cũng sẽ chạy debugger lậu thôi
Đa số mọi người (99,9%) chẳng hề quan tâm tới OSS
Điều họ quan tâm chỉ là dùng điện thoại của mình theo ý muốn, không có app độc hại/app rác/app quảng cáo
Ngoài ra, xuất bản và phát triển là hai hoạt động hoàn toàn khác nhau
Việc ép buộc xác minh khi sideload bất kỳ app nào cũng là kiểu kiểm soát phát xít
Tôi thấy xấu hổ thay cho Google và Apple, vì đây từ lâu đã là đích đến cuối cùng của họ
Bước tiếp theo sẽ là tự ý xóa những app họ không thích, và chúng ta sẽ không thể ngăn cản
Cảnh báo của Stallman là đúng
PC mở chỉ là vì IBM đã không lường trước được
Đến lúc IBM muốn giành quyền kiểm soát thì đã quá muộn
Tôi nghĩ chính từ “sideload” cũng đã là vấn đề
Tại sao lại nói “sideload” thay vì chỉ nói là “chạy chương trình”?
Một OS không cho tôi chạy chương trình tôi muốn là điều vô lý
Tôi có hỏi LLM xem “Stallman was right” nghĩa là gì nên cũng hiểu lờ mờ, nhưng vẫn muốn ai đó giải thích trực tiếp
Mỗi lần cố hiểu những chuyện như thế này mà chỉ nghe câu trả lời từ LLM thì tôi vẫn thấy không thoải mái, nên muốn hỏi trực tiếp
Tôi kiên quyết phản đối những biện pháp như thế này, và vì lý do đó mà đã tẩy chay sản phẩm Apple suốt đời trên phương diện ý thức hệ
Tuy nhiên, gọi mọi thứ là “phát xít” thì theo tôi là lạm dụng thuật ngữ
Tôi hy vọng quyết định lần này sẽ khiến Google hứng chịu phản ứng dữ dội, và các ROM như LineageOS sẽ lấy lại được mức độ phổ biến như xưa
Cũng mong các tính năng né phát hiện root tiến bộ hơn để app ngân hàng v.v. có thể chạy trên máy đã root như bình thường
Những yêu cầu ID phức tạp như chứng nhận nhà phát triển cũng tệ chẳng kém gì Apple
Vì thế mà các lập trình viên dùng sản phẩm Apple từ trước tới nay chưa bao giờ tạo cho tôi cảm giác nghiêm túc
Chuyện này hoàn toàn không thể chấp nhận được
Nếu đã sở hữu thiết bị thì người dùng phải có thể chạy bất cứ thứ gì mình muốn
Hạn chế hay khóa quyền truy cập vào sản phẩm mình đã bỏ tiền mua thì không còn là quyền sở hữu thực sự nữa
Nó chẳng khác gì thuê thiết bị
Cũng không cần tưởng tượng xem liệu người ta có chấp nhận chuyện hãng xe cấm lái ở một số khu vực nhất định hay không
Mặt khác, VW thực sự đã giới hạn mã lực nếu ngừng trả phí thuê bao hằng năm
Vì lòng tham của doanh nghiệp và sự thiếu hiểu biết của người dùng mà hiện tượng này đã xảy ra ngoài đời thật rồi
Bạn có thể mua giấy phép trò chơi điện tử trên Steam rồi tự do cài mod
Mô hình thuê bao trá hình đã lén len vào rất nhiều nơi rồi
Trước đây tôi từng dùng Shizuku trên điện thoại để chạy Hail (công cụ tạm dừng app)
Nhưng gần đây ngân hàng phát hành thẻ tín dụng của tôi bắt đầu kiểm tra xem USB debugging có tồn tại hay không, nên tôi đành bỏ không dùng nữa (3DS OTP giờ cũng phải nhận qua SMS)
Hiện ở Thái Lan chỉ còn khoảng hai ngân hàng là chưa kiểm tra kiểu này, nhưng tôi có cảm giác sớm muộn gì tất cả cũng sẽ chặn
Cuối cùng tôi chuyển sang Dhizuku; thiết lập có hơi rắc rối nhưng sau khi xong thì không còn phải mỗi lần đều khởi chạy Shizuku theo cách phức tạp nữa, cảm giác gần như một kiểu untethered jailbreak hoàn chỉnh
Về cơ bản Dhizuku hoạt động như điện thoại công ty, chỉ khác là chủ sở hữu chính là tôi
Để “quản lý profile chính”, phải xóa mọi tài khoản trong hệ thống tài khoản Android và nhập một lệnh ADB rất dài, nên gần như không thể bị lạm dụng cho mục đích xấu
Về sau nếu muốn dùng F-Droid thì có lẽ cách này sẽ trở thành tiêu chuẩn trong giới kỹ sư
Tôi muốn gợi ý việc dùng website ngân hàng thì sao
Tôi không cài app ngân hàng trên điện thoại, và mỗi khi cần chuyển khoản thì tôi ngồi vào máy tính để xử lý
Thiết bị này rõ ràng là của tôi, và đúng ra tôi phải được dùng nó theo ý mình
Dù vậy cũng cần tính đến việc việc sử dụng các công cụ được nhắc tới này (Shizuku, Dhizuku) thực sự có thể ảnh hưởng tới bảo mật của thiết bị và khiến việc tấn công trở nên dễ hơn
Tôi cho rằng việc lạm dụng quyền hạn, bao gồm cả chuyện tạm thời cho ứng dụng khác mượn quyền DeviceOwner, là nguy hiểm
Hơn nữa, nếu ngay cả những hệ thống bảo mật như GrapheneOS cũng bắt đầu chặn kiểu thiết lập này thì vấn đề sẽ còn lớn hơn
Việc phát hiện root, kiểm tra call stack v.v. trên thực tế cũng rất dễ bị qua mặt nên hiệu quả không cao
Có một form phản hồi dành cho những ai muốn nêu ý kiến
Liên kết form phản hồi của Google
Thảo luận liên quan
Tôi cho rằng chính sách này sẽ không áp dụng với các OEM Trung Quốc
Thiết bị Trung Quốc được xuất xưởng với Google Mobile Services bị vô hiệu hóa mặc định, và cũng không có app Play Store cho người dùng
Việc yêu cầu Google phê duyệt để phát triển app nội bộ là điều vô lý
Có lẽ mỗi OEM sẽ phải tự xây dựng dịch vụ cấp phép debug riêng, và việc debug app dựa trên nền Google sẽ trở nên khó khăn hơn tương ứng
Nhiều OEM Trung Quốc vốn không được Google chứng nhận từ đầu, nên tôi thực sự nghĩ chính sách đó sẽ không áp dụng
Một số hãng (Huawei) đã có sẵn app store riêng và giải pháp thay thế dịch vụ Google
Về thực chất đó là các thiết bị de-googled, nhưng tiếc là thay vào đó lại thường cài spyware của phe đối diện
Việc có cho phép cài app (sideload) hay không là quyền mà chính chủ sở hữu thiết bị phải tự quyết định
Giống như điện thoại có thể bật tùy chọn mở khóa bootloader, những tính năng quan trọng như vậy cũng phải để người dùng tự cấu hình
Đó là nguyên tắc cơ bản không thể rõ ràng hơn
Có những câu hỏi có thể khiến người ta khó chịu, nhưng nghĩ rằng những câu hỏi đó có thể khiến Google cảm thấy bất tiện thì quá lạc quan
Google hoàn toàn không quan tâm tới những vấn đề kiểu này
Bộ phận PR được trả lương để khéo léo né tránh những câu hỏi khó chịu như thế
Thậm chí từ góc nhìn của Google, kiểu giao tiếp này còn được dùng để tạo hình ảnh là họ đang “hợp tác”
Vì chuyện này mà một trong những lý do lớn nhất khiến tôi dùng Android thay vì iPhone đang dần biến mất
Tôi thậm chí còn nghĩ điều này tệ hơn cả những chính sách Apple áp dụng
Người dùng iPhone xem việc không thể cài app bên thứ ba là một tính năng
Tôi không đồng ý, nhưng ít nhất Apple ngay từ đầu đã nói thật rằng người dùng không thể kiểm soát thiết bị của chính mình
Trải nghiệm đó đối với tôi vẫn rất khó chịu, nhưng ít ra là thành thật
Trong khi đó, Google lôi kéo người dùng bằng khẩu hiệu nền tảng mở rồi quay lưng đâm sau lưng họ, đúng kiểu “mồi nhử”
Khi Android và iPhone cạnh tranh ở giai đoạn đầu, ưu điểm lớn nhất của Android là có thể cài bất kỳ app nào mình muốn mà không cần Google cho phép
Có lẽ việc này (Google ngày càng đóng chính sách) cuối cùng sẽ khiến chính Google tự rơi vào thế khó
Nếu Android cũng đi theo hướng đóng và kiểm soát chặt như iOS, thì sẽ không còn rõ vì sao phải dùng Android nữa
Tôi tự hỏi liệu động thái này có thể tạo cơ sở để những công ty như Epic kiện Google hay không
Giải thích vụ việc liên quan
Nếu Google độc chiếm quy trình xác minh, thì quyền phân phối các app Android qua Epic Store sẽ không còn nằm ở Epic mà nằm ở Google
Vì thế tôi nghĩ ở Mỹ (và ở EU vì những lý do khác), thực tế Google sẽ không thể thực thi chính sách này
Thực ra tôi còn không nghĩ họ sẽ dám thử, nhưng giờ thì cảm giác chuyện gì cũng có thể xảy ra nên tôi không dám dự đoán nữa