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

Brad Kemper wrote:
>  The way that fonts are different from images is that downloading a
>  few fonts, in order to have closer fidelity to the design, would be
>  much more bandwidth-intensive than the typically small, compressed
>  graphics used for similar purpose (the purpose being fidelity to the
>  design, such as in backgrounds, etc.). Feel free to correct me if I
>  am wrong about comparative file sizes, as I had posed that as a
>  question in my previous e-mail and only got arguments in reply.

Yes, I’ve considered this and note that you have a point.

Brad Kemper wrote:
>  So, given that the use case for the spec can have such a large
>  deleterious effect on bandwidth use, I thought this would be a good
>  place to ask if this is being addressed, and proposed an
>  implementation detail that might alleviate the potential problem and
>  make the CSS feature more useful. I would like to use the feature,
>  but I have concerns about it, and I thought it would be OK to discuss
>  the technical aspects of those concerns here. I know it strays from
>  the technical discussion of the spec itself, but it seems to have a
>  bearing on it.
>
>  If there was a way to safely share bandwidth-intensive resources
>  amongst multiple sites and domains, then JavaScript libraries would
>  likely benefit from using a similar mechanism, but that would be
>  beyond the scope of this discussion list.

The only safe solution that I can think of at the moment is to have the 
files in a central repository at a single URI, but that would be a 
bandwidth cost burden on whoever hosts the repository.

Additionally, you could have a less reliable solution where a style 
sheet author sets a flag that shows their willingness to allow fonts 
sourced from |@font-face| rules to be used in font name only calls. The 
author would, of course, be responsible for the risks. You could also 
have a second, sharing flag that could be used to prevent/allow your 
fonts to be used by authors who set the previously mentioned flag.

Brad Kemper wrote:
>  Another way that fonts are different is that the "font-family"
>  attribute does not base what it displays upon a URI. As specified, if
>  the font is available, it can be used, wherever it came from
>  originally. By itself, it does not say where the resource comes from,
>  unlike "background-image", for instance. Unlike font-family, you
>  can't have an external resource to use in "background-image" without
>  specifying where it is to be downloaded from. Further, the
>  @font-face spec does not restrict the downloaded font from being
>  available to other sites, only from being shared with other
>  applications. Other than some descriptors that indicate what values
>  it can be used with, @font-face does not restrict its availability
>  except that "downloaded fonts should not be made available to other
>  applications". The word "applications" is not defined, but I take it
>  to mean software programs outside of the UA.

Yes, I am aware of this. Keep in mind, however, that the specification 
currently has W3C Working Draft status and is not definitive since it’s 
subject to change. The question remains as to whether or not fonts 
called via |@font-face| should be available by name reference only.

Brad Kemper wrote:
>  The spec says that the font "downloaded fonts should not be made
>  available to other applications". You said that it also should not be
>  made available to other sites, which is stricter than what the spec
>  says.The font-family property picks a font from a list based on what
>  is available for each character. It doesn't say what it is that
>  makes the font available. I see nothing in the spec that would
>  prevent a UA from making a font downloaded via @font-face available
>  to all other Web pages **in the same application**.

Again, this is largely irrelevant since the spec is a draft and we’re 
still discussing its merits. I think that you have made the point though 
that the phrase “other applications” needs clarification.

Brad Kemper wrote:
>  Well if that is true, then I guess my idea wouldn't work then. Are
>  you sure it is? I would think that you could query its file size in a
>  theoretical new HTTP header to see if it exactly matched, and that
>  would be something pretty precise. Font files that are downloaded
>  with sizes that don't match their claims are not allowed to be shared
>  between pages with different locations for the same supposed file.
>  That could be written into the spec.

File size is not an adequate indicator of identity. For example, if 
you’ve ever used a download application, you may note that some of them 
have the ability to reserve space for files being downloaded by creating 
placeholder files of matching file size but filled with filler content. 
Thus, you have two files of identical size but that are not the same file.

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. Unfortunately, I 
don’t know much about encryption, but I would imagine that if you used 
that, you would have to give every client the a single, public 
encryption key to decrypt the header and that would render the 
encryption useless. Of course, I could be totally wrong since, again, I 
don’t know much about encryption.

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”.

Received on Wednesday, 16 April 2008 08:08:36 UTC