Giả định rằng máy tính hoạt động đúng
(emptycity.substack.com)- Vụ bê bối truy tố Post Office Horizon ở Anh là một ví dụ về oan sai hàng loạt quy mô lớn trong nước Anh hiện đại, cho thấy không chỉ các thất bại cá nhân và tổ chức mà cả vai trò của pháp luật và thủ tục tòa án
- Tòa án giả định rằng thiết bị máy móc hoạt động bình thường nếu không có chứng cứ ngược lại, và điểm xuất phát này cũng được áp dụng cho hồ sơ máy tính
- Dưới giả định về chứng cứ này, chỉ riêng hồ sơ máy tính cũng có thể chứng minh các sự việc như khoản thiếu hụt kế toán, tạo ra một cấu trúc trong đó bị cáo phải chứng minh có lỗi
- Section 69 của Police and Criminal Evidence Act 1984 đặt ra quy tắc ngược lại, theo đó bên công tố phải cho thấy máy tính hoạt động bình thường, nhưng điều khoản này đã bị bãi bỏ vào năm 1999
- Nếu Section 69 vẫn còn hiệu lực thì cách các vụ truy tố của Post Office được tiến hành có thể đã khác, và sau khi bị bãi bỏ, gánh nặng lại chuyển về phía bị cáo
Vụ bê bối Post Office Horizon và trách nhiệm của thủ tục pháp lý
- Post Office prosecutions scandal được xem là một trong những vụ oan sai hàng loạt lớn nhất của nước Anh hiện đại
- Vụ việc chồng chất cả thất bại cá nhân lẫn thể chế, đồng thời tài liệu pháp lý và chứng cứ cũng đồ sộ đến mức khó nắm bắt toàn bộ
- Phán quyết then chốt năm 2019 của Ngài Justice Fraser gồm hơn 1.000 đoạn, chưa kể các phụ lục
- Cuốn sách liên quan của Nick Wallis và cuộc điều tra công khai lần theo diễn biến vụ việc và các biện pháp ngăn tái diễn
- Nhiều phân tích tập trung vào các thất bại của ban lãnh đạo Post Office, luật sư và nhà cung cấp phần mềm Fujitsu
- Tuy nhiên, luật và thủ tục được áp dụng cũng là một phần của vụ việc, và trách nhiệm không vì thế mà nhẹ đi, bởi những người ra quyết định đã biết hoặc lẽ ra phải biết rằng chúng có thể vận hành một cách khắc nghiệt với bị cáo
Giả định chứng cứ rằng “máy tính hoạt động bình thường”
- Giả định (presumption) theo cách các luật gia sử dụng là một cơ chế mà theo đó, nếu không có chứng cứ ngược lại, tòa án chấp nhận một trạng thái nhất định làm mặc định
- Cách diễn đạt kinh điển là: “nếu không có chứng cứ ngược lại, tòa án giả định rằng thiết bị máy móc ở trong tình trạng bình thường tại thời điểm liên quan”
- Ở đây, thiết bị máy móc cũng bao gồm cả máy tính
- Giả định này không có nghĩa là tòa án luôn phải tin máy tính trong mọi trường hợp, mà là một điểm xuất phát có thể bị bác bỏ bằng chứng cứ
- Chừng nào trạng thái ngược lại chưa được chứng minh, tòa án có thể chấp nhận trạng thái đó là sự thật
Vì sao cần giả định và những rủi ro
- Bản thân việc tòa án sử dụng giả định không phải là vấn đề; nếu không có giả định thì trên thực tế sẽ rất khó xử lý nhiều vụ việc
- Giả định giúp thu hẹp các điểm tranh chấp của vụ án xuống phạm vi có thể quản lý được
- Hợp đồng có thể được xem là không phải tài liệu gian lận trừ khi được chứng minh là giả mạo
- Bị cáo có thể được xem là không mắc bệnh tâm thần trừ khi được chứng minh là có
- Điểm mấu chốt là trạng thái nào được chọn làm mặc định, và bên nào phải phá vỡ mặc định đó
- Nếu nội dung của giả định thiếu thực tế hoặc điều kiện phản bác quá khó, thì giả định không còn là công cụ hỗ trợ tư pháp mà trở thành công cụ tạo ra oan sai
Cấu trúc trong đó hồ sơ máy tính trở thành tiền đề của kết tội
- Quy tắc cho rằng máy tính hoạt động bình thường là một giả định về chứng cứ
- Nếu không có chứng cứ cho thấy máy tính hoạt động không đúng, tòa án có thể xem chỉ riêng hồ sơ máy tính là đã chứng minh được sự việc liên quan
- Ví dụ, nếu hồ sơ máy tính cho thấy khoản thiếu hụt tài chính của một trưởng bưu cục hoặc nữ nhân viên bưu điện, tòa án có thể chấp nhận đó là chứng cứ về khoản thiếu hụt thực tế
- Muốn làm lung lay tiền đề này, bị cáo phải cho thấy máy tính đã không hoạt động bình thường
- Khi chứng cứ cốt lõi của việc truy tố là hồ sơ máy tính, cấu trúc đó rốt cuộc trở thành “computer says guilty”
Việc đưa vào và bãi bỏ Section 69
- Giả định về chứng cứ này không phải lúc nào cũng vận hành theo cùng một hướng
- Section 69 của Police and Criminal Evidence Act 1984, được ban hành năm 1984, đã đảo ngược hướng của giả định
- Theo Section 69, không phải bị cáo phải chỉ ra lỗi máy tính, mà bên công tố phải chứng minh máy tính hoạt động bình thường
- Điều khoản này đã thay thế lập trường thông luật trước đó rằng “nếu không có chứng cứ ngược lại thì thiết bị máy móc được giả định là ở trong tình trạng bình thường”
- Nếu Section 69 vẫn còn hiệu lực khi Post Office truy tố các trưởng bưu cục và nữ nhân viên bưu điện, diễn biến vụ việc có thể đã khác
- Section 69 đã bị bãi bỏ vào năm 1999, và giả định theo thông luật trước đó quay trở lại
- Từ đó trở đi, cấu trúc không còn là công tố viên phải trước tiên chứng minh máy tính hoạt động bình thường, mà là bị cáo phải chứng minh máy tính đã không hoạt động bình thường
- Section 69 đã bị bãi bỏ như thế nào và liệu lý do bãi bỏ có thỏa đáng hay không vẫn là chủ đề cho phần tiếp theo của bài viết
1 bình luận
Các ý kiến trên Hacker News
Ấn tượng của tôi khi lần cuối xem xét vụ bê bối Post Office là câu “chúng ta đã quá tin vào hệ thống IT” gần như chỉ là một lời biện hộ tiện lợi
Cấp trên dường như đã biết rõ vấn đề, cũng biết rằng họ đang truy tố những người vô tội, nhưng vẫn thúc đẩy để che đậy thất bại của chính mình. Nếu đúng vậy thì cần có án tù thực sự đáng kể. Cản trở công lý không phải là tội nhẹ, và còn có cáo buộc rằng Paula Vennells đã cố ý nói dối trước Quốc hội
Vì vậy, do phân biệt chủng tộc, hội đồng quản trị Post Office có một rào cản tâm lý khiến họ không thể nối các manh mối lại với nhau; và ngay cả sau khi đối mặt với bằng chứng áp đảo về hàng trăm bản án kết tội sai, họ vẫn càng cố chấp hơn vì thiếu đạo đức. Đây vừa là câu chuyện đáng buồn về thất bại công nghệ, vừa là lời cáo buộc đối với văn hóa hội đồng quản trị ở Anh. Tạp chí Private Eye đã theo dõi thảm họa này hơn 10 năm
Chẳng phải sẽ đúng hơn nếu lập luận rằng nên loại bỏ quyền lực đó về mặt cấu trúc sao
Sau cả đời sửa lỗi, đôi khi bản thân việc các hệ thống máy tính überhaupt hoạt động đã là điều đáng ngạc nhiên
Cá nhân tôi cũng từng gặp chuyện tương tự hệ thống thất bại của Post Office: dù đưa ra bằng chứng, mọi người đều bác bỏ khả năng hệ thống máy tính sai. Vì đào sâu để hiểu thì quá phiền phức
Vì đã chứng kiến phần mềm được tạo ra như thế nào, tôi không hiểu nổi làm sao tất cả có thể hoạt động được. Câu trả lời của tôi cho nghịch lý này là: thực ra không phải tất cả đều hoạt động. Chúng ta đã tự huấn luyện mình chấp nhận những thứ không hoạt động như một điều gì đó khác. Người ta hoặc xem hệ thống máy tính như một thực thể toàn năng và không thể sai, hoặc ngược lại coi nó là vật tế thần
Ví dụ, các website của những hãng hàng không như TAP, Vueling, KLM trong 2 năm qua khi tôi dùng thường xuyên có lỗi khiến không thể đặt vé hoặc đăng nhập tài khoản, và tôi thấy số lần không hoạt động còn nhiều hơn số lần hoạt động. Instagram và Google đã tự động vô hiệu hóa tài khoản không vì lý do rõ ràng; riêng Instagram, sau khi gặp 3 lần trong 2 tháng thì tôi bỏ luôn và không dùng nữa. Skype thì ai dùng rồi không cần giải thích; Teams thất bại theo những cách đáng kinh ngạc dù “cập nhật” bao nhiêu lần, như nút tắt tiếng thực tế không tắt tiếng, thứ tự chữ trong câu bị đảo khi gõ chat, hoặc đột ngột thoát và không phản hồi giữa cuộc gọi. Những tổn thất năng suất như vậy hẳn là rất lớn trên toàn cầu, và tiền nhân công mà các công ty lãng phí có thể còn lớn hơn phí license họ trả cho Microsoft. Telegram xử lý màn hình ngoài không đúng khiến tỷ lệ hiển thị hỏng và phải khởi động lại, còn iCloud mất từ vài giây đến khoảng một giờ để đồng bộ tệp dù mọi thiết bị đều có kết nối tốt
Dù liên tục thấy bằng chứng ngược lại, nhưng với tư cách kỹ sư, tôi thấy điều này tự nhiên và hiệu quả. Ta phải đặt ưu tiên, và có lỗi ít quan trọng hơn lỗi khác. Tôi nghĩ thay vì sửa mọi lỗi trong mọi phần mềm, tốt hơn nên dồn nhiều nỗ lực hơn cho giáo dục, y tế và nghiên cứu cơ bản
Vì vậy, khi bắt đầu thất bại trong 1% trường hợp, mọi người phớt lờ vì nó đã hoạt động trong 99% trước đó. Họ đã được huấn luyện để tin vào kết quả nên thậm chí không nảy sinh nghi ngờ. Tôi nhớ đến cuốn Systemantics: https://www.amazon.com/Systemantics-Systems-Work-Especially-...
Một trong những luận điểm cốt lõi của cuốn sách là ngộ nhận vận hành rằng “hệ thống không thực sự làm việc mà nó nói là mình làm”. Không chỉ người thường mà cả kỹ sư cũng hay quên điều này. Chỉ vì một hệ thống nói rằng nó làm X không có nghĩa là nó thực sự làm X. Ta cần nuôi dưỡng sự hoài nghi lành mạnh đối với các hệ thống IT phức tạp. Phần lớn thời gian có thể nó không thất bại, nhưng rốt cuộc một ngày nào đó nó sẽ thất bại
Ít nhất tôi cảm thấy vậy
Một vấn đề lớn của các vụ truy tố này là bên có quyền truy tố lại chính là Post Office
Trước vụ này tôi không biết Post Office có quyền như vậy. Trên thực tế, Post Office vừa là bên tố cáo vừa là cơ quan truy tố. “Post Office Investigation Branch (IB) là tổ chức điều tra hình sự được công nhận lâu đời nhất thế giới. Trong hơn 335 năm, tổ chức này đã phát hiện các tội phạm liên quan đến bưu chính và truy tố những người phạm tội đó.”
https://www.postalmuseum.org/blog/the-post-office-investigat...
Về lý thuyết, đó là một phương tiện để buộc người có quyền lực chịu trách nhiệm, nhưng chi phí rất đắt, nên gần như mọi vụ tư tố trên thực tế đều do các doanh nghiệp khởi xướng
Đây là lần đầu tôi nghe về vụ bê bối này
Tôi tò mò vấn đề chính của phần mềm gây ra sai lệch là gì. Kiểu như mất kết nối chăng? Wikipedia không nói chi tiết. Tôi tìm thấy ở đây: https://www.benthamsgaze.org/2021/07/15/what-went-wrong-with...
Tôi muốn khuyên bạn tìm hiểu thêm, nhưng phải có tinh thần thật vững. Nhiều người đào sâu vào vụ này đã phải tìm cái xô gần đó. Nội dung thật sự rất khó xem
Các hệ thống lớn hầu như luôn có bug trong quá trình phát triển, nhưng thường thì chúng được phát hiện và sửa. Ở đây bug đã được phát hiện nhưng không được sửa
Giả định mặc định của tôi là máy tính không hoạt động đúng
Vì tôi đã thấy quá nhiều trường hợp thực tế nó không hoạt động đúng. Khi lái xe tôi cũng không tin nguyên xi Google Maps; tôi kiểm tra xem tuyến đường có hợp lý không, rồi nhìn lại tên đường và số lối ra ở chỗ nó bảo rẽ. Tôi đã bị dính quá nhiều lần rồi
Theo kinh nghiệm của tôi với tư cách lập trình viên, bản thân máy tính thường hoạt động đúng
Trường hợp là bug phần cứng rất hiếm. Nhưng phần mềm thì luôn sai, còn phần cứng máy tính chỉ mù quáng thực thi những gì phần mềm bảo nó làm
“Cứ sửa trong phần mềm là được” gần như có thể là khẩu hiệu chính thức của ngành phần cứng
Ở đây “máy tính” nghĩa là một hệ thống gồm phần cứng và phần mềm, và từ “máy tính” hầu như luôn được dùng theo nghĩa đó. Vấn đề là tòa án giả định máy tính hoạt động bình thường nếu không có bằng chứng ngược lại. Tức là tòa có thể cho rằng chỉ riêng hồ sơ máy tính đã đủ chứng minh các sự kiện liên quan, và nếu bị cáo không thể cho thấy máy tính đã không hoạt động đúng, tòa sẽ chấp nhận rằng giám đốc bưu cục có khoản thiếu hụt tài chính. Nói ngắn gọn, nếu trọng tâm của vụ truy tố là hồ sơ máy tính, thì thành ra máy tính nói rằng người đó có tội
Phần mềm chạm trực tiếp vào phần cứng ở mức rất thấp thường được kỳ vọng sẽ bù trừ cho những chỗ gồ ghề này
Một ví dụ cũ là CPU Intel Pentium có hai lỗi nổi tiếng được phát hiện sau khi phát hành. Lỗi chia số thực dấu phẩy động FDIV dẫn đến đợt thu hồi năm 1994, và lỗi F00F được phát hiện năm 1997 khiến bộ xử lý bị treo cho đến khi khởi động lại.
https://en.m.wikipedia.org/wiki/Hardware_bug
Vì phần lớn thời gian nó hoạt động, nên hầu như luôn bị xem là lỗi người dùng. Nếu không biết phải tìm gì, bạn chỉ loại trừ những trường hợp lỗi mình biết, rồi đi đến một phán quyết sai lầm khủng khiếp như trong bài trên
Giả định này chủ yếu trở thành vấn đề khi bên vận hành máy tính cũng là cùng một bên đang truy tố/đàn áp người kia
Đây đúng là vấn đề tòa án nên giả định điều gì, nhưng cũng đáng hỏi các lập trình viên phần mềm giả định hay không giả định điều gì
Lập trình viên phần mềm có lẽ sẽ giả định rằng phần mềm được dùng rộng rãi thì hoạt động đúng. Dù GitHub issue có 3.500 bug của pandas, họ vẫn coi JavaSDK hay thư viện pandas là hoạt động đúng. Nhưng nếu tích hợp một thư viện ít được biết đến hơn, hoặc dùng phần mềm ít nổi tiếng hơn, họ sẽ kém chắc chắn hơn về việc nó hoạt động
Theo nghĩa là rồi sẽ có hàng nghìn người phàn nàn trong nhiều năm. Nói ít hoài nghi hơn, ta có thể kỳ vọng các chức năng được dùng rộng rãi của phần mềm được dùng rộng rãi đã được kiểm thử trong điều kiện thực tế, nên nếu có bug thì ít nhất khả năng cao là nó đã được biết đến. Nhưng chỉ riêng không gian trạng thái của phần mềm có độ phức tạp trung bình cũng đã cần lượng kiểm thử khổng lồ để bao phủ hết. Cứ nhìn bộ kiểm thử của SQLite lớn đến mức nào là thấy. Cách tiếp cận duy nhất có vẻ hoạt động tốt để tạo phần mềm ít bug là ghép các bộ phận nhỏ, tự hoàn chỉnh, tách biệt và được hiểu rõ, để toàn thể trở nên dễ suy luận hơn. Đây vốn là triết lý Unix, là triết lý của lập trình hàm, và cũng là một phần triết lý của hệ thống actor, dù việc suy luận về tương tác bất đồng bộ khó hơn. Tôi kỳ vọng sẽ thấy cách tiếp cận này xuất hiện ngày càng nhiều hơn trong thực tế
Tiêu đề có lẽ gần như là ngược lại của clickbait
Bài viết nói về vụ bê bối Post Office, nhưng đã nắm lấy một chủ đề lớn thật sự
Liên kết lưu trữ: https://archive.ph/wip/AJl8i