Re: [css3-webfonts] Proposal-in-progress for cross site font sharing [was "Downloaded fonts should not..."]

On Apr 17, 2008, at 1:28 AM, Patrick Garies wrote:

>> 1. Site A has a font that you've never come across before,
>> "font_a.ttf". At this point, it's name doesn't match anything on your
>> computer, so the UA downloads it. 2. The UA compares the header
>> information to actual font/file information of the already downloaded
>> font and sees that it matches. 3. Site B has a font of the same
>> name. Your UA downloads the header information. It appears to be the
>> same font, so it doesn't bother downloading it again. If Site B is
>> lying in their header, its not going to do them any good, because
>> their font is not being downloaded at that point.
>>
>> or
>>
>> 1. Site A has a font that you've never come across before,
>> "font_a.ttf". At this point, it's name doesn't match anything on your
>> computer, so the UA downloads it. 2. The UA compares the header
>> information to actual font/file information of the already downloaded
>> font and sees that it DOES NOT match. 3. Site B has a font of the
>> same name. Your UA no longer cares about whether the name matches
>> site A's "font_a.ttf", because that one had incorrect header
>> information. So it downloads site B's font and uses it wherever site
>> B tells it to on site B.
>
> The scenario that I had conceived of had Site A hosting the  
> malicious file which would render your solution unworkable if the  
> headers could be duplicated for two files that don’t actually  
> match. [ ...later: "There just needs to be a good proposal to  
> address issues like security." ]

Agreed. I was hearing it being dismissed as impossible before, and I  
believe it is possible to come up with a solution that worked as I  
proposed it, in a manner that made it impossible (or at least very  
difficult and easily reversible) to spoof another site's fonts.

Cross-site font sharing sounds like a scary thing, but in fact if I  
specify a font now, I really don't know where it might have come from.  
If I say that "optima" is the first choice for my "font-family"  
property (ignoring any at-rules for the moment), then I am taking the  
chance that someone might have a font called Optima that is actually a  
joke font full of slanderous sayings or something, and not the Optima  
that many designers are familiar with. What I am proposing is actually  
something that could improve that situation somewhat, in additional to  
being kinder on time spent downloading.

> Maybe your suggestion would work though if the headers contained  
> something like an MD5 number that was verified.

There you go. Now you're thinking along similar lines to what I was  
thinking when I mentioned encryption.

> The problem is, where would these headers go? Would this need a new  
> font format? Could they be applied to existing formats?

Short answers: "TBD", "hopefully not", and "hopefully so".

I think we have enough font formats already; I don't think this would  
be practical or of much interest to implementors or authors if it  
required a whole new font format. I think that is part of the problem  
with "eot".

I was initially imagining that information to be in a new type of HTTP  
header, but that might not be workable (I'm not sure). I am no expert  
on file structures, but I was also thinking that a file can provide  
meta-data to the file system, and that maybe it could be added there  
without requiring the font to be a new format. It seems like Web  
servers have some access to that level of data, and if there is  
already an HTTP header with file meta-data that precedes a download,  
then it could be shoe-horned into that. If that is not a possibility,  
then perhaps a small companion file that the browser checks for would  
be the answer ("myfont.meta" to accompany "myfont.ttf", for instance).

I also imagine the header or companion file or whatever to be in XML  
format (or something similarly easy to read and edit manually), which  
some simple script or software program could generate by examining the  
font. It could also contain a list of domains that the font is allowed  
to be used with, if the author wanted to have such a restriction (in  
case it is a proprietary font for the company, or in order to abide by  
licensing agreements). Something like the xml files that Flash files  
use to allow cross-site sharing.

> Brad Kemper wrote:
>> *Speed:* Also, I would very much like to use @font-face, but if the
>> page fails to render for a couple minutes while a font downloads over
>> a dial-up connection... well, that's just not an option either
>> (which is why I was curious as to if WebKit does any kind of
>> progressive rendering).
>
> I can’t say for sure, but based on Safari 3.1 (525.13) for Windows  
> and a view of the document at <http://www.fonts.info/info/press/font-face-embedding-demo.htm 
> >, it seems to be that WebKit downloads the fonts before rendering  
> text that uses said fonts. I’m on dial‐up here and I note a  
> noticeable delay while the document is loading; it’s completely  
> white, then the smaller text shows up after a delay in downloading  
> resource 4 of 5 (I didn’t verify which file this was), then the  
> large text shows up.

Thanks for testing that. My connection is too fast for me to see a  
noticeable difference. I was hoping it was something like what IE does  
with the EOT files, where the font loads asynchronously, and the page  
is initially drawn without the font, and then updates once the font is  
loaded. But I guess the WebKit implementation of @font-face is not yet  
that optimized (not a criticism of WebKit, as I am very happy they  
have what they do so far).