Re: [css3-webfonts] Downloaded fonts should not...

On Apr 16, 2008, at 1:07 AM, Patrick Garies wrote:

> Brad Kemper wrote:
>> Maybe there is also a way to encrypt some of the fonts other vitals
>> (font metrics and file info) into a small header file for
>> verification, using a certificate. Then the encrypted header could be
>> compared to the vitals of the font already downloaded to see if it
>> is the same, or if it is a different font. That would tell you if the
>> fonts were exactly the same and would not need to be re-downloaded.
>> If the font vitals did not match what the header claimed, then the
>> font file should not be used as a stand-in for pages that claim to
>> have the same font at a different location.
>
> If header information is plainly accessible, it could easily be  
> copied into a malicious version of the font file; if the information  
> is derived from the font itself, that would entail downloading it.

Well, of course a font will be downloaded if it is ever to be used.  
You have to think about the order of things.

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.

Actually, the encryption part would not even be needed.

> Brad Kemper wrote:
>> Thank you so much for delineating my options. That's not what I was
>> looking for though. I thought we were discussing the technical issues
>> surrounding the permanence and "sharability" of fonts.
>
> My point was that you’re using UA UI issues and user ignorance/ 
> paranoia regarding that UI as an argument to design a specification  
> around and I think that that is a poor idea. The only real issue  
> here is that you’re afraid of scaring off users by referencing a  
> non‐HTTPS URI and, thus, invoking a security dialog and I disagree  
> that that’s enough cause to accept the risks imposed by allowed  
> “sharability”.

You are entitled to your opinion, however wrong it is.  ;)

Actually what I am suggesting is an enhancement that addresses two of  
the areas of greatest concern to people, as revealed in survey after  
survey: speed and security.

Security: Security concerns is always the most common reason people  
give for not using e-commerce and/or online banking. I work for a  
large credit union, and we just are not going to do something that  
causes security alerts to pop up whenever they sign into home banking.  
Maybe for your site it is no big deal, but for us, and many, many like  
us, that just isn't an option if we can avoid it.

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). Our call center would immediately be filled with calls  
from irate members, and my boss would want to know what I was smoking.

However, if a downloaded font could attain permanence in the UA  
without being able to mess up other sites in ways they didn't expect,  
then that would be a huge improvement. How is that not worthy of  
consideration? In that case, a considerable amount of bandwidth would  
be saved throughout the net, a potential speed hit would not have to  
take place more than once per font per person's UA, and authors  
concerned about speed could pick fonts based on their popularity on  
other sites (to avoid the likelihood of forcing a new download) rather  
than just picking from the handful that are common to most OS's.

That seems like a pretty significant gain. You say you don't want to  
accept the risks, but you are unwilling to even explore ideas for  
removing those risks? I think it is worthy of further discussion and  
investigation.