compression (deflate) before encryption: default expectation (EPUB < 3.1 spec.)

[danielweck]

In the LCP Content Filter implementation, the default fallback (if CompressionMethod metadata does not exist in encryption.xml) is to consider that the resource was not deflated / compressed before it was encrypted:

https://github.com/readium/readium-lcp-client/blob/develop/src/lcp-content-filter/LcpContentFilter.cpp#L68

    uint8_t* checkAndProcessDeflateBuffer(uint8_t* buffer, size_t* outputLen, LcpFilterContext *context) {

        if (context->CompressionMethod() == "8") {
...
//// INFLATE BUFFER
...
        }

        return buffer;
    }

https://github.com/readium/readium-lcp-client/blob/develop/src/lcp-content-filter/LcpContentFilter.cpp#L228

    ByteStream::size_type LcpContentFilter::BytesAvailable(FilterContext *filterContext, SeekableByteStream *byteStream) const
    {
...
                if (context->CompressionMethod() == "8") {
//// USE context->OriginalLength()
...
                }
...
        return byteStream->BytesAvailable();
    }

This seems like a valid assumption based on the EPUB 3.1 specification (where CompressionMethod was first standardised), see: http://www.idpf.org/epub/31/spec/epub-ocf.html#sec-container-metainf-encryption.xml

Streams of data that are compressed before they are encrypted
should provide additional EncryptionProperties metadata to
specify the size of the initial resource (i.e., before compression and encryption),
as per the Compression XML element defined below.
Streams of data that are not compressed before they are encrypted
may provide the additional EncryptionProperties metadata
to specify the size of the initial resource (i.e., before encryption).

However, the default assumption in EPUB 3.0.1 was somewhat different: http://www.idpf.org/epub/301/spec/epub-ocf.html#sec-container-metainf-encryption.xml

When stored in a ZIP container, streams of data must be compressed
before they are encrypted and Deflate compression must be used.

Related ReadiumSDK issue: https://github.com/readium/readium-sdk/issues/162

[danielweck]

In LCP, the compression + encryption rules from the latest EPUB 3.1 specification are used, regardless of the actual version of the ingested EPUB (v3, v3.0.1, v3.1).

So, I would argue that the current implementation of LCP Content Module (decryption) correctly conforms to the EPUB3.1 specification, and implementations of LCP encryption are expected to follow that path too, such that the CompressionMethod metadata in encryption.xml is always generated (SHOULD conformance requirement) when a resource is compressed / deflated before it is encrypted.

In LCP at least, the design is consistent.

Issue closed.

CC @jpbougie