Những vấn đề kỹ thuật và bảo mật của ứng dụng BlueZone

Bộ Thông tin- truyền thông và BKAV tuần trước có ra thông báo về app BlueZone để dò vết virus Covid ở Việt Nam. Đây là một ý tưởng tốt, và nếu thực hiện tốt thì càng giúp gây dựng hình ảnh tốt về nước Việt Nam đã thực hiện việc phòng chống Covid rất bài bản, tránh được bao nhiêu người bị bệnh, chết. Thường thì trước khi kết luận tiêu cực, mình luôn có hy vọng là những người làm sẽ làm tốt. Việc viết app này không nằm ngoài quy luật đó.
Mình đã có hy vọng họ Việt hóa một phần mềm hay giải pháp của nước ngoài nhưng thực tế là họ quyết định đi phát minh lại cái bánh xe. Việc này về bản chất cũng không có vấn đề gì nhưng rất tiếc khi họ phát minh lại cái bánh xe, những người lập trình viên viết phần mềm đó gặp phải nhiều lỗi. Việc này vô cùng đáng tiếc, vì mặc dù đã có nhiều nước khác trên thế giới làm rồi, mình đi nghiên cứu, thậm chí copy thay đổi lại mã nguồn của họ thôi thì đã tránh được những lỗi đó.


Những người phát triển phần mềm này mới phát hành mã nguồn này với dạng nguồn tự do và đặt tên BlueZone-Global chắc để ý các bạn nước khác có thể học hỏi và làm theo. Có một câu châm chích ngôn mình hay bị đập vào mặt khi xem Youtube là của Neil Degrasse Tyson. Ông ấy có nói "Một trong những thách thức của cuộc sống: Biết đủ để nghĩ rằng mình đúng, nhưng biết chưa đến nơi để hiểu rằng mình sai." Có lẽ đây là vấn đề thách thức của các bạn làm phần mềm này và tung ra mã nguồn có lẽ chính xác là như vậy. Các bạn nghĩ sai và làm sai, nhưng lại chưa biết đến nơi, nghĩ rằng mình đúng.
Cụ thể những lỗi trong suy nghĩ và kỹ thuật cụ thể là lỗi nào thì có thể đọc blog của vnhacker: App đó nói là đảm bảo riêng tư cho người dùng nhưng với cách nghĩ như vậy thì thật sự là không đảm bảo được. Ở đây mình chỉ tóm tắt lại cho dễ hiểu.

Cách nghĩ

Ý tưởng của việc tìm dấu Covid là mỗi điện thoại sẽ nhận một bí danh riêng rồi hét lên để tất cả các điện thoại khác ghi nhận lại là mình gần ai. Ví dụ, điện thoại của tôi (tự) chọn bí danh là Phúc, thì đi ra đường nó sẽ hét lên "Tôi là Phúcccccc!!!!". Sau này nếu tôi bị bệnh, bệnh viện ghi lại điện thoại có bí danh Phúc bị bệnh thì điện thoại của ai có ghi lại gần tên Phúc đó sẽ báo cho chủ biết. Bình thường giải pháp của các công ty như Google hay Apple là mỗi vài phút cái điện thoại nó sẽ hét lên một tên ngẫu nhiên khác nhau theo một quy luật mà chỉ có cái điện thoại của người chủ biết, điều này khiến cho kẻ xấu không thể theo dõi được vị trí hành tung của người họ muốn theo dõi. Khi nào người bị bệnh bị đánh dấu, thì bệnh viện sẽ gửi tới mọi người một danh sách những bí danh mà điện thoại của người nhiễm đã chọn (đại loại là như vậy, sự thực họ có thể không cần gửi cả danh sách đó nhưng đó là tiểu tiết không quan trọng ở đây). Nhưng giải pháp của BlueZone kỳ khôi ở chỗ là app chọn tên ngẫu nhiên, nhưng từ đầu hét thế nào thì về sau cứ hét như thế. Như vậy, chỉ cần dụ người ta cài cái app Covid này là đi đâu điện thoại nó cũng sẽ (thay mình) hét lên thường xuyên đúng một tên như vậy. Vì thế, nếu có ai có vợ/chồng gì nghi ngoại tình mà không bắt được tận tay day được tận mặt thì đây là cơ hội tốt nhất. Khi ai đó ở nhà biết cái điện thoại của vợ chồng hét lên thế nào thì chỉ việc gắn thêm một cái máy ở gần nhà nghỉ, xem có cái gì hét lên như vậy không, khi nào nó hét lên thì mình mang máy ảnh đến chụp.
Sau khi lỗi này được thông báo, các bạn còn đi chống chế rằng có cái giao thức Bluetooth Classic nó cũng hét lên cùng một tên như vậy. Cái các bạn nghĩ là mình đúng nhưng chưa hiểu mình sai ở chỗ là điện thoại bình thường nó không hét lên nó là ai khi mình không yêu cầu nó hét lên. Đây là các bạn làm một cái app đi đâu nó cũng hét lên thường xuyên, và khi mình hét lên thường xuyên như thế thì mình phải thay đổi biệt danh của mình liên tục, và đó là cái các bạn đã không làm. Đó là cách nghĩ cơ bản sai.

Cách làm

Còn cách làm sai cũng có. Cách làm sai thì sai từ lỗi SQL injection tới sinh mã ngẫu nhiên. Việc sinh mã ngẫu nhiên chỉ mất một chục dòng mã nhưng rất quan trọng và người làm cần một sự nghiêm túc và tuyệt đối chính xác. Một chục dòng mã này thường quyết định tính an toàn của giải pháp. Nói nôm na, để giải pháp hoạt động đúng thì mỗi người đều phải có một cơ hội rút thăm biệt danh giống nhau. Giả sử chúng ta có 6 cái tên có thể chọn: Kiều Vân Phúc Diễm Kim Lợi, không ai biết ai chọn tên nào thì một thuật toán tồi là một thuật toán sẽ làm cho mọi người dễ chọn một tên cùng nhau. Nếu ai cũng gào lên "tôi tên Kiều" thì việc theo dõi sẽ rất khó khăn. Rất đáng tiếc là việc này các bạn cũng làm sai và làm cho thuật toán dễ chọn cùng một tên. Việc này mình bàn kỹ bằng tiếng Anh ở đây.

Và những điều nhỏ hơn

Nhưng khoan hãy tiếp tục bàn đến những điều đao to búa lớn. Một trong những lý do của việc không nghiêm túc ở đây là mình thấy các bạn đi viết chú thích cho mã nguồn của mình không giống ai. Như mình đã từng viết ở trước, việc chú thích cho mã nguồn là một việc quan trọng khi ta phải làm việc với đội lớn, nhiều người hợp tác với nhau (Global-Toàn cầu mà!)
Các chú thích của mã nguồn lúc thì ghi bằng tiếng Anh, lúc thì ghi bằng tiếng Việt, lúc thì không dấu, lúc thì có dấu:
... COLUMN_NAMES_USER_ID = "userid";   // user_id
... COLUMN_NAMES_MAC_ID = "macid";      // mac
... COLUMN_NAMES_RSSI = "rssi";         // Sóng
... COLUMN_NAMES_DEVICES = "devices";    // Thiet bi

Việc viết code như vậy thể hiện một sự thiếu chuyên nghiệp ngay cả cho một phần mềm tiếng Việt. Một điều nữa quan trọng hơn, là các chú thích này thường không giúp ích người đọc hiểu được người viết định làm việc gì và tại sao lại làm việc đó. Mình đã viết rất rất nhiều về việc này (Đọc thêm bài "Viết phần mềm: Dùng git và comment như thế nào cho đúng" của mình ở trước). Ý tưởng chính mình xin được trích lại:
Nguyên tắc: Comment về giải thích về các thành phần liên quan, ý tưởng, căn nguyên của bạn chứ không giải thích hành động cụ thể. Comment cái gì không hiển nhiên, không dễ nhận ra. Đặt tên cho các variables hợp lý để không phải comment cái tên đó để làm gì.
Hãy cùng nhìn lại chú thích ở trên đoạn mã mình dẫn trên kia. Người viết đi giải thích tên biến y như cái tên biến hai lần để làm gì?
Một ví dụ khác, ở file mã nguồn java ở trên, những nhà phát triển có viết chú thích như thế này:
// Open
openDatabase();
Dĩ nhiên cái hàm ở dưới là để mở cơ sở dữ liệu chứ còn làm gì, chú thích như vậy là giải thích cái người ta đọc được ngay ở dưới. Việc chú thích như vậy không giải quyết được việc gì, chỉ tốn công gõ phím, tốn công người đọc đọc hai dòng trong khi họ có thể đọc một dòng mà vẫn hiểu. Mình theo dõi dự án này thì phần lớn có xu hướng comment là như vậy, đọc rất rối rắm và bực mình.
Một điều cũng đáng thất vọng là mặc dù vnhacker đã có nhiều chỉ trích nhưng theo vnhacker, cái anh ta nhận được chính thức chỉ là sự im lặng. Câu trả lời "không chính thức" ở trang whitehat.vn thì có vẻ mang tính chống chế hơn là thật sự nhận khuyết điểm (và thật sự điều quan trọng không phải là nhận hay không mà là sửa hay không, đây không phải là một cuộc buôn nước bọt).
Như vậy đây có thể là một ví dụ đầu tiên cho việc một ý tưởng và ý định tốt nhưng vì việc thực hiện không tới nơi tới chốn, cách nghĩ (cho đến giờ) cho thấy sự bảo thủ và không cầu thị đã làm cho dự án trở thành một sự thất vọng khác của mình. Tuy vậy, mình vẫn hy vọng rằng những người lập trình viên trong dự án này quyết định đặt sự đúng đắn lên trên cái tôi cá nhân để sửa lại những gì mình chưa hiểu và làm đúng. Thời gian vẫn còn để giải quyết các vấn đề này.
77
1834 lượt xem
77
12
12 bình luận