Đầu tiên tôi đánh giá logic dọn dẹp của Babylon dựa trên sáu đối tượng cuối cùng. Việc đó trông có vẻ hiệu quả. Sau đó tôi nhận ra việc xóa bản thân nó có thể trở thành một phần của mô hình bảo mật.@BabylonLabs_io
Điểm hiển nhiên là giảm dung lượng lưu trữ. Nhưng đó không phải là vấn đề thực sự.
Hành vi ẩn là phân loại (classification). Một payload ứng viên có thể không cần thiết về mặt mật mã, nhưng vẫn quan trọng về mặt vận hành trong một phiên cắt-và-chọn bị gián đoạn, bản sao lưu bị lỗi, hoặc một chuyển đổi trạng thái đang tranh chấp. Xóa nó sớm có thể khiến hệ thống mất đi dữ liệu cần thiết để giải thích điều gì đã xảy ra.
Một rủi ro dọn dẹp là bình thường. Không giao thức nào có thể giữ mọi đối tượng tạm thời mãi mãi.
Nhưng bài kiểm tra thật sự của BABY là kỷ luật vòng đời (lifecycle) so với sự tiện lợi cho người vận hành. Babylon có xóa chỉ sau khi thay đổi trạng thái đã được ghi nhận một cách bền vững (durably) không? Bản kê (manifest) có chứng minh rằng cả sáu phiên bản cuối cùng đều được xác minh đúng và có các bản sao lưu độc lập không? Công việc xóa có thể thử lại an toàn mà không đụng đến một trong số sáu đối tượng đó không?
Tự động hóa thì có giúp ích. Nhưng chỉ khi các quy tắc là bất biến (idempotent) và điều kiện xóa là rõ ràng.
Tôi vẫn đang theo dõi phần “đường biên” khó chịu: điều gì xảy ra khi người vận hành tin rằng việc thiết lập đã hoàn tất, trong khi phân tích lỗi lại nói rằng nó chưa xong?
Với BABY, thu gom rác (garbage collection) không còn là việc “quản lý văn phòng” (housekeeping) nữa. Đó là một quyết định bảo mật bị trì hoãn, và chỉ một nhãn sai có thể xóa nhiều hơn dữ liệu.
#baby $BABY
Điểm hiển nhiên là giảm dung lượng lưu trữ. Nhưng đó không phải là vấn đề thực sự.
Hành vi ẩn là phân loại (classification). Một payload ứng viên có thể không cần thiết về mặt mật mã, nhưng vẫn quan trọng về mặt vận hành trong một phiên cắt-và-chọn bị gián đoạn, bản sao lưu bị lỗi, hoặc một chuyển đổi trạng thái đang tranh chấp. Xóa nó sớm có thể khiến hệ thống mất đi dữ liệu cần thiết để giải thích điều gì đã xảy ra.
Một rủi ro dọn dẹp là bình thường. Không giao thức nào có thể giữ mọi đối tượng tạm thời mãi mãi.
Nhưng bài kiểm tra thật sự của BABY là kỷ luật vòng đời (lifecycle) so với sự tiện lợi cho người vận hành. Babylon có xóa chỉ sau khi thay đổi trạng thái đã được ghi nhận một cách bền vững (durably) không? Bản kê (manifest) có chứng minh rằng cả sáu phiên bản cuối cùng đều được xác minh đúng và có các bản sao lưu độc lập không? Công việc xóa có thể thử lại an toàn mà không đụng đến một trong số sáu đối tượng đó không?
Tự động hóa thì có giúp ích. Nhưng chỉ khi các quy tắc là bất biến (idempotent) và điều kiện xóa là rõ ràng.
Tôi vẫn đang theo dõi phần “đường biên” khó chịu: điều gì xảy ra khi người vận hành tin rằng việc thiết lập đã hoàn tất, trong khi phân tích lỗi lại nói rằng nó chưa xong?
Với BABY, thu gom rác (garbage collection) không còn là việc “quản lý văn phòng” (housekeeping) nữa. Đó là một quyết định bảo mật bị trì hoãn, và chỉ một nhãn sai có thể xóa nhiều hơn dữ liệu.
#baby $BABY
