- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 7 May 2010 12:45:08 -0700
- To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
- Cc: Matt Colyer <matt@typekit.com>, Erik van Blokland <erik@letterror.com>, "www-font@w3.org" <www-font@w3.org>
On Fri, May 7, 2010 at 11:35 AM, Levantovsky, Vladimir <Vladimir.Levantovsky@monotypeimaging.com> wrote: > On Friday, May 07, 2010 12:08 PM Tab Atkins Jr. wrote: >> >> On Fri, May 7, 2010 at 6:59 AM, Levantovsky, Vladimir wrote: >> > Sorry for a delayed response. The reason I proposed to consider >> adding >> > checksum is because the WOFF file contains extended and private >> metadata >> > fields that are currently can be easily discarded – one can simply >> cut them, >> > zero-out related offset/length values in the WOFF header and modify >> the WOFF >> > length. I realize that adding checksum isn’t going to be a strong >> protection >> > against willful modifications, the same could be done with the >> checksum >> > present, but it would require a bit of an effort (to write the code >> to >> > recalculate the checksum). >> >> I believe that, by the time people are reaching into the file to cut >> out tables and modify several values, recalculating a checksum is >> trivial. The operations and abilities required to do so are basically >> the same. >> > > Well, the key difference here is that I can discard metadata fields and zero-out their respective offset/length values using any HEX editor with no efforts. Recalculating a checksum does require writing a piece of code. Anyone who knows enough to use a hex editor like that, though, can certainly write the code. The extra knowledge/effort that is required to handle the checksum is so trivial as to be nonexistent. ~TJ
Received on Friday, 7 May 2010 19:46:00 UTC