RE: WebFonts WG discussions

The initial checksum idea was triggered by a discussion about same-origin restriction, where an easy way to circumvent it would be to download a WOFF file and re-upload it on a different server. In the course of that discussion I pointed out that doing this with existing metadata intact would immediately expose the license-infringing use, but then I realized that discarding the metadata would eliminate that risk (both extended and private metadata fields are optional) and it is so easy to do with readily available tools.

Hence, it  was the checksum suggestion as way to introduce a mechanism that would be real easy to implement on both the WOFF creation and UA side, yet it would allow to catch a case when WOFF data was tampered with. I do realize it is not a strong protection, that data can be easily modified and the checksum can be recalculated. Like everything else we discussed last summer, I believe it is a "garden fence" philosophy where simple and easy to implement mechanism would be able to stop the majority of infringing uses (and I realize that nothing will stop someone who is a determined infringer).

Regards,
Vlad


From: Matt Colyer [mailto:matt@smallbatchinc.com]
Sent: Friday, May 07, 2010 1:03 PM
To: Jonathan Kew
Cc: Tab Atkins Jr.; Levantovsky, Vladimir; Erik van Blokland; www-font@w3.org
Subject: Re: WebFonts WG discussions

On Fri, May 7, 2010 at 9:22 AM, Jonathan Kew <jonathan@jfkew.plus.com<mailto: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<mailto: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