Re: WebFonts WG discussions

On Fri, May 7, 2010 at 9:22 AM, Jonathan Kew <jonathan@jfkew.plus.com>
 wrote:

> On 7 May 2010, at 17:08, Tab Atkins Jr. wrote:
>
> > On Fri, May 7, 2010 at 6:59 AM, Levantovsky, Vladimir
> > <Vladimir.Levantovsky@monotypeimaging.com> 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).
>

Ahh, now I understand what you want to do. What I think you want is
cyptographic file signing (like the DSIG table, which didn't ever really
take off). http://www.microsoft.com/typography/otspec/dsig.htm

That way a WOFF file could be guaranteed to be unmodified by the original
author and no one (unless they got your private key) could properly resign
the file (but a checksum as previously pointed out could be easily
recalculated).

However this would require alot of effort to create a web of trust for
foundry certificates. Assuming all of this did work, what should happen if a
file wasn't properly signed? What should happen if it was signed but not by
a trusted entity?

I think the most difficult part of this is creating a user experience that
effectively used the signing information without causing a disruption to the
average web user. The Firefox 3 SSL warning page has had to deal with
similar issues
http://www.pcworld.com/businesscenter/article/150215/debating_the_firefox_ssl_certificate.html

Thoughts?
-Matt

On Fri, May 7, 2010 at 10:03 AM, Matt Colyer <matt@smallbatchinc.com> wrote:

> On Fri, May 7, 2010 at 9:22 AM, Jonathan Kew <jonathan@jfkew.plus.com>wrote:
>
>> On 7 May 2010, at 17:08, Tab Atkins Jr. wrote:
>>
>> > On Fri, May 7, 2010 at 6:59 AM, Levantovsky, Vladimir
>> > <Vladimir.Levantovsky@monotypeimaging.com> 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).
>>
>
> Ahh, now I understand what you want to do. What I think you want is
> cyptographic file signing (like the DSIG table, which didn't ever really
> take off). http://www.microsoft.com/typography/otspec/dsig.htm
>
> That way a WOFF file could be guaranteed to be unmodified by the original
> author and no one (unless they got your private key) could properly resign
> the file (but a checksum as previously pointed out could be easily
> recalculated).
>
> However this would require alot of effort to create a web of trust for
> foundry certificates. Assuming all of this did work, what should happen if a
> file wasn't properly signed? What should happen if it was signed but not by
> a trusted entity?
>
> I think the most difficult part of this is creating a user experience that
> effectively used the signing information without causing a disruption to the
> average web user. The Firefox 3 SSL warning page has had to deal with
> similar issues
> http://www.pcworld.com/businesscenter/article/150215/debating_the_firefox_ssl_certificate.html
>
> Thoughts?
> -Matt
>
>
>
>