Re: Data compression APIs?

FYI. despite of a little different point,

http://www.russellbeattie.com/blog/we-need-a-standard-zipped-html-file-format

In fact, most of app packaging are accompanied with encryption and
compression.

Channy
---------------------
Tech Evangelist : Web 2.0, Web Standards, Open Source and Firefox
http://channy.creation.net





2012/1/26 Mark Watson <watsonm@netflix.com>

>  I imagine that any JS "Web Compression" API would be *technically*completely independent of the Web Crypto APIs (not least because it can be
> so, as well as for the reasons below).
>
>  We raised it here because one of the strongest use-cases for a Web
> Compression API would be compression before encryption and so the rationale
> for such a compression API is much stronger when a Web Crypto API exists.
> Absent the Web Crypto API there are fewer and weaker arguments for a Web
> Compression API.
>
>  So the questions to this group are: Does this make sense ? Where should
> it be progressed ? Is there existing work in this area we should look at
> first ?
>
>  ...Mark
>
>
>  On Jan 25, 2012, at 6:55 PM, Richard L. Barnes wrote:
>
>  You're exactly right about the need to compress before encrypting, but
> my inclination would be to say that a crypto API is probably not the right
> place for compression/decompression.
>
> In general, one of the goals of crypto software design is to be
> validatable (e.g., for FIPS 140-2 validation [1]), and the addition of
> unnecessary features within the "crypto perimeter" tends to make that
> validation harder.  For example, Firefox contains a FIPS-accredited crypto
> module [2], so one could imagine that if the bridge to the Javascript API
> were implemented properly, this accreditation might be extended to the
> Javascript layer as well.  This would be more difficult if functions were
> introduced at the Javascript layer beyond what is present in the
> FIPS-accredited module.  (I do note that NSS includes a copy of zlib [3],
> but it's not immediately clear whether that's within the accredited part.)
>
> --Richard
>
>
> [1] <http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf>
> [2] <
> http://support.mozilla.org/en-US/kb/Configuring%20Firefox%20for%20FIPS%20140-2
> >
> [3] <
> http://hg.mozilla.org/mozilla-central/file/8eab8fdaa675/security/nss/lib/zlib
> >
>
>
>
> On Jan 25, 2012, at 8:11 PM, Mitch Zollinger wrote:
>
> In designing the technology that satisfies the use case doc posted
> previously (http://www.w3.org/wiki/NetflixWebCryptoUseCase) it would
> appear that we need to support compression / decompression APIs.
>
>
>  The reason is that for our "MsgSec" protocol, we encrypt every message
> going over the wire and since encrypted data cannot be compressed, the
> compression has to happen before encryption. Therefore standard things like
> HTTP gzip compression will not work.
>
>
>  What we're looking for is something along the lines of:
>
>
>  function compress(data, algorithm)
>
> function uncompress(data, algorithm)
>
>
>  where algorithm is one of the standard ones (gzip, bzip2, etc.)
>
>
>  Is this the right forum for looking at this type of functionality?
>
>
>  Mitch
>
>
>
>
>
>
>
>