Re: Web font linking progress summary

On Fri, Jul 10, 2009 at 2:59 AM, Mikko
Rantalainen<mikko.rantalainen@peda.net> wrote:
> Dirk Pranke wrote:
>> The three concrete requirements I've seeming heard from the foundry
>> representatives are:
>>
>> 1) A solution MUST optionally prevent casual
>> cross-linking/deep-linking (perhaps solved by CORS, also solved by EOT
>> w/ root strings),
>> 2) A solution MUST optionally prevent casual user download (which CORS
>> doesn't address but maybe EOT + root strings do)
>> 3) A solution MUST optionally prevent trivial interop between web
>> fonts and desktop fonts (which EOT and the other variants do address,
>> at least until EOT gets baked into the O/S)
>
> Could you provide references to relevant messages (you can link to
> individual messages at http://lists.w3.org/Archives/Public/www-font/)?
>

Gah :) I knew someone would call me on this. I will attempt to pull
together my sources and post them, but in the meantime I will try to
answer your other questions.

> If I'm understanding this list of requirements correctly, all browsers
> are required to implement all these features but it's up to the authors
> if they choose to use those features? I believe that that list cannot be
> implemented by browser vendors.

I think you are right. I have heard these requirements requested by
different parties
in this forum; I do not believe they are all mutually compatible, and
if we are to ever
get  a single solution, some will need to be mutated/abandoned/compromised.

> What does the requirement 2) mean in concrete terms? How would such
> "prevention" work? Are foundries in fact asking for a DRM system ("The
> user MUST be able to use the font data to render the page but user MUST
> NOT be able to download and save the data as a local file")?

Good catch. I was not clear about this, which means it completely fails
my "concrete" definition. I think I meant that the solution would
prevent a user from
pirating a font by simply downloading it from one website and then
uploading it to
another (which is the easiest way to defeat CORS as a protection scheme).

A different requirement would be to prevent download completely, which would
certainly be a form of DRM and be practically impossible to boot.
While some might
ideally like this, I've not seen anyone seriously request it.

> Any mechanism that resembles a DRM is out of question (Mozilla has
> stated that they are not willing to implement such system):
> http://lists.w3.org/Archives/Public/www-style/2008Nov/0254.html

I have heard this, at least for some definition of DRM. I am not sure which
definition Mozilla is using, but I haven't gone back and read that
thread yet. I will
try to include it in the annotated revision to come.

>
> Do you think that EOT Lite
> (http://blog.fontembedding.com/post/2009/06/29/Revised-Web-Fonts-Proposal.aspx)
> would be acceptable to font foundries? It doesn't implement 1) or 2) above.

Not being a foundry representative, I wouldn't want to put words in
their mouths. Not having
the revised proposal fresh in my mind to compare against this list, I
don't know. More
generally, I haven't yet considered how any of the proposed solutions
on the table stack up
against this list of requirements.

-- Dirk

(not speaking on behalf of Chromium)

Received on Friday, 10 July 2009 21:00:17 UTC