Chuyến thăm tòa án về SQL injection
(sockpuppet.org)- Nguyên tắc công khai rộng rãi của FOIA Illinois đã bị thử thách trước schema cơ sở dữ liệu của cơ quan công quyền, và yêu cầu về cơ sở dữ liệu vé phạt đỗ xe Chicago CANVAS đã dẫn đến kiện tụng và thảo luận lập pháp
- FOIA bảo đảm mạnh mẽ việc công khai thông tin hiện có, nhưng không thể buộc tạo hồ sơ mới; vì vậy, dữ liệu càng nằm trong ứng dụng thì schema cho biết nên yêu cầu truy vấn nào càng trở nên quan trọng
- Chicago phản bác rằng schema CANVAS đe dọa an ninh, và trọng tâm phiên tòa là việc công khai schema có thực sự khiến tấn công SQL Injection trở nên khả thi hoặc dễ dàng hơn hay không
- Ở sơ thẩm và phúc thẩm, phía công khai đã thắng, nhưng Illinois Supreme Court xem file layout tự thân là đối tượng được miễn trừ và phán quyết rằng SQL schema cũng thuộc diện này
- Hiện các cơ quan công quyền Illinois có thể từ chối công khai schema cơ sở dữ liệu, còn SB0226 muốn bắt buộc cung cấp mô tả cấu trúc cơ sở dữ liệu để người yêu cầu có thể đề nghị truy vấn cơ sở dữ liệu cụ thể
Vấn đề Illinois FOIA gặp phải trước cơ sở dữ liệu
- Illinois FOIA về nguyên tắc xem thông tin do cơ quan công quyền thu thập là tài sản công, với các ngoại lệ hạn chế
- Người yêu cầu thường không bị tính phí
- Cơ quan công quyền không thể dễ dàng giới hạn số lượng yêu cầu
- Thời hạn phản hồi mặc định là 5 ngày, và có thể thêm 5 ngày nếu có yêu cầu gia hạn bằng văn bản
- Nếu kiện vì bị từ chối không chính đáng, có thể thu hồi chi phí luật sư
- Hạn chế lớn là FOIA không thể buộc cơ quan công quyền tạo hồ sơ mới
- Nếu báo cáo mong muốn đã tồn tại, có thể yêu cầu báo cáo đó
- Nếu không tồn tại, phải yêu cầu dữ liệu thô rồi tự lắp ghép
- Khi thông tin của cơ quan công quyền ngày càng nằm nhiều hơn trong các ứng dụng và cơ sở dữ liệu chuyên biệt, thay vì tủ hồ sơ, ổ đĩa dùng chung hay tài liệu Word, giá trị của schema tăng lên
- Schema cơ sở dữ liệu là cấu trúc chứa tên của nhiều bảng và tên cột của từng bảng
- Bài viết ví nó như một tệp Excel có nhiều tab
- Tên của mỗi tab và hàng tiêu đề của từng tab tương ứng với schema
Yêu cầu schema CANVAS của Matt Chapman
- Matt Chapman được giới thiệu là một civic hacker làm báo chí dữ liệu bằng cách tận dụng các yêu cầu FOIA quy mô lớn
- Trong quá trình làm việc với dữ liệu vé đỗ xe của Chicago, một hệ thống tên CANVAS xuất hiện
- CANVAS là kho lưu trữ trung tâm chứa toàn bộ dữ liệu vé đỗ xe của Chicago
- Matt Chapman đã yêu cầu schema qua FOIA để hiểu trong cơ sở dữ liệu CANVAS có những gì
- Chicago từ chối yêu cầu dựa trên điều khoản ngoại lệ liên quan đến xử lý dữ liệu tự động trong Illinois FOIA
- Điều khoản này bao gồm phần mềm, giao thức vận hành, mô tả chương trình, file layouts, danh sách nguồn, module, hướng dẫn người dùng, tài liệu thiết kế logic/vật lý, sổ tay nhân viên, v.v.
- Thông tin có thể đe dọa hệ thống hoặc an ninh dữ liệu nếu công khai cũng được liệt kê là ngoại lệ
- Chicago gọi Matt Chapman là “hacker” và lập luận rằng nếu schema CANVAS rơi vào tay kẻ xấu, nó có thể gây nguy hiểm cho thành phố
Vấn đề kỹ thuật cốt lõi tại tòa: SQL Injection
- Câu hỏi trung tâm của phiên tòa là việc công khai schema CANVAS có khiến tấn công SQL Injection trở nên khả thi hay không
- SQL là ngôn ngữ được nhiều chương trình dùng để giao tiếp với cơ sở dữ liệu, còn SQL Injection là lỗ hổng bảo mật có thể xảy ra trong các chương trình dùng SQL
- SQL Injection xảy ra khi đầu vào của người dùng bị chèn sai vào mẫu truy vấn SQL trong mã ứng dụng
- Ví dụ, trong một truy vấn đặt tên trong dấu nháy, đầu vào có chứa dấu nháy như
Bob O’Connorcó thể khiến cách diễn giải của cơ sở dữ liệu bị rối - Kẻ tấn công có thể lợi dụng các điểm nhập liệu như vậy để khiến phần còn lại của đầu vào được thực thi như mã
- Ví dụ, trong một truy vấn đặt tên trong dấu nháy, đầu vào có chứa dấu nháy như
- CISO của Chicago, Bruce Coffing, lập luận rằng việc công khai schema giúp kẻ tấn công theo ba cách
- Giúp tìm lỗ hổng
- Giúp việc dò tìm lỗ hổng kín đáo hơn
- Giúp chọn ứng dụng đáng để tấn công
- Lập luận phản bác tập trung vào việc schema không phải là nơi để tìm lỗ hổng SQL Injection
- Lỗ hổng SQL Injection được tìm trong mẫu truy vấn SQL của mã nguồn ứng dụng, chứ không phải trong schema cơ sở dữ liệu
- Đối tượng được yêu cầu là schema, gần giống hàng tiêu đề của các bảng, chứ không phải mã nguồn
- Kẻ tấn công có thể thu hồi schema bằng SQL Injection; schema gần với kết quả của cuộc tấn công hơn là tiền đề của nó
Phán quyết sơ thẩm và phúc thẩm
- Ở sơ thẩm, phía Matt Chapman thắng
- Chicago lập tức kháng cáo, và Matt Chapman không nhận được schema CANVAS
- Tòa phúc thẩm xử lý vấn đề pháp lý trên tiền đề rằng tòa sơ thẩm là chủ thể chính trong việc xác định sự thật
- Rủi ro do công khai xoay quanh tiêu chuẩn “would jeopardize”
- “could” chỉ mức có thể tưởng tượng rằng một việc có thể xảy ra
- Tiêu chuẩn pháp lý của “would” được mô tả là bằng chứng rõ ràng về nguy hại, không để lại nghi ngờ hợp lý cho thẩm phán
- Tòa phúc thẩm phán quyết theo hướng khả năng gây hại phải rất cao
- Tòa phúc thẩm xem xét liệu cụm giới hạn trong điều khoản ngoại lệ chỉ áp dụng cho “any other information”, hay áp dụng cho toàn bộ “Administrative or technical information” của ngoại lệ
- Nếu chỉ áp dụng cho “any other information”, thì file layouts và các mục tương tự tự thân được miễn trừ
- Nếu áp dụng cho toàn bộ ngoại lệ, phía Matt Chapman có thể thắng chỉ bằng xác định thực tế rằng việc công khai không đe dọa an ninh
- Tòa phúc thẩm cho rằng cụm giới hạn áp dụng cho toàn bộ ngoại lệ và xử thắng cho phía Matt Chapman
Kết luận bị đảo ngược tại Illinois Supreme Court
- Chicago tiếp tục kháng cáo, và vụ việc lên Illinois Supreme Court
- Illinois Supreme Court diễn giải điều khoản ngoại lệ của FOIA khác với tòa phúc thẩm
- Cụm giới hạn chỉ áp dụng cho “any other information”
- Các mục còn lại tự thân là đối tượng được miễn trừ
- Với phán quyết này, việc SQL schema có phải là file layout hay không trở thành vấn đề quyết định
- Có phản biện rằng schema và file layout khác nhau về mặt kỹ thuật
- Cùng một SQL schema có thể được nhiều engine cơ sở dữ liệu sử dụng
- Mỗi engine cơ sở dữ liệu quản lý dữ liệu kết quả bằng một underlying file layout khác nhau
- McGraw-Hill Dictionary of Scientific & Technical Terms, 6E định nghĩa file layout là “mô tả cách sắp xếp dữ liệu trong một tệp”
- SQL schema gần với một lớp trừu tượng được tạo ra để không phải nghĩ về cách sắp xếp thực tế của dữ liệu
- Illinois Supreme Court cũng dùng định nghĩa schema trong Merriam-Webster Online Dictionary là “structured framework or plan: outline”
- Tòa cho rằng khác biệt chỉ nằm ở tên gọi
- Kết quả là schema bị xem là file layout, và phía Matt Chapman thua kiện
Tình trạng hiện tại và SB0226
- Hiện các cơ quan công quyền Illinois có thể từ chối công khai schema cơ sở dữ liệu
- Khi dữ liệu chuyển sang các ứng dụng chuyên biệt, ngày càng có nhiều tình huống phải yêu cầu truy vấn cơ sở dữ liệu qua FOIA để tiếp cận dữ liệu nền tảng
- Vẫn còn vấn đề rằng cơ sở dữ liệu không nên trở thành vùng an toàn giúp chính quyền địa phương tránh công khai thông tin công
- SB0226 muốn bổ sung câu chữ vào luật FOIA để buộc cơ quan công quyền cung cấp mô tả đầy đủ về cấu trúc của mọi cơ sở dữ liệu do họ quản lý
- Mục đích là cho phép người yêu cầu đề nghị cơ quan công quyền thực hiện truy vấn cơ sở dữ liệu cụ thể
- Dự luật này phần lớn gắn với mạch vấn đề mà Matt Chapman đã liên tục nêu ra
1 bình luận
Các ý kiến trên Hacker News
Tôi là nguyên đơn trong vụ kiện này. Tôi vẫn đang viết một bài đồng hành cho bài của tptacek và sẽ sớm xong, nên trong lúc đó có thể đặt câu hỏi ở đây.
Trong khi chờ, bạn cũng có thể tham khảo bài cũ này: https://mchap.io/that-time-the-city-of-seattle-accidentally-...
Tuy nhiên cần nhớ rằng Matt, dù được Loevy and Loevy, một trong những hãng luật dân quyền hàng đầu toàn quốc, hỗ trợ, về mặt kỹ thuật vẫn đã thua. Điều đó cho thấy việc đấu với chính quyền thành phố phi lý và khó khăn đến mức nào, và nếu không có luật sư thì còn tệ hơn nữa.
Điều có lợi cho chúng ta là thay đổi luật, như bài viết đã đề xuất. Nếu Tòa tối cao bang đã ra phán quyết thì nếu không sửa luật coi như hết đường, và Illinois có lịch sử thường xuyên sửa luật FOIA. Tuy vậy, một số sửa đổi trong đó lại theo hướng siết chặt việc không công khai thông tin hơn là mở rộng công khai.
Một thay đổi nữa cần có là áp đặt hình phạt mạnh với các cơ quan thua trong những cuộc chiến như thế này. Ở Illinois, hình phạt chỉ giới hạn ở mức kiểu phạt dân sự 5.000 USD đối với cơ quan. “Phạt dân sự” là gì cũng được định nghĩa khá mơ hồ; trước đây khoản đó được trao cho nguyên đơn, nhưng trong các vụ tôi đấu tranh sau này thì họ chỉ bắt nộp tiền cho quận. Như một công tố viên bang từng nói, kiểu như “thua cũng chẳng sao, tôi chỉ cần viết séc cho chính mình”.
Cuối cùng, hãy cẩn thận với điều bạn yêu cầu trong một vụ kiện. Một phán quyết phúc thẩm như thế này có thể biến chính điều bạn đang đấu tranh chống lại thành luật. Không phải lỗi của ai, nhưng thực tế là chuyện đó xảy ra. Tôi cũng từng nhận được một phán quyết vô lý, thay vì củng cố quyền của tù nhân thì lại xóa bỏ chúng.
'); SELECT col FROM loginssẽ dễ hơn rất nhiều so với phải đoán tên cột sao?Tôi cũng khó phản đối phán định của tòa về schema và cách bố trí tệp. Schema không phải chính bản thân cách bố trí tệp, nhưng tương tự: nó cho biết “các tệp” (bản ghi) được bố trí như thế nào trong “hệ thống tệp” (bảng cơ sở dữ liệu). Chẳng hạn, phi chuẩn hóa rất giống với việc nhúng dữ liệu inline vào trong bản ghi tệp. Quan điểm rằng hệ thống tệp về thực chất cũng là cơ sở dữ liệu cũng khá quen thuộc. Tôi tò mò làm sao có thể lập luận rằng hai thứ này không tương tự nhau.
Tôi tò mò bạn xem bước tiếp theo là gì.
Tôi cho rằng thành phố nên chia sẻ schema, và về cơ bản họ đang viện dẫn bảo mật bằng sự mơ hồ, nhưng tôi không đồng ý với tiền đề cốt lõi của bài viết rằng “biết schema SQL cũng không giúp ích cho kẻ tấn công”.
Tôi hiểu lập luận của bài là: “Kẻ tấn công khôi phục schema SQL bằng tấn công SQL injection. Schema không phải là tiền đề của cuộc tấn công, mà là sản phẩm của cuộc tấn công.” Điều này có vẻ muốn nói rằng nếu tìm được lỗ hổng thì dù sao cũng có thể khôi phục schema, nhưng không phải lúc nào cũng vậy. Một số SQL injection chỉ có thể lấy một phần dữ liệu trong bảng đang được truy vấn hiện tại, chứ không lấy được các bảng khác như
information_schema. Nếu tín hiệu nhận được từ lỗ hổng chỉ là “truy vấn thất bại” hoặc “truy vấn thành công, có trả dữ liệu”, thì biết schema sẽ khiến việc khai thác dễ hơn nhiều.Nếu các truy vấn cơ sở dữ liệu thất bại được ghi log riêng, thì những điểm injection mà một cuộc tấn công chạy 24/24 có thể tìm ra nhiều khả năng đã được vá rồi. Khi đó log có thể không ồn ào cho đến khi phát hiện ra một điểm injection thực sự, chẳng hạn lỗ hổng chỉ tồn tại với người dùng đã đăng nhập nên bot không tìm thấy; lúc đó bạn vẫn có thời gian nhìn thấy và sửa trước khi kẻ tấn công thực sự tìm ra cách khai thác.
Biết schema không chỉ làm tăng tốc độ khai thác lỗ hổng, mà còn làm tăng khả năng dò tìm injection ngay từ đầu mà không gây ra lỗi truy vấn.
Tiêu chí không nên là “kiểm duyệt mọi thông tin có ích”, mà nên là “đừng công khai mã để lộ mật khẩu hoặc backdoor”. Schema không thể thuộc phạm trù đó.
Dù vậy, tôi từng thực sự xử lý các ứng dụng mà việc biết schema giúp rò rỉ dữ liệu ngay cả khi không có injection hoàn chỉnh. Ví dụ rõ nhất là khi truy vấn được xây dựng dựa trên tham số URL, nhưng các tham số đó không bị giới hạn bằng allowlist.
Vì vậy tôi đồng ý rằng schema có thể đem lại một chút lợi thế cho kẻ tấn công.
https://brutecat.com/articles/leaking-youtube-emails
Vì vậy tôi nghĩ lập luận đó không đứng vững.
Trong log máy chủ không có gì thể hiện lỗi cả.
Phần lớn các bài thực hành SQL injection ở mức khá nhập môn mà tôi từng dạy cũng được thực hiện khi không biết schema. Vì vậy SQL injection mới tinh vi và nguy hiểm đến vậy.
Kurt đăng cái này để dụ tôi vào. Cũng nên biết rằng độc giả mục tiêu ban đầu phần lớn là những người không chuyên kỹ thuật tham gia chính trị chính quyền địa phương ở khu Chicagoland của tôi
Nếu làm một đoạn quảng bá lợi ích công về chính trị địa phương thì: tham gia chính trị toàn quốc u ám và làm nản lòng như một con côn trùng bay đập vào kính của tòa nhà chọc trời. Ngược lại, chính trị địa phương phản hồi rất tốt. Tôi đã tạo được kết quả thực tế trong thời gian rảnh và gần như không tốn chi phí, thậm chí còn giúp thông qua một luật. Khác một trời một vực với chính trị toàn quốc
Điều đáng ngạc nhiên ở nhiều nơi là chính trị địa phương vận hành xoay quanh các diễn đàn. Diễn đàn đó có thể không phải nơi bạn muốn ở, và đặc biệt là có rất nhiều Facebook Group, nhưng cứ phải chấp nhận thôi. Nếu bạn thích tham gia các cộng đồng như HN, bạn cũng có thể tham gia chính trị, và chỉ bằng hoạt động trên diễn đàn cũng có thể làm cho việc thành công
Thực ra ngay trong Mỹ cũng có nhiều trường hợp như thế. Chỉ các chính quyền địa phương có quyền home rule mới có thể ban hành sắc lệnh về bất kỳ chủ đề nào miễn là không xung đột với luật tiểu bang/liên bang; còn các chính quyền địa phương không có quyền này chỉ có thể ban hành về những chủ đề cụ thể mà nghị viện tiểu bang cho phép. Có bang trao home rule cho tất cả quận và đô thị, có bang không trao gì cả, và có bang chỉ trao cho một số nơi. Ví dụ ở Texas, một đô thị có thể có quyền home rule sau khi đạt dân số 5.000 người và được cử tri phê chuẩn
Tôi cũng muốn biết bạn có thể chia sẻ các tài liệu tham khảo tốt, trên Facebook hay nơi khác, cho người muốn tham gia nhiều hơn vào chính trị Chicago không. Trước đây tôi từng tìm thử nhưng kết quả rất hạn chế
Không phải thật vô lý khi Tòa Tối cao và tòa phúc thẩm bất đồng về vấn đề cấu trúc câu sao? Bỏ qua chuyện điều đó là thường gặp, cá nhân tôi thấy cách diễn giải “mọi bố trí tệp và các mục khác cũng thuộc phạm vi, nhưng các mục khác đó chỉ là những thứ xấu” là vô lý. Thật lạ khi thực tế lại chấp nhận việc điều khoản luật bị bỏ lại trong trạng thái hoàn toàn mơ hồ
Tôi cũng biết sự mơ hồ như vậy có lợi cho các tòa án vì họ có thêm quyền tùy nghi, và dù có những nỗ lực dũng cảm thì cũng không thể biến ngôn ngữ pháp luật thành một ngôn ngữ “hoàn chỉnh về hình thức”. Tôi biết luật pháp lộn xộn, và luật được viết bởi những con người ngây thơ đầy lỗi lầm
Nhưng nếu cấu trúc câu cơ bản được viết trong luật mà ngay cả tòa án cũng không thấy rõ ràng, chẳng phải toàn bộ hệ thống đã thất bại ngay từ cửa đầu tiên sao?
Thông thường câu trả lời là luật nên được viết sao cho không mơ hồ, nhưng nói dễ hơn làm. Hơn nữa, chính các nhà lập pháp đôi khi cũng không hoàn toàn đồng thuận, nên họ cố ý để một số câu chữ mơ hồ cho tòa án diễn giải
Có phải chỉ mình tôi thấy hơi bối rối và lo ngại khi phần ngoại lệ mã nguồn được đưa thẳng vào không?
Có thể dễ dàng tưởng tượng một kịch bản trong đó thành phố tự phát triển một phần mềm nào đó nội bộ, rồi giấu trong mã nguồn những “thiên lệch” hoặc yếu tố khác mà họ không muốn bị thấy
Thậm chí cũng không cần phải xây tất cả từ đầu. Chỉ cần vá một component bên thứ ba có giấy phép dễ dãi rồi dùng là được
Theo tôi, đề xuất sửa đổi chưa đi đủ xa
Đây là cùng vấn đề mà những người muốn chuyển một dự án đóng sang mã nguồn mở gặp phải. Khắp nơi đều bị khóa bởi mã độc quyền mà nhà phát triển và khách hàng chỉ có quyền sử dụng chứ không có quyền chia sẻ mã nguồn
Ngay cả một dự án được xây từ đầu với định hướng mở mạnh mẽ, không có lợi ích thương mại trực tiếp như một nhà thầu chính phủ, cũng có thể gặp vấn đề này. Những vấn đề mà Linux kernel gặp phải khi hỗ trợ ZFS hoặc các driver blob nhị phân ở ranh giới kernel/user space là chuyện đã biết rõ[1]
Nghịch lý là một mặt thông tin muốn được tự do, và về mặt kinh tế thì phần mềm nguồn mở theo thời gian sẽ đẩy lùi các đối thủ đóng. Nhưng bản thân việc chuyển một dự án sang nguồn mở lại đắt đỏ và đôi khi đắt đến mức không thể gánh nổi, khiến các quản trị viên và công ty không thể công bố các công cụ cũ dù họ muốn. Chỉ riêng việc lôi đội pháp lý vào và tìm chủ sở hữu quyền của từng component cũng đủ khiến hầu hết quản trị viên bỏ cuộc
Nếu chính phủ yêu cầu trong hợp đồng rằng nhà cung cấp chỉ được dùng các component nguồn mở trong toàn bộ cây phụ thuộc, chi phí có thể trở nên rất cao. Lý do là nhiều phụ thuộc không có phương án nguồn mở tương đương, hoặc phương án đóng có những chức năng còn thiếu nên cần ngân sách để lấp khoảng trống. Trong ngắn hạn, không hội đồng nào chấp nhận khoản chi phí bổ sung đó, nhưng về dài hạn công chúng sẽ được lợi
[1] Đúng là vấn đề kernel phần lớn là một hàm của GPL. Với các giấy phép dễ dãi hơn như Apache 2 hay MIT thì hẳn không có vấn đề đó, và các hệ BSD cũng không gặp khó khăn với hỗ trợ ZFS. Tuy nhiên, lập trường rằng về nguyên tắc chính phủ nên làm các ứng dụng công ở dạng nguồn mở, xét từ góc độ giấy phép, gần với GPL hơn MIT. Nếu không, nhà cung cấp có thể đưa những phần thật sự quan trọng vào mã blob nhị phân được “vendor” kèm theo, còn các component công khai chỉ giữ một bộ khung vô nghĩa để đáp ứng yêu cầu
Tuy nhiên, những phán quyết như thế này có thể tạo hiệu ứng làm nản lòng
Theo tôi nhớ, chính phủ liên minh trước đây của Đức, nay đã thất bại, đã đưa điều này vào cam kết nhưng không thực hiện được. Chính phủ mới có thể sẽ làm
Một bài viết rất thú vị
Việc xem việc công khai schema là đối tượng cần bảo vệ nghe có vẻ phi lý. Nếu đúng như phần giải thích, có thể dẫn đến một kết quả như phép màu kiểu “vì nó nằm trong cơ sở dữ liệu nên không thể biết gì cả, và nếu không nói được cách tìm thì coi như xong”
Ở vị trí làm việc tại một công ty nhỏ có nhiều khách hàng, tôi không muốn đưa nguyên schema cơ sở dữ liệu ra, nhưng dù vậy vẫn sẽ cố tìm và cung cấp dữ liệu khách hàng muốn, chứ không từ chối
Tôi đã yêu cầu hơn 1 triệu trang tài liệu về cơ sở dữ liệu chất lượng nước của Mỹ theo FOIA cho dự án cleartap.com
Phần lớn các bang chỉ tính một khoản nhỏ để thu thập tài liệu
Michigan yêu cầu 50.000 USD cho yêu cầu FOIA. Tôi nghĩ là vì vụ ô nhiễm chì ở Flint. Có vẻ họ muốn làm tôi bỏ cuộc
Dự án rất tuyệt
“Hãy lấy toàn bộ dữ liệu vé phạt đỗ xe đã phát cho Bob O, rồi lấy cả mọi thông tin còn lại trong cơ sở dữ liệu và mật khẩu của tất cả mọi người.”
Đây là một ví dụ SQL injection viết bằng tiếng Anh thường, nhưng ở đây “everyone's” cũng có vấn đề vì tạo ra một dấu nháy đơn lẻ mồ côi. Nếu “Bob O'Conner” là xấu thì “everyone's” cũng xấu
“Mã nguồn của các chương trình mà họ chạy nói chung cũng không thể được yêu cầu theo FOIA.”
Đáng tiếc là tôi nghĩ phần đó lẽ ra phải là bất hợp pháp theo FOIA
Mã nguồn nên là mã nguồn mở và có thể kiểm chứng. Nếu trở thành ngoại lệ FOIA, nó sẽ né tránh niềm tin của công chúng đối với việc chính phủ sử dụng phần mềm
Tôi tò mò tòa án đã phán quyết những vấn đề như thế này ở đâu và như thế nào
Trên thực tế, cũng có thể có logic nghiệp vụ mà cơ quan chính phủ muốn giữ bí mật và về mặt pháp lý được phép làm vậy. Nếu là cơ sở dữ liệu vé phạt đỗ xe trong bài gốc, mã nguồn của phần mềm giao tiếp với cơ sở dữ liệu đó có thể chứa logic chọn thời điểm và địa điểm nhân viên kiểm soát đỗ xe sẽ “ngẫu nhiên” mở các đợt kiểm tra tập trung
Chính những điều như thế này đã làm tôi nản ý định vào trường luật. Một phần đáng kể của kiện tụng giống như sân khấu Kabuki; nó trông không giống nghệ thuật biện luận để đạt được kết quả công bằng hay logic, mà giống nghệ thuật biện luận nhằm trao cho người có thẩm quyền một cái cớ để đưa ra quyết định mà họ đã muốn đưa ra từ trước phiên tòa
Ai đó hoàn toàn có thể thiết lập một hệ thống kiểu tường lửa web hợp pháp để quét các từ khóa như
information_schematrong request HTTP và các biến thể mã hóa của chúng. Những thứ này luôn là nỗ lực hack nên có thể chặn. Nếu đã biết schema, người ta có thể tạo truy vấn mà không cần trước hết vượt qua rào cản đó. Khả năng đây là một rào cản nghiêm túc có cao không? Không. Nó có liên quan gì đến tính tự quy về mình không? Có vẻ khôngNói rằng nó có giá trị rất nhỏ, chỉ theo nghĩa “ngoại vi”, tức không phải cốt lõi và không đủ quan trọng để bàn, có vẻ là chính xác. Nhưng khi chỉ nói sự thật, phía bên kia lại phóng đại nó để thuyết phục tòa rằng “đấy, chuyên gia bên kia cũng nói là có giá trị”. Vì vậy họ kết luận rằng chuyên gia lẽ ra chỉ nên nói “không có giá trị”. Tôi cho rằng câu đó là sai, nhưng sai quá nhỏ đến mức khó chứng minh rằng phía bên kia không hoàn toàn đúng. Cuối cùng, cách nói kém chính xác hơn lại có lợi hơn trong phòng xử án này, và tu từ trở nên quan trọng không kém vai trò chuyên gia