Encrypted workloads no longer reveal their unencrypted size
The readable header of a Level 1 or Level 2 workload included the exact size of its unencrypted content. New encrypted builds leave that out; the real values are kept inside the encrypted index, where only a reader with the key can see them.
Every .ee workload starts with a short header that is never encrypted, because
a reader needs it to find the encrypted parts. For encrypted workloads, that
header also recorded:
- the exact size of the content before encryption
- how many blocks it was split into
- how many files it contained
None of these needed a key to read. Together with the file’s own size, they also revealed how well the content compressed.
Level 1 and Level 2 builds now write zero for those fields. The real values are still there, inside the encrypted index. The header keeps the compressed size, which is about the same as the file size anyone can already see.
Level 0 workloads are unchanged. Their content is public, and the real figures stay useful for tooling.
Rebuild to get the new header. Workloads built before this change keep their original header until they are rebuilt and redeployed. Nothing else is needed: the file layout hasn’t changed, so existing and new workloads are read the same way.