- Một người yêu cầu hồ sơ công khai chỉ yêu cầu metadata như người gửi, người nhận, cc, thời gian và ngày tháng của email
seattle.govtrong năm 2017, nhưng thành phố Seattle đã cung cấp một tệp chứa cả 256 ký tự đầu của khoảng 32 triệu email - Seattle IT ban đầu ước tính việc rà soát sẽ tốn 320 năm công sức nhân viên và 33 triệu USD tiền lương, nhưng sau đó hạ chi phí đợt đầu xuống 1,25 USD với lý do đây là metadata không có nội dung thư nên không cần rà soát
- Khoảng 400 tệp được đưa lên cổng hồ sơ công khai có lẫn thông tin nhạy cảm như tên người dùng và mật khẩu, số thẻ tín dụng, số an sinh xã hội, bằng lái xe, thông tin điều tra của cảnh sát và FBI, cảnh báo Zabbix
- Khi người yêu cầu báo vấn đề, Seattle đã tạm dừng quyền truy cập GovQA và nói sẽ xử lý lại bản đã sửa; sau đó còn yêu cầu xóa tệp, quét ổ cứng qua Kroll và đưa ra điều kiện miễn trừ trách nhiệm pháp lý
- Cuối cùng người yêu cầu đã xóa các tệp, thực hiện bản khai và các bước dọn dẹp đĩa; từ ngày 26/1/2018 Seattle bắt đầu cung cấp theo từng phần đúng phần metadata được yêu cầu ban đầu, và đến thời điểm bài viết đã giao 27 triệu bản ghi
Điểm khởi đầu của yêu cầu hồ sơ công khai
- Sau khi từng yêu cầu metadata điện thoại và email của văn phòng thị trưởng Chicago, người yêu cầu mở rộng các yêu cầu hồ sơ công khai để kiểm tra xem vấn đề tương tự có xuất hiện mang tính hệ thống ở nhiều nơi tại Mỹ hay không, đồng thời lập bản đồ cấu trúc liên lạc
- Người này đã nộp hơn 100 yêu cầu metadata email trên khắp nước Mỹ, tối thiểu 2 yêu cầu cho mỗi bang
- Đợt yêu cầu quy mô lớn đầu tiên được gửi đến thành phố lớn nhất của 14 bang được chọn ngẫu nhiên, và cuối cùng chỉ còn Houston và Seattle là nơi người này cố theo đuổi đến cùng
- Houston phản hồi khá nhanh và gửi metadata của 6 triệu email qua đường bưu điện
- Yêu cầu gửi đến Seattle sau đó phát triển thành một vụ việc phức tạp hơn nhiều
Yêu cầu ban đầu gửi đến Seattle
- Ngày 2/4/2017, người yêu cầu gửi tới bộ phận Seattle IT yêu cầu metadata của toàn bộ email trao đổi trong năm 2017 qua các địa chỉ email thuộc sở hữu của Seattle
- From address
- To address
- bcc addresses
- cc addresses
- Time
- Date
- Về mặt kỹ thuật, người yêu cầu cho rằng đây là kiểu yêu cầu có thể xử lý bằng một lệnh PowerShell một dòng, nhưng về mặt chính sách thì thường sẽ vấp phải phản ứng mạnh
- Phản hồi đầu tiên của Seattle cho biết trong 90 ngày gần nhất có 5,5 triệu email được gửi từ địa chỉ
seattle.govvà 26,8 triệu email được nhận, nên có rất nhiều hồ sơ cần rà soát trước khi chia sẻ - Người yêu cầu giữ nguyên yêu cầu cho toàn bộ khoảng 32 triệu bản ghi, cho rằng vì chỉ yêu cầu metadata chứ không phải nội dung nên khối lượng rà soát đáng lẽ phải nhỏ hơn đáng kể
Ước tính chi phí 33 triệu USD
- Khi viết lại nội dung yêu cầu, Seattle dường như đã dùng cách diễn đạt làm thay đổi phạm vi ban đầu
- Yêu cầu gốc chỉ giới hạn ở metadata, nhưng câu chữ được viết lại lại giống như bao gồm cả nội dung email
- Người yêu cầu nói không rõ vì sao lại có thay đổi đó
- Seattle IT ước tính mỗi email cần từ 30 giây đến 2 phút để rà soát, và toàn bộ công việc có thể tiêu tốn khoảng 320 năm công sức nhân viên cùng 33 triệu USD tiền lương
- Người yêu cầu nhận xét rằng các yêu cầu hồ sơ công khai lớn thường bị từ chối với lý do “quá tải”, nhưng mức ước tính chi phí ở quy mô này là rất hiếm
- Chi phí lưu trữ cũng được nêu riêng
- Seattle cho rằng dữ liệu được yêu cầu có thể lên tới 8–10TB và có thể cho tải xuống bằng cách dựng một máy chủ FTP
- Theo mô hình chi phí nội bộ, thành phố có thể thu 2.480 USD mỗi năm cộng 2,11 USD mỗi GB; nếu là 10TB thì tổng chi phí mỗi năm sẽ là 21.606,40 USD
- Người yêu cầu đem so sánh với bản dump metadata email của Houston chỉ nặng 1,2GB, và việc Seattle khi đó dùng Amazon S3 để lưu dữ liệu cho các yêu cầu hồ sơ công khai
- Giá S3 khi đó là 0,023 USD mỗi GB
- Seattle không đóng yêu cầu ngay mà hỏi có muốn tiếp tục hay không; người yêu cầu hỏi vào ngày 29/5 là sẽ nhận được bao nhiêu hồ sơ nhưng không được trả lời
Rút lại ước tính chi phí và đợt đầu 1,25 USD
- Ngày 5/6, Seattle thừa nhận ước tính chi phí ban đầu là sai và yêu cầu 1,25 USD cho đợt hồ sơ đầu tiên, gồm bản ghi của hai ngày 1/1 và 2/1 trong giai đoạn ba tháng
- Thành phố giải thích rằng tệp được cung cấp là bảng tính Excel chỉ chứa metadata được yêu cầu, không có nội dung email nên không cần rà soát và có thể cung cấp nhanh hơn nhiều so với con số 320 năm trước đó
- Người yêu cầu hiểu việc bắt phải gửi một tấm séc riêng cho mỗi hai ngày là cách khiến yêu cầu trở nên khó khăn có chủ ý, nên đã gửi trước 14 tấm séc
- 13 tấm đầu mỗi tấm khoảng 1,25 USD
- Sau đó Seattle không còn yêu cầu thêm các khoản thanh toán lẻ riêng biệt nữa
- Trong hai tháng tiếp theo không có nhiều cập nhật; sau khi đổi tiền toàn bộ séc, Seattle tạo tài khoản trên cổng hồ sơ công khai cho người yêu cầu
Vụ rò rỉ quy mô lớn lộ ra trên cổng GovQA
- Ngày 22/8, khi người yêu cầu thêm lại tài khoản email đó vào điện thoại, họ nhận ra yêu cầu đã được hoàn tất
- Trên cổng yêu cầu hồ sơ công khai của Seattle có khoảng 400 tệp sẵn sàng tải xuống, tổng cộng chứa metadata của khoảng 32 triệu email
- Vấn đề lớn nhất là 256 ký tự đầu của mọi email cũng được kèm theo
- Các tệp có lẫn những thông tin sau
- tên người dùng và mật khẩu
- số thẻ tín dụng
- số an sinh xã hội và bằng lái xe
- điều tra cảnh sát đang diễn ra và báo cáo bắt giữ
- nội dung tin nhắn liên quan đến ngoại tình
- điều tra của FBI
- cảnh báo Zabbix
- Người yêu cầu cho rằng đây là một bộ dữ liệu khổng lồ chứa đầy thông tin riêng tư, và rất có thể đã vi phạm nhiều đạo luật, bao gồm Privacy Act of 1974 và các luật của bang Washington về hồ sơ công khai
- Khó xác định nguyên nhân chính xác, nhưng người này cho rằng việc viết lại nội dung yêu cầu cùng lúc nhân viên phụ trách hồ sơ công khai ban đầu đi nghỉ có thể đã làm đứt gãy liên lạc
Nêu vấn đề và phản ứng ban đầu của Seattle
- Người yêu cầu trả lời với hy vọng Seattle tự nhận ra sai sót, nói rằng hồ sơ được cung cấp không khớp với yêu cầu ban đầu và chứa nhiều thông tin hơn rất nhiều so với những gì đã yêu cầu, nên đề nghị rà soát lại
- Seattle trả lời rằng thông tin được yêu cầu nằm ở các cột cụ thể trong báo cáo, và vì đây là hồ sơ được tạo từ báo cáo hệ thống nên không thể giới hạn chỉ theo các trường được yêu cầu
- From address ở cột J
- To address ở cột K
- bcc address ở cột M
- cc address ở cột L
- Time and date ở cột R
- Seattle cho rằng họ không có nghĩa vụ tạo ra hồ sơ mới vốn chưa tồn tại, và vì đã cung cấp toàn bộ hồ sơ phản hồi cho yêu cầu nên xem như yêu cầu đã kết thúc
- Khi người yêu cầu nêu cụ thể các thông tin bị lộ và nói sẽ báo vụ việc lên Washington Office of Privacy and Data Protection, Seattle thừa nhận đây là một sai sót bất cẩn
- Seattle tạm dừng quyền truy cập GovQA để điều tra nguyên nhân và thông báo sẽ cung cấp hồ sơ đã chỉnh sửa qua GovQA vào tuần sau
- Đồng thời, thành phố yêu cầu người nhận không rà soát, chia sẻ, sao chép hay sử dụng các hồ sơ đó
Cuộc gọi với CTO và Chief Privacy Officer
- Sau đó, thông qua những người trong Slack Open Data của Seattle, người yêu cầu tham gia một cuộc gọi hội nghị có CTO và Chief Privacy Officer của Seattle
- Cuộc gọi bàn về chuyện gì đã xảy ra và nên xử lý các hồ sơ này ra sao
- Trong lúc người yêu cầu hỏi liệu có được giữ lại các email hay không thì kết nối Internet bị rớt; khi kết nối lại khoảng 10 phút sau, không khí cuộc gọi đã thay đổi
- Seattle đưa ra các điều kiện sau
- xóa toàn bộ tệp
- thuê Kroll quét ổ cứng và xác nhận việc xóa
- nếu đồng ý với 1 và 2 thì sẽ được miễn trừ trách nhiệm pháp lý hoàn toàn
- Người yêu cầu không đồng ý và sau đó hai bên chuyển sang để luật sư làm việc với nhau
Sức ép pháp lý và xác nhận xóa dữ liệu
- Sau cuộc gọi, luật sư của người yêu cầu liên hệ với luật sư phía Seattle, và theo mô tả thì Seattle dường như tiếp cận vụ việc theo hướng xem xét các cáo buộc liên quan đến Computer Fraud and Abuse Act
- Người yêu cầu cho rằng cách xử lý đó là vấn đề, vì chính Seattle đã gửi số thông tin này, nhưng cuối cùng vẫn xóa các tệp
- Trong khoảng một tháng sau đó, phần lớn trao đổi diễn ra giữa luật sư hai bên
- Người yêu cầu đề xuất một bản khai giải thích diễn biến, cách xóa tệp và cách xác minh việc xóa
- Seattle nhìn chung đồng ý với bản khai nhưng yêu cầu thêm các biện pháp bảo đảm, như chạy bash script để ghi đè không gian đĩa chưa dùng bằng các bit ngẫu nhiên
- Cuối cùng, người yêu cầu chạy
zerofreevàfstrim, và Seattle chấp nhận bản khai - Sau đó không còn thêm các đe dọa pháp lý nào nữa
Truyền thông bên ngoài và thông báo của Seattle
- Khoảng một tuần sau cuộc gọi, một nhân viên của thành phố Seattle đã báo tin vụ việc này cho KIRO7 của Seattle
- Cuộc điều tra của KIRO7 cho thấy Seattle khi đó vẫn chưa thông báo về vụ rò rỉ, dù đây là bước cần thiết theo luật yêu cầu hồ sơ công khai của bang Washington
- Chỉ sau cuộc điều tra của KIRO7, Seattle mới thông báo cho nhân viên về vụ rò rỉ email
- Bài liên quan được đăng tại KIRO7
- Một tuần sau, bài của Crosscut đưa tin chi tiết hơn, bao gồm cả lịch sử của bộ phận Seattle IT
- Ngày 19/1, CTO của Seattle là Michael Mattmiller từ chức; người yêu cầu nói khó biết việc này có liên quan đến vụ rò rỉ email hay không, nhưng xét về thời điểm thì đáng được nhắc tới
Cung cấp metadata cuối cùng
- Từ ngày 26/1/2018, Seattle bắt đầu cung cấp theo từng phần đúng phần metadata email đã được yêu cầu ban đầu
- Tính đến thời điểm bài viết, đã có 27 triệu bản ghi metadata email được cung cấp
- Hai đơn vị chưa cung cấp metadata là Police Department và Human Services
- Dữ liệu thô có thể tải từ bộ dữ liệu trên Kaggle
- Bộ dữ liệu vẫn còn những yếu tố khiến việc xử lý và phân tích trở nên khó khăn
- lẫn
triple quotes, dấu chấm phẩy, dấu phẩy nên rất lộn xộn - có hàng triệu cảnh báo hệ thống
- liên lạc giữa các địa chỉ
seattle.govcó hai bản ghi metadata khác nhau cho cùng một trao đổi
- lẫn
- Người yêu cầu đang làm một proof of concept để khai thác dữ liệu này trong bối cảnh luật hồ sơ công khai, và đã trực quan hóa metadata của một ngày bằng Gephi
- layout là Yifan Hu
- lọc với k-core tối thiểu 5 và degree tối thiểu 5
- Người này mời những ai có thể hỗ trợ mô hình hóa mạng liên hệ với mình
Tranh cãi lập pháp tại bang Washington và kế hoạch tiếp theo
- Ngày 23/2, giữa đợt metadata đầu tiên và đợt thứ hai, cơ quan lập pháp bang Washington đã tìm cách thông qua SB6617
- SB6617 là dự luật nhằm loại trừ nhiều loại hồ sơ, bao gồm trao đổi email, khỏi nghĩa vụ công khai theo luật hồ sơ công khai của bang Washington
- Dự luật này được Hạ viện và Thượng viện thông qua rồi chuyển tới văn phòng thống đốc chưa đầy 24 giờ sau lần đọc đầu tiên
- Seattle Times đưa tin về việc này trong bài báo
- Văn phòng thống đốc bang Washington nhận hơn 6.300 cuộc gọi, 100 lá thư và hơn 12.500 email, và cuối cùng thống đốc đã phủ quyết dự luật
- Khi người yêu cầu hỏi liệu tranh cãi này có liên quan đến việc chậm giao các đợt metadata hay không, Seattle trả lời là không liên quan; họ đã sửa lỗi từng cản trở tiến độ và sẽ gửi thêm hồ sơ trong tuần đó
- Một tháng sau, Seattle bắt đầu gửi phần dữ liệu còn lại
- Người yêu cầu đang tiếp tục thu thập metadata email của nhiều thành phố khác và dự định viết thêm về những điều cơ bản trong yêu cầu hồ sơ công khai cũng như yêu cầu đối với hồ sơ số
- Bài tiếp theo sẽ nói về vụ kiện đang diễn ra với White House OMB liên quan đến metadata email tháng 1/2017; ở phiên tòa đầu tiên, luật sư phía bị đơn được cho là đã không xuất hiện
1 bình luận
Ý kiến trên Hacker News
Phần thú vị nhất trong câu chuyện này là rủi ro pháp lý khi tiếp tục giữ các hồ sơ bị công khai nhầm
Nếu tác giả không báo cho thành phố rằng “các ông đã công khai thông tin nhạy cảm hơn nhiều so với tưởng tượng”, có lẽ thành phố sẽ mãi mãi không biết lỗi này, và tác giả có thể đã làm bất cứ điều gì mình muốn với dữ liệu đó
Nhưng ngay khoảnh khắc báo cho họ, thành phố biết rằng dữ liệu đã rơi vào tay một người lẽ ra không có quyền truy cập, và nảy sinh câu hỏi pháp lý rằng liệu anh ta có quyền giữ dữ liệu đó hay không
Nếu là tài sản vật lý hoặc tiền, có rất nhiều án lệ về việc phải xử lý thế nào với thứ nhận được do nhầm lẫn rõ ràng. Nếu đại lý ô tô giao nhầm một chiếc xe mới đến sai địa chỉ rồi sau đó biết ra vốn là địa chỉ khác, bạn không thể giữ chiếc xe đó; và nếu 100.000 đô la bị chuyển nhầm vào tài khoản ngân hàng, số tiền đó cũng sẽ bị thu hồi
Nhưng với dữ liệu, tức thông tin, thì sao? Tôi cho rằng có khá nhiều cơ sở pháp lý để có thể bị yêu cầu không được giữ một số loại dữ liệu nhất định, chẳng hạn như bí mật thương mại
Vì vậy, dù đây là một sai lầm nghiêm trọng của thành phố tạo ra tình huống này, việc tác giả quyết định hợp tác theo yêu cầu của thành phố có vẻ là quyết định đúng. Chỉ tiếc là thay vì đền đáp vì anh ấy đã báo vấn đề, thành phố lại cố đe dọa nếu anh ấy không hợp tác để dọn dẹp sai lầm của chính họ
https://about.usps.com/publications/pub300a/pub300a_v04_revi...
https://faq.usps.com/s/article/What-Options-Do-I-Have-Regard...
Cũng có thêm thảo luận về trường hợp nhận hàng bị giao nhầm
https://law.stackexchange.com/questions/17533/if-a-retailer-...
Nếu bạn nghĩ cách họ đối xử sau khi được báo đã không tốt, hãy tưởng tượng không báo thì còn tệ hơn đến mức nào
Và kết luận rằng anh ta có thể tùy ý làm bất cứ gì với dữ liệu đó cũng không nhất thiết đúng. Nếu công khai thêm dữ liệu, rất có thể anh ta đã gặp rắc rối lớn
Ngay cả bây giờ, rốt cuộc việc dữ liệu đã bị xóa vẫn là điều phải tin phần nào vào bản tuyên bố có chữ ký của anh ta
Vì vậy, khá mơ hồ liệu có một khung pháp lý rõ ràng để truy tố chỉ vì tiếp tục giữ các hồ sơ nhận nhầm hay không. Nếu là tài sản vật lý hoặc một số loại dữ liệu được công nhận bản quyền thì lại là chuyện khác
CNTT của chính phủ nổi tiếng là đắt đỏ, và nhiều khi còn là thảm họa. Gần đây tôi phải tạo tài khoản ở một cơ quan địa phương, và qua thử-sai mới phát hiện hai ô nhập ngày trong biểu mẫu web yêu cầu hai định dạng khác nhau
Cuối cùng tôi nhận được thông tin đăng nhập nhưng không hoạt động; nghĩ rằng chắc là vấn đề mật khẩu nên bấm đặt lại thì gặp lỗi 404
Người phụ trách rất lịch sự, nhưng phía cơ quan phải đặt lại tới ba lần tôi mới đăng nhập được
Nếu một công ty tư nhân gặp những vấn đề như thế này thì đã phá sản rồi. Còn chính phủ có lẽ sẽ lại thuê thêm một người kém năng lực khác, và người đó sẽ có việc làm suốt đời
Tất nhiên có lẽ cũng chẳng có cách nào buộc nhà thầu đó chịu trách nhiệm cho đúng
Đó là lý do CNTT chính phủ không được tốt cho lắm. Môi trường làm việc tệ hại, và đãi ngộ cũng không tốt so với khu vực tư nhân
Trước đây tôi từng làm nhiều trong lĩnh vực dữ liệu mở, và cũng từng làm ở bộ phận dữ liệu mở của chính quyền một đô thị lớn
Những hành động kiểu này chẳng giúp ích gì cho chính nghĩa đó cả. Nó chỉ củng cố niềm tin rằng dữ liệu mở và yêu cầu công khai thông tin là một sự lãng phí khổng lồ về thời gian và nguồn lực, đồng thời chỉ mở ra rủi ro pháp lý mà không có lý do gì đáng kể
Việc cho rằng metadata email của chính phủ là dữ liệu mở chính đáng cũng khá đáng kinh ngạc. Bạn có nghĩ rằng việc bạn đã gửi email cho chính phủ bao nhiêu lần, có nhận được trả lời hay không, và đã trao đổi với bộ phận nào nên được công khai không? Tôi thì không nghĩ vậy
Nếu họ có metadata của bạn thì được, còn bạn có metadata của họ thì không, đó sẽ là một sự bất đối xứng kỳ lạ
Không phải một hình ảnh phản chiếu hoàn hảo, nhưng nếu OP chứng minh được metadata này mạnh đến mức nào và thúc đẩy việc cả hai phía đều không nên thu thập loại metadata này, thì tôi có thể nghĩ ra một cách sử dụng chính đáng cho những yêu cầu công khai thông tin như thế
Những chuyện như vậy xảy ra liên tục. Tệ hơn nữa là các cấp lãnh đạo, chẳng hạn như chief data officer, thường không được tiếp xúc với báo chí hoặc các tổ chức lân cận vì đội pháp lý. Thực tế tôi từng nghe một CDO nói: “Tôi không thể nói chuyện với anh/chị”
Câu tôi hay dùng về dữ liệu mở là “dữ liệu mở là lời nói dối”. Rốt cuộc không hề có phương tiện pháp lý nào để kiểm chứng rằng một bộ dữ liệu được cung cấp dưới dạng dữ liệu mở có đầy đủ cả theo cột lẫn theo hàng hay không
Rất hiếm khi có giải thích liệu thông tin có bị thiếu hay không, và vì sao lại thiếu. Kết quả là công chúng hiểu sai sâu sắc về tình hình thực tế, và không ít trường hợp cố ý làm vậy vì sợ công chúng sẽ hiểu sai dữ liệu
Vì thế cuối cùng phải đi theo FOIA và thậm chí bước vào tranh chấp pháp lý. Có lý do khiến tôi đã phải theo đuổi khoảng 10 vụ kiện FOIA
Tóm lại, dữ liệu mở là tốt, nhưng do thiếu tính nghiêm ngặt và trách nhiệm giải trình nên gần như vô dụng đối với những việc cần chiều sâu
Cả metadata lẫn nội dung đều được bao gồm, và họ hướng dẫn không đưa vào những nội dung nhạy cảm mà bạn không muốn bị công khai
Đọc rất thú vị
Từ góc nhìn của người từng làm quản trị hệ thống ở phía bên kia, tôi gần như hình dung được yêu cầu ban đầu của anh ấy đã được tiếp nhận như thế nào
Như nhiều trường hợp khác, có lẽ họ chỉ đọc một phần yêu cầu và hoảng trước quy mô của nó. Vì vậy trong đầu họ nghĩ rằng anh ấy đang đòi hỏi quá nhiều thông tin, và dưới một tiền đề sai lầm, có thể đã cười nhạo người đó suốt mấy ngày bên máy nước uống
Cuối cùng, có lẽ ai đó nhận ra sự hiểu lầm, rồi mắc sai lầm chết người là xuất ra các header được cắt từ giá trị hard-code thay vì parse header email
Và chỉ sau khi anh ấy chỉ ra vấn đề này, họ mới bắt đầu nghiêm túc với anh ấy
Tôi không nói rằng tổ chức IT phải luôn cúi mình trước mọi yêu cầu, hay phải giữ lịch sự ngay cả khi bị ngược đãi thật sự
Nhưng những lời đàm tiếu độc hại bên máy nước uống không phải là chuyện đó. Đó đúng nghĩa là xúc phạm trí tuệ của người khác, hoặc tận hưởng nỗi khổ của người khác, đặc biệt trong bối cảnh họ đang có quyền lực đối với người dùng
Chuyện này làm tôi nhớ đến Assessor của quận chúng tôi từng dọa gọi cảnh sát chỉ vì tôi nói rằng mình muốn dữ liệu công
Họ còn cố tính thêm hàng nghìn đô la cho những tài liệu mà lẽ ra chỉ được thu chi phí sao chép hồ sơ, cùng nhiều chuyện khác nữa
Làm việc với các cơ quan công quyền đúng là vui thật
Ở châu Âu, một yêu cầu như vậy gắn với thông tin liên quan đến con người, tức là ai đã liên hệ với ai vào ngày giờ nào
Việc lưu trữ, chứ chưa nói đến xử lý, những thứ này chỉ được phép khi có nhu cầu cần biết
Ngay cả nếu cố lập luận rằng công chức hành động thay mặt Seattle không còn là cá nhân nữa thì đó đã là một cách diễn giải gượng ép; mà ngay cả trong trường hợp đó, mọi địa chỉ email ngoài miền của chính quyền Seattle vẫn hoàn toàn là vùng cấm nếu không có lệnh tòa, lý do, và điều kiện là điều tra viên hình sự
Ôi, quyền riêng tư
Và các thành phố vẫn thường xuyên công khai thông tin cá nhân như không có gì. Địa chỉ nhà riêng hay chủ sở hữu bất động sản trong thành phố là đối tượng của hồ sơ công khai, và thành phố chẳng thấy có vấn đề gì khi trao tên và địa chỉ cho bất kỳ ai yêu cầu
Địa chỉ email có mức độ rủi ro thấp hơn nhiều
Việc công dân phải có khả năng kiểm tra chính phủ đang làm gì là hợp lý. Đáng tiếc là chính phủ ghi lại quá nhiều thứ, và đôi khi tôi ước gì họ đừng ghi, và càng tốt hơn nếu những hồ sơ đó không thuộc diện công khai
Nếu bạn nghĩ yêu cầu này là tệ, nên tìm hiểu lịch sử của LexisNexis. Mảng kinh doanh cốt lõi của họ là yêu cầu dữ liệu, gom vào một cơ sở dữ liệu, rồi cho phép chính phủ Mỹ kiểm tra lý lịch bất kỳ ai mà họ biết lờ mờ
Trước đây cũng từng có một trang tên masscorruption, tôi nhớ là do một người bị ám ảnh với chính quyền một hạt ở Massachusetts vận hành. Anh ta đã gửi yêu cầu FOIA đối với mọi tệp ảnh trên máy tính để bàn của chính quyền, thực sự nhận được chúng, rồi công khai các ảnh cá nhân của nhân viên vốn không nên được lưu trên máy tính chính phủ
Ở nơi tôi làm việc, mỗi khi thêm nhân viên chính phủ vào ô người nhận, Outlook sẽ hiện một banner rằng thông điệp đang soạn có thể thuộc diện FOIA. Đặc biệt ở chính quyền địa phương, bạn thật sự không biết điều gì sẽ khiến người ta hành động và họ sẽ quan tâm đến gì
Có vẻ tác giả nhìn “siêu dữ liệu” theo một cách hoàn toàn khác
Theo tôi, siêu dữ liệu sẽ là “số lượng email xấp xỉ”, nếu có thể thì là “khối địa chỉ”, “khung giờ được lấy trung bình rộng”, có lẽ là “các danh mục rất mơ hồ”
Ai gửi, gửi cho ai, ai nằm trong Bcc và Cc thì không phải siêu dữ liệu theo tiêu chuẩn của tôi
Theo luật, hồ sơ về mọi hành động và trao đổi phải được lưu giữ, và bất kỳ ai cũng có thể xem
Nói nghiêm ngặt thì không được dùng tài nguyên chính phủ cho liên lạc riêng tư, và về mặt pháp lý cũng không được dùng phương tiện liên lạc riêng cho công việc công
Ngoài trọng tâm của bài viết, tôi thật sự tò mò: có nhiều người có thể gọi ngay “luật sư của tôi” đến vậy sao?
Trong bài, Seattle được mô tả như thể họ định theo đuổi cáo buộc theo Computer Fraud And Abuse Act (CFAA) đối với thông tin chính họ đã gửi, nên tác giả nói đã để luật sư của mình liên hệ với luật sư phía bên kia
Vì ở các khu vực tài phán tôi biết, khi yêu cầu bị từ chối hoặc bị đòi khoản phí mà người yêu cầu cho là vô lý, kiện tụng trên thực tế là biện pháp khắc phục chính
Khi còn nghi ngờ, tốt hơn là tiếp tục làm việc với người đã biết tình huống của mình
Ví dụ, tôi từng gặp một số vấn đề ở căn nhà thuê trước đây, và trong quá trình đó đã tham gia Mieterschutzbund, một hiệp hội bảo vệ người thuê nhà. Thông qua đó, tôi có thể được chuyên gia của hiệp hội tư vấn 1 giờ, và cũng có thể được luật sư chuyên về luật thuê nhà tư vấn 1–2 giờ
Quy trình này thường chỉ mất 1–2 ngày, nên về cơ bản tôi có một luật sư thuê nhà ở trạng thái sẵn sàng
Đổi lại, tôi sửa hệ thống điện dùng dây nhôm ở nhà người bạn đó
Bản lưu trữ: https://web.archive.org/web/20231024164822/https://mchap.io/...
Liệu yêu cầu cung cấp các thông tin sau về tất cả email đi và đến từ địa chỉ email thuộc sở hữu của Seattle trong năm 2017 có thật sự là một yêu cầu hợp lý mà chính phủ phải phản hồi không?
Điều này chẳng phải phơi bày rất nhiều thông tin riêng tư của nhân viên chính phủ và những người giao tiếp với họ sao? Bài viết và luật dường như xem đây là chuyện hoàn toàn bình thường, nhưng với tôi thì trông rất kỳ lạ
Chẳng hạn, nó có thể tiết lộ thời điểm chính xác mọi người ra vào văn phòng, thông tin nghỉ phép của mọi nhân viên, các mối thân quen hay quan hệ không được giải thích bằng sơ đồ tổ chức hay phân chia nhóm, thậm chí cả manh mối liên quan đến điều tra hình sự
Nếu có thể suy ra nhiều thứ đến vậy, tôi nghi ngờ liệu có thật sự nên gọi nó là siêu dữ liệu hay không
Nhân viên giấy tờ chỉ biết gây cản trở? Có. Mù máy tính? Có. Đổ lỗi sai lầm của mình cho người yêu cầu? Có. Tất cả cộng lại? Vô giá