Re: Compressed SVG? (and a couple of announcements)

> Bumping the major version of the table just to get original size in on the other hand, IMO, is excessive.

Below I’d sketched out bumping what’s actually a minor version number. (The “Table version numbers” section of the spec says "When a USHORT number is used to indicate version, it should be treated as though it were a minor version number; i.e., all format changes are compatible extensions.”)

It would still not be a totally compatible extension, of course, since a table version 0–savvy engine will not handle the SVGZ it might see when presented with a version 1 table. This is why I indicate version 0 would then need to be indicated as deprecated in some way. But this would be acceptable given that Firefox’s is the only implementation.

Sairus


From: Behdad Esfahbod <behdad@google.com<mailto:behdad@google.com>>
Date: Wednesday, September 24, 2014 at 6:59 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Cc: Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>>, Robert O'Callahan <robert@ocallahan.org<mailto:robert@ocallahan.org>>, "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: Re: Compressed SVG? (and a couple of announcements)

On Thu, Sep 18, 2014 at 8:08 PM, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:
You’ve never seen (or been attacked by) a Zip Bomb (<https://en.wikipedia.org/wiki/Zip_bomb>) or HTML Decompression Bomb (<http://www.aerasec.de/security/advisories/html-bomb/>).   We (Adobe) have and as such any new file format that we design that involves compression or archiving we incorporate the length to avoid this.   Yes, you are correct, you can find other ways – but having the original length is quickest and best.

Let me put it this way: what would providing the original length in the table allow for (against attacks) that not having them doesn't?  AFAIK what Firefox does when decoding WOFF is to reject the font if any table has its original length greater than some constant (2GB?).  Firefox can do the same by refusing to allocate buffers larger than that size.


As Sairus mentions, we would STRONGLY recommend (and in fact, will push for) this addition.

Works either way for me as long as Firefox is happy with breaking compatibility with existing font format.  Bumping the major version of the table just to get original size in on the other hand, IMO, is excessive.

behdad

Leonard

From: Behdad Esfahbod <behdad@google.com<mailto:behdad@google.com>>
Date: Thursday, September 18, 2014 at 7:01 AM
To: Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>>
Cc: "robert@ocallahan.org<mailto:robert@ocallahan.org>" <robert@ocallahan.org<mailto:robert@ocallahan.org>>, "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: Re: Compressed SVG? (and a couple of announcements)
Resent-From: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Resent-Date: Thursday, September 18, 2014 at 7:02 AM

On Wed, Sep 17, 2014 at 7:43 PM, Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>> wrote:
I think solid security best practices suggest we also add the uncompressed length of each SVGZ doc (see Adobe’s original proposal I pointed to earlier in the thread).

I don't think so.  HTTP Transfer-Encoding doesn't include the original length for example.  I never understood that argument.  Clients can use heuristics to compensate.  For example, a client can allocate an 8kb buffer on stack and try decompressing.  Only if that is not sufficient, they need to do something else.

Another approach would avoid allocating a full decompression buffer completely, by chaining a gzip decompression stream to the XML parsing library, completely obviating this issue.

Note that gzip has a max compression rate of around 1100, so it's not like a 1kb gzip buffer can explode to gigabytes either.

I don't think any action is needed here.  It's convenient to have the original buffer length in case of WOFF, but not needed for any security reason IMO, and certainly not for any reasons other than convenience.

behdad

So it looks like we need an ‘SVG ‘ table with version 1 (current OFF proposal is version 0), with an optional set of uncompressed lengths (perhaps a particular “uncompressed length” can be set to 0 to indicate that its corresponding SVG doc is not compressed). Since such a version 1 table using SVGZ would not be compatible with version 0 engines (Mozilla’s), there would have to be some language indicating version 0 is deprecated in some way or that engines may reject an SVGZ with version 0 due to security reasons. This way, Behdad and others can continue to use SVGZ with version 0.

Sairus

From: Robert O'Callahan <robert@ocallahan.org<mailto:robert@ocallahan.org>>
Reply-To: Robert O'Callahan <robert@ocallahan.org<mailto:robert@ocallahan.org>>
Date: Tuesday, September 16, 2014 at 2:07 PM
To: Behdad Esfahbod <behdad@google.com<mailto:behdad@google.com>>
Cc: Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>>, "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: Re: Compressed SVG? (and a couple of announcements)

On Wed, Sep 17, 2014 at 3:30 AM, Behdad Esfahbod <behdad@google.com<mailto:behdad@google.com>> wrote:
As a concrete proposal, I like to suggest updating the spec to allow SVGZ where SVG is currently accepted, with no other changes.  WDYT?

That sounds OK I guess.

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo
otohoeo ofoioroeo ooofo ohoeololo.